Development Communications Standard

No Comments

In the recent past there have been a ton of applications that I’ve followed almost religiously.  I’d read forum posts about how their software or service was coming along great, then they disappear off the face of the planet for months of a time, with no updates.  Lynn Wallenstein and I were talking last night and we decided that there should be a standard for development communications.  Right now it’s still in the early idea phase, but any input would be appreciated.

As a developer, especially one that works with insane deadlines, I know that you can’t always hit the mark.  As a corporate developer, I’ve also learned that if you aren’t going to hit a deadline it’s good to to just put it out there and let everyone know what is going on.  In the corporate world it is a necessity, plans need to be changed, milestones need to be rearranged.  With the rise of web based services, and small application development, it’s easy to say “It free or almost free, be happy that we’re doing it at all”, this is an understandable attitude, and one I’ve often shared, but it doesn’t help the people who actually use your service, and people who want to rely on your software.

Lately I’ve noticed development teams (especially Rails) have a very hot/cold development cycle.  Powered By Geek does it, as well as many others.  We have so many great ideas that we want to get done, and the minute we hit a good new idea, development on our other, on going, projects slows down.  Or we’ll get a client job that takes priority over the rest of our side projects, which moves all the different items we’re working on to the back burner.  Fairly often this is accompanied with little to no updates on progress, or even a mention that we’re going to be putting it on hold.

A development communications standard would lay the ground work for development teams to do public communications with progress.  This wouldn’t leave customers so frustrated when their favorite software mentions a linux version coming soon then disappears for 6 months, or a service that you’re really interested in stops almost all communications about the project.

I personally love the idea, both as a developer and as a consumer.  As a developer, more communication with your core audience, letting them know when things are going to be done and what is going to be done, is a good practice.  As a consumer, knowing when things are going to be happening and what to look for would resolve the disappointment I feel when I look at a blog entry about a feature or product I really want, only to see that it was dated 6 months ago and there hasn’t been an update since.

SVN & GIT

2 Comments

With the recent change over to my Mac, I’ve started to really take a look at the differences between SVN and GIT.  I’m still in the process of learning how to use both bundles for TextMate so when I’m actually in “work mode” I’ll usually forego playing around and just use the command line and I’ve noticed some definite differences.

SVN

SVN is actually what I’ve been using the longest, and am much more familiar with.  However using it from the command line is something I’m not very familiar with because up until my switch to my Mac I have always used TortoiseSVN which is probably the best implementation of an SVN client out there because of it’s integration right into the Explorer shell.

Some of the pros of SVN:

  • Output is much more descriptive
  • Without branching it is completely straightforward
  • A lot of documentation out there to help you get started
  • Easier to move between old revisions

And, of course, some of the cons:

  • Slow and clunky feeling
  • Hard to setup initially
  • Pain to fix merge errors
  • Branching is a chore
  • Require an “always on” server/connection

Pros In Depth

Descriptive output

By default, committing, updating, checking out in SVN yeilds very clear and easy to read output.

Macintosh:upillar_motors danahern$ svn up
U    app/models/notifier.rb
U    app/views/notifier/invite_users_private_en.rhtml
U    app/views/notifier/question_for_seller_en.rhtml
U    app/views/notifier/reply_to_buyer_en.rhtml
Updated to revision 5776.

You get a clear understanding of what it is doing every step of the way.  With GIT the updating is a little harder to understand

Macintosh:truth danahern$ git pull
remote: Counting objects: 17, done.
remote: Compressing objects: 100% (10/10), done.
Unpacking objects: 100% (14/14), done.
remote: Total 14 (delta 4), reused 14 (delta 4)
From git@github.com:lwallenstein/truth
ecd1c5c..73c70a0  master     -> origin/master
Updating ecd1c5c..73c70a0
Fast forward
README.txt |   62 +++++++++++++++++++++++++++——————————–
1 files changed, 28 insertions(+), 34 deletions(-)

Straight forward workflow

As long as you aren’t branching SVN’s workflow is a lot more straight forward than GIT.  You have your server repository which is the definitive copy, then you have your local copy that you work on and then check files into the server repository.

Tons of documentation

Both have been around for a long time, however GIT has only recently really hit the limelight as the new choice for code repositories.  SVN has oodles of documentation out there, and while this won’t be a factor for much longer, GIT is still catching up with regards to documentation explaining the how’s and the why’s.

Moving between revisions

This might be a short coming on my part, but SVN feels a lot easier to move between revisions.  You do a little research to see what revision you want to grab and then just do an update with a “-r <revision number>”.  I haven’t yet gotten the hang of reverting to previous revisions with GIT. Thanks to Pieter, I’ve found out that reverting in GIT is just as easy as SVN (In fact far easier when using Github). git checkout

Cons In Depth

Slow and Clunky

SVN really doesn’t excel at giving me the feeling that it’s actually doing something.  It feels slow, committing a large file or groups of large files leave you sitting at “Transmitting Data.” forever.  No status indication, which means you don’t know if you should sit there and watch, or maybe go grab a bite to eat, enjoy some TV then come back and hope it is done.

Hard to setup initially

I haven’t really ever had to do this by my self, but from the experiences I’ve had with others as the developer waiting patiently to start a project or drop an already alpha product into subversion this seems to be a time consuming and difficult process.  I can’t go into the details on what went wrong each time, but I do know that by the end of the process everyone involved was frustrated and praying that there would be a better solution one day.  It should be noted though that once it’s up, as long as you don’t change anything, it stays up pretty solid.

Pain to fix merge errors

Merge errors are a way of life when working with others on a code repository.  The merge errors in SVN are a pain to fix.  Not only does SVN leave the file name with extra characters with the files diff’d into the file name, but it generates 3 different versions of the file and sticks those in there as well.  In reality, one of those solutions or the other would make more sense as a standalone.

Branching in SVN

Branching in SVN is actually so much of a pain, that rather than creating a branch we’ll either create a new repository or just say “screw it” and make a backup copy of the repo and just start committing.  Once you use git’s branching there is no way you could actually stand to go back to SVN.

Require an always on connection

This hasn’t been a real problem for a while, however, on the occasions where our SVN server goes down or for some reason or another I can’t connect to it all development stops.

GIT

Git is the relatively new to me versioning software.  I haven’t checked out any of the GUI based interfaces for it yet (and at a glance it would appear there aren’t many), but the command line version has been treating me right for a while now.

Some of the pros of GIT:

  • Everything is faster than SVN
  • Branching is a breeze
  • Github
  • Merge is amazing

Some of the cons:

  • Hard to understand what is going on
  • Github’s pricing system
  • No really good UI
  • Few web based tools

Pros In Depth

Everything is faster

This might be just a perception, but everything on git seems faster than SVN.  From checkout, to merge, to commit, everything seems to speed along on git.  It could be just that it’s more verbose, you can see it actually working instead of sitting there pondering

Branching

My heart actually expands three sizes at the thought of how easy the branching is to handle on git.  So many projects I’ve worked on would benefit greatly from being able to branch off and work on a big revision.  The problem that’s held me back so far is that SVN is such a pain to branch, I look forward to getting to branch a lot more.

Github

Github is a great tool.  I would almost wholeheartedly recommend it, and if you only have a few things you’re working on I do in fact recommend it from the bottom of my heart.  It is amazingly simple to setup, and if you see a public project you’d like to patch it’s actually impossible to mess up checking out, and commit a patch. There are some problems with it, which I’ll expound upon in the con section.

Merging

Git is infinitely better at handling merging when compared against SVN.  I’ve actually never had a bad merge issue with git.  It’s also far faster than the SVN merge.  It’s a win all around.

Cons In Depth

Hard to understand

Git’s pro is also a con.  It’s very verbose, it tells you exactly what is going on.  It’s hard to understand what it is doing at every step.  Especially when compared to the simple output of SVN.  (To see an example scroll back up to the SVN Pro)

Github’s pricing schema

No one knows better than I do the value of making a buck off your hard work, and I would be more than happy to pay for such a wonderful service as Github. The problem I have with Github’s pricing schema is the limit on space or projects.  However, the way it is setup is based on public/private repos as well as space, this means that because of the limit on private repositories you can’t post all your private client work.  Powered By Geek contracts out to a LOT of companies, and if we want to host all our repos with them then it would cost us a small fortune.

No good UI tool

As of right now there isn’t a good graphical user interface for interacting with git repositories.  SVN has been main stream for a while longer and has had more time for tools to develop, and between Versions on the Mac and Tortiose on Windows. Right now the Git GUI tools are very basic, and not really useable.

Few web based tools

There aren’t that many web based tools out there for viewing repositories.  The SVN tools are pretty mature and refined, however, the git tools aren’t there yet. From the little I’ve read, the git API tools are still developing.  So I don’t think this is going to be a con for very long.

Final Thoughts

I think for our new projects GIT makes a lot more sense than SVN. Since I’ve been working with git with the command line and have gotten used to it I can’t really imagine moving back to SVN. Git really seems like the better tool, but it needs to mature a little more, I think shortly there will be no real con to using git as opposed to SVN.

Phone Conversions

2 Comments

I’ve become a fanboy.  I keep telling myself no, but slowly I’m coming to terms.  Last week I picked up an iPhone (bought off ebay so I wouldn’t have to extend my ATT contract).  So I’m going to list some thoughts, and I’m going to compare it to my steallar little Nokia E70 that I had before.  This should hopefully be both similar and contrasting to something that a good friend Michael wrote here on his phone changing experiences.

Let’s start with the Pro’s of the iPhone:

  • Beautiful large display screen
  • Novel multitouch navigation
  • Accurate GPS
  • Almost Fully Functioning Web Browser
  • Nice Looking Applications

The Screen

The screen is on par, if not better, than the screen on iPod 5th Gen that I have, and at over double the size it’s amazing.  I’ve been watching Dr. Horrible on it and just amazed at the clarity (this also really gets me interested in buying movies and shows off iTunes, except for their crappy interface for letting me download my content onto multiple computers). Applications look great and you can see details almost on par with my 1920×1200 Mac Book Pro.

The Multitouch

The multitouch is a neat thing to play with for a while.  Similar to DS stylus, this can add a lot of functionality for some stuff and can make for frustrating user experience for other stuff.  Moving around Vay (http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=284940607&mt=8) a remake of a Sega CD RPG is horrible, while moving around Google Maps is great.

GPS Functionality

The GPS functionality almost makes me want to drop the money for an iPhone SDK and learn Objective C, because it’s accurate enough that you could make a lot of neat apps for it (and looking at the app store people are already starting).  This is my first time having built in GPS in my phone (my car has an awesome GPS system in it) and just imagining the possibilities of things you could do with it has me excited to see what other developers can come up with.

Safari in your pocket

This would be the one thing I think that makes it worth while to get an iPhone.  Although the Nokia’s browser is pretty good, some of the stuff it does can really ruin a web experience (not rendering CSS right, sometimes barely rendering anything at all).  As someone who does web development for a living, and whose secondary job is just keeping up with all the new developments and sites coming out on the internet (Lynn keeps me well informed), this is almost a necessity.  I don’t think I could ever go back to an experience less than the standard the iPhone has set, the large screen, speedy connection and near full featured experience has really made me question how I could live with out it.

Look at the pretty little app

The application designs for most things, looks great.  I’ll talk about the cons of the UI a bit later.  The applications with reflective surfaces and easy to understand buttons.  Every app has a very iPhone feel to it, and you are fairly comfortable moving between apps without the bone jarring feel of a completely different layout, and completely different icons.

Now on to the cons:

  • Text entry sucks
  • The UI layout is pretty bad
  • Working with iTunes and multiple computers is impossible
  • Just using touch controls is irritating

Text Entry or how the helk van u tuoe on thus thomg

Coming from the Nokia E70 with it’s flip out real QWERTY keyboard to the iPhone’s virtual keyboard was and still is a real challenge.  Typing on the Nokia had the feel of a real key being depressed and the keys were big enough to type with my thumbs, typing on the iPhone has no tactile feedback and the touch screen makes for some pretty inaccurate key presses when trying to use it to type in the vertical position.  I’ve read enough about it to know to just type the words you’re trying to get and the iPhone will hopefully figure out the word you’re typing and replace it when you hit space.  That works somewhat, however, as someone who prides himself on not using all the acronyms that have sprung up, and who tries to spell everything right, this is annoying when you type in a full word, only to realize that the iPhone has no idea what you’re typing.  Even when everything is working perfectly and it’s correcting my typing mistakes I still type slower than on the real Nokia keyboard.

The UI

The UI on the iPhone really annoys me, menu’s are the worst offender, where you have to hit the upper left corner to go back to the previous level.  The problem with that layout is normally I’m using my right hand to hold and navigate my phone, so I have to move my thumb up to the top of the phone to press the button or I’ll have to bring a second hand into the action, with the phone laying down this isn’t a bad thing, but I hardly ever use the iPhone on a flat surface.  Other things about the UI bother me, how it takes more than one key press to bring up certain things like voice mail.  The whole SMS process, while neat that it displays it in a chat like format, is extremely hard to use and figure out.

iTunes and multiple computers

While I generally like iTunes for managing content on my iPod the iPhone is a different story.  Unbeknownst to me, who figured it would work just like an iPod, I setup my iPhone on my MBP laptop, intending to also set it up on my home desktop since I tend to keep only one copy of my downloads and then just connect the device to the computer that has what I want.  Once I got home with the iPhone and attempted to set it up to my desktop I found out that I couldn’t actually access my items on my desktop without first syncing it to my desktop and losing everything, which would mean that I would no longer be able to sync it to my laptop.  This is annoying because this system has worked for almost a year with my iPod with no problems.  Now I have to make sure that my PC and Mac sync up and share their iTunes libraries so that I can access all my content, not a major problem, but a giant inconvenience.

Only Touching

This is probably a giant limitation to the iPhone.  I understand they were going for the sleek and elegant look and didn’t want a bunch of buttons and knobs and whatnot on their phone, however this limits the iPhone to just the touch based approach, and honestly somethings would be a lot better with a different mode of input.  What I’m imagining is actually similar to the DS, where you would have a little directional pad and maybe a button or two.  This would allow you to navigate certain programs (like the RPG mentioned above) that aren’t conducive to the touch only mentality.

Overall

The iPhone is a neat gadget and some things like the web browser really make an experience for me.  However I think that I might be happier with my Nokia as a phone and an iPod Touch as a web browser (if I could get one that would connect to the internet via my Nokia’s bluetooth connection and use the GPS functionality of the bluetooth GPS receiver).  It’s a nice phone and well designed, but I feel like there are some fundamental flaws in the way it does things and the things that it does really well have nothing to do with actual phone functionality.  I’m going to stick with the phone for a while to see how it fares after more than a week’s use, I’m hoping I’ll grow to understand the reasoning behind some of the things I think of as flaws, and if not, then at least there are some Android phones down the pipeline, not to mention some really cool stuff coming out of Nokia.

Working, Working, Working

No Comments

Starting with this post I’m going to try a new format for my writing style as recommended by Lynn.  Focus more on bullet points and logical breaks, less on writing what comes to mind.

  • Why I do it?
  • What I do?
  • How do I do it?
  • What I’ve learned?

Why I do it?

Lately, due to an abundance of free time, I’ve driven myself into working almost constantly (I live in a town whose night life ends around 9pm, and isn’t much of a life to begin with).  Over a year ago I moved to St. George, Utah to work for a small internet startup.  You won’t find me talking about my day job much here though because while it’s nice for a day job it’s not where my passion lies.  However, far before I moved up here I fell in love with Ruby on Rails and was working with Powered By Geek and Lynn.  Since my day job can only bring in so much revenue and frankly isn’t as creatively satisfying as my PBG projects, I not only spend 8 hours at work, but come home and spend some time almost nightly writing code.

What do I do?

Both jobs I am the Lead (sometimes the only) Developer.  I specialize in Ruby on Rails (although I’ve been known to dabble in JavaScript and CSS).  Most of my time is spent pondering how to solve problems that push the capabilities of Rails and Web Development in general.  Sometimes I do a great job (Kiobo and Environs) and sometimes I run into major problems (iStalkr) and try to learn what I did wrong and how to improve.  Because Lynn’s somewhat of a leader and thinker in the Web 2.0 revolution (iStalkr was one of the first site that focused on lifestreaming), I tend to specialize in Web 2.0 apps, not to mention social networking and data portability.

How do I do it?

First off, if you’re going to spend 10-16 hours a day working you need a stead supply of caffeine.  It might not be the most health conscious thing, but to maintain higher brain functions, I feel like I need to keep a flow of caffeine.

Second you need to love what you do.  I had been playing with programming since I was 12 years old, however until I ran into Ruby on Rails I was content to specialize in IT Administration.  Once I started learning Rails though I was hooked.  I started to love web development, it became fun and the framework gave me a structured device to create something unique.  Not to mention the gems plugin manager, where I don’t feel like I’m constantly reinventing the wheel.

What I’ve learned?

I’ve learned Ruby on Rails far better than if it was just a hobby or a full time job.  It’s both my hobby and full time job.  I’ve also had the opportunity to see other developer’s code, sit down and ask questions about why they do things a certain way.

Databases and optimization have also been a huge issue to learn.  There is only so far you can take an idea with an unoptimized database (which iStalkr taught me).  Once again I got a chance to work with people who specialize in databases and could give me pointers on how to improve.  Databases, unfortunately, seem like something that you can only learn optimization for after you run into the issue.

Other items I’ve learned are:

  • Site APIs (digg, delicious, flickr, etc.)
  • RSS (both creating them and parsing them)
  • XML (parsing and creating)
  • ATOM
  • oAuth
  • OpenID
  • Facebook (app creation)
  • Lots more!

On Environs

No Comments

Environs Logo

Another project Powered By Geek recently did was an entirely Facebook application called Environs. This was our first real foray into the world of Facebook applications. For the Rails side we used a gem called facebooker this application, we also used RoRBook (http://github.com/lwallenstein/rorbook/tree/master) as a base.  Here is the about page written by Lynn about Environs.

You have friends
You are connected to those friends on social services

Because you’re all web 2.0 tastic, you and your friends use, like, a kerbillion social services

We quickly show you what you use, what they use, and where you haven’t connected yet.


Ah, haven’t I already connected with these people already?
Yep… at least once. But while you’re connected to some of your friends through most social services, you’re probably not connected to all your friends on all social services. And maybe that’s the way you like it, which is totally cool.

Also, there might be some apps you’ve thought sound interesting, but you didn’t know if anyone you knew was using them. Which makes sense, because using a social service all by your lonesome is kind of… well, not the point. But we can tell you, hey, 4 people you know are using Brightkite right now. Come on over! You know people here!


Why on earth would I want to do this?
Social services are fundamentally about information. What people like (for example, del.icio.us), what they watch (YouTube) and what they’re doing (twitter). You’ve already decided you want some information on some of your friends. What we do is give you the option of easily expanding the amount of information you can get about those friends. Like, say you follow your friend Mikey on BrightKite, and you know he likes dive bars. Awesome. But what if we told you hes also on flickr, and takes crazy-good photos of taco trucks. You might not have known that, but by expanding the number of services you use to connect to Mikey, you get to learn more about him. Basically, were a match-maker… but for people you’ve already met. Its your choice, though — we give you the option to connect with people on additional services, but you don’t have to connect to anyone on anything.
Screenshot of Environs

Screenshot of Environs

This app was tricky in two ways. First it was the first real Facebook app I have done, which meant there was a large learning curve as things that work just fine with a regular Rails site some times just don’t work with Facebook. Ajax and JavaScript in particular are completely different, and require a “hand roll” approach. This necessitated a lot of trial and error, not to mention the learning curve of what Facebook’s changes to JavaScript effect.

The other tricky aspect of this project was the main aspect of it, the parsing of other services. Each of the other web services (ex. Twitter, Last.Fm, Digg, etc.) have their own format for doing everything. We had to consolidate a parser to read all those varying formats and return the same result set so that it could be displayed. I had done stuff similar to this with iStalkr so I was prepared for gathering and reading all sorts of standard formats (RSS, XML, JSON). How we solved the problem was to create a library module, I initially designed it, but then submitted it to Bruce to help me improve the readability. This is still an ongoing problem, as more and more services are added to Environs I need to investigate their API’s and get them working.

Screenshot of Environs Service Matching

Screenshot of Environs Service Matching

Some services such as Flickr or MySpace are extremely tricky (in fact I’m still working on a way to parse MySpace). This might turn into somewhat of a rant, but services that allow you to set a URL to one thing, but then have a completely different value for tracking users, make it next to impossible for application developers to work with them. Flickr has their login, user id, and url, some queries to their API will accept any of the 3, however others want only the user id. Luckily, Flickr has a way around this because they have an API call that you could provide the piece of the information on the user and have it return the user id. Other services don’t offer this and it makes it a lot harder to get the data we need.

Overall, I think the project turned out pretty well. It’s a work in progress, there are still some services that we need to get working. Also, we’ve got some plans for recommendations that are in the pipelines. It’s a fun project that will only get better in time (at least until someone finally agrees on how to standardize these separate friend’s lists on each site).

On Kiobo

No Comments

So after a good long while in development and being kept under wraps I’m finally able to write about the newest big project I’ve been a part of, Kiobo.  Kiobo’s goal is:

Kiobo helps users enrich their browsing experience by making browsing a more social activity. We enable users to explore and leverage their social graph’s browsing behavior. Users can effortlessly find not only new sites relevant to their interest but also people with similar browsing behavior.

Kiobo, as a development job, was actually a challenge,  as there were a couple of big questions.  “How do you hold every website that a user goes to in a day?”, “How do you keep the database moving day after day, with one person able to submit thousands of records a day?”, and “How do you integrate with Facebook, the social networker’s tool of choice?”  Luckily I had help on this project, in the form of Bruce and Nate who are probably the two most influential developers in my life (both have mentored me at some point or another).  We also received help on the database side of things from Will who hails from the land of MS SQL, but has since started getting down and dirty with our database of choice MySQL.

This project started out because of the semi sucess that iStalkr received, because of iStalkr and the fairly recent bout with maintaining a server that was storing TONs of information I was a little wary to start on a project that had an even broader scope of what it would be tracking.  We spent a good long time designing visualizations, planning out the database schema that would provide the best performance versus ease of use, and working out how all these things were going to fit together since this was by far the most ambititous project we had worked on.  Bruce and I worked primarily on the Rails side while Nate worked on the firefox plugin and visualizations.  The project also spawned an oAuth plugin that Bruce wrote that is actually pretty nice, and that Nate integrated into the toolbar.

This project taught me that with the right database design that databases go from fragile bottlenecks that slow everything down to super speedy efficient ways of storing vast amounts of information.  One of the things that I learned from the problems we had with iStalkr was that storing text fields on large tables is a nightmare waiting to happen.  Luckily with this project we weren’t archiving the internet but were instead just logging where you went which was a lot less data we had to store.  We haven’t quite gotten to the point where we’ve started implementing caching but it is coming up soon.  Luckily I’ve gained quite a bit of experience during this time with working with memcached, page caching and slaving databases, so I feel confident that I’ll be able to improve performance in future releases.

We were able to solve the problem of performance by avoiding just one linked table, and instead going with multiple tables funnelling the information so that what ever the purpose of the query was you could work with the minimum number of records.

Privacy was a huge concern with this project.  Let’s face it, everyone goes to an internet site once in a while that they aren’t proud of it’s the nature of the internet now-a-days, one transposed letter is taking you to who knows where, to see who knows what.  With Kiobo people needed to be able to access and see EVERYTHING that we had on them, and be able to do with that what they like.  This instituted the need for multiple levels of privacy, as well as an easy way for someone to delete records.

Also I got my first crack at the rfacebook gem (which ran into serious problems when we upgraded to Rails2.0) and then the facebookr gem which since then I’ve had a lot more experience with on other projects, such as rorbook.  The facebook implementation started out as only a “link your account to facebook then login with facebook” but quickly grew to a facebook app, along with befriending people who are your friends on facebook.  The facebook implementation isn’t all quite there yet, but we’re working towards getting it there.

As for the business side, well I try to stay out of that as much as possible and luckily Lynn translates it and just tells me the highlights.

Kiobo was a really fun project to get started, and I look forward to hopefully getting a chance to create an HTML based version of the site to go along with the flash based version that is up now (what can I say, I’m prejudiced against flash).

On Conversion

No Comments

This week, after running into one RubyGem too many that was required to be compiled, I’ve switched over to the Mac for development. For the last 4 months (since I bought the 17inch MBP) I’ve been flirting with development on it. Until now it’s been the trophy wife that has been trotted out when I needed to do something “unixy”.  The transition hasn’t been easy, years of UltraEdit and Windows have engrained a muscle memory of hot keys deep into my subconscious.  I’ll go over some of the pros and cons I’ve noticed in my first 3 days as a hard core mac only user.

Pros:

  • It’s pretty – I am still blown away by how even little things are pretty in MacOS.  Things like the dock, the icons, even the transition between desktop spaces, are fun to just look at.  None of these things are extremely new to me (Windows Vista has a very pretty task switcher and Ubuntu’s Compiz has a neat desktop transition). But the amazing thing is that as pretty as it looks all those things don’t seem to slow it down.
  • Hot keys – It seems like there is a hot key for everything. As I start to learn more and more of them I’m starting to need the mouse less and less.
  • It’s a Unix environment – Things like the terminal, compiling, SSH are all built in. You don’t have to use DOS which is like a crippled kid, compared to a Unix terminal.  You don’t have to deal with running one “administrator” console and one “normal” console.
  • Unix Programs – You can run things like memcached (this is important because some of our sites have gotten to the point where we need it, and this way I don’t have to setup a special environment where memcached isn’t running.

Cons:

  • The trackpad sucks – I don’t know what it is, the giant track pad just doesn’t seem to work as well as any of my other laptop’s track pads.  I could hook up a wireless mouse, but when I’m sitting outside or in my recliner working a mouse isn’t feasible.  It also lacks a right click, why I just need one giant button is beyond me.
  • The keyboard layout – I’m almost certain the mac keyboard is a slightly different size than a standard pc keyboard.  Not to mention the lack of a 10-key pad even on the large 17 inch laptop.
  • The Apple, Option and Ctrl keys still trick me – muscle memory works against me ctrl+s doesn’t save my document.  Ctrl+arrow doesn’t jump around words.  I’m still trying to teach my fingers where they need to be to do things that I don’t even think about in windows/unix machines.
  • Task switching – I love alt+tabbing (apple+tabbing) and when the task switcher comes up I don’t see 20 things, however you pay for that because firefox browser windows are all open under the same task and to switch between windows in a task you need to push F10.  And I have to admit that besides F1-F5 I don’t tend to use the function keys in Windows/Unix.

So far I love TextMate, as limited as my understanding of the hotkeys are it seems like anything I want to do can be done by typing a little then hitting a button and it will do the rest for me.  I love going into a terminal and typing “mate project” and it opens my entire project up.

I also think that the 1920×1200 resolution is a bit too high for a 17 inch monitor (yes I’ve got oodles of desktop space but the font is a little impractical).  Watching movies on it looks amazing (if only it came with a bluray player).

Working with Rails on the Mac is a dream.  You have the ultra powerful text editor with TextMate, and you also have the ease of working in a Unix environment.  Something needs to be compiled?  No problem, you don’t need to install mingw or visual studio, spend hours setting it up, send the right flags.  This also applies to things like SSH.  Working with a private/public based ssh keys in windows with putty, was alright, but had serious limitations.  I installed OpenSSH on windows then spent hours upon hours configuring and getting it to finally work with key (which after about 5 hours I did get it working exactly like a Unix ssh environement).  With my Mac I do the same thing I have done a half million times in Linux, took me 30 seconds.

I can see now why so many Rails developers sound like Apple fanboys.  After working with Windows so long I had learned to work around strange errors and compile problems and turn a blind eye to all the issues I had, because I knew the environment I could whip out code from memory, hot keys were all based on muscle memory, but I seemed to be living in a very primitive age, one where all the time I saved not learning a new environment was lost fixing random errors and problems working in that environment.

The one thing I’m still wary about is using both a Windows/Linux OS at the same time as the Mac OS.  It’s easy to fall into old habits and just go back to what you know and feel safe with (it’s what happened about 2 weeks after I got my Mac).  I’m in the process of getting my boss to get a Mac or Mac Clone for me so I can go into total Mac Goodness immersion.