Yesterday I made public a little project I’ve been working on lately: Brewer.js. It’s basically a asset manager. If you’ve been into this sort of things, you know I’m not the first to have that idea. What I’m trying to reach with this project is this :

1. A one-stop tool to kick start any project, no matter what external javascript/css libraries you need. Brewer.js would ship with common templates (bootstrap, jquery only, etc.) and you could roll/publish your own.
2. A streamlined way to keep track of dependencies (jQuery, Backbone.js, etc.), keep them up-to-date. e.g. you barely specify you need the latest version of libraries X, Y and Z, and Brewer pulls them and keeps them up-to-date for you.
3. A ”forget-about-it” way to package all scripts/stylesheets into neatly optimized files, even if the sources are a mix of javascript, (iced) coffee-script, tamejs, etc. Have them reference each other as if they were meant to live together all along.
4. Manage templates so they are as easily accessible from client-side logic as they are server-side. Bundle them together to reduce bandwidth usage.

The project is currently 0.3.2. Points 1 and 3 are implemented and ready-to-use for javascript, css, coffeescript, stylus and LESS. A branch was created to implement 2. After that, I plan on expanding language support to Iced Coffeescript, Coco and Move for javascript and SASS, Haml for CSS. Then, I’ll branch out development for 4, namely template processing (which should be a good fit with a static site generator).

Feel free to contribute to the project hosted on github. Fork the project and post issues! Oh, and a complete annotated and nicely formatted (using docco) version of all source code is available here.

Some time after all have been said, here is my take on the whole Apple TV, “I finally cracked it!” story. People have been either speculating on the future announcements, or just pointing out how it seems impossible for Apple to make something so interesting as to bring everyone on board for the next product targeting the living room. I plainly wanted to bring up how it could be possible for an disruptive company like Apple to make that exciting something.

With the observation that there exist a few apps out there, running on iOS devices that can stream live video content potentially to millions of users, an obvious application of this for a TV is simply to encourage such apps for content providers, so that it can stream to users not only at home, but everywhere. Plus they get better analytics about their viewers and provide a richer experience. That have been pointed out numerous times on the web lastly. It has the problem of relying on the content providers to do some work, just like what happened with magazines and newspapers.

A faster way of improving the experience for the user would be to wrap video inputs in apps. HDMI inputs could be handled as simply as just a stream of video content, so one could hook up gaming consoles. Cable inputs could be handled at a software level to integrate with other Apple services and functionalities like iCloud, Home Sharing and AirPlay (see next section), while matching video streams with the actual programming. Individual channels could become individual apps organized the way the user wants it to. This could allow the user to view program scheduling from distant iOS devices, selecting later shows and specifying which one to record for later. Knowing how Apple likes to minimize the amount of ports on its devices, it would probably ship it with as least as possible, selling adapters for more flexibility.

The nice thing about this is that, suddenly, everything becomes an app: your Wii or PS3, The Weather Channel, HBO, everything. For the users, it doesn’t matter if the content comes from the cable or over the Internet, they’re just apps, and for them it seems like some of these apps have richer content. So without the content provider needing to do anything, the experience is better for the user, thanks to Apple. Then the user might start prioritizing those apps where they have more control, or that offer that extra something that is only possible when using the Internet. There might even emerge apps that take an hybrid approach to simplify broadcasting: video pushed through cable, but extras pushed through the Internet.

Then, the usual story : Music, Video and Photos apps for accessing content on the network using Home Sharing, AirPlay streaming like it already does, and maybe iCloud to access documents, presentations, music and photos from the cloud. iCloud could also be used with its calendar service to work with channel apps and record specific shows or games. If iCloud can support device-to-device direct communication, and if there is no copyright issues against this, content could be streamed live from Apple TV to your iOS device, wherever you are.

Combine the current iOS remote apps with Siri as a somewhat more human way to interact with that device, we’re nowhere close to current TV sets. What’s still missing in that story is how they’d make us interact with “apps” in such a device. Clearly, the way they’re arranged in the iPhone, iPod Touch and iPad is not optimal for a distant display device, with which we’d interface using a remote or voice. I wouldn’t be surprised Apple can come up with a good way to do that.

When new interesting open source projects emerge, some of us hackers start scrutinizing it to see how it was built, how it managed to solve specific problems and how it approached issues like security, performance, etc. A debate, sometimes fierce, that arise every now and then, is about sticking or not with what is thought to be good practice.

Yesterday, if you happen to follow the same open source devs as I am on twitter, you might as well have lost a couple hours reading through a quite lively discussion about the choice of cryptography system to protect passwords, stored on Lamer News’ redis database. The core dev, Salvatore Sanfilipo, was trying to bring an educative discussion forward about the right system for the requirements, after being criticized for his early inappropriate simple solution – technically SHA-1 with a global salt. A lot of the people there were simply urging him to opt for what’s now considered as a good solution, namely bcrypt, without further development.

I think a part of the issue brought up can be approximated to this : A lot of people argue that projects should focus on the function they wish to provide, reusing proven libraries as much as possible, in order to simplify the work to just gluing them together. This is incredible about nowadays’ way of doing programming, and now tech businesses. Factoring out libraries usable by others and releasing them under an open source license is greatly valued today; programming stars rise and fall on github; the pace at which influential new projects are released is amazing.

Apart from the collaboration perspective, one perverse effect expressed by some community members can arise from this culture : Some people become dogmatic about the use of remote projects for solving problems, often quite specific to local constraints. Never should a library/database/template engine/[blank] be used in any serious project, without an thorough (and polite) debate – even just to oneself – on the available options.

As important to respect is the creativity of the developers, where a new solution might arise and later be factored out to a separate, open source project. This new solution might just be the perfect solution for the actual constraints and might become the next big thing. Even if that component is not directly targeted at the core function of the project, let’s not forget that programmers’ creativity is at the heart of today’s richness in software.

Virtually years after the announcements of Apple new iPhone and after reading a few interesting posts on the matter, such as this one, from Redis developer @antirez, here’s my take. One thing that jumps as obvious when we look at the way Apple advertises Siri, i.e. beta, is that it doesn’t want the massive number of iOS 5 adopters to beta-test their new service all at once, in the case things aren’t ready for the masses yet. Just like @danbenjamin pointed out in his last Talk Show podcast with John Gruber, it must really not be trivial to test a service like Siri in the scale required by the hundred millions iOS users. Throttling the flow of users of Siri seems like a efficient way to do just that. But Apple is not the kind of company to Beta-test their software in the wild.

A strong argument, and I think this is where the meat lies, is the product differentiating factor. But I think it goes beyond the idea of “just a feature that the other iPhone’s don’t have”. For the average user, it’s a major feature. It’s not just a piece of software, it’s a whole new experience. And by binding it to the iPhone 4S instead of iOS 5, people see this new experience as a characteristic of the new device. This gives the impression that it’s indeed a huge step forward in the smartphone industry, let alone its better chip, camera and antenna. It provides the “Apple has done it again!” perception, at the device-level, which is where the money lies.

So Siri might eventually – and that would make my day – make it to older devices, but I wouldn’t bet my money on it.

Hello! I’m Mathieu and I’m starting a blog in which I’ll talk about challenges I encounter while developing and how I solve them, and sometimes give my opinions on new technologies. I’m the lead developer at Nextorms, where we’re using Node.js, Python (and its science-oriented libraries), MongoDB, Redis, ØMQ and a bunch of javascript technologies. We’re building for the future, and it’s quite exciting!

Octopress

This blog is built using Octopress and deployed to github pages, so the repository is freely accessible. A few upsides of doing it this way are :

• Octopress is using Jekyll to generate static pages, which can be served with minimal impact on the server
• It comes with a great deal of batteries included, so the blog is responsive, optimized and very pretty!

Infinite Gratitude goes to the awesome contributors of Jekyll and Octopress (@mojombo, @imatis, @qrush).