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.

Time to time I help my friends with system configuration and other “wtf? it worked yesterday!” kind of issues. One of them runs a thematic torrent tracker that has a certain popularity and medium-sized community around it. The tracker itself is based on a heavily modified TBDev code with some performance fixes and functional additions, and it was forked so long ago that I’m not even sure how closely it relates to the official TBDev branch now. And these guys have about 30,000 registered users stacking up to 100,000 simultaneous upload/download activities.

But that was all quite irrelevant, just to give a broad picture. A couple of monthes ago this tracker was upgraded to the second server – it was running on a single server before that has started to choke. And after the upgrade everything was running fine and fast with a plenty of extra resources to spare until yesterday, when this guy came to me with the words: “Damn, man, looks like we already need yet another server, everything is hell slow and just dying here”.

Of course, my first reaction was “WTF?”. They were running happily last week, and suddenly – overloaded. Hell no, this stuff just never happens.

So let’s say you have some big codebase in Git repository. Or maybe not even that big, but with a complex dependency added in as a submodule. And this submodule is complex enough that it makes sence for it to reference other project and include them as submodules, too. Sounds too complex? Well, maybe it is, but there’re certain situations when this workflow is plausible, especially if your upstream uses Subversion instead of Git. Symfony comes to mind as an example – huge framework with a number of dependencies (look at version 1.2) that uses svn for development.

You’ve found a good guy at GitHub doing svn clone of upstream’s repository periodically, you’ve pulled his git repo as a submodule, initialized and updates submodules and things look good so far. Feeling lucky, you’re dropping in you Capistrano config, customizing it with your server and repository details, and finally typing your magical “cap deploy”. Still feeling lucky and going to grab that hard-earned cup of coffee? Well, hold on there for a minute and pay some attention. Whooops! What’s this? That bloody thing fails.

The problem here is that Capistrano by default (by that I mean when you have :git_enable_submodules settings in your config file) only issues “git submodule init && git submodule update” at the root of your checked out repository, so if you application depends on any submodules down the tree to be initialized, too – well, “Screeewed!” © GoW2