Sunday, 22 August around 2 o'clock pm
Browsing around on hacker news one day, I came across a link to a paper entitled "A micro-manual for Lisp - Not the whole truth" by John McCarthy, the self-styled discoverer of Lisp. One commentor stated that they have been using this paper for awhile as a code kata, implementing it several times, each in a different language, in order to better learn that language. The other day I was pretty bored and decided that maybe doing that too would be a good way to learn something and aleviate said boredom. My first implementation is in perl, mostly because I don't want to have to learn a new language and lisp at the same time. The basic start is after the jump.
Tagged:
Perl
Programming
Read More -
permalink
Sunday, 1 August around 6 o'clock pm
Modern web applications are complicated beasts. They've got database processes, web serving processes, and various tiers of actual application services. The first two generally take care of themselves. PostgreSQL, MySQL, Apache, Nginx, lighttpd, they all have well-understood ways of starting and keeping themselves up and running.
But what do you do if you have a bunch of processes that you need to keep running that aren't well understood? What if they're well-understood to crash once in a while and you don't want to have to babysit them? You need a user space process manager. Zed Shaw seems to have coined this term specifically for the Mongrel2 manual, and it describes pretty accurately what you'd want: some user-space program running above init that can launch your processes and start them again if they stop. Dropping privilages would be nice. Oh, and it'd be cool if it were sysadmin-friendly. Oh, and if it could automatically detect code changes and restart that'd be nifty too.
Tagged:
Programming
Perl
Proclaunch
Read More -
permalink
Wednesday, 2 June around 5 o'clock pm
As some of you might know, Twitter provides a streaming API that pumps all of the tweets for a given search to you as they happen. There are other stream variants, including a sample feed (a small percentage of all tweets), "Gardenhose", which is a stastically sound sample, and "Firehose", which is every single tweet. All of them. Not actually all that useful, since you have to have some pretty beefy hardware and a really nice connection to keep up. The filtered stream is much more interesting if you have a target in mind. Since there was such a hubbub about "Lost" a few weeks ago I figured I would gather relevant tweets and see what there was to see. In this first part I'll cover capturing tweets and doing a little basic analysis, and in the second part I'll go over some deeper analysis, including some pretty graphs!
Tagged:
Programming
Perl
Read More -
permalink
Sunday, 9 May around 8 o'clock am
After using Calorific for a month two things have become very clear. First, I need to eat less. Holy crap do I need to eat less. I went on to SparkPeople just to get an idea of what I should be eating, and it told me between 2300 and 2680 kcal. I haven't implemented averaging yet, but a little grep/awk magic tells me I'm averaging 2793 kcal per day. This is too much. So. One thing to work on.
Second, in the morning after I come back from lifting and sit down to enter my breakfast, I just add three lines to my calories file:
- 2010-05-07 breakfast:
- 1 workout breakfast (blues)
and then type calorific in my shell, it takes ages to start up. Literally several seconds on a cold cache. I was pretty sure that this was due to the fact that I use Moose to help me define the four classes that compose Calorific. Now, Moose is great. Before writing Calorific I had only used a really old version of Class::MethodMaker or Class::Struct to build classes. That or build them myself, which is always fun (FUN FACT blessed array refs are wicked fast if you can get away with them). Moose is sort of a revelation. In the simplest case, you can say
package Foo::Bar;
use Moose;
has [qw/ baz blah frob /] => (is => 'rw');
1;
And you have yourself a fully functional class with three properties with read-write accessors. Pretty snazzy. However, you can get way more advanced:
package Calorific;
use Moose;
has 'filename' => (
is => 'ro',
required => 1,
);
has 'recipes' => (
is => 'ro',
traits => [ 'Hash' ],
isa => 'HashRef',
lazy => 1,
default => sub { {} },
handles => {
getrecipe => 'get',
setrecipe => 'set',
},
);
has 'entries' => (
is => 'rw',
traits => [ 'Array' ],
isa => 'ArrayRef',
lazy => 1,
default => sub { [] },
handles => {
addentries => 'push',
filterentries => 'grep',
numentries => 'count',
allentries => 'elements',
sorted_entries => 'sort',
},
);
1;
This is directly from Calorific. It defines three properties: a read-only simple scalar named filename which is required to be present in the call to new(), a recipes property which contains a hash ref and gets two accessors, get_recipe and set_recipe, which you call like this:
$calorificinstance->setrecipe('foo', 'bar');
$calorificinstance->getrecipe('foo'); # returns 'bar'
In addition, it sets up one more property named entries which contains an array ref and defines five accessors. There are actually more accessors defined than the code uses, but they're basically free so why not? You can see what they do and their calling conventions in the Moose::Meta::Attribute::Native::Trait::Array docs.
Ok, so Moose is great! Except, it's slow. Way slow. Wicked slow, especially on a groggy cache like my laptop has when I rudely wake it up in the morning and demand it actually do something for me for once. Geeze.
HOWEVER, there's a neat little project called Mouse, which has the lofty goal of emulating all of the sugar of Moose without any of the fat. Meaning, it doesn't pay nearly as large of a compile-time penalty that Moose does while retaining most of it's meta-y goodness. I ran one little command on the source tree yesterday evening and bam, just like that, everything was three times as fast.
find . -name '*.pm' | xargs perl -pi -e 's/Moose/Mouse/g'
Actually I had to install
MouseX::NativeTraits from CPAN before everything worked but that's just details.
Anyway, the moral of the story is that Moose is great and makes building classes really easy and all, but if you care about startup speed and not so much about delving into meta classes and such, Mouse should be your go-to class. And in fact, you don't have to make that choice. There's another project called Any::Moose, which will load Mouse unless you declare you want Moose, which can be set with an environment variable. Pretty neat.
Tagged:
Perl
Read More -
permalink
Thursday, 8 April around 7 o'clock pm
I'm a nerd. I write software for a living. I spend a lot of my day either sitting in a chair in front of a computer, or laying on my couch using my laptop. I'm not what you'd call... athletic. I did start lifting weights about six months ago but that's really just led to gaining more weight, not losing it. A few years back I started counting calories and I lost some weight, and then stopped counting calories and gained it all back. Time to change that.
Now, I could use one of the many, many online calorie trackers. They're all ok and they have the advantage of being able to enter data whenever and where ever you are, but most of them have ads and using a web interface is kind of slow and staring at ads sucks. Also, the reports you can generate from them are always a bit limited. What if I want to see a monthly average of how many calories I ate as snacks? Or how many calories I shoved down my gullet from fast food? Or maybe I want to track another nutrient, like grams of protein. Doing all of this through a limited web interface would be tricky, to say the least. There has to be a better way.
I've been using this program called ledger for more than three years now to keep track of my finances. The idea is that you maintain a text file that contains all of your transactions in a really simple format, and then you can run basically arbitrary reports on it. I always have emacs open, so maintaining that file is a snap. I'd like to maintain my calorie history in the same way, using a lightly formatted text file. I actually tried to use ledger for this purpose but the syntax just wasn't right. What I really wanted was a way to build up foods from simpler foods, and have those be built from other, simpler foods, all the way down to calories. Something like this:
1 cup milk = 100 kcal
1 scoop protein powder = 65 kcal
1 protein shake =
1.5 cup milk,
2 scoop protein powder
2010-04-08 breakfast
1 protein shake
I danced around this format for quite awhile, trying to parse it line-wise and trying to parse it with Parse::RecDescent and treetop, and nothing ever really fit. Then, I punted. What's a lightweight, human readable format that already has a parser built? Why, YAML of course! Here's the same thing as a YAML snippet:
- 1 cup milk: 100 kcal
- 1 scoop protein powder: 65 kcal
- 1 protein shake:
- 1.5 cup milk
- 2 scoop protein powder
- 2010-04-08 breakfast:
- 1 protein shake
The basic idea revolves around the concept of a recipe. Essentially, a recipe is a count, a label, and a bunch of components that can also be recipes. "100 kcal" is actually a recipe all by itself. Entries are just recipes that have a date instead of a count. At run-time, we resolve all the labels into recipes and then recursively get the values. Ideally everyhing will resolve down to a handful of base units, like "kcal" or "g protein", but if something doesn't resolve it'll get included right into the output.
So, ok, now I just need a program to analyze this stupid thing and print me some reports. That's where Calorific comes in. It's a little application (<500 lines, actually) that parses that YAML file and prints out either a detail or daily report. I have some big plans for it, including a report that gives the monthly average of daily totals, options to limit the date range you want to report, and 30 day moving averages. Installation instructions are in the readme file, if you'd like to try it out.
Tagged:
Perl
Programming
Ledger
Read More -
permalink