For The Skril of It

I recently created a new site, Skril, which is a prediction engine with Twitter oAuth for login. So far, the only game running is the daily, "What Will the Dow Industrial Average Close At Tomorrow". If you guess correctly without going over you could win the game prize.

Skril started out as python project (Tornado + CouchDB) but quickly morphed into a ruby project (Doozer + Unicorn) sometime last week. I had a great time learning about CouchDB and it's potential applications. In the end, I found myself starting to rewrite some of the base functionality that I've put in place with Doozer and just said, "Enough, already!"

Give Skril a try. If you win, I'll give you an Amazon Giftcard. Good luck! When time permits, I'm going to add a new game type for predicting the final scores of Basketball and Football games.

Doozer Rides the Unicorn

I added Unicorn support to Doozer this evening.

Add 'server: unicorn' in your app.yml clusters section and that's it! To start the server from app_root: script/cluster -C start.

To start the server with an Unicorn config-file just pass '-c FILE' to the cluster script.

Doozer support for Unicorn was necessary because Rack doesn't come with a default handler like it does with CGI, FastCGI, Mongrel, EventedMongrel, SwiftipliedMongrel, WEBrick, LSWS, SCGI, or Thin.

Twitfaced - Real-Time Twitter/Facebook Client

I coded a demo application called, Twitfaced, using Tornado Web Server and Framework. It has a few minor dependencies (see the readme).

The basic functionality allows you to stream your twitter timeline and/or facebook newsfeed in real-time. It also handles updating statuses to both, as well.

Future improvements include:

1. Retweeting and @Replies
2. Facebook Post Commenting
3. Better error handling

ActiveRecord and The Dreaded RuntimeError: Mysql::Error: MySQL server has gone away

I've been running Doozer on mzk.me since starting the Doozer project. Mzk is configured to use ActiveRecord for its ORM and is not anything other then a simple url shortening service (you know they're all the rage these days?).

After scanning my log files one day, I came across the following error:

This error meant the site was dead in the water. ARRRGGGHHH!!! Now, I like water, but not dead things in the water. Thankfully, the error led me in the right direction.

It turns out: MySQL defaults to 8hrs. of inactivity before it releases all open connections. See here and here. To adjust this value you need to configure the 'wait_timeout' variable.

Logically, this seems like something ActiveRecord should check if a connection exists and open one if it doesn't. Having never come across this error before (I know one of the side effects of having a not-so-popular domain) I automatically assumed ActiveRecord would handle this and open a fresh connection.

ActiveRecord has a few deprecated methods #allow_concurrency and #verification_timeout which may have solved this at one time, but no longer do or list alternate solutions.

In the end, I ended up taking the hackish way out and setting up a cronjob to ping the webserver every 6 hours to reset the wait timeout period. This solved the immediate problem but wasn't the solution I was looking for.

Doozer 0.1.5 Released

I added project configuration support for loading a specific Doozer gem version this evening.

All you need to do is declare the version of the gem your project requires and it automatically loads it for you. This is facilitated from 'config/boot.rb' which handles the loading. I have one small change which isn't committed to load 'grippy-doozer' (github gem version) if it exists. I'll commit this with the next patch.

Next up: Turn some of the project generator templates into Erb files to make them easier to maintain.

Migrated mzk.me to Doozer

I spent all of 20 minutes today migrating mzk.me over to Doozer 0.1.4.

In the process, I realized that there is no way to specify a Doozer version dependency from within a project.

Right now, this isn't a huge deal since I'm only running Doozer on two apps. But it could quickly get out of hand if I start adding new features.

This seems like it should be pretty trivial. I'll work on it as time permits.

Introducing: Doozer MVC Rack Middleware

I just posted a version patch for the Doozer project I released earlier this week.

Doozer is a lightweight, Rack compatible, MVC framework built with Ruby I've been working on here and there since December 2008.

It borrows a few rails conventions. It comes with a project and file generator to get busy with. It currently features initialization support for ActiveRecord, DataMapper, or Sequel. It also features support for clustering out of the box.

So far, it's turning out to be pretty handy. But before that, how about some background info?

Nice Rack!

Rack is a simple Ruby middleware framework inspired by WSGI. It allows you to define applications, chain them together, and then map them to request paths. It also features adapters for many http servers (mongrel, thin, webrick, etc.).

Doozer is a piece of Rack middleware which globs onto root requests. However, it also allows you to override this behavior if you want to map a specific path outside of Doozer. In addition, you can also define routes and have them processed by Doozer or have them handed off to a sub-application within the Doozer middleware.

Test Coverage

I finally added the foundation for testing the Doozer gem. I would say the test coverage is only 5% as of now. So, I have some more tests to write.

Git Cheat Sheet

I came across this ultra dope git cheat sheet. It's missing a cheat for deleting files.

Never fear.

All you need to do is delete the file and on the next bulk commit it's automatically removed.

Or, you can run 'git rm filename'.

Reboot, Reload, Retool

I scrubbed the old Typo blog and decided to roll my own. This should hopefully give me the old kick in the arse to actually write about all the code related nuggets I find on a daily basis.

We'll see how it goes.