eval(code)

I presented at Boulder.rb last night. It seemed to get a decent reception. Slides are below.

So I just finished up almost 2 months of using EngineYard Solo as my hosting platform. I recently cancelled my account and moved back to a Linode VPS (720) and I am actually much happier than I was on Solo. I figured since there are no reviews of the service to be found, I would write one.

I originally demoed Solo at MountainWest RubyConf’s Hackfest. Ezra Zygmuntowicz sat me down and took me through all setup process, posted our hackfest application, and than gave a whirlwind tour of the other features in the Solo control panel. I was very impressed even given the deployment hiccups we encountered (but Ezra was right there fixing them as they came up, if only I got that one-on-one service everywhere! ). I got the app running, played around with different configurations, Apache + Passenger & Nginx + Mongrel. I was blown away by how easy it was to roll out an entirely new configuration, and within 2 weeks, I cancelled my Linode slice and moved exclusively to Solo. Maybe I expected too much, but that is when fighting the control panel became a daily activity.

Since a basic EC2 instance has 1.7GB of RAM, I moved 3-4 applications over from Linode. The control panel for Solo is awesome when it comes to establishing gem dependencies, and different application configurations (Rack, Merb, or Rails), but don’t expect the nginx / apache configuration to be as easy. As a default, when you create a new application it will only create a vhost configuration like:

<VirtualHost *:80>
ServerName refactorme.com
DocumentRoot /data/refactorme/current/public
</VirtualHost>

This configuration works fine if your only hosting one application on your instance, but most people are not doing that (from other’s I know who also use solo). When you have more than 1 application running on an instance, and lets say you added refactorme second, and you visit www.refactorme.com, apache will route you to the ‘default’ or first application defined. This caused many headaches because I would have to manually login to the box, add ServerAlias www.refactorme.com, save, and issue an apache config reload. Not so bad, right? WRONG! If you ever change your configuration from the control panel, it is like your deploying a fresh instance, that configuration file you manually changed isn’t saved. This makes the main selling point of EY Solo completely useless when redeploying configurations actually causes more work. I reported this bug several times to the #ey-solo channel on IRC, but to no avail, it was never fixed. Somehow Flex and all these other redeploy features were added, but a simple task like defining an application to sit at a subdomain was never addressed.

It leaves a bad taste in your mouth to see new features being added that help make configuration and automated tasks being added only to see that you cannot use them since every deployed instance requires personal attention to add a mundane configuration change. Don’t get me wrong, the EngineYard Solo control panel is an excellent idea, but when your paying a $40/mo+ premium on top of EC2, but it can’t even get Apache configurations right, why would someone pay a premium to fight the control panel that is supposed to make deployment easier? Some may argue that EY Solo was intended as a staging box for testing and sharing apps between them, that would work fine if you only have one application running at a single time, but what happens the minute you need to QA two applications concurrently? Isn’t it supposed to mimic production, meaning that www.domain.com would point to the same place as domain.com?

Made my way up to Boulder last night to hear Tony Arcieri speak about Reia, his implementation of a Ruby/Python-like syntax for the Erlang Virtual Machine. I have only just begun my venture into learning the world of Erlang, but the syntax is hard to digest. Tony’s inspiration for Reia came from trying to implement an actor model in Ruby similar to Smalltalk’s, but quickly realized that Erlang had the actor model he was looking for and decided to write a Reia instead. Building Reia on the Erlang VM also allows all code to be run concurrently, one of the big drawbacks to most OO languages. Reia is not without is drawbacks either. All variables are versioned (more later) and each instance will spawn a new gen server which makes garbage collection difficult unless you utilize linking techniques to build a tree structure or call @thing.kill() explicitly. Variables are versioned in Reia since Erlang does not have the concept that variables can be reassigned. To get around this, Tony creates versioned variables which converts from Reia’s syntax: a = a + 1, to Erlang syntax as: A1 = A0 + 1. There are a handful of things missing from Reia that are either planned or purposely absent: Loops cause a dead lock, instance_eval is planned, Mixins? Still up in the air on implementation, Metaclasses, and a handful of other niceties of Ruby. The tradeoff though is the ability for powerful pattern matching, concurrent code, a messaging protocol, and no more ugly Erlang syntax. To me its a great win for anyone who needs concurrency and speed, but does not want to fight the righteous Erlang fight. Thanks again to Tony for the great talk!

This past Wednesday, Corey Donohoe stopped by the office to give a tech talk during our weekly brown bag. He covered a range of topics all revolving around Sinatra / Rack. We recorded the talk and posted the slides online. This is the best Sinatra talk I have watched, he gets into best practices and how Sinatra can be used as middleware or Rails metal.

Sinatra 0.9 – Rack, Middleware & Metal.

Slides from Sinatra 0.9 – Rack, Middleware & Metal

Usually don’t tend to post updates unless I have something to announce, but figured it was due since I have had quite the response to my pairing post. I actually do agree that pair programming is very useful and effective given the right task. At the time I was pairing for nearly a week on nothing but CSS stylesheets and that was really just a waste of a pair’s time. If it wasn’t for the frustration that I was going through, I think that the article would have taken a much different stance.

Outside of that, I am now a 100% emacs user when working on projects. TextMate has changed to just a “TextEdit” alternative when I need to edit miscellaneous configuration files and don’t feel the need to launch up the entire emacs environment. Also I have been focusing my free time between RefactorMe launch, learning Erlang / Clojure and getting another project rolling. Hopefully I will have a more interesting post soon with details on the new project and with a new facelift to the ol’ blog.

A project that began nearly three months ago has finally launched. The initial work was halted due to time constraints, but was reborn at the EngineYard Hackfest at MountainWest Ruby Conf this year. With the some help from EY Hackfest participants, I was able to get enough of a jump start to finish the application. This also is my first app ever launched on EngineYard Solo, which so far has been amazing. This also means that I have departed from my long time host, Linode. Anyway, head on over and check it out. The idea is 1 refactor is posted a day, you reply and see if your refactor is voted the best for the day. Let your code speak for itself!

MWRC 09 is winding to a close and wanted to post by brief thoughts on how it went. Some of the talks I was most excited to be seemed to be quite dry. It was not a fault of the projects being discussed but the presenters. I think it shows that it isn’t always the best idea to have the main contributer giving the talk as they cannot connect well with the audience on the topic. Outside of that, I was surprised by the topics I was indifferent about. In particular the Cucumber talk was probably my favorite even though its a topic I already knew a lot about. Another was Yehuda’s talk but he is consistently good even when discussing the same topic month after month (Rails 3) . If you get a chance to, check out the Confreaks videos and reply with your thoughts.

I have not had much time to post lately about Ruby, Rails or other goings on inside the community, this is due largely to my work on a new side project called Smokehut. The application is centered around being the one application you need when you hit the slopes at your favorite mountain resort. This ranges from tracking down friends to finding someone interested in grabbing a beer afterwards. Well, I don’t want to spoil it all right away so head on over and check it out.

Ran into this problem today installing do_mysql on my OSX machine that is running on 8GB of RAM. I installed the x86_64 version of MySQL as I wanted to be able to address that amount of RAM. I originally had installed do_mysql by issuing the command:

sudo env ARCHFLAGS=”-arch x86_64″ gem install do_mysql — –with-mysql-dir=/usr/local/mysql

The install went fine, or so I thought. When trying to use the adapter in my latest Sinatra app, I was getting an error complaining about:

dlopen(/Library/Ruby/Gems/1.8/gems/do_mysql-0.9.11/lib/do_mysql_ext.bundle, 9): no suitable image found.  Did find:

/Library/Ruby/Gems/1.8/gems/do_mysql-0.9.11/lib/do_mysql_ext.bundle: mach-o, but wrong architecture – /Library/Ruby/Gems/1.8/gems/do_mysql-0.9.11/lib/do_mysql_ext.bundle

The solution? Reinstall the do_mysql gem with the following 2 commands

PATH=$PATH:/usr/local/mysql

sudo gem install do_mysql

Agile Development has taken the Ruby community by storm. It has been engrained into every corner of the community. However, many take the components as rules instead of guidelines which I feel is very detrimental to overall development speed. The component which speaks most to me as being a guideline is the idea of pair programming.

I feel that pair programming is an essential tool for developers and should be practiced in every business that adopts the agile mantra. The idea is not a new one either, it has roots to the saying that “two heads are better than one.” However, I feel that the commonly accepted practice of pair programming is what should be adjusted and improved upon. The practice I am talking about is that two programmers should work in a pair every day, all day on the same task using one computer.

The first problem with this is that in any business, dedicating two resources to solve a single problem is not always the most cost-effective practice. If the problem is easily solvable, having two resources solving the problem is like using 8 bullets when 1 would do the job, its overkill plain and simple. Now what if the problem is of average difficultly and you dedicate your two brightest minds to that same task? Well from my experience is that one will end up ‘driving’ and the other will fight to maintain concentration because their mind does not really need to be fully applied to the task at hand. This is again, a waste of resources. The only scenario where this practice works at an acceptable level from a business perspective is when you have two equally talented people working on a challenging task. Given that most development is spent outside this limited scope, I feel that this practice should be revised.

I will explain with a scenario: Given story X, two people decide to tackle the problem together. They decide what component each will work on, and sit on computers next to each other and set to work. These components hopefully have to interface together at some point, and both should be working within the same SCM branch. They continue to do TDD on their respective components, but along the way they are forced to work together to make sure that they are working toward the same common goal, which is meeting the story requirements. Asking the person if they are going to be returning json, scripts, or html to their interface and other related questions. Allowing both people to work together but exercise their creativity and influence onto their component, but still communicating/discussing implementation choices.

I feel that this scenario meets a broader target and allows for interruptions to happen without sacrificing the pair. In addition, it handles the case that both developers are both equally competent on the subject so that one mind is not wasted while one drives. People will argue that when this happens that one of them is being a bad pair and I will agree with you on that, but the problem happens to good pairs when one of them had an ‘off day’, etc (see: 21 Ways to Hate Pair Programming). Another problem is accountability of ‘pairs’. If two people are working together on a component, it becomes much easier to weed out the ‘weaker pair’ to either replace or work with on improving.

I am interested in hearing from the Ruby, Rails, & Merb communities about this approach and what their feelings are about using it within their business. This is by no means perfect, but its just trying to illustrate that pair programming may end up being something like communism is, “Good on paper, Bad when applied.”

Update – Some have said that this is just not a pair programming revision, but more of doing away with pair programming. I did not mean it to come out this way. I agree with common pairing techniques when the scenario is warranted for it, however I feel that the majority of scenarios do not. Also working with 2 computers on 2 different components of a story would work given the right scenario (a story that is over basic tasks, or is multi-dimensional) I described above. Teaching and Challenging stories still benefit from current pairing techniques.