It’s useful to know the distance from the top of a dome to the foundation — the surface distance. The formula for our PCalc plugin works fine for spherical domes that are less than a hemisphere. Turns out it doesn’t work for spherical domes greater than a hemisphere. The formula would “invert” and only give the bottom portion surface distance.
Setting up a Rails development environment to handle subdomains and custom domains is tricky. There are lots of suggestions from editing your /etc/hosts file, custom rack applications to handle CNAMEs, dnsmasq for wildcard domains, and more. All of them are compromises and often caused more problems than they solved. However, there is a decent solution to the problem.
iCloud keychain synchronization is more trouble than it’s worth. With 2-factor authentication on Google it causes no end of trouble as it tries to copy my Mail setup between my Mac Mini and MacBook Air. Additionally, keychain really only works with Safari, but I actually use four browsers — Safari, Chrome, Firefox, and Opera. And finally, iCloud keychain easily exposes passwords on iOS devices. My recommendation, use 1Password and don’t turn on iCloud keychain synchronization on your Macs.
Mavericks Mail broke my favorite method of linking to Gmail. I created a workaround, but it was a poor substitute. Fortunately, today Mavericks mail was upgraded to fix the problem. Now we can go back to the BEST way to set this all up.
A month ago I received an email about my GmailMe mashup of Gmail and MobileMe. This is the set up I’ve used for years to forward Gmail to my MobileMe account so it can handle IMAP duties. Apparently iOS 5 beta won’t allow custom SMTP servers for outgoing mail. This letter spooked me into holding off migrating MobileMe to iCloud. After a lot of messing around I finalized a new set up to use iCloud services and use Gmail as a lightweight (yes, really lightweight) email service.
Ruby guard is an excellent replacement for ZenTest’s autotest. Originally guard would not run all tests unless you told it to. I liked this behavior because it meant running just the test I’m working on until I’m ready to run the whole suite.
We had a working solution to use wildcard domains on the localhost. Using a proxy.pac file and a tiny rack application we could pass any domain into the development environment. It was working great, until we tried switching to Rails3 beta. Whenever we specified a non-standard local domain, the Rails router would strip the query string off the URL. This method is out-of-date. For a far better way please read Rails subdomains, CNAMEs, and crzy.me
Having two methods of identifying the same edition on a CMS — subdomains and CNAMEs — is painful. Yet many websites have advocated this approach. Every request to the application requires multiple checks on the domain to correctly identify the edition. I believe this process developed from the difficulties of dealing with subdomains and domains in the development environment. Recently we found the answer that simplifies the whole system. This method is out-of-date. For a far better way please read Rails subdomains, CNAMEs, and crzy.me.
When we created our CMS we used tried-and-true subdomains to separate editions. SubdomainFu handled the logic of separating editions and it was easy — until we added custom domains. The standard method is to point — via CNAME — the custom domain (www.davesouth.org) to the subdomain (davesouth.example.com). Unfortunately the rails app can’t use SubdomainFu routing. This method is out-of-date. For a far better way please read Rails subdomains, CNAMEs, and crzy.me.
The NeolithicCMS we are writing separates editions by using subdomains. It works great in production. A single entry of *.neotrib.com in the DNS points all subdomains to the same server. But for local development we have to manually edit the /etc/hosts file for each subdomain. After adding a few editions it becomes a royal pain. Short of installing a DNS server, we needed a better solution. +This method is out-of-date. For a far better way please read This method is out-of-date. For a far better way please read Rails subdomains, CNAMEs, and crzy.me.
Managing email is a royal pain. Especially if you read email on more than one device. After buying iPhones last year, Mike and I worked up an excellent system of managing our email on the iPhone, computer and web.
There are several ways to set up a system for Ruby on Rails development. Leopard comes pre-installed with Ruby and Rails and is perfectly fine for most users. For me, however, I kept running into troubles. Trying to do a free standing install of graphic libraries (FreeImage or ImageMagick) proved too painful. I switched back to using MacPorts.
Security is a pain. Too much security gets in the way of productivity. Too little and the world owns your bank account. Finding the right balance is difficult. For me, securing my laptop has proven to be a challenge. Sure, I can lock it down so it requires a drop of blood every time I wake it up, but that’s too painful (and I need the blood). So I found a decent balance that you may want to try.
The new iPhone has the best mail client I’ve ever used on a smartphone. When I first got my iPhone, I immediately connected it to my Gmail account. Unfortunately, Gmail uses POP to download messages. It started sending every single message from my archive — thousands of messages.
What’s worse is the lack of synchronization between my iPhone and the Mail program on my MacBook because of POP. If I delete a message on the iPhone, the message remains on Mail. I needed a better solution and it was Mike who came up with the answer. He suggested using .Mac and Gmail as a Mashup. Here is how it works for me.
I never use the GMail web interface unless I’m on the road. Instead I POP my email into my Apple Mail program. The downloaded email is not erased from GMail (like traditional POP servers). Instead it is stored in the “All Mail” archive along with all my sent messages, too. After a year and a half, I’ve used 2600 MB of my 2800 MB email box (thank you Google).