Florian Weber launches bellybutton.de

Hot on the heels of Snowdevil, Florian Weber has completed the work to relaunch German e-tailer of pregnancy.. uhm stuff.. bellybutton. The shop is part a CMS for the company behind it to manage the content on the site and part a e-commerce operation to take and process orders. And it’s very nicely designed too!

In addition to the launch, Florian has written a short retrospect of the project. He talks about not optimizing too soon, using a strong domain model, and having Damage Control do continuos integration.

The completion of bellybutton should also herald Florian’s return to active Rails development. Florian had a lot of interesting developments going in Rails before bellybutton kidnapped him for three months. We’re eagerly awaiting his return.

Joe Agliozzo is looking for a Rails developer

Joe Agliozzo is looking to hire a Rails developer for a freelance project to work on an application that will “…allow users to post local restaurants, shops, attractions etc. to the database along with reviews and ‘star’ ratings. Comments and additions to the posts by users will also be allowed.” Sounds like a fun community project.

Here’s what he’s looking for in a developer:

The developer hired wll be provided with wire frame layouts of all pages, and a feature set summary will also be provided. Architecture of the db and programming is left to the discretion of the programmer. There will be as little “reinventing the wheel” as possible. I intend to use industry standard interfaces, etc.. such as Amazon.com uses in posting book reviews. Please include at least one example of similar site you have done in Ruby already.

Sounds interesting to you? Get in touch with Joe at joeag [at] gte [dot] net as soon as possible.

BARRA seeks Rails developer

MSCI Barra is looking for a developer that preferably is already up-to-speed with Ruby on Rails or at least interested in getting it. It’s pretty darn cool to see a company like Barra list Ruby as a required skill and Rails as a preferred one.

The short bio on Barra:

Join BARRA, the world’s leading provider of analytical investment and trading solutions. Our products are used by many of the most prestigious investment institutions in today’s exciting global financial markets to determine investment strategies. More than 2500 organizations worldwide rely on BARRA’s unique combination of risk management software, value-added information and consulting as an integral part of their investment process.

The job posting was made to craigslist’s San Francisco East Bay Area listing, so I expect its primarily targeting locales in that area.

The rise of lighttpd as the alternative web server

Apache has long appeared to be the only viable show in town for your Rails’ web serving needs when it comes to running a production system. Of course, there has always been many others, but beside my brief fling with thttpd, I’ve never actually been terribly interested in an alternative. That was before discovering lighttpd.

Where Apache is the swiss army knife of web serving, and a great swiss army knife, lighttpd is much lighter and focused. It’s driven by a single lead developer that’s incredibly available (now where did I see that work before…) and has pretty much all the features you need to make a great web server for Rails applications.

What made me particularly interested is the strong FCGI support, which includes a built-in load balancer to have a single lighttpd process be the entry point to multiple FCGI application servers behind it. In other words, you can scale up without getting a hardware based load balancer, doing round-robin DNS, or running a web server on the application servers themselves.

Today I was playing around with a single lighttpd process playing gateway to FCGI processes on four different application servers. The flexibility that gives to plug in another server into your cluster and be running in no time at all is pretty impressive.

Conveniently enough, Routes is going to rid Rails of the mod_rewrite dependency and open up the caching framework to run without complicated rewriting rules, which in turn means that it’ll work on lighttpd (and other web servers). And I’m doing my best to make Rails friendly to lighttpd and lighttpd friendly to Rails in my experiments running Basecamp and Ta-da List on it. Jan Kneschke is doing a great job already to help push that integration tighter.

So if you’re looking at an easier way to scale your Rails application, then you might be interested in looking into lighttpd already. And you’ll certainly be interested once the early adopters have had the time to familiarize us fully with it, document the process, and adapt the software.

Jason Hoffman of TextDrive also has a great post about lighttpd in Should I consider lighttpd?

Natural selection for frameworks in Ruby vs Java

Dion Almer is pondering the difference in how the Ruby and Java communities have dealt with natural selection in web-application frameworks. About Rails, he writes:

There were various web frameworks available to a Ruby developer, and then Ruby on Rails came on the scene… How did natural selection kick in with Rails? Developers started to use it. They liked it, and the community grew and grew. As the community has grown, so has the quality of the software itself (as well as documentation).

So a case of natural selection where a popular choice emerges from the opinions and usage of many. Dion contrasts this with the “unnatural” selection in Java where the de facto champion Struts is being replaced by a committee-driven JavaServer Faces:

So, the progression has had little to do with natural selection. JSF wasn’t suddenly the best framework out there that the Java community jumped on. It was made by committee. It was funded by large corporations. And, as such, it doesn’t have the quality of a natural winner.

It’s fascinating what drives the forces of natural selection. And how it takes a long time, or doesn’t occur at all, in some communities. Or whether its even good or bad that it happens (I, surely biased, strongly believe in the good of it).

Snowdevil: First e-tailer on Rails

I’m proud to announce the launch of the first e-tailer to go life with Rails Inside: Snowdevil. Especially so because the team behind it has core contributor Tobias Luekte at the technical wheel and because the site just looks cool and sells something as cool as snowboards.

It took Tobias and crew just under four months to produce the application that KLOCs in at around 6. In addition to the launch of Snowdevil, the team is looking to extract a platform for creating shops quicker with Rails. So if you’re looking into starting a shop project on Rails, you should have a chat with Tobias and see if that’s a platform that might be right for you.

Tobias posted a post-launch announcement on his blog (also powered by Rails) where he attributes the success of the project to Ruby on Rails and their TDD/XP practices. The flattering bit about Rails:

I consider the unveiling of Rails as one of the biggest jumps in productivity the computer industry has seen since it moved from assembler to high level languages. This is the time where small businesses can compete or outperform big businesses just because of better tools. You need to be as efficient as a team? No problem! By the end of the year most companies worth a damn will use Rails or a clone of it. Be ahead of the curve.

Tobias, who is also known as xal on IRC, is certainly doing his part to further Rails as well. If you look through the changelogs, you’ll notice just how busy he has been over the past couple of months bringing the framework further.

So. Do shop your next snowboard at Snowdevil. Do talk to Tobias and crew if you’re looking to get a jumpstart on your Rails-powered shop or e-commerce project.

When longer is better and more is more

The father of Java, James Gosling, is traveling the down under and has some.. erhm.. “interesting” thoughts on scripting languages. I’m getting these sound bytes from Alan Fracis’ summary of the Sidney meeting, so there is a chance they might not be accurate, but here they are:

Opinion of script languages – Perl, Python, Ruby, PHP
Program density and comprehensibility are inversely related
Write Once, Read Never. TECO was worse. Rapid Development
static typing gets you to prod faster, scripting gets you
to demo first. easy to write small things, harder to wrote
big things.

Oy. First of all, lumping all these dynamic languages together under the convenient banner of “scripting” to attack them in symphony is disingenuous in itself. But claiming that writing a long program leads to a more comprehensible one is just plain silly. I hope that wasn’t what he meant.

Additionally, the artificial distinction between “demo” and “prod” in a post-agile world rings awfully hollow in that High Priest of Architecture kind-of-way. Once more oy.

Address book tutorial in Portuguese

Learn how to build an address book using Rails. Or, learn to read Portuguese, then learn how to build that address book. Regardless of whether you need step two of that or not, I’m told that Ronaldo Ferraz has done a fantastic job to present Rails. The introduction bit:

Rails é uma nova biblioteca para aplicações Web que está conquistando as mentes e os corações de desenvolvedores em todo o mundo por causa da flexibiidade e poder da mesma. Este tutorial apresenta a tecnologia e mostra como a mesma pode ajudar a produtividade de qualquer desenvolvedor.

Amen. Oh, and the whole thing is available as a 47-page PDF complete with loads of screenshots. Great local stuff indeed!

Becoming a better programmer with Rails

Justin French have survived the first week on his transitionary journey from PHP to Rails. I have special sympathy for refugees from that camp as I used to do a lot of PHP myself not too long ago. Justin sums up his experience with:

I also think that a Rails developer is inherently a “better” programmer by force. PHP makes it very easy for anyone (myself included) to slap together some poorly planned procedural code and claim the title of “PHP Web Application Developer”. Rails on the other hand at least tries to make us better programmers by default.

It’s certainly possible to write PHP that doesn’t succumb to the draw of becoming a big ball of mud, but the structure is completely self-imposed. Easy to slip if you’re not careful.

Seems like Justin has quite a following of other PHP’ers curious about Rails, so its great to see that he’s continuing to blog the transition and hopefully instill others with the courage to do the same.