Tuesday, September 27, 2011

Switching to Mac from Windows: Getting Used to New Tools

I've been a Windows guy since 3.1--a long painful experience, but you get used to the tools and tech of the MSFT world, and it lulls you into thinking in the limits of that paradigm.

Over the summer I made the switch after repeated config issues with Rails gems on Windows vs Mac. My team is on Mac, so I was the outlier.

I got a Macbook Air--the new version with Lion OS--because I plan to travel a ton and I wanted the latest and greatest. I got the 11" screen so I could work on a plane in the cheap seats without worrying too much about the guy in front of me leaning back.

I'm not what you would call a professional developer--I am not. I can teach myself anything, but I'm slower than the average bear, and it's better to have smarter people than I working on my projects.

Last year we chose Rails instead of--wait for it--Classic ASP, which shows you just how adventurous I was at the time. Rails scales nicely, especially on the Heroku platform.

I use Sublime as a text editor, simply on a recommendation, but I'm going to try something else, hopefully with code completion.

Ryan pushed me onto Ubuntu running on Oracle's vBox virtual machine, so we have a consistent environment, because...hh, right: there was that config issue with a Ruby gem on Lion OS. The compatibility issues weren't fixed because the team is on OSX 10.6. That's why we went to the VM.

Since then I've had to learn a few things (gasp) like command line stuff (gasp gasp...feels like DOS). After logging into the VM, I need to be able to execute commands that inherently write to the file system outside the VM, so you have to use "sudo". Sudo is basically a proxy that acts on behalf of the VM to execute commands outside the sandbox.

So instead of git pull origin master, if you're in the VM you have to write sudo git pull origin master. Doing it without sudo throws a permissions error.

So what's git? For the non-programmer it's gittin' too technical. Git's basically a utility for accessing and modifying the contents of a shared code repository. We use github.com as our repository, and it's fantastic--one of the best dev startups, it seems.

Next there's Ruby on Rails. I'm not a Rails programmer and don't aspire to be. I'd prefer working in Javascript from server to browser: up and down the stack JS. With node.js--an all JS http server--you can do that. Node, Express for MVC (model, view, control) framework, MongoDB (JSON document db), PhoneGap for mobile (just learning about PhoneGap) using HTML5 and JS, jQuery for lots of handy stuff, etc.

But we're in Rails. So I have to know a bit of it. Ruby is really quite elegant and doesn't require quite the syntax of other languages.

Rails as a framework is cool because of the amazing number of free objects out there (ruby gems) that install instantly from their remote locations--a very, very nice feature of rails.

I tend to forget the next one: rake sunspot:solr:start. We use Solr as our interface to the Lucene indexing server, which indexes everything we store to make it highly searchable. Fun stuff that we haven't dug into enough yet, but I'm looking forward to the time when it's possible.

For the db, Rails uses SQLite, and I use SQlite Manager to inspect the db and perform test queries.

Post-funding I doubt I'll be coding much; some may argue I shouldn't be coding at all. But there's nothing like really getting in there and learning along the way. What we're doing isn't terribly complex yet; once we've nailed down the concept and made choices about how to deliver it.

I find it incredibly refreshing and fun. But I think I'd have more fun if I really, really new Rails, or had 3 or 4 Rails developers working with me in the same room. It's time to expand the toolset a bit--time to add some cash to it and get moving.

No comments:

Post a Comment