t.pitale

Dream Setup: iMac & Macbook Air

2011-10-04T07:50:00-07:00

It has been nearly three years since I last purchased an Apple computer (laptop or desktop) of my very own. For anyone that knows me, this is a very, very long time. Recently, I went all-in and replaced my entire home computing setup, selling my Mac Pro (and previously a 15" Macbook Pro) in order to purchase a new iMac and 11" Macbook Air. I'd like to share my reasoning for this particular pairing, my brief review of both pieces of hardware, and my experiences assembling my dream setup.

I have no qualms that this is an expensive setup. Whatever the reasons that make it worth the money to me will not be covered herein. If you've read this far, you probably don't need convincing anyway.

The Story

My Mac Pro is heavy, it's big, and a lot of times, it's surprisingly slow. I dread moving it to a new apartment. I think the speed issue is even more noticeable in comparison to my work computer, which has an SSD. I have a Macbook Pro at work, and previously had one for personal use. But, traveling with the Macbook Pro when I didn't really need it was a drag (especially through airport security). There's no reason to have two identical computers at home and at work. All in all, too much power in some places, not enough in others, and a nearly complete lack of portability.

Tangent 1: a few months back I wanted a standing desk for home. I looked around at all of the conventional free standing desk only to be aghast at the price, especially for the adjustable variety. Instead, I took a note from my friend and colleague, Jason Garber, and went looking for the pieces to build a standing desk. I accomplished this using shelving from Ikea which bolts to the wall of my apartment, and is extremely height adjustable.

The 11" Macbook Air

Having made this purchase first, I'll review it first, too.

I knew it was coming. I'd read all the rumors. So, within an hour of the announcement, one of Steve Jobs' last announcements, I purchased my 11" Macbook Air. I ordered it with the maximum RAM and CPU, but kept the 128GB SSD. The price for the 256 is still too much to swallow.

Tangent 2: Interestingly, but not surprisingly, my father ordered a similar configuration 13". The race was for delivery was now on. He won. Mostly because mine inexplicable sat in Alaska for 4 days, despite paying for priority shipping.

Screen Size

I actually do all of my coding (Ruby, mostly) on the Air. It's fantastic. The screen size is well worth the portability, especially considering the increased pixel density. I've been using spaces since Leopard and my workflow means I don't need nearly as much single-screen real estate.

Performance

The tests I run perform better on my Air than on my three-month-old Pro at work (even with an SSD it)! The Core i7 in the Air will spike the frequency from 1.8 GHz to a much faster frequency as demand on the CPU rises. This will have some effect on battery life, but I don't run my full test-suite continuously. The database performance on the SSD in the Air also outclasses the SSD in the Pro. I'm not exactly sure why this is, but likely has something to do with the controller.

The iMac

After a month or so, I returned to the Apple store. I tapped on the little iPads they have at every computer around the store (a great idea, by the way). Shortly thereafter, I walked out with a 27" iMac. Having previously ordered 16GB of RAM from OWC I felt comfortable in getting the base configuration CPU (Core i5) and HDD. The CPU was fast enough, faster than the Mac Pro. As for storage, I'm happy with external. With Thunderbolt, I fully anticipate external storage to get even better (read: Drobo or Lacie Little Big Disk).

Tangent 3: Absolutely buy 16GB from OWC. It's half the price of RAM from Apple, and comes with fantastic warranty. It's one of the few remaining user-replaceable parts on Apple computers.

Screen Size

It is … HUGE!

Even better, I can use it with my Macbook Air as an external display.

Performance

Although I sometimes miss the SSD, the quad-core Core i5 makes up for it in video transcoding. I use Handbrake, and I can hardly believe the speedup from the Mac Pro. Photo editing in Aperture, Photoshop, and Pixelmator is no problem at all. I'm not a power user in this department. But, my Aperture library has nearly 10,000 photos, in three libraries, split across two HDDs. This would often choke the UI on the Mac Pro. I think the 16GB of memory available to Photoshop is really what makes the difference.

As for development, I do a fair bit on iMac. To get it to perform like the powerhouse that it is, I tuned my PostgreSQL instance to use the appropriate amount of RAM given what's available to the machine. Redis, too, has more space to play around with than I have ever had before. On the Macbook Air, I tune PostgreSQL to use less RAM because the SSD is so darn fast that it hardly matters. I try to keep my indexes in memory, but they don't get very large at all in development and testing.

What I Love

There's a lot to love when mixing these two fantastic machines. I love the portability. I love having something with permanence. I love the tiny screen. I love the big screen! I love the small, fast SSD. I love the big HDD. I love thunderbolt!

This setup, more than any other I have had in my lifetime, provides me with the most flexibility, with the most ease of integration, for the least amount of money. As compared to having a Mac Pro, and a 15" Macbook Pro, this combination is downright affordable. The computers themselves perform above and beyond anything I have previously owned.

Tangent 4: I'm not a gamer. The Macbook Air would be a horrible gaming computer, even worse than the previous model. I don't care.

Downsides

The connection between the Macbook Air and the iMac, when using it as a display, takes a very unreliable moment. It requires both external keyboard and trackpad be connected, as well as power. When using bluetooth devices, this can be a bit wonky.

My recommendation? Keep the MBA open until the external display switches, then close the lid and pop it stand. When you use the mouse or keyboard, the display on the iMac will wake up.

And then there's the price. But you know that already.

What's Missing?

Drobo. I really can't wait for a Drobo with Thunderbolt. I hope it comes soon.

My Mac Pro had 6TB of storage. I removed all those HDD's and shoved them in external cases I had accumulated over the years. And so, at present, I'm daisy chaining these 4TB of HDD's off the Firewire 800 port on the iMac. Most troubling of all? I can't back it up. Thankfully, it's all media that I have somewhere on physical media or from iTunes (which permits re-downloading now!) or that I won't otherwise miss (mostly television episodes I've already watched). All my photos are backed up both on my TimeMachine, and somewhere outside my apartment in case of catastrophe. All my work is in Github (of course).

So, all I really want is a Drobo, with Thunderbolt.

Conclusion (tl;dr)

My love for Apple has driven me to buy an 11" Macbook Air and a 27" iMac. They go very well together. I made my dream a reality with a little work, a trip to Ikea, and a lot of money. Check back soon for more on PostgreSQL tuning in these two environments.

NSDistributedNotificationCenter in MacRuby

2010-10-25T21:28:00-07:00

I've started working on MacRuby project, that I'll talk more about later, but I had some fun getting notifications from iTunes about track changes and play/pause events. I found the documentation for NSDistributedNotificationCenter and was able to whip up this quick example in MacRuby.

First, you have to install and use MacRuby. The fastest way to do this is with the fantastic RVM. Simply do rvm install macruby && rvm use macruby. After that you can use the following gist and watch it spit out any and all distributed notifications. Try opening iTunes and switching tracks to see some interesting information.

MacRuby Notification Gist

I hope this quick example is useful and I hope to post more about my MacRuby experience, soon. Stay tuned to see what I'm building!

Rails 3 Routing

2010-09-20T12:58:00-07:00

While working on Tasty and an, as yet unannounced, new product I came across a situation in which I wanted to route two different controllers with two different sets of functionality to what was essentially the same path. Normally, this is impossible. There has to be something to differentiate the two paths so that a route can be sent to a controller and action.

Thankfully, in Rails 3, we now have constraints. The common case for using constraints would be to match a subdomain. In my case, I could easily use such a differentiation.

Constraints, combined with the use of namespacing of controllers in modules allowed me to route two different controllers at the path '/items'. Unconstrained it simply goes to ItemsController, but if a subdomain matches it is sent to Store::ItemsController. The trick is to use the :path option on the appropriate namespace within the constraint. Here's how that might look:

Tasty Routes Gist

All in all, the new Rails 3 routing is extremely flexible, miles ahead of Rails 2.3. The SubDomain class used in the constraint is simply a class that implements a class method called matches? which takes a request and returns true or false. I match on the request.subdomain to check for what I need.

DevNation DC 2010

2010-09-05T01:36:00-07:00

Last weekend I had the privilege of speaking at DevNation in DC held at Viget's own offices in Falls Church. I was among the ranks of some of the finest presenters in a community of passionate developers including Aaron Bedra of Relevance, Dave Troy, and one of Viget's senior front-end developers: Blake Walters. Here are my slides from my presentation on Tonality and Timbre: Lessons for Personal Improvement from Musical Instruction.

DevNation DC 2010

View more presentations from Tony Pitale.

My original intention with this talk was to seek inspiration in my years of musical study (I play trombone) and to draw parallels to the software development universe. By doing so, I had hoped to uncover some new and innovative ways by which we all might seek to improve our skills. However, I found that there already existed a significant number of practices. Most of all, we must be reminded to keep up with the basics, seek feedback, and always be cognizant of our own growth. I hope future iterations of this talk will allow me to expand on some of these ideas.

If you were present at DevNation and at my talk, I would sincerely appreciate any feedback or a rating.

In addition, I really enjoyed my comrade Blake's presentation on the Garber-Irish Implementation for management of architected javascript. You can see his presentation on his blog markupboy.com.

Switched to Github Pages

2010-08-06T01:29:00-07:00

When I first began writing on this blog I used the excellent Webby gem to generate a static site from my content. I love this approach considering that I write so infrequently. Combined with comments by Disqus, it was (and still is, in some ways) the perfect solution for me.

Counter to this was the slight pain I had in remembering how to make a new blog post when I did get around to writing, the rake tasks (in a webby wrapper command) to regenerate the whole site, and the process of deploying the resulting html to my own server. I was using a combination of HAML, HTML, Markdown, and Erb at varying degrees of complexity to mark up the site that would be output by Webby. I came to realize this was more than I needed.

Github Pages and the underlying gem, Jekyll, have been available for quite some time now. Given the overall simplicity of the blog I had built, and that, ultimately, most of the content came out to be HTML in the end, I decided to ditch the plethora of markup I was using and make the switch to a more homogenous setup.

The transition was extremely painless. I simply took most of the output from Webby and plopped it into the very simple structure Jekyll uses, along with my images, javascript, and css (all intact). I read up on the Liquid helpers provided and made the quick transition from the post/site syntax used by Webby to the quite similar syntax used by Jekyll.

In the end, my favorite feature is simply git pushing my new content to Github. No self-hosting, no deploying, no hassles whatsoever. I love it! Go ahead and take a look at the repository.

Redis LaunchDaemon

2009-12-28T07:13:51-08:00

LaunchDaemons are the Mac OS X equivalent of init.d scripts on most Linux systems. I keep mine collected in the root LaunchDaemons folder at /Library/LaunchDaemons. LaunchDaemons are simply xml plist configuration files which indicate the how, where, and when to start a server which daemonizes at startup. Here's one for Redis:

Redis LaunchDaemon

LaunchDaemon Gist

The important lines to note are 9 and 10, under ProgramArguments. The first line is where I built the Redis server and placed it on my system. Yours may be in a different location entirely. The second is the configuration I use. If you are using the default you can probably skip that line.

In either case, you should change the working directory to the path in which you have Redis built so that the default configuration is used, relative to the server command.

Overall, the LaunchDaemon is simple despite being foreign to most of us used to creating init.d scripts. I'll have one up for MongoDB shortly.

MongoDB LaunchDaemon

2009-12-28T07:38:35-08:00

LaunchDaemon Gist

Intro to Mongolytics

2009-08-12T11:41:45-07:00

Last time, I wrote about how I was messing around with MongoDB ( = link_to_page 'MongoDB in a Deployed Environment' ) and how I had gotten it in a deployed state. However, I failed to cover my reasons for doing so. Why would I need to deploy MongoDB if I was only "messing around"?

The answer is my latest Ruby library: Mongolytics. As you can probably surmise, the name is a combination of MongoDB and analytics. You would be correct in guessing so. The interesting thing about Mongolytics, aside from its use of MongoDB is that the analytics are tracked on the server side of the request/response cycle.

Google has been (and will continue to be) the leader in the web analytics domain. And as everyone who has worked with Google Analytics knows, the tracking is done via Javascripts on the client side. This is the best way to operate given the scale of the operation and the data that GA collects.

I needed something to track not only page requests, but actions in Rails which may or may not have associated unique URIs. An example of this would be a create action. Typically, in a resourceful controller and in REST principles, a successful create should redirect to the newly created resource. This is most likely a show action.

In order to track this sort of thing, I could have added some fancy Javascript to make a pageview of every submit button click or any number of other fancy solutions.

This solution provides a few benefits. Speed, first and foremost. The results of any request instantly present a query-able statistic. This leads to the second benefit. The entire history of our statistics are permanently and easily accessible through a MongoMapped class.

Using Mongolytics

There are three main parts to using Mongolytics (aside from setting up MongoMapper ): include the module, tell it what actions you want to track, and when some stats have been tracked we can turn around and retrieve them. Here is what that might look like:

And that is it. MongoDB will store all that stuff and make it easy to pull back out again. I tried to make it as quick and painless as possible. There are more options, including tracking session variables, that I will get to in another post (with a real example). In the meantime, please check out the project and README on Github and please tell me what you think in the comments.

MongoDB in a Deployed Environment

2009-08-05T13:45:04-07:00

I've been messing around with MongoDB in a Ruby/Rails environment for the past week or so. It's been pretty great. I've tweeted about it, and I'm planning to write more than one blog post about it. While at the same time I'm very wary of the so-called NOSQL movement and getting caught up in it. As such, I'm going to avoid dropping my RDBMS of choice (PostgreSQL) and say I'm actually using it in a mixed environment, with zero trouble at all.

So, what will I talk about here? Two things are most important aside from the actual install of MongoDB (which itself is amazingly simple). The first is Security, and the second is Init.

Security is something that must be specially considered with MongoDB because, by default, it runs without any sort of auth in place. This may be contrary to the normal expectations you might have of a data-store. However, this is just fine for many applications, and turning on auth isn't really going to stop anyone, when the password is already in plaintext in a Rails application. The important security aspect we must consider is the firewall. If you are not running iptables on your server, you're behind already. Either way, be sure to double-check the settings and lock any open stuff down. My personal settings only allow for SSH, HTTP, HTTPS to get in. There already exist many good resources available for setting up iptables. So, I'll be skipping it here.

The other half is setting up an init.d script to run the mongod server at boot time. To start, we'll want to download and position the binary files from MongoDB.org and since I'm on a 64-bit linux (ubuntu) system I went and downloaded this: 64-bit linux download

Shortly after downloading, I untar'd it, and moved /bin the files to a location within a usable path (e.g., /usr/local/mongodb). I checked the permissions to verify that it was executable, but still owned and writable only by root. I finally created symbolic links from /usr/local/mongodb/bin to /usr/local/sbin. In addition I created a logs directory for a pid and a log file within /usr/local/mongodb. Then, I was prep'd to write the init.d.

Since there are many, many init.d scripts on even a barebones server I decided I would crib something from the fine folks on the nginx project who make use of the start-stop-daemon utility. Here is the init.d script that I came up with: MongoDB init script.

It's fairly simple to understand, but the important parts are the $DAEMON and the extra params I provide to start-stop-daemon. "run" is the command that must be passed to start MongoDB, and after that I log to the given $LOGFILE I created earlier. This has the benefit of keeping mongod in the background, and also keeping a desired log.

Hopefully, MongoDB will find itself in the repositories of many popular Linux distributions very soon (especially Debian). This should hopefully include a useful init.d script within the package as is par for the course.

In the near future I'll write a post on my experiences mixing MongoDB and a typical SQL database. Amazingly, there's not much difficulty in doing so. I'll also have a post up with a better introduction to Mongolytics, my new gem for doing base server-side analytics tracking with storage provided by MongoDB.

If you'd like to share your experiences, best MongoDB practices, and any comments/questions, please comment!

Rubynation 2009 Slides

2009-06-13T19:02:06-07:00

Not much going on other than giving my talk at Rubynation in Reston. I think it went well for my first presentation of that size. If you were able to attend I would really appreciate a rating on SpeakerRate. I hope everyone enjoyed it. Here are the slides for reference:

Legacy Database with Datamapper

I just want to say thanks to the organizers and sponsors, as well as, a special thanks to Russ Olsen for introducing me and kicking off the QA portion when my talk ran under the expected time.

t.pitale

Dream Setup: iMac & Macbook Air

The Story

The 11" Macbook Air

Screen Size

Performance

The iMac

Screen Size

Performance

What I Love

Downsides

What's Missing?

Conclusion (tl;dr)

NSDistributedNotificationCenter in MacRuby

Rails 3 Routing

DevNation DC 2010

Switched to Github Pages

Redis LaunchDaemon

Redis LaunchDaemon

MongoDB LaunchDaemon

Intro to Mongolytics

Using Mongolytics

Include the Module

Track Actions

Check the Stats

MongoDB in a Deployed Environment

Rubynation 2009 Slides