Every now and then, I enjoy solving logic puzzles (or attempting to). Recently I came across this one:
| | 3 | 17 |
| 5 | | |
| 13 | | 7 |
There are five prime numbers in a 3x3 grid, and the goal is to fill in the empty cells with four other prime numbers, so that the sum of every row, every column, and both diagonals is also a prime number, less than 100. Each number can only be used once, and this applies to the numbers in the grid as well as to all the sums. Lastly, the sum of all these numbers must be a prime number as well (greater than 100, obviously).
I took me quite a while to find a solution — but when I finally did, I had not one, but (at least) two solutions. The puzzle description didn’t mention anything about multiple solutions, so I thought I made a mistake along the way. However, having triple-checked all the math, I couldn’t find any errors. I decided it was time to use the force (I couldn’t miss the opportunity to use this phrase, considering the date when I’m posting this) — namely, the brute force.
When developing a Perl module, I often want to get a quick preview of the documentation that I'm writing, just to see if everything is in order and how it turns out. I used to do this the old fashioned way, by generating an HTML file with pod2html or pod2cpanhtml and opening it in a browser, but I was hoping in this day and age there is an easier and better solution, preferably a web application.
Looking around, however, the only thing I could find was the pod2html page at the CPAN Search site, which allows you to upload a POD file, have it processed by pod2html, and displayed with CPAN style. I thought it might be a good idea to try building something more user-friendly, with features like editing POD in the browser, drag and drop file uploads, etc.
And what better time for a little project like this than a weekend when you're ill and not supposed to leave your apartment? Well, that's what my last weekend was like -- two days of coughing and coding, and here's the result: POD Web View.
I have recently returned to working on Arriba, the PSGI-compliant web server with support for the SPDY protocol, modeled on Starman.
I sort of released it (on GitHub only, not on CPAN) back in January, at that time the code was passing the tests in Plack::Test::Suite when running as a regular HTTP/HTTPS server. My next goal, before considering the module ready to be released on CPAN, was to make it pass those tests in SPDY mode. This meant I needed to add support for SPDY to good old LWP::UserAgent, which was used as the HTTP client in Plack tests.
Over the weeks/months that followed, I made a few attemps at tackling this problem, but had a hard time wrapping my head around the architecture of LWP::UserAgent and figuring out a reasonable way to add SPDY into the mix. Having very little time to devote to this project, I didn't get anywhere with it.
Having some free time during the Christmas break, I decided to give a shot at a small project that I had in mind for a while, and that was to develop a PSGI-compliant(-ish) web server with support for the SPDY protocol.
In case you haven’t heard of it, SPDY is a networking protocol developed at Google with a goal of reducing web page load latency. It is currently used by some of Google services (including search and Gmail) and by Twitter, and is supported natively in Firefox, Chrome, and Opera — so if you visited any of those sites with any of those browsers, it’s highly likely that your web content was transmitted by means of SPDY. An official standard for the protocol is in the works.
Happy 25th Birthday, Perl! I made you a card:
perl -C -e'print map+(v9635 x8^unpack B8).(v10)[++$n%9],(unpack u,"MK__^=^WW_S_WK)FNO\$3F5U\$7BJJ.=>U51S-WK)GNM>UF=W%[K[N>?___SW__")=~/./g'