AR lazy eval

Web Development Insights

Writing good code is not an easy task to accomplish and every developer has his weak spots.

For me, developing in a concurrent environment and scheduling between tasks is a serious weak spot.
I know, it may be obvious why these two specific topics might burden the development but I’d like to put it into simple words:
(1) The tiny fact that I cannot read the code line by line and know it really was the order of execution can sometimes make me wish I would have chosen a different profession (not really 🙂 )
Debugging suddenly becomes hell, if not useless, and all these threads pop up to your console from nowhere without having control over them. Not a pleasant experience indeed.

Lucky lucky me, as a Rails developer, I don’t get to deal with concurrency too much (if at all), but that doesn’t mean that (1) is solved…

View original post 599 more words


Leave a comment

Burn your controller a la Erez Rabih

Web Development Insights

Don’t Solve The Problem, Prevent It.

When you deal with input in programming, it is always a good practice to make sure you can’t get from the user what you wouldn’t want to get. I know it sounds strange at the beginning, but let me further explain with the simplest example:

Let’s say you want to get a date as an input from the user. A date can have many different formats and dealing with every possible format could become very frustrating. Now if you let the user enter the date in a simple text box you leave the power in the hands of the user. He decides how the input gets to your server, and you find yourself wasting a lot of code lines on the parsing of the date.

That is exactly the reason why graphical date picker components were created. A date picker lets the user choose…

View original post 494 more words

Leave a comment

Great post by Erez

Web Development Insights

1. It is open source

Open source projects are just inherently awesome.
Get a strange error that does not include a code line of yours? Want to know how things really work from behind? Want to improve your programming skills?
All of these may be achieved by just going through the source code on Github.
I know – it is just awesome.
Open source comes with a responsibility though: if something breaks down there’s no one to complain to, you must dig inside and handle it yourself.

2. Its fluid code

RoR is well-known for its idiomatic code style, which I sometimes call “English with underscores instead of spaces”.
This is thanks to the Ruby language itself, which the platform relies on, and to the RoR infrastructure which produced a great platform to work with.
When you develop with RoR you can achieve such levels of code-readability,
that you can just…

View original post 721 more words

Leave a comment

(Do not) Use Rails cache as a distributed lock system

You should strive to design your application in a way that eliminates the need of critical sections as possible.

It is not robust, it adds layers of complexity and is VERY difficult to test.

You can avoid such burdens by using alternative threading constrains such as actors

Having said that there are still cases in a large distributed environment that you need to use Distributed lock manager in order to wrap a critical section of your flow.

It is preferable to use event based distributed locking – can be achieved with Zookeeper (based on Google’s Chubby)

I will show here a very simple locking mechanism based on Rails cache store.

You can set a shared cache between all your rails processes by setting config/environments/#{env}.rb

In the example I use Dalli (excellent memcached client by Mike Perham) but any store that is shared between the machines will work.

You can scroll to the bottom to see the CacheMutex spec and code

Usage is simple:

As you can see, the main disadvantage here is using a sleep-lock instead of event to notify the waiting thread.

CacheMutex source code:


Due to potential race conditions scenario identified by I switched to provided lock abilities of Redis-Objects


, , , , , ,


Speed up network bound specs with vcr

Fast tests feedback is crucial for productivity (don’t wait for your tests on TDD), commit time (continuous integration), deploy time (continuous deployment)

VCR is a great tool for speeding up network bound tests. It uses an underlying layer to imitate web requests by dumping the first request into yml file and using the dumped response to stub future requests with the same headers.

Setup is super easy:

1) Gemfile

2) spec_helper

3) go over all failing tests and add :vcr to the group:

Each example group will be represented by a yml file in the spec/cassettes directory. The file will include all the requests and responses for the example group

4) update .gitignore to ignore cassettes

Run your specs and enjoy the velocity (on the second run ;-))

Leave a comment

DRY your scopes

I encountered a pattern today that I would like to share:

There is no justification to write such a code in ruby (or in any language)
ActiveRecord 3 with ARel does not defer class singleton methods from scopes and in my opinion they are more readable.
We could write the same functionality with:

Now, the path is short to go to:

I like it – do you?

We didn’t only clean the code.
We did much more – every new status in the STATUS list will effortlessly represented with a matching method.

For instance :curator key which had no scope in the original version is now represented with the User.curator method.

DRY is not (just) about aesthetics. DRY is about maintainability and simplicity.

, , ,


Simple buffer for queuing methods with callbacks in CoffeeScript

Leave a comment