paul doerwald

Back in November 2009, Liquid Media bought one of the new Mac Mini Servers. We were really excited about it: group chat using iChat server, calendaring, Asterisk, continuous integration, etc., all in a sweet Apple-flavoured package. Since then we’ve had to reinstall the entire operating system 3 times, and essentially all we have is an over-powered file and Asterisk server. I’ve never been so thoroughly disappointed in an Apple product. In fact, I was so disappointed that I wrote Apple a letter about it. Not an email — a letter; you know, the thing that you put in an envelope and stick in the mail.

This is the letter in full:

Apple Canada
7495 Birchmount Road
Markham ON
L3R 5G2

31 March 2010

To Whom It May Concern:

In early November 2009 I purchased the newly released Mac Mini Server with OS X Snow Leopard Server. I was very excited to set this machine up to act as a server for my small web development business. It has failed miserably in this role. I am extremely disappointed in the quality of the OS X Server software.

First, some context: we are a small staff of 5 software developers. We have all been using Macs for many years. We are all reasonably experienced unix administrators and have managed all manner of Linux installs as well as our Apple computers. We are all unabashed Apple fans and have, and will continue to buy Apple products.

However, we all feel that Mac OS X Server falls far below your usual standard of quality. I am writing and mailing a letter, rather than sending an email or even a fax, to underscore the depth of our disappointment in the product. Some of our specific complaints include:

• In order to set up iChat Server, we need to specify an externally addressable hostname and configure DNS. This is impossible because our Internet Service Provider assigns us a dynamic IP. Even if we used the hostname, which right now is an unmemorable blk-138-72-175.eastlink.ca, any name resolution we configure would break as soon as our IP address changes. Thus, running iChat Server, which was one of our core requirements, remains unfulfilled.
• Calendaring in OS X Server is shockingly poor. We are all using Macs on the same network, yet we can’t use iCal on our Macs to create events and invite our colleagues to those events. The only way we have found to invite each other is by logging on to the web interface on the server.
• We have had issues connecting multiple people at the same remote location to our network via VPN at the same time. The issues are still unresolved; our lesson has been to not trust the VPN services.
• When we have successfully connected via VPN, although we are logically on the same network, we cannot see the Mac Mini Server in the list of servers in Finder. The only way to access the server’s files was by choosing “Go to Server” in Finder and manually entering the server’s internal IP address.
• We realized earlier this week that Software Update Services was, for reasons unknown to us, not downloading any Mac OS X updates. Rather than taking advantage of our fast internal network, every one of the 5-person team ended up downloading the update separately.
• There is no way that we are aware of to add new services to the Server Admin tool. For instance, instead of MySQL, we run PostgreSQL. We would like to configure a continuous integration server. We would like to add additional controls to manage web application deployments for our staging environments. We would like to manage our Asterisk phone system. Unfortunately, we can only manage these services from the command line — which is not a problem for us — but it would be nice if we could use the graphical tools that made us choose OS X Server in the first place.

Ultimately, we have spent a great deal of time and effort trying to configure this server, only to end up with little more than an under-used file server. For our Calendaring and Chat services, we have returned to Google Apps. For everything else, an inexpensive Linux PC will do just as well, if not better.

I am therefore writing to ask that you accept the return of and refund the full price of our Mac Mini Server, the AppleCare Protection Plan that we purchased, as well as any costs of returning the machine to you, if applicable. I am including a copy of the receipt in this letter.

I look forward to hearing from you with instructions on how to proceed. The best way for you to reach me is by email at ((hidden)) or by phone at 902-407-3037.

Sincerely,

Paul Doerwald
Chancellor
Liquid Media

enclosure

I’ll keep you up to date on what happens.

At long last, I’ve migrated off of Mephisto on to Jekyll, as much of the Rails community has done. This message serves as a test, more than anything else, but at least now I can start posting again soon.

Although they tell you that Rails (2.3) is ready for Ruby 1.9, the reality is that few of the gems are. On a particular project where we really wanted to use Ruby 1.9's new M17N and I18N functionality, I didn't actually run into too many problems with most of the gems I use, but for one, VERY painful one: the postgres(/pg/ruby-pg) gem.

Interestingly enough, the gems work just fine until you pull some UTF-8 content from the database. The existing database adapters (and mysql is included in this) return that content as encoding ASCII-8BIT (aka BINARY). As soon as you try to show that content on a page that is otherwise encoded UTF-8, you get incompatible character encodings: ASCII-8BIT and UTF-8.

This is definitely a problem with the database drivers, which should be returning the same encoding as the database. This problem hasn't officially been fixed yet, but there has been some effort to that end. For postgres, you'll need to use ruby-pg (rather than postgres or pg, even though they're somehow the same, yet different... if anyone cares to explain...?) along with a patch that's referenced in an excellent ticket on the topic. I know this works on Mac OS X and on Fedora 8. For Windows, YMMV:

# do everything as root (it's just easier this way)
sudo bash

# get rid of the pg if you have it already; you might want to do this for ruby-pg as well
/usr/local/bin/gem uninstall pg

# change to some convenient working directory
cd /usr/local/src
svn checkout http://ruby-pg.rubyforge.org/svn
cd svn/ruby-pg/trunk/ext

# download and install the patch
curl -O http://rubyforge.org/tracker/download.php/3214/12398/25931/4535/pg-m17n3.patch
patch < pg-m17n3.patch
# should respond indicating that all patches successfully applied

# set up an important environment variable
export ARCHFLAGS='-arch i386'

/usr/local/bin/ruby extconf.rb
make
make install

Worked for me. Let me know in the comments if I need to make a change to the instructions above.

Update

It strikes me that if you run into any troubles applying the patch, then these instructions may be out-of-date, and you can probably just go ahead and install the latest gem, assuming it's something higher than 0.8.0.

For a client I needed to set up a sort of staging/development instance. We're a distributed team and in order for us to review each others' work before it's deployed, we need to host it somewhere that's not the production server.

Apparently there's a Capistrano extension for handling this, and there's some good, well-cited documentation out there as well, but it all felt really heavy weight until I found this article.

I love the simplest, most elegant solution, and this approach wins. Now deploying the staging version (off the git staging branch) is as simple as cap staging deploy. If I want the main production branch, I cap production deploy, and I can easily add another branch if I wish. The code (from deploy.rb):

task :production do
  role :app, "192.168.100.1"
  role :web, "192.168.100.1"
  role :db,  "192.168.100.1", :primary => true
  set :branch, "master"
end

task :staging do
  role :app, "192.168.100.2"
  role :web, "192.168.100.2"
  role :db,  "192.168.100.2", :primary => true
  set :branch, "staging"
end

cap staging deploy:migrations, cap production mongrel:cluster:start, etc. all work as expected, and even better yet, if I fall into my old habits of cap deploy I'll get an error which reminds me that I have to specify a deploy target.

Who needs complex capistrano extensions when you have this? I don't think it can get cleaner or simpler!

I've taken over a Rails project whose database is MySQL. While I've grudgingly come to respect MySQL, I still vastly prefer PostgreSQL, largely because I'm more familiar with it. I decided to take the plunge and migrate the project from MySQL to PostgreSQL.

A search for MySQL to Postgres conversion scripts turns up pretty empty, but then it struck me that I can do the conversion using ActiveRecord's schema dumping. The problem with this approach is that AR ignores constraints, foreign keys, etc., but in my case, the data I was migrating used none of those. Then to copy the data, I used MySQL's select into outfile feature and PostgreSQL's copy from file feature. The steps were:

1. I created a postgres database application_development and put it in the test section of config/database.yml.
2. I dumped the current schema by running rake db:schema:dump.
3. I loaded that schema by running RAILS_ENV=test rake db:schema:load.
4. Grant your MySQL user file privileges. Log on to MySQL as root: mysql -u root, and then do the grant: grant File on *.* to 'paul'@'localhost'; — bear in mind that this may introduce a significant security risk in a production system; be safe and revoke the privilege when you're done.
5. Create a /dumps directory and give it 777 (world write) permissions.
6. For each table (users, profiles, friendships, etc.) in MySQL, run: select * into outfile '/dumps/users.sql' from users;.
7. In Postgres, load the dumps. You'll have to do this as a postgres superuser, or you'll have to copy from STDIN. copy users from '/dumps/profiles.sql';.

From here, I updated my config/database.yml and restarted my mongrels, and everything worked perfectly! I'm going to start adding database constraints now...