At my current job we are building mobile web applications using Sencha Touch, and one of my responsibilities is to make sure that the applications loads as fast as possible. And that as lot to do with javascript minification, as pages load faster if they have to load less and smaller files, but writing all the application in a single file is really a bad practice, so I had multiple JS files to minify into a single one. Initially I tried rack-pagespeed, but it was slowing my requests too much (my page was dynamic, and I couldn't use HTTP Conditional Get for the first request, as suggested by the gem's author).
There are ton of minification solution out there, but I haven't found an extremely simple one that I could run even offline, programmatically, as I've learned that minifying 450 KB of JavaScript code is something that is better done once at deploy time (I love Capistrano!). I've written my own gem, which is just a simple rake task: rake minify. It's extremely simple to setup and use, but if you found bugs or feature suggestion, feel free to contact me.
Recently I've been implementing over and over again (well, 3 times :P) the same authentication pattern: http basic with fixed password. Every time I build a small prototype or a project for a single user, I need to protect it in some way. Well, I really hate messing with spaghetti-code solutions, so I build my own gem to solve this problem: Yauth.
Citing from my own writing on Yauth website:
Yauth is a extremely simple authentication solution for prototypes, and provides a drop-in solution for http basic authentication. It uses a yaml file to store usernames and hashed password combined with the http basic authentication. The whole gem provides a better-than-nothing security, and it was designed with small prototypes in mind. It is entirely developed as a github.com/hassox/warden strategy, the same library on which the popular Devise is based.
Yauth to store username and password pairs in a yaml file, and because the password is hashed (BCrypt), you can check that file in the Vesion Control System (I hope you use git!).
So you are building a small web app? or a prototype? Give Yauth a try.
UPDATE: I released a new version (0.2.0) which uses BCrypt instead of SHA2.
At my current workplace (Mavigex), we are using Delayed Job (DJ) to import a really big XML file, containing links to thousands of images we have to process in order to generate thumbnails and mobile versions. Once a week, we go through all the fetched images to update them if they were changed: we created a delayed job with low priority for each of them. We ended up with a delayed_jobs table of 300k jobs.
I was experiecing a massive slowdown with 300k entries in the delayed_jobs table, here is a snippet of the mysql-slow.log:
# User@Host: >ZYX[XYZ] @ localhost []
# Query_time: 9.354156 Lock_time: 0.000093 Rows_sent: 5 Rows_examined: 18919
SET timestamp=1296832078;
SELECT * FROM `delayed_jobs` WHERE ((run_at <= '2011-02-04 15:07:49' AND (locked_at IS NULL OR locked_at < '2011-02-03 15:07:49') OR locked_by = 'delayed_job.1 host:ip-XYZ pid:12346') AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT 5;
That query is the one each worker does to fetch new jobs to execute. Why was the db examining ~ 20k jobs for each query? Where did that number came from? I had nearly 20k failed jobs in my table, and the DB was passing through all of them before fetching the right results. That happened because all the failed job had by construction a lesser runt_at column than the jobs to be executed, and they were the same priority. So in the index on columns "priority, run_at" they came before the expected results.
I needed way to tell the DB to skip all those failed jobs, so I changed the 'dalayed_jobs_priority_index':
Bingo! The execution time of that query dropped to 0.2s.
One way to avoid this problem at all is not storing all the failed jobs in the DB, but sometimes some debugging information is needed.
I know I'm stretching DJ capabilities a bit, and I don't know if this change should be applied to everyone. However I've opened a bug: https://github.com/collectiveidea/delayed_job/issues/issue/202.
I'm using DJ 2.0.6 on MySql 5.1.
