199 out of 200 applicants for every programming job can't write code at all. I repeat: they can't write any code whatsoever.
An oldie but goodie from coding horror. But the fix is easy: always have them code for you in the interviews.
Can you imagine this being true for other professions? Though I suspect it might actually be.
Solve only 80% of a problem. That's usually good enough and you'll not only get done faster, you'll actually have a chance of getting done at all.
This strategy is given by Amix in HOW TWITTER (AND FACEBOOK) SOLVE PROBLEMS PARTIALLY. The idea is solving 100% of a complex problem can be so hard and so expensive that you'll end up wasting all your bullets on a problem that could have been satisfactoraly solved in a much simpler way.
If you solve your scaling issue 100%, then you might not be working on features or other important things enough. In a startup, you just can't freaking afford the time and effort.
Doing research now about ESI / Varnish, and saw this useful explanation of the entire process. ESI looks like a pretty powerful weapon in the web scaling arsenal.
Assembling Pages Last: Edge Caching, ESI and Rails
Using this validation method in conjunction with ActiveRecord::Base#save does not guarantee the absence of duplicate record insertions, because uniqueness checks on the application level are inherently prone to race conditions. For example, suppose that two users try to post a Comment at the same time, and a Comment‘s title must be unique. At the database-level, the actions performed by these users could be interleaved in the following manner:
User 1 | User 2 ------------------------------------+-------------------------------------- # User 1 checks whether there's | # already a comment with the title | # 'My Post'. This is not the case. | SELECT * FROM comments | WHERE title = 'My Post' | | | # User 2 does the same thing and also | # infers that his title is unique. | SELECT * FROM comments | WHERE title = 'My Post' | # User 1 inserts his comment. | INSERT INTO comments | (title, content) VALUES | ('My Post', 'hi!') | | | # User 2 does the same thing. | INSERT INTO comments | (title, content) VALUES | ('My Post', 'hello!') | | # ^^^^^^ | # Boom! We now have a duplicate | # title!
Something to watch out for as you scale or build out your Rails app. This is the kind of stuff that only bites you when you get bigger.
Here's how to have your gem and eat it too. It's been quite a pain previously to try and a) modify functionality in a gem and b) also use it in a working dev project directory.
Previously, I've had to resort to git submodules or other horrendous integration points. But now (this is SO simple) I realize all I have to do is:Tada! Now your production / staging / other development instances (and your dev buddies) will pick up whatever is checked in as a gem, but you'll be able to mess around with your local copy of the gem and work on it without any hassle.
Don't forget to update your VERSION, generate a new gemspec, and push to github to make sure everyone else picks up your changes when you're done making changes to your gem.