Colin Putney recently released a preview version of a new Smalltalk web framework, Altitude.
Altitude seeks to be a RESTful Seaside: an HTTP framework that uses RESTful URLs, ubiquitous use of Xtreams, and learning the lessons of years of Seaside development.
Let’s take it for a spin!
Admittedly, more and more of them are doing this already, but this is a slightly more DIY option…
So, you’d like some more reading material for your Kindle. Maybe you’re going away for the holidays, or just want to survive the elongated journey times of the Olympic period. There’s a few blogs I’d like to read more of, but I’d never gotten around to because of the sheer volume of back-reading I’d need to do first. What if we could dump those blogs (and blog-like things) onto the Kindle? Glad you asked, as that’s exactly what I’ve put together. (more…)
At the first mention of configuration management (CM), everybody and their dog (and links on their respective blog posts!) will direct you to one of what I take the liberty of calling ‘The CM Triumvariate’: Puppet, Chef and CfEngine 3. But I reckon the interwebs is presenting a skewed view and hides from you some real, useful alternatives.
“Alternatives?! With a gazillion resource types, cloud integration, and promise theory readily available, what else could you you possibly want to manage your thousand server infrastructure with?”
If I may reply with a question, can a developer use any of them, say, to provision a bunch of remote hosts directly from his developer machine without installing any additional software?
Sometimes one has a set of interrelated (monotonic) recursive equations one needs to solve. An naïve implementation will recurse infinitely. Handily there’s a solution: the least fixed point. I had need of one the other day, implementing parsing with derivatives. So why bother with least fixed points? Let’s find out…
You start off meaning to contribute a tiny tweak and then forget about it, and you end up spending hours writing reams of multithreaded C code.
A friend posted to Twitter asking for help optimizing his code to find double word squares. I spotted a small optimization: instead of copying his working state for his recursive search, he could just undo his changes, and pass around a reference to a single shared data structure. A 10% boost!
However, not long after that it started to look like we’d nearly exhausted the room for optimization in Python, and were nowhere near being able to solve the more difficult cases. The inner loop seemed simple enough, and conveniently doesn’t directly do any string manipulation, instead handling references. So it seemed easy enough to convert to C. It still seemed like I might stop there. But no; then came the multithreading (very hacky at first, then cleaned up) and the replacement of the implausibly huge hash table with direct calculation at the point I needed it for a big saving in memory usage, to the extent we could hope to fit in L3 cache.
Finally, it was optimized enough that, given less than a day to work, it could handle any wordlength. I can report that with our dictionary, there are no double word squares for words of 9 letters or more, and for 8 letters all 42 double word squares are word squares (ie symmetrical around the leading diagonal). Rather sad!
You are currently browsing the LShift Ltd. blog archives for July, 2012.