Many rubyists consider threads in Ruby as somewhat of an arcane knowledge, though in reality they’re a very well researched and understood concept. Of course, writing effective multithreaded concurrent programs requires certain amount of knowledge and discipline from the programmer, but there’s nothing that a smart one can’t learn if he wants to.

To help with the task, awesome @brainopia compiled a list of recommended reading on the topic of concurrency and threads, traslation of which into English you can find in this post.

Sometimes we don’t really need a full-blown gem with a lot of bells and whistles, when a simple hand-made class worth a dozen of lines will do the job just as well, and even better – due to the cut off of extra external dependencies. And I believe that the task of keeping a set of configuration options or settings for the application can be implemented in such “lean” class quite often. Let’s see in this post how it can be done.

Recently we’ve started playing with implementing progress-bar-style upload functionality in our of our applications. After certain consideration and discussions it’s been decided that Flash-based uploads are so last century and tried a simple proof-of-concept of flashless uploader widget on one of our servers running LigHTTPd 1.5, and that turned out to be a huge success. So the next logical step was to upgrade LigHTTPd on my own machine to be able to play with it first-hand.

And that gave me a problem – Mac OS X 10.5.7 is my work horse, and apparently 1.5 branch has a whole bunch of issues on OS X. To save you some time and frustration (and probably me, if I’ll ever need to repeat it in the future) here is the full package of things you’ll need to run 1.5 under OS X.

A couple of times I’ve faced a problem of performing NTLM authentication from Ruby code. The issue here is that it’s a proprietary Microsoft’s authentication scheme, so it is a certain challenge for the developers to implement. After using different workarounds and proxies, I’ve moved on and implemented a proper solution that extends Typhoeus – networking library build upon libcurl.

So I’ve decided to scrap the old WordPress installation and moved everything to Jekyll, using Disqus to power the comments. Design is based on Simplr theme from plaintxt.org. Let’s see how it goes this way. Some old and not-so-relevant posts were killed on the way as I dislike them now.

There’re two awesome methods in prototype.js library those are often overlooked by newcomers – Function.bind() and Function.bindAsEventListener. These methods are so damn nice that their absense from another awsomeness called Ruby is just driving me crazy every time I stumble upon it.

But let’s take a closer look at why these methods are so useful. First of all, you should familiarize yourself with a concept of binding. The core of it is simple – it allows you to define a function in one context and scope and run it in completely different context. Let me show you almost a real app example.

So you’re using RSpec for your specifications, HAML for your views and Factory Girl to build your test models (and maybe even Factory Girl on Rails to quickly load ‘em – it’s nice, try it).

And everything is good and you feel good and you’re sure that you’re just damn good, but something is still bad… It’s that damned default scaffold generator that comes with Rails and just doesn’t want to use all that candy stuff, and instead builds those ugly mocks and pushes ERb templates here and there! And you have to rewrite your specs and templates every time, or maybe you’ve just stopped using that generator at all. So what do we do in these cases? Why, of course – we build our own generator!

There’s a relatively new player in the town of role-based access control for Rails – acl9 by Oleg Dashevskii. The first look through it’s README page may leave a confusingly bitter taste of complexity in your mouth, but don’t you worry – it’s nice and flexible and easy to use once you get into it.

acl9 has not only global user roles (like this user has admin role, and that user has editor role), but it also allows you to specify users’ roles over specific objects. For example, some blog post can have one user with “author” role and another with “editor” role, and these roles can belong to different users over different objects.

And it’s all good but looks a bit too complex for me in the default implementation – all these per-object roles are stored in the database so you have to assign them by calling user.has_role!(:admin, blog_post) and user.has_role!(:editor, blog_post). And if some roles are changed over time – we have to go over the relevant objects and remove/change the roles.

So let’s sprinkle this basic goody with some dynamic pepper to give it just the perfect flavor we need. And by the way I’ll show you just how easy it is to modify roles behaviours with acl9 – and that’s why I love it.

Looking around for the way to make custom validation errors for ActiveRecord I’ve found a number of different solution, including some quite complex ones those rewrite the helper to get required behavior messages. But it seems that the simplest possible way to do it is to rewrite ActiveRecord::Errors#full_messages method.

The cons of this way is that you keep all standard functionality of ActiveRecord – that means that if you want to provide custom messages only for some validation and keep the old ones for all others, you can easily do it. Just prefix your own messages with ‘^’ character – and they’ll be printed without column name in front of them. Other messages will have that name just as usual.

It’s even implemented as a plugin, but I’m not sure if two modified lines are really worth being separated into a plugin. Anyway, if you wish – just grab the plugin from GitHub/RubyForge, and if you don’t – you can put the following code into your initializers, it will rewrite ActiveRecord’s default method on Rails startup.

Sometimes I wonder why git users still use the old ways to manage dependencies for their projects. And when I say “dependencies” I mean things like plugins, not gems – Rails config takes care of gems for us, of course. But really, why bother with old script/install and all these tools like piston, etc, if we have that awesome VCS tool called git, and it has that awesome feature called submodules.

I’ll try to collect in this post current best practices of a submodules workflow and form a “howto” kind of guide, and maybe talk a little about why this thing is so good in the end. So if you’re still asking yourself “How shall I track changes in my submodules?” or even (if you’re cool and eat your own dog food) “How shall I use the submodule in my app, have it editable/pushable and let others clone the app without any issues?” – read on, you’ll find your answers here.