Category: Code

On the hidden dangers of highly integrated application frameworks

qupzilla-failure

I have been evaluating WebKit and Blink-based open-source browsers for Linux—mostly because Firefox is often noticeably laggy on an old laptop I like to use. (I still <3 you though, Moz!!) Chromium is an obvious option, but I would like to investigate solutions that don’t rely on Google. This has led me to Midori and QupZilla. Both position themselves as lightweight alternatives to the big kids. Both have their pros and cons.

A con with QupZilla that I want to take on in this post is the result of its use of Qt. I love Qt. It’s the right tool for a lot of jobs. But it harbors a hidden gotcha when it comes to rendering web pages: you are at the mercy of the Qt maintainers’ web rendering engine update policies. The latest version of QupZilla that you can build with the production version of Qt (5.5) uses QtWebEngine, which is based on the Blink-based Chromium. (So much for not relying on Google!)

The current Qt release bases QtWebEngine on Chromium 40—which is almost a year old; the next Qt release (5.6) will base QtWebEngine on Chromium 45—already three months old. The version of QupZilla provided by Debian sid (unstable, rolling release) uses the deprecated QtWebKit, which in Qt (5.5) is based on Webit 538.1.0. This version of WebKit is already a couple years old.

A similar situation exists with Midori. It uses GTK’s WebKitGTK+, which in Debian sid is as of this writing at 2.4.9-2 and also is about about two years old. Probing the user agent indicates it uses WebKit 538.1.5. But as there is in Qt, there is an additional wrinkle in the GTK+ world. There are currently two versions of WebKit for GTK: WebKitGTK+ and WebKit2GTK+ . Depending on which one your GTK+ application uses, you may get an old or a new version of WebKit. The version of WebKit2GTK+ that ships with Debian sid appears to provide WebKit 602.1 at the moment, which is the current point-release WebKit, and new releases of WebKitGTK+ flow regularly.  (Why Midori doesn’t use WebKit2GTK+ is a question for the developers and one that I hope to pursue. FYI, GNOME’s Web, née Epiphany, uses WebKit2GTK+.)

Whatever the specifics may be in this case, the takeaway is this:

When using integrated application frameworks, you need to be aware of versioning limitations with third-party tools that they bundle.

Open source audio remote control

audio-remote

I’ve started a FLOSS remote control receiver project for DIY audio preamplifiers. I think it’s just about good enough to make public.

Remote control is one of the more challenging things for an audio DIY person to implement, so I thought having an open source hardware and software platform for doing this would be useful. It uses our good friend Arduino for brains and works with the Philips RC-5 protocol. I like RC-5 because its the closest thing I know of to a universal, well-documented, brand- and model-agnostic protocol.

The IR command decoding is done using Guy Carpenter’s excellent RC5 library. I also considered using Ken Shirriff’s multi-protocol IR library. Ken’s library works with a large number of protocols, but I thought its larger memory footprint might preclude porting this thing to tiny AVRs.

Details on the project are available in my RC5-Preamp GitHub or GitLab repository. [2021 update: This project is currently abandonware, so I have made the above repos private. If anyone wants access, contact me and we’ll figure something out.]

Acceptance testing and BDD with bash

berdea2
I’m working on a project that has some fairly weird acceptance criteria. I’d really like to automate the acceptance testing, but none of the tools I know of will cover all the requirements without a good amount of hoop dancing. So I wrote one … in bash. Truns out a few others have gone down this path as well.

While it’s currently quite limited and coarse, it might form the basis for a more comprehensive framework. Check the repo if you’re curious and/or interested.

Gitorious and GitLab

gitorious-logo gitlab-logo

My last post talked about using alternatives to GitHub in order to (in no particular order):

  1. Encourage diversity in project hosting in light of GitHub’s (not undeserved) domination in the area. This is all the more important because the GitHub stack is completely proprietary.
  2. Patronize vendors who more completely embody the spirit of FOSS (i.e., those who make significant parts of their platform available as FOSS).

I’ve done a bit more work with two Saas projects that can be used to achieve both goals above:  Gitorious and GitLab Cloud. My impressions follow.

Gitorious

gitorious-logoGitorious has been around a long time. I remember considering their hosting and software about the time when Google Code was still really hot (i.e., IIRC, before GitHub was a “thing”; Wikipedia says Gitorious launched in January of 2008 and GitHub in April of the same year). Many well-known and important FOSS projects are hosted on Gitorious.

If Gitorious (the service and the software) were the only option available today, people would be praising it to the nines. It offers repository hosting with decent code browsing, project logging/graphing, project wikis, and an interesting feature that lets you POST stuff to an arbitrary URL whenever a commit is made. The interface is pleasant and generally clear. The software that runs the service is FOSS and easily downloadable. Bitnami even packages a bundle that makes setting up your own service stupid easy.

However, there are a couple caveats. First, compared to other hosting options, Gitorious is a bit short on features. Notably absent are issue tracking and continuous integration support. While there are third-party tools that will do these for you, one of the nice things about GitHub and BitBucket (and, if we limit ourselves to issue tracking only, Google Code and Sourceforge) is that these are part of the service—meaning virtually no setup and good integration with the codebase. Some might actually prefer having orthogonal tools for issue tracking and CI, so this won’t be an issue for those.

The other thing you need to be aware of is that Gitorious organizes repositories based on projects rather than on users. Projects can have multiple repositories in them, but all the repositories will share the the same wiki (i.e., there is no per-repo wiki). Also, the owner of the repo will not be in the URL of the project. In other words, Gitorious isn’t really designed to support a “Here’s a collection of my repos,” Web presence. It’s setup is great if you are deploying a server for internal projects, but it’s not really optimal for being a “social coder.”

GitLab

gitlab-logoGitLab, or more relevantly, GitLab Cloud, is new to me—I discovered it only a few days ago. Indeed, it looks like it’s new to everyone, with late 2011 being the date of the first entry on the company blog.

It seems to me that GitLab is trying to be a feature-compatible alternative to GitHub. Even the names are similar. A GitLab account gets you repository hosting, per-repo wikis, issue tracking, and code review. GitLab also makes a FOSS Continuous Integration product—though I have yet to explore how it integrates with GitLab Cloud. The GitLab Community Edition is FOSS and easily downloaded.

My biggest concern with GitLab is that since it’s relatively new, it might go away. The fact that it’s FOSS hugely mitigates this concern. If Facebook buys GitHub and shutters it, your workflow, community, everything is screwed. But if GitLab shutters, you only need to grab the last release of the software stack, set up your own server, transfer your data to the new server, and update your URLs. As was the case with Gitorious, there is a Bitnami bundle to make setting up your own service brain-dead simple should you need/want to do this. (There’s also one for their CI project). In spite of this, it would be a bit of a drag of they disappeared.

My other concern is that I don’t know how much GitLab’s development will focus on introducing new features not available on GitHub (or elsewhere) and how much it will focus on simply maintaining feature-parity with GitHub. I’d be feeling a bit warmer and fuzzier if they were more aggressively inventing solutions rather than reimplementing GitHub’s offerings.

All said, I think I will focus on working with GitLab to see if there are any unforeseen gremlins. If not, GitLab may become the new primary host for my FOSS work.

Why aren’t you on GitHub?

github-logo gitorious-logo bitbucket-logogitlab-logo

Only one of my 20 or so public repositories is currently on GitHub. The remainder are mostly on Bitbucket. I am seriously considering moving my public Git repos to Gitorious.

Why, when everyone and their mother is shoving heaps of projects at GitHub, would you consider anything else? It’s precisely because GitHub has become the defacto standard that I am trying to avoid it. The Git/Github conflation is bad enough (GitHub invented Git, right?), but it’s also disconcerting that Github (a private Saas company) is creating a virtual (!) monopoly in the field. Given that, I think it’s a good idea to support credible alternatives.

I originally started using Bitbucket because they offered Mercurial hosting. This was back when Git support on anything but POSIXy systems was pretty poopy and Mercurial was the friendly, multi-platform alternative. Bitbucket offered features on a par with Github and were quite generous with their no-cost offerings (and still are). Eventually, Bitbucket saw the writing on the wall and introduced Git hosting alongside Mercurial. Later, I too conceded that Git had won the DVCS race and switched to Git as my default DVCS. However, I saw no reason to change where I hosted my public repos—especially in view of GitHub’s growing dominance.

Both Bitbucket and GitHub are private Saas companies that make money hosting private repositories and/or offering additional services. Gitorious is as well but with one difference: the platform that runs Gitorious is FOSS that you can install on your own servers. Which means you get all the Saas perks along with all the great things that go along with FOSS. The range of features that Gitorious has added over the years has grown to the point where I think it’s worth a serious look. I’ll report back when I have more info.

Update: Another worthy contender is GitLab Cloud. It runs on GitLab’s own software—which has an open source version (MIT license). I’ll be taking a close look at that as well in the upcoming days.

enchant.js | Fundamentals

enchantjs-fundamentals-1

We’ve entered Phase Two of my game programming course, and to help support this phase, I’m putting together enchant.js | Fundamentals.

While currently not as interactive nor as descriptive as what I developed for Phase One, I’m hoping these incremental examples will make it easy for those new to programming to grok some fundamental techniques and concepts.

Again, feedback is appreciated.

Just Enough JavaScript

just-enough-js-1

I got a last-minute opportunity to teach an introduction to game programing course for people with no programming experience. I decided to base it around an open source HTML5 framework*. When I started looking around for a crash course with which to build basic JavaScript programming skills, I found none that were appropriate. Hence, Just Enough Javascript was born.

I’m creating it as a just-in-time resource for the course. There a little bad-but-expedient practice in there, but it’s working quite well for the course so far. Each page is resource-complete in itself—meaning you can download just a single HTML document and later view it without a live Internet connection.

I would love to hear any feedback about it.

* I considered enchant.js, Phaser, and melonJS. There were pros and cons to each, but I ultimately went with enchant.js because I like it’s event-driven nature (better reflects how JS “should” work) and it has a smaller (and therefore less intimidating for beginners) API.

(Over)thinking JavaScript objects 3

tally-clicker

Defining objects inside self-invoked anonymous functions

In our previous episode, we saw a canonical way to create objects in JavaScript that suggested code reuse and facilitated automatic object initialization, but it didn’t let you implement private attributes nor did it go out of its way to keep from polluting the global namespace.

What follows is the simplest way I’ve seen that accomplishes all of the above. And boy is it a ride! We are going to create a self-invoking anonymous function and inside the function we will define the object and create a single point of connection to the window with a closure.

Here we go:

// == Begin definition ==============================
(function(window) {
  // -- Constructor ---------------------------------
  var Clicker3 = function() {

    // -- Private properties --
    var _numClicks = 0;

    // -- Private methods --
    // Methods defined in this scope and not on
    // 'this' are private'.
    var _update = function() {
      console.log("Clicker3 obj: " + _numClicks);
    };

    // -- Public methods --
    // Methods defined on 'this' are public, can
    // access private and public members.
    this.click = function () {
      _numClicks++;
      _update();
    };

    this.reset = function () {
      _numClicks = 0;
      _update();
    };

    this.getNumClicks = function () {
      return _numClicks;
    };

    // -- Initialize state --
    this.reset(); // reset is redundant here;
                  // for demo only.
    _update();
  }; // !Clicker3()

  // -- "Hyper-public" methods ----------------------
  // Methods defined on the prototype can only access
  // public members!
  Clicker3.prototype.showInfo = function() {
    alert("I am a Clicker3 object who is at " +
      this.getNumClicks() + " clicks.");
  };

  // -- Publish -------------------------------------
  // Expose Clicker3 (and only Clicker3) to the
  // global window (i.e., make it public).
  window.Clicker3 = Clicker3;

}(window));
// == End definition ================================

The self-invoking function creates a new scope in which everything is defined. Passing in window as a parameter allows easy access to global window from within that new scope. This setup lets you:

  • Prevent pollution of global namespace.
  • Expose what you want to the global window and keep the rest private.

So, now we  have something that:

  • Has, “Reuse me!” written all over it.
  • Allows for automatic object initialization.
  • Lets you fully encapsulate objects.*
  • Protects the global namespace.

But it’s not totally cool because none of the above are code-level constructs. In other words, it’s neither readable or writable. JavaScipt is/isn’t fun. :-\

Just as a reminder, I am not (yet) taking on the following:

  • Inheritance-like stuff
  • “Class” (i.e., static) members*
  • Polymorphism

*An issue of religious importance.