I’ve been a fan of Lua since the early 2000s when a friend introduced it to me, even though I never got around to finding the time to properly learn and use it in production stuff. We have discussed about using Lua as a scripting language to allow for downloadable bundles that would extend AthensBook/ThessBook functionality (or fix bugs, or provide dynamically determined personalised features etc., but that never happened until now, due to licensing restrictions by Apple) for ages. Codify is an unbelievably cool app that leverages lua to provide a simple programming environment for the iPad. Combined with the general appeal of the device, the lack of third party, scripting programming environments for it, the ease of programming and use of Codify and the excitement of using such great hardware, I feel that Codify might be the Logo/Basic equivalent for this generation of children between the ages of 5-10, a great introductory platform for programming and an amazing tool for everyone else. And at $7.99 I think it’s a steal. You might want to use a bluetooth keyboard for it though; typing code on the on-screen keyboard seems like a horrible horrible nuisance.

One of the most annoying thing with Rails has always been how it provides for convenience at the expense of uncertain (and sometimes shady) abstraction implementations. It’s a great framework for prototyping, yet there are reasons why quite a few people are skeptical about it.

Nevertheless, in the truest tradition of Ruby, Rails provides a pretty clean way to do web application development. Rails 3, the latest incarnation of the framework builds upon a solid foundation, offering great improvements in many areas. But not everywhere.

Take for example the html_safe string escaping that supersedes ‘h’. In Rails 3, all input strings are automatically escaped, unless the developer passes the string through raw() before the string. That’s fine, as it’s bound to make sloppy developers safer by forcing them to go out of their way to leave the string unescaped. One of the issues with this, however, is how the old way of escaping, ‘h’, is still around in some cases: say when you want to render a link using link_to and you use raw to provide formatting to your link (via span) and include some part of user provided input (as found in the example provided in the xss and scripting screencast at 02:20), then you have to resort — once again — to using ‘h’.

This is confusing and inconsistent; if all strings are automatically escaped, you’d expect input variables to be automatically escaped too, even if included in strings using raw().