RubyRX

Rails may be the framework that turned many of us on to Ruby, but if you are using it for all of your server-related Ruby projects, you probably have a hammer and are seeing every problem as a nail. There are a number of smaller, tighter solutions to problem in this space, including GServer (built into the Ruby libraries), StaticMatic and Webby (tools for generating a static site, but with all the templating goodness), Sinatra, a small server with an awesome DSL for restful web services, and Rack, an easy way to get content published as a web service.

Spend an hour learn about Erlang -- a functional programming language designed for demanding multi-threaded environments. You'll get an introduction to the language including syntax and major concepts. You'll also learn which companies and projects are using Erlang today and the kinds of problems they're solving with Erlang.

Learn how to use Erlang in a practical setting. This talk will cover building and deploying a simple, but complete, web application using Erlang. The talk will illustrate how to use the OTP framework to write robust servers and how to leverage third party libraries, like Mochiweb, to make developing for the web easier.

We developers spend a lot of time talking about how to improve technically at our craft, how to write better code, how to be more productive when we're writing code. But what about when we don't feel like coding? What about the emotions that often keep us from putting our fingers on the keyboard and working on that cool library we want to write or finishing up that cool side project we
were so fired up about a few weeks ago?

Or to put it another way, why is it that some developers turn out so much more code than the rest of us? How do they maintain five open source projects (or more!) while we might be doing good to make progress on one? It certainly might be that they're smarter, or that they spend more time at it. But maybe not...

Maybe the reason we don't create more is that we're afraid. Afraid of not finishing, afraid of what others will say, afraid we won't know how to solve a problem, afraid that we're not working on the right thing. If creating code is even partly an act of artistry, then it's worth examining our emotional connection with what we're making. It might be time to start realizing that coding productivity is affected as much by our emotional outlook as it is by
our technique.

Lots of developers decide to try going it on their own - perhaps they're tired of being a cube rat, having technical decisions made by uninformed management, or having to service the bureaucracy before the client. Rubyists seem to have an especially high likelihood of going independent, since it gives them much more flexibility to use the language that makes them happy.

But as alluring as it might be to "be your own boss", everyone who makes the jump from the cube to the room over the garage finds out real quick that there's a whole new set of skills necessary to be successful. Even worse, freelancing doesn't come with a training manual that outlines all these important skills, and most folks just have to learn them the hard way: by trial and error.