Andrew Cholakian’s Blog

I've been mulling over learning a new language for the last few months, I've done bits of reading here and there on Haskell, Lisp (via SICP), and a couple other languages. The more time I spend looking the more Clojure likes the answer. Haskell looks fascinating, but at the end of the day, perhaps too baroque and just not as useful. Lisp + the power and libs of the JVM seems flat out awesome. Worth reading are these excellent slides by Clojure's creator:

This list of solutions to common SQL query problems is insane. It's incredibly useful and deep. http://www.artfulsoftware.com/infotree/queries.php?&bw=1280

New Photo, my Oven Light:

I've been making some slightly odd food recently. To start with I made a dish from a '70s dairy centric cookbook, California Sour Cream Shrimp, which is shrimp cooked in a sour cream  and onion sauce with tomatoes and avocado (hence the California) seasoned with curry powder. The dish came out a sort of neon '70s yellow, that was initially off putting, but quickly made up for by the fairly good taste.

I also experimented with making tacos using Ezekiel tortillas, that is tortillas using only sprouted grains. I'm not sure Ezekiel bread makes for the best tortilla, but you can't argue with the health of these tacos, Grass Fed beef, spices, cilantro, red peppers, and some sharp cheddar. Definitely not a conventional taco.

   

Click here to download:

Recent_Cooking.zip (2357 KB)

Excerpted from here: http://www.nytimes.com/2006/01/29/books/review/29keillor.html?_r=1

If you're using the Engine Yard Cloud, and you want to run in a single master, single slave MySQL setup you can accomplish this pretty easily using Masochism. It's as easy as:

1. script/plugin install git://github.com/technoweenie/masochism.git

2. Create deploy/before_migrate.rb if you don't have it already, then add this line to it:

   run "sed -ibak -e 's/^production:$/master_database:/; s/^slave:$/production:/' #{shared_path}/config/database.yml"

3. Add to environment.rb (within the Rails::Initializer.run block):
   

   config.after_initialize do
     if Rails.env.production?
       ActiveReload::ConnectionProxy::setup!
     end
    end

Via the Stack Overflow Blog, an excellent post on writing parsers: http://www.cforcoding.com/2010/01/jmd-markdown-and-brief-overview-of.html

I've submitted the following to the nginx mailing list, after dealing with errors caused by this hard to dig up bug:

What I'd like to propose is having requests with headers with single lines larger than large_client_header_buffers respond with a status of 414 rather than 400. Additionally, large_client_header_buffers should default to a larger value, double the platform's page size, to bring up it up to an 8k minimum to match the largest cookie size in a mainstream browser (IE 8) which maxes out at 5117 bytes by my calculations.

I recently ran into this where very large (4.7kib) cookies from IE were causing requests to my nginx server to fail with 400 Bad Request errors. The underlying problem--besides the erroneously large cookie--was a too small large_client_header_buffers value. According to the nginx docs (http://wiki.nginx.org/NginxHttpCoreModule#large_client_header_buffers): "The request line can not be bigger than the size of one buffer, if the client send a bigger header nginx returns error "Request URI too large" (414). The longest header line of request also must be not more than the size of one buffer, otherwise the client get the error "Bad request" (400)."

The fact that it was a 400 error made it quite hard to debug, as the cause was rather ambiguous, and only a small subset of clients, due to app logic, had the swollen cookies. I ended up finding a particularly cooperative user and getting a TCP dump to ascertain the problem. Obviously, getting a user to agree to letting someone remote in and run wireshark is highly unusual, and it is my guess that nginx users who encounter this problem in the future are more likely to abandon nginx than go to this length to figure out the issue. An error like this should really provide more helpful info to debug on the server side.

I've run some tests on Firefox 3.5, Chrome 3, and IE 8 to see what their largest cookie sizes are:

Firefox 3.5.5:          4096 Bytes
IE 8.0.6001.18828:  5117 Bytes
Chrome 3.0.195.33: 4131 Bytes

These numbers were generated by this code, running on my home system, a Windows Vista 64 bit machine (all browsers are 32 bit):

var data = '';
var last_len = -1;
while (last_len < document.cookie.length) {
  data += 'x';
  last_len = document.cookie.length;
  document.cookie = data;
}
document.write('Max Size: ' + last_len + ' Bytes');

I'm temporarily hosting it here: http://www.andrewvc.com/cookietest.html for convenience if anyone else wants to test their browser.

On the menu tonight, Shrimp + Pancetta served atop fresh Polenta. Delicious.

http://www.epicurious.com/recipes/food/views/Shrimp-and-Pancetta-on-Polenta-356050

This year my contribution to my family's thanksgiving meal was a pear and blueberry gallete. I made a modified version of Alton Brown's No-Pan pear pie. This is really a gallete, a freeform tart, but it's quite pie-like. The crust uses corn-meal, which I'd not used in a crust before. I must say the corn meal adds a bit of crunch and grit that's fantastic.

I made a few modifications to this recipe to suit my own tastes. I'm not much of a sweet tooth, so I used 5 pears instead of 2, and got rid of the pound cake for the filling. I also multiplied the crust ingredients by 1.5 since some commenters on the recipe page mentioned the pie this made wasn't very big. This maxed out my food processor's capacity, and gave me just enough crust for the different quantity of filling. I also added in a more sugar to the filling to compensate for the reduction in sweetness I anticipated from removing the pound cake. The result was delicious. With these ingredients it created a gallete that had about 12 2"x5" pieces.