I still believe in what I said in my “What is SlowNews?” post: the move toward real-time random links and news is a bad move, in general. That basic part of the experiment is not why I’m dropping my weekly SlowNews posts.

This blog is more than 8 years old, and I’ve always posted to it for myself. I’ve posted thoughts that I wanted to work out in writing. I’ve posted things that I wanted to share because I thought they could help people. I’ve posted about things that I thought were interesting and worthy of additional commentary. I thought these SlowNews postings would fit in that latter category.

But, I haven’t particularly enjoyed putting those posts together in the format I’ve been doing. While it is a chance to reflect on the happenings of the week, what I’ve done so far has felt too random. There’s too little narrative. So, for now, SlowNews goes back onto the idea shelf, waiting for a better implementation.

This is the last issue of this SlowNews format. I may or may not try a new format. I’ve written a bit more about why.

Reactive JavaScript: Declarative Programming for Events

When a problem space is well understood, adding declarative forms can really save on a lot of work. Here’s an interesting look at the Reactive Extensions to JavaScript, created by the team at Microsoft that creative the Reactive Extensions for .NET. I didn’t find the syntax there appealing, but the ideas are interesting. The Flapjax project provides a nicer looking syntax, but requires a compilation step to pure JS (the compiler is written in JS and can run in the browser). I like the Flapjax tutorial reference to spreadsheets, because spreadsheets provide a great model for certain kinds of declarative work and tying declarative structures with additional imperative programming is very powerful. One of the reasons we chose SproutCore for Bespin is the ability to bind views directly to data so that the two automatically stay in sync.

A Collection of Redis Use Cases

Mathias Meyer’s Collection of Redis Use Cases provides a great collection of examples to give you an idea of where you might apply Redis in your own applications. In the “Not Only SQL” movement, Redis is a good tool to have in your toolbox.

Using node.js To Bootstrap a Server from Client Code

Dion Almaer wrote up the experience he and Ben Galbraith had in creating the Project Appetite site for Palm WebOS developers. Following the modern style of having the client do presentation and the web server just providing an API, they could work on client and server independently. It turns out that a quick way to get a server up and running was just to reuse client-side code on the server (in this case, using node.js).

Harmony: JavaScript Testing in Ruby

Harmony takes advantage of Johnson, a Ruby to JavaScript bridge and lets you write unit tests for your JavaScript code in Ruby. It’s not unreasonable to ask why, given that you can write the tests for your JavaScript code in, say, JavaScript… but, on first glance to me, the benefit here would seem to be that you can test server and client bits together conveniently.

Making Facebook 2x Faster

Jason Sobel gives the rundown on a 2009 project to make Facebook’s pages load twice as fast. This is a good account of what it can take to make a speedy site.

Thoughtworkers Subjective Impressions of VCS

Having trouble picking a version control system (VCS) for your next project? Martin Fowler has posted some general impressions that Thoughtworks people have picked up while working on client projects. I’ve worked on a variety of projects using a variety of tools (RCS, CVS, ClearCase, Subversion, Bazaar-NG, Mercurial, Git) and Martin’s roundup meshes pretty well with my own impressions.

Canviz: graphviz on Canvas

Need to produce a directed graph? Only care about the “modern” browsers? Then canviz is for you! Canviz is open source (MIT license) and lets you create a variety of graphs just as you can with the graphviz project, but entirely client side.

HTML5 Web Sockets Spec Reimagined

Tim Bray dove into the HTML5 spec and found a number of new features that he liked. He also went deep on the Web Sockets spec in particular, going so far as to produce an alternate version of the spec to make things clearer. Looking at Tim’s alternate, there’s a lot that he left alone.

State of Mono

Miguel de Icaza has written up an overview of what’s been going on with the Mono project. It looks to me like the Mono platform is still evolving quite nicely. If you happen to be near Ann Arbor on Thursday, February 25th, you can learn about the state of .NET web development at the a2

The MIT-licensed Ajax IM library lets you add instant messaging to your site and features a new node.js server side. This is certainly a good use for an async framework like node! The one thing I noticed while sitting on their site is that it has an unpleasant way of tacking things onto your browser’s history without actually going anywhere. Should you want to roll your own messaging, you could fire up Faye on node.js and use your favorite Bayeux client side library.

XHP: E4X for PHP

Did you know that some implementations of ECMAScript allow you to embed XML right in your JavaScript? I’d imagine many people don’t, because folks in the “real world” need to make sites that run on IE. Well, if you’ve been pining for the ability to embed XML right there in your code, or if you’ve been looking for a chance to turn PHP inside out, you’re going to love XHP, which Facebook recently open sourced. At the very least, you’ll go read about it and then learn about XHP’s implementation performance characteristics from none other than Rasmus himself.

wtfjs

OK, so I’m a well-known booster of JavaScript. But, you’ll never hear me say that it’s perfect. Every language has its warts, and wtfjs has an enjoyable collection of JavaScript’s.

LESS.app Now With Automatically More Less

LESS.app lets Mac users write their CSS in LESS and have that LESS automatically turned into valid CSS as they work. Languages like LESS are cool, because they have an opportunity to influence how the actual standards will evolve.

ePub in JavaScript

The ePub standard looks to be gaining serious momentum as an ebook format, albeit without the support of the top selling ebook reader to date. There has been a good bit of work done to create usable ePub readers in JavaScript, and Michael Mahemoff has a good roundup over at Ajaxian.

> list
11 goto 11

Top 11 JavaScript Features (from wtfjs)

11. "string" instanceof String; // false.
10. typeof NaN // number, of course.
1.

(function(){
  var x = y = 1;
})();
alert(x); // undefined
alert(y); // 1 -- oops, auto-global!

What do you do if you have to serve up 400 billion PHP page views a month? You don’t, because you’re not Facebook. But, for Facebook speeding things up can make a real difference on their compute costs. Their newly open sourced tool HipHop translates PHP to C++ and then compiles the result with g++. Net benefit? Apparently 50% less CPU usage. Nice!

Also, check out Paul Biggar’s take on PHP compilation and how HipHop impacts the phc project.

Mozilla Weave Hits 1.0, Adds Developer APIs

The Mozilla Weave project recently shipped 1.0 of their Firefox extension that synchronizes information (securely and privately) between your browsers. This week, the Weave team has announced Python and JavaScript client libraries and APIs in general for accessing this data. They have web-based and iPhone clients as prototypes, which is really cool. Personally, I find the identity aspects to Weave very interesting and hope to see more experimentation and implementation of identity directly in the browser (how many more username and password systems do you want to implement?)

Disclaimer: I work for Mozilla Labs.

Redis Goes Beyond RAM

Redis is a very useful disk-backed key/value store with lots of interesting atomic operations. It’s always had the limitation that the entire dataset needed to fit in memory. antirez explains how that limitation is removed in Redis 2.0. The concept of virtual memory is lifted straight from OS theory and practice, but the application-level implementation is a better fit for Redis’ needs.

Homebrew: OS X’s Missing Package Manager

Homebrew continues to be a fairly stealth project, I think. If you’re a Mac user, though, it’s worth looking at. It’s a super simple package management system that makes it easy to install many common packages and even makes it easy to manage packages that you download and build yourself. Andre Arko posted a nice introduction.

Removing Features

Lukas Mathis has written one of the best articles about removing features that I’ve seen. It’s always tempting to keep adding more, when really adding better is really what’s required.

More On The Use of h.264

The hubbub around h.264 that I talked about in the first SlowNews issue has a great new summary courtesy of Ben Schwartz. Ben took the actual license text from various pieces of software that produce h.264 videos, making it plain as day that people creating videos and posting them online are quite often in violation of the patents. Whatever people may think of Theora’s quality, at least it is unencumbered.

Mugtug Sketchpad: Fast Painting with Canvas

If you’ve doubted the growing ability of standards-based webapps to fully replace many desktop apps, Sketchpad should sway you. As long as you’re not using IE.

Detailed Riak Overview

Sean Cribbs insists that you should use Riak for your next Rails app. I’m not likely to be created a Rails app any time soon, but this was still a good overview of Riak. I’ve personally had a lot more exposure to MongoDB and Redis than Riak, so it’s nice to get a feel for what Riak’s all about. Also worth a look: Riak now supports JavaScript-based map/reduce jobs.

Rails 3 Beta Release

I don’t intend to include beta releases or vaporware here in general, but Rails 3 has been in development for a long time and is coming out from under its merger with Merb. So, in case you missed it, here’s DHH’s post about Rails 3.0’s beta.

Free F# Book

I’ve been impressed by some of the directions in which Microsoft has taken their development tools. The F# programming language, a functional language, seems like the kind of thing you wouldn’t see coming out of Microsoft (or, at least, beyond the research prototype stage). But, it’s certainly well beyond research prototype and now you can even get a feel for F# from a new, free book by John Puopolo with Sandy Squires.

> list
11 goto 11

Top 11 Reasons Why There Was No List Last Week

11. Perhaps every other SlowNews issue has no list?

10. There was no list?

1. I forgot.

Obviously, the iPad was introduced this past weekend and probably a million words or more about it have spilled out onto the net. Here’s just a few of those words.

Yehuda Katz takes the open side in “A GREAT Day for Open Technologies”. Actually, Yehuda takes both sides. Apple has created a closed platform while at the same time creating a very powerful platform for the Open Web. The trouble is that if you view the iPad as the future of computing, it is a scary thought as a geek to work on a platform that is so closed off. That’s more of Peter Kim’s take.

Personally, I agree with stevenf’s take that the iPad is the “new world” of computing, and it’s really a better world for most users. But, it’s only “new world 1.0″. It requires another computer. It can’t print. I believe that Apple is going to create a Time Capsule sort of device to which you can dock iPhones and iPads without needing a full computer, because an iPad is a full-enough computer for most people. For now, though, iPad is going to start making its way in the world as that “third device” that Steve Jobs referred to upon introducing it.

Mark Pilgrim and I apparently had similar tracks to learning computers (though mine was a TRS-80 Model III, not an Apple ][). He worries that future tinkerers will be left in the cold because of devices like iPads. There’s a huge difference between now and a couple decades ago. Computers were all for tinkerers then. Computers are for everyone now. I think there will remain ways for people to tinker.

iPad SDK: No Multitasking, New Shared Files

MacRumors has a quick rundown of the new iPad SDK. It has support for external displays (for Keynote, I’d imagine). No multitasking is supported. There’s a new shared filesystem, which is presumed to be the way to get iWork documents onto the tablet. There’s also said to be support for apps that support both iPad and iPhone, which should be interesting.

zeromq: Very Lightweight Messaging

Martin Sustrik and Martin Lucina have written an article about zeromq (“a new approach to messaging”), which looks to be about as minimal a messaging system as you can imagine. It’s got an API that’s patterned after BSD sockets. The comments that follow the article are quite interesting and useful as well. There’s a comparison of zeromq, AMQP and RestMS and the different kinds of things those are good at. RestMS actually sounds quite interesting to me. I’ll need to read a bit more about Zyre, which is a RestMS implementation.

ScriptCommunicator: Long Polling for Every Browser

Amir from Plurk has created a small (80 lines) module (ScriptCommunicator) for doing long polling, regardless of the browser. Even if real time isn’t right for everything (this is SlowNews after all), Comet is quite important and this little library deals with some of the tricky bits for one style of Comet.

(fab): A DSL for async coding with node.js

fab will likely remind people of Lisp, because of all of the parentheses. Look more closely, and you’ll notice that the parens are not nested… because this is proper JS, and fab is working through function call chaining. The goal of fab was to provide a nice way to define how URLs get handled in a node.js-powered web app. It’s a neat idea and the result is reasonably clean.

gccgo is Official

GCC 4.5 is slated to include Go. It will be interesting to see when Go-based projects actually start appearing, and when the first Go-based “killer app” arrives on the scene (think of what CouchDB and RabbitMQ have done for Erlang, for example).

75% of Linux Code is Written by Paid People

Over the years, I have seen a number of people characterize open source as written by “hobbyists”. That isn’t actually a derogatory thing to say, because people volunteering their time to a project that they believe in and love will likely do it well and with gusto. But, I’ve always thought that the view of hobbyist-driven open source is not the likely picture for large and successful open source projects. Jonathan Corbet analyzed Linux kernel contributions across 2009 and found that 75% of the code came from people who were being paid to write that code.

Creating a significant open source project can be at least a full time job. For something like Linux, it’s obviously many full time jobs.

toppcloud: Easy, Reliable Cloud Deployment

The prolific Ian Bicking has just spread word of toppcloud. He’s been mentioning it on twitter for a while, but now he gives the full story. If you have to deploy server side code (and don’t mind using Ubuntu on your VPS), check out toppcloud as a way to potentially make things easier.

Hot Code Reloading for node.js

Blaine Cook has a branch of node.js that can hot reload modules. This is obviously great in both development and production, when implemented well.

A zsh Prompt That Understands Hg, Git, Mac Batteries

Steve Losh has created a seriously tricked out zsh prompt.

CommonJS: The First Year

CommonJS turned a year old this past week, and I wrote a retrospective on that first year. Short form: JavaScript is growing fast!

Geek Conversation Killers

Philip Guo has an interesting article about awkwardness of “geeks” in conversation. I have definitely both witnessed this and caught myself doing some of these things. If you’re a geek like me, put a few brain cells onto the task of watching for these things during your next conversation. Calley Soukup has an interesting collection of observations about how sci-fi fans communicate, dating back to 1999.

Feedback for SlowNews #1

“very promising debut!!!” @uhop

“Hypocrite. The article was posted today. Let’s see if it’s still here 24 months from now in the same form.” lutusp on reddit. Ed: this is odd, everyone has to start with a thought sometime. I’m pretty sure that in two years I’m still going to think that real time flow of random news is a bad thing.

The Original Goals

As laid out in my original blog post, we were seeking to create:

• A module system,
• A cross-interpreter standard library,
• A few standard interfaces,
• A package system, and
• A package repository

Note that the idea here is that this group creates specs, which will have multiple implementations.

The goal is to have these things working across as many operating systems and interpreters as possible. There are three major operating systems (Windows, Mac, Linux) and four major interpreters (SpiderMonkey, Rhino, v8, JavaScriptCore). Plus there’s “the browser”, which is a unique environment unto itself. That’s a fair bit of surface area to cover.

Oddly, I think the one of those eight “platforms” with the poorest implementation support is Windows. Most of the CommonJS developers are using Macs or Linux machines, so I’m not sure how much time has really been spent on Windows. I would imagine that JavaScriptCore on Windows is probably the least supported combination.

The good news, however, is that there are projects using all of those JavaScript interpreters and platform compatibility issues will ultimately be ironed out.

CommonJS and the ECMAScript Standard

The CommonJS group is a grassroots effort, and not some formal standards body. In some ways, however, it works like a standards body in that the people working on the standard are also implementing the standard-in-progress and using it to build real applications.

We have no control over the ECMAScript language, which is managed by the TC39 working group. However, there are a few people involved in CommonJS who are part of TC39, and I have firsthand knowledge of others who are keeping an eye on how things are going with CommonJS.

The CommonJS standard-in-progress is designed to work on a subset of ECMAScript 5 that can be made to work on today’s ECMAScript 3 interpreters. ECMAScript 3 is the standard that is running in all of the browsers. In other words, in a CommonJS application you can count on Array.prototype.forEach to be implemented. Obviously, applications can do whatever they want (array destructuring? knock yourself out, but your app will only work on SpiderMonkey and Rhino).

One certainty about CommonJS is that inventing new language syntax is out of scope.

The Module System

The CommonJS group has been remarkably good at avoiding bikeshedding. While there is discussion about names of things, there isn’t heated discussion about it. People are far more interested in issues of functionality and ease-of-use. This is a very good thing, and it allowed us to get modules out of the way early on.

Of course, the lack of bikeshedding doesn’t mean that everyone agrees on things. The CommonJS module system has its controversial aspects, but I think it does well given the constraints:

1. must work with ES3 syntax (destructuring could actually be useful, but we’re not going to do it)
2. modules should have self-contained namespaces and be explicit about data the want to export
3. it should be possible to make modules tamper-proof, though this is not a requirement
4. using a module should be competitive with using modules in languages like Python and Ruby

TC39 had considered adding modules to ECMAScript 4 and there are module proposals on the table for ECMAScript Harmony that would add some syntax to JavaScript that would look similar to CommonJS modules. Here’s a short module to give you an idea of what CommonJS modules look like:

var sillymath = require("extramath/silly");

exports.addTwo = function(num) {
    return sillymath.add(num, 2);
};

Personally, I find this to be reasonably concise with a nice level of explicitness. Some syntax sugar would be good, and I hope we get that in ES-Harmony. But, this syntax works fine today.

Of course, this syntax is not without controversy. The biggest controversy has been that require() is synchronous – the “extramath/silly” module has to be available as the module above is loaded. However, there are a couple of reasonable ways to deal with this problem and I am happily working with CommonJS modules in the browser which is the environment that is least tolerant to synchronous loading.

Controversy or not, this basic module system was ratified last winter and has been implemented on all target environments of CommonJS.

Discussion is ongoing for a tie-in to the module standard: the module transport standard. Without additional help from the browser or some additional scaffolding running in the page, the module syntax above doesn’t work via a <script> tag. By standardizing what that scaffolding would look like, it is possible for a variety of build tools, servers and client side libraries to come into existence to provide many options for loading modules in the browser. There have already been several implementations of CommonJS module loading in the browser, but a standard will make it much easier to mix-and-match client and server.

The Standard Library

I had hoped we’d get farther on the standard library than we have, but it can indeed be a long process. system and unit testing are the only ones that have been ratified at this point. We have come a long way on file access.

“What!?!?”, I hear you say, “there’s no standard for accessing files yet?” That’s right. And there are a couple of reasons that it’s been challenging to get there.

Consider that JavaScript does not even have a standard object to deal with binary data. That is a basic prerequisite to working with files. JavaScript strings are not the same as a binary data container. So, there’s binary data to handle, streams to figure out and then file functionality built on top of that. There’s also the consideration of whether file access is synchronous or asynchronous. We’ve made tons of headway on this, and there are certainly implementations of some of the specs. It’s just a matter of finishing them.

I’m hoping to see promises become a part of the standard, because some form of that interface is very convenient to use for asynchronous operations.

Standard Interfaces

We do have a very useful interface with implementations and people actively using it: the JavaScript Gateway Interface (JSGI). That spec has not yet been ratified, but it is getting closer and there are apps being built against it today.

Database access has not yet been standardized. It will be interesting to see if we can come up with a good interface that can usefully target SQL and NoSQL databases alike.

Package System

We have a recently ratified spec for packages of CommonJS code. I hope this will bring about a collection of good package managers with different focuses and targeting different environments. There have already been a couple of attempts to create package management systems, and the most fleshed out one that I’ve seen is Tusk, which is bundled with Narwhal. Once a few more specs are ratified, Tusk should be able to run on other CommonJS implementations.

Package Repository

Tusk is using GitHub as a package repository, and that is working okay for the time being. A couple weeks back, we got word that the jQuery plugin repository is going to provide a CommonJS package.json file for the ~5000 plugins in their database. This is exciting, because this infrastructure could prove to be very useful to us going forward.

JavaScript: Bubbling Up

2009 was a terrific year for JavaScript. In the browser, we’ve obviously seen tons of growth in increasingly sophisticated applications. I think the interest is steadily building to use JavaScript more and more outside of the browser. The two JSConf conferences (in Washington DC and Berlin) were great successes by all accounts I’ve seen. PhoneGap, Titanium and Palm’s WebOS have created ways for people to use web tech to create installable apps for mobile phones. node.js has been a huge driver for people to check out building scalable, asynchronous JavaScript apps on the server. And, of course, CommonJS is finding its way into more and more applications.

My Personal View

I had hoped to personally have more time to devote to CommonJS in 2009, but I am delighted at how a great collection of people have stepped in and carried the specifications and implementations forward through a lot of hard work and force of will. More than 5,100 messages have gone across the mailing list, and more than 10% of those have been from Kris Kowal. Kris has done a ton of work in ironing out many of the specs and deserves a good deal of credit for where CommonJS is today. He and Tom Robinson even stood in for me when I had to cancel my trip to JSConf.eu (thanks, guys!).

Taking a look at the top posters on the googlegroup, you can see how many people have put so much into CommonJS. More than 10 people have contributed more than 100 messages a piece and, for many of those people, there was a lot of time spent in the email discussions, IRC chats, spec writing and implementation of those specs. Plus, as early adopters, they have the joy of tweaking things as the specs have changed over time. Thanks to all of you for the dedication and the will to get it done.

Bespin’s client side JavaScript code is all CommonJS modules now, partly thanks to the efforts of Charles Jolley to migrate the SproutCore framework to CommonJS and creating the Tiki module loader. From that standpoint, I’m already using more CommonJS now than I did in 2009. I’m also hoping that 2010 will bring a Bespin server “reboot”, where we start migrating server functionality to CommonJS.

On the whole, I think that 2009 was a great year for JavaScript and CommonJS and I think 2010 is going to be even bigger. I hope to meet more enthusiastic JavaScript hackers at JSConf.us in April!

Comments?

You can direct them to the thread on the CommonJS googlegroup or email to editor@blueskyonmars.com.

I’ve adopted my SlowNews newsletter-like format for sharing and commenting on what’s going on in the software world. A weekly post for software developers and technically minded product managers. This is a way to keep up with interesting things that are happening, but through the lens of a weekly view where the uninteresting is edited away, the more interesting is promoted to the top and a bit of commentary ties it all together.

SlowNews is a chance for me to gather my thoughts and to review the truly interesting things that are going on in software product creation.

Blue Sky On Mars SlowNews is published on Tuesday mornings at 9am Eastern time.

This is my first SlowNews issue. Read What is SlowNews?, if you’re curious about it.

Sikuli: Picture-Driven Scripting

Sikuli

The Sikuli project out of MIT has to be seen to really get a feel for it. The short of it is that it’s a scripting language for controlling applications that works by taking screenshots of the various controls that need to be clicked on or otherwise manipulated. Sikuli uses computer vision techniques to find a matching part of the screen at that point in the script. This is seriously cool.

Firefox 3.6: Speed, Personas and Video Controversy

Disclosure: I work for Mozilla. My opinions are my own.

Firefox 3.6 was released last week, representing a lot of work from a whole lot of people. JavaScript performance is faster still than the already fast 3.5 and there have been a number of other areas of the UI that tightened up, performance-wise. Personas made it into the main product (before they were available only as an add-on).

Unrelated to the 3.6 launch, there was some controversy as YouTube and Vimeo both announced support for HTML5’s video tag. Firefox supports the <video> tag, but not the H.264 codec used by both YouTube and Vimeo. There are some very good reasons for this, which Mozilla’s Mike Shaver went into detail on. Chris Blizzard went into even more detail, and provided an interesting historical comparison with gif. Those are worth reading if you produce any videos for consumption on the net, because the issue extends not just to browser manufacturers and sites like YouTube. Even people producing videos encoded with h.264 may find themselves with a bill to pay come 2011.

Pintura: CommonJS/JSGI Server-Side JS Framework

Kris Zyp introduces Pintura, a server-side JavaScript framework that keeps the presentation on the client side where it belongs. Kris also wrote a Getting Started with Pintura article that’s worth a read. Pintura wins bonus points for running on node.js, Narwhal and Flusspferd. For those keeping score at home, that means that Pintura can run on SpiderMonkey, v8, Rhino and JavaScriptCore. That’s what CommonJS is all about!

Amazon Kindle: There’s An Active Content For That?

Amazon has announced a development kit for the Kindle, coming in February. The SDK will allow developers to create “active content”. Active content will certainly be different from iPhone apps, if for no reason other than the refresh rate of the eInk screen. Still, it’s an interesting development. Amazon has never said how many Kindles they’ve sold, but you can bet it’s less than the tens of millions of iPhone OS devices out there. You can sign up for the beta now.

Letters.app: Concept-driven Open Source

The Letters Icon

Most open source software begins its public life with code. It obviously started out as an idea and was built up following some need or desire, but by the time it’s public there’s some code. The currently-vaporous Mac mail client “Letters.app” started off with NetNewsWire developer Brent Simmons saying he wanted a better mail client. Macworld commented on the literally hundreds of email messages that followed. John Gruber was elected president for the 1.0 release, and Gus Mueller has taken on the technical leadership. Gus has also started a GitHub repository for Letters.app.

This is a really interesting way to start an open source project, and I wish them well. As has been pointed out on the mailing list, creating a better mail client has been tried before and failed. But, the leadership of the project is encouraging and this is certainly one to watch.

Fusebox Gives You Safely Extendable JS “Natives”

JavaScript is cool in that you can extend String or Array to add many conveniences. It’s not so cool in that others may do it for you, and in ways that are not quite what you want. If you’re willing to suffer through a bit of inconvenience (like declaring an array by calling fb.Array() rather than just []), Fusebox lets you extend native objects without impacting any other JavaScript code.

LuaJIT Gets Funded

It’s news to me that Google uses Lua internally, but they apparently do count Lua among the languages they use. Enough so that Google has pitched € 8,000 into the development of LuaJIT. Add to that Athena Capital Research’s € 12,000 and a couple of smaller donations, and you’ve got a successful funding drive. It’s great to see open source development supported so directly.

Realism In UI Design

Realism in UI Design is an excellent article for anyone who might be contemplating just using photos from iStockPhoto for their icons rather than having a custom icon set designed for their app. For everyone else, it’s a good read with some nice visual reinforcement about striking a balance in realism in your user interfaces. Also worth checking out is Mike Rundle’s article from December which provides some tips for getting subtly realistic user interfaces.

Bill Gates Joins the Internet World

BillG seems to be going all-in with a new Twitter account and a bloggy sort of site (The Gates Notes). Whatever you may think of Microsoft and Gates’ driving of Microsoft, it’s impossible to deny that he’s a big thinker and one worth following. Speaking of following, after just a day on Twitter he has nearly 250,000 followers. The welcome from Ashton Kutcher (4.4 million followers) no doubt helped, though it’s unclear to me just how much overlap there is between Ashton Kutcher fans and BillG devotees.

Notable Releases

• Firebug 1.5 was released ahead of Firefox 3.6 with a bunch of new features. This is notable, because Firebug would always lag Firefox releases in the past.
• Cassandra 0.5 includes improvements to multicore performance, the bootstrap process and adds the ability to decommission a live node.

> list
11 goto 11

Top 11 Most Anticipated Product Introductions This Week

11. Microsoft Ribbon Hero for the Xbox360.

10. Google Sock Search

1. CrunchPhone

so far a2 <div> has turned out to be “A2 Javascript Lovefest”

While I certainly like JavaScript, that wasn’t intentional. We have to run with what people want to hear and are willing to talk about. Luckily for us, Trek himself was prepared to do something about it and gave a great talk last night about Heroku.

Trek had a demo ready to go, involving getting the open source code for RubyFlow running and customized. He had a neat way of doing the demo without resorting to live coding: he had the demo code in a git repository with separate branches for each step of the demo. It worked quite well and Heroku looks awesome. Video of the demo is available online.

In the loosely structured part of the meeting that followed, we had bits of discussion about a few different things, including a quick demo of Node.js by Majd. We also talked about what topics we’d like to hear more about in future meetings. Here’s the list that came up:

• Comparison of NoSQL engines
• Node.js or other Comet serving technologies
• The Microsoft stack for web development (Jay Harris offered to talk on this topic)
• Something involving designers + programmers (maybe even a “basic principles of design” intro to help us avoid creating designs with misaligned bits and eye bleed inducing colors)

The January meeting will be at its usual time and place (January 28th, 7PM, SRT Solutions). Topic to be decided.

Thanks to Trek for a great meeting at the spiffy Workantile Exchange!