Mr. Frenandez’s post on Rails Maturity has sparked quite a reaction, most notably from Mr. Bowkett. There was one part that made me happy and frustrated all in one go:

Actually, I hate to end on a bad note, but I really think that there’s some urgency to all this and that our collective failure to set high standards for the community is strangling the continued growth of Ruby and Rails overall.

Tom Mornini: Our customers at Engine Yard are screaming for more developer capacity, and in fact, TWO previous customers abandoned Rails (one for PHP and the other for Java) simply because they could not find enough skilled and savvy Rails developers to move their projects forward.

It’s not a problem only for Tom and Engine Yard. At Hashrocket we’ve been helping organizations transition from legacy technologies to Rails and they all have difficulties finding qualified developers. I know that folks like Courtenay at ENTP are having the same problem. Please don’t shoot the messenger. Something has to be done about this, and I think it’s more important than Rails 3 or anything else we are currently excited about.

If this is you, if you’re looking for someone who would make a great rails dev, please post in the comments.

[update] I would also love to work with erlang, if anyone is listening.

After working away at it for a month or two of scraped together free time, whilst learning erlang, grove is done and there’s a screencast to demo it.

(By done I mean done for now, I’ve got some other projects to attend to for a bit)

http://nickelcode.com/grove

http://railslab.newrelic.com/scaling-rails

Been watching these, and they are great from every perspective. Even if you’re rails app is small and doesn’t really need to scale, the client side optimization tips in the first video are awesome stuff to put into practice.

[Update] I filed a ticket on the mochiweb google code site, and they pointed out that this IS expected behaviour. Mochijson2 expects binary strings, which makes good sense since when you decode with mochijson2, strings are converted to just that! Also, string operations in Erlang are faster on binary strings (or so I’ve been told). See the gist for an example.

So I’m working on my test coverage for grove, which has been otherwise abysmal and late to the game. The bright side is that I caught some funnyness with my testing that I was not dealing with before, and I thought I would share my good fortune with everyone.

Notice I said funnyness and not wrongness, this may be the intended behavior but I was not expecting it.

I realized this once I started building my unit tests because I’d been dealing with atoms and numbers ONLY for the value position of those key/value tuples. Obviously I thought it a bit odd when the string result I got included and array of integers where I expected to see a string.

Solution: use mochijson. Not sure why I was using 2 in the first place.

Blah, blah worthless post, _but_ I am constantly reminded why testing makes the world a better place. To take it a bit farther I’m going to borrow a story my high school econ teacher, Mr. Werbylo, told me to explain why we shouldn’t sit on the desks in class:

Look, [ these desks are old < => programming is hard ].

If you [ fall of the desk < => don't build unit tests ] you’re going to be hurt and everyone is going to laugh at you for your clumsiness. Most people think the story ends there, but it doesn’t. When you get home, you’ll still be angry and you might kick your dog. Your dog, being angry and sad from the physical pain you’ve caused him will bite the mailman. And finally, ultimately, the mailman will go to work the next day with an Uzi and kill everyone.

That, is how [ falling of a desk < => failing to get test coverage ] causes loss of life.

One of my favorite teachers.

[Update] I did some refactoring that I’ve been meaning to do thanks to ayrnieu in #erlang.

So as I’m hacking my first Erlang project I’ve come across a few places where I was unsure what would generally be a more readable/understandable/robust solution to a given problem. The one I’m thinking about right now is using pattern matching in my function definitions or, alternatively, case statements. I’m hoping someone from the community might be able to shed some light.

Part of the project I’m working on turns a tuple like:

into a set comprehension like:

As you can see my goal is to be able to query Mnesia, or rather to produce a standard way to query any data store. The following function definition and support functions do the work:

The tuple is “filtered” down the function definitions, and when each tuple (columns, operations, etc) is handled it is translated into a string and thus not matched again until ultimately the final definition concatenates all the pieces together to build/return our query. I REALLY like the way this works in that its short and simple. Also the tuples could in theory be replaced by an appropriate string built outside the function and it would still work, which makes it more flexible.

It has other issues, such as its fragile ordering requirement. If its not ordered properly it may break, or worse just not form the comprehension properly. Which leads me to wonder if there’s a better way to implement this, even if its not _quite_ as concise.

The following is a quick hack and not tested but another way to handle it might look like:

Honestly, I can’t say which would be better as I haven’t tried replacing the version I’m using with a case statement. Is there even a third and better way to handle this situation? Or is this just a case of agonizing over the fork or spoon for eating your pie: doesn’t really matter both will work equally well.

Also, I am proposing a new term for pattern matching in function declarations:

patmatchlarations!

I’m not sure if anyone reads this regularly, but with that uptick in people stopping by I thought I would wish everyone a great holiday season just in case they do!

I switched the theme for the site because I was running out of tab space at the top and I will be putting up at least one new project for people to look at relatively soon. My first in erlang!

Also, if you haven’t already checked it out, erlanguid.com is up and running. Not too many members right now but I’m hoping that as time passes and I can get some good tutorials/screencasts up there about working with erlang and setting up a development environment (yaws appmods, debugging with emacs, io:format vs io_lib:format, etc).

Again, have a great holiday and a wonderful new year!

I work as a .NET consultant in New York, most often with ASP.NET and SharePoint so the frustration expressed here comes directly from experience. Outside of work I like to dabble with lots of other neat tools an one thing I’ve really gotten used to in web development is NOT having to compile when I make simple changes to my app. PHP, Python, and Ruby all make this very easy. And if your project is pretty small, using ASP.NET doesn’t add too much over head. But that doesn’t last for long

The problem is when the project gets large or you group a lot of classes/code into a single DLL and THEN have to compile them to see your changes. Even failing to mention the need to get IIS to clear its cache before anyone can see a change from the code, there’s a wait time of 30 seconds to a minute depending on the size of the dll.

I hear you say, “30 seconds isn’t that big of a deal”, but doing a little math shows you that 30 seconds compounded maybe a hundred times (conservative) a day over the course of a week or two and you end up with hours wasted. All that time spent just waiting, doing nothing. What’s worse is that you lose your focus on what you’re testing. You’re continuity of thought is crushed under the weight of compiling your 1 liner alteration.

So, lots of whining without many suggestions. Well here it is: http://tirania.org/blog/archive/2008/Sep-29.html. That’s the mono project’s leader Miguel De Icaza’s blog and he talks about the csharp interactive shell that came out of the mono project recently.

What I would like to see is a development mode for IIS that deals with C# in a script like fashion, using something like the aforementioned link so that we can stop compiling things while were working on them, and still get the nice quick execution we’ve come to expect from compiled/cached .NET assemblies in production. Faster iterations means more efficiency and less brain breaks when developing web applications.

Right, the page might load slower when you fire up your server, but I’m tired of recompiling some huge thick dll every time I make an extremely small change.