While walking in the woods this afternoon, I came across this red, tubular plant growing on some decaying wood.  Upon further investigation, I found that inside was a nice green mucous with lots of flies inside.  Then, the smell hit me.  It was definitely the most foul smelling plant I've ever encountered.  Interestingly enough, according to Wikipedia, its actually an invasive species brought over from Europe.  There's always something cool in the woods.

See the full gallery on Posterous

References:

http://en.wikipedia.org/wiki/Clathrus_ruber

Permalink | Leave a comment  »

Here's a nifty little piece of useless Ruby code:

and the result is:

require "quine"
this.that.and.something_else

Permalink | Leave a comment  »

I recently started a couple new projects (Rails 3 + mongoid) and I've noticed a pattern in the way I handle coded fields.  My key example is something like the following: you have a field, say status, that can have several values, say active, closed, and invalid.  Obviously you could store those as strings in the database or you can code them, say 0, 1, and 2.  Normal database practice is to code them as integers to save space but a far more important concern is that clients change their mind about what you call things.  So its much easier to just change the string values in some code than it is to go changing every string in the database.

Anyway, the usage is something like this (yanked directly from the README):

Here line 4 (the coded_options call) basically gets mapped into lines 6 through 14.  Nothing spectacular but it's really cleaned up my code quite a bit so maybe it will be useful to some other folks.  The code is up on github (http://github.com/jasondew/coded_options) and the gem is on gemcutter (http://rubygems.org/gems/coded_options).

Permalink | Leave a comment  »

I'm studying for the computer science Ph.D. qualifying exam and so I've started going back through my algorithms book (Intro to Algorithms by Cormen, Leiserson, Rivest, and Stein).  The first chapter was, of course, about motivating the study of algorithms.  One exercise that made an impression on me was the one that had you generate a table giving the largest problem you could solve in different amounts of time given different asymptotically complex algorithms.

Since I take every opportunity to make progress learning Haskell, I coded it up:

What the table shows is the largest value of n you could process given an algorithm of certain complexity and a certain amount of time:

* The values here aren't really infinity but they are over 300 digits!

So the lesson here?  Having an algorithm with a good asymptotic complexity makes a huge difference in the amount of data it is feasible to process.  Just look at the difference between linear complexity (n) and logarithmic complexity (lg n): 41 orders of magnitude!

Permalink | Leave a comment  »

For a project that I'm working on at my day job, we have a governmental client for which we are building a pretty large and complicated online/offline Ruby on Rails application. As part of this app there are tons of data-specific rules. For example, if a client with HIV is being assessed then certain fields may have to be displayed/hidden and there are rules that get applied differently. So lets say you have the following setup:

http://gist.github.com/205241

Now, somewhere in your code you want to be able to do take a specific action only if that client has a particular diagnosis. Without named_instances you might do something like:

http://gist.github.com/205250

With named_instances you can do the following faster and more concise code:

http://gist.github.com/205253

We've been using this functionality for about 6 months now and its been great. The gem is out on GemCutter (which rocks) and the repo is at GitHub. Hopefully it will be useful in your projects. Comments, criticisms, and patches welcome.

Permalink | Leave a comment  »

So based on some customer feedback on a project I'm currently working on, I added a validation requiring that one of the dates be in the past. The validation is pretty straightforward:

http://gist.github.com/188474

After re-running the test suite though, I got a couple of failures. After digging into the code, it turns out that the following code snippit evaluates to true!

http://gist.github.com/188475

Of course this makes no sense. What's more is that I tried the code again while writing this blog post and now its false. So I did some digging into the Ruby internals and it turns out that Time#< is implemented in C in the following method:

http://gist.github.com/189385

The best I can come up with is that there's an problem with the GetTimeval method since its just a macro that pulls out some data from a time struct -- but the Date class is implemented in pure Ruby. Anyone come across this or can explain better?

Permalink | Leave a comment  »

So I've been working on the Darwin hobby project again recently and decided to find out where the program is spending all of it's time. It turns out that there are some really nice profiling tools in Haskell (GHC to be specific). Armed with that, I found out rather quickly that the bottleneck was the getPixel function I added to the GD bindings.

http://gist.github.com/470216

My first thought was that it would be nice to grab all of the pixels at once instead of repeated (slow) calls to getPixel. So I read up on Haskell FFI and the GD documentation and churned out the following:

This code returns a nice Haskell array of arrays with the color information. This improved the speed from 1 minute per 10 iterations to 1 second per 10 iterations -- about a 60x improvement!

However, this only works with true color images at this point; no indexed palette support since that information gets stored elsewhere in the GD image struct. All in all, it was a very pleasant and rewarding experience into Haskell. Next on the list is (Erlang-style maybe?) parallelization.

BTW, the GD binding code is under the dependencies folder here.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Here are the slides from the talk I gave on Wednesday. Enjoy!

Permalink | Leave a comment  »

Awesome conference. Met lots of great people and the roundtable and ensuing conversation at the end were the best part. We need more of these kinds of conferences. Here are the slides from my talk:

I'm looking forward to next year!

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

I've been teaching a Statistics course at USC for a few years now and so, being the geek that I am, I decided a couple of semesters ago to write some course management software in Rails. I've worked on it on and off since then and I would consider it to be in a semi-usable state at this point. I've used it in my last two semesters without major problems.

The features at this point are

• course announcements
• course documents
• ability to assign multiple choice quizzes
• quiz statistics, including per question
• ability to add exam grades

The source is available at http://github.com/jasondew/learnstat. Please send any bug reports or feature requests to jason.dew at gmail.

Permalink | Leave a comment  »

So I decided to give the latest Ruby Quiz a shot. I created an Algebra module to deal with finding the root of a function -- using Newton's method.

and here is the more specific code to calculate the IRR:

Permalink | Leave a comment  »

I know its geeky, but I love it.  Its great practice -- http://refactormycode.com/.  The general idea is: people post code that they think could be written better and then other people refactor it and get rated on it.  How cool!

Permalink | Leave a comment  »

Cowboys live on the bleeding edge of technology and, therefore, tend to bleed at times (normally in the form of overtime). Of course, with risk comes reward. In software development this is increased productivity, more robust products, and programmer happiness.

Farmers, on the other hand, represent stability. They are willing to use the same tools, year after year, and normally produce steady results. They are the risk averse -- willing to do twice the amount of work with a tool that is comfortable rather than try a tool that is more specialized and/or capable.

Obviously, we need some sort of a balance between the cowboys and the farmers. Too much of either type is a recipe for destruction. However, I'm certainly a cowboy. I love learning new tools, especially when they get the job done better than the old tool.

Permalink | Leave a comment  »

Permalink | Leave a comment  »