Archive for the ‘Random’ Category

Data driven

The Economist recently wrote a bit about how speech recognition got so good:

… words do not appear in random order, so the computer does not have to guess from (say) a vocabulary of 20,000 words for each word you speak. Instead, the software assesses how likely you are to have said a given word based on the surrounding words, drawing on statistical models derived from vast repositories of digitised documents and the previous utterances of other users.

This reminded me of a talk by Peter Norvig: The Unreasonable Effectiveness of Data, where he discusses utilizing such large repositories of data in order to develop effective algorithms for a number of problems; there is a heavy focus on natural language processing problems but the concept can, of course, be applied in other areas.

(If the name Peter Norvig sounds familiar, he’s the co-author of Artificial Intelligence: A Modern Approach which you might have used if you ever took an AI class.)

As a programmer, this is exciting stuff and certainly changed my thinking in regards to how I would approach similar problems in the future. Whereas before I would look at sample data sets and try to derive an algorithm, I’d now attempt to mine as much data as I could, build a statistical model, and use that as the basis of the algorithm. Of course mining a massive data set is sometimes easier said than done; especially in regards to data, much of the web is still a walled garden.

Launching an application with XPCOM

Continuing to document my work with XULRunner, XUL, and XPCOM, here I’m presenting code on how to launch an executable using XPCOM’s nsILocalFile interface fetch the executable file and the nsIProcess interface to execute the process.

// target = path to executable
// args = arguments for executable
function exec(target, args) {

try {

var file = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
file.initWithPath(target);

var process = Components.classes["@mozilla.org/process/util;1"].createInstance(Components.interfaces.nsIProcess);
process.init(file);

var args = [''];
process.run(
false, args, args.length);
        
        
return process;
}
catch (err) {
alert(err);
return null;
}

}

Fixed (non-resizable) windows with XULRunner

I’ve been working a bit with XULRunner lately and wanted to create a fixed, non-resizable application window. After some searching, I eventually stumbled upon some code which led to a solution – adding a function call to the application’s prefs.js file:

pref("toolkit.defaultChromeFeatures", "chrome,resizable=no,dialog=no");

resizable=no prevents the window from being resized, dialog=no makes it a non-dialog window so that you can still minimize it.

Simple stuff, but this was difficult to find. Discovered thanks to this post on glazman.org

Note that after some testing with XULRunner on Ubuntu, it appears that this may be a Windows-only setting.

Habitat 67

An interesting housing complex design in Montreal. Habitat 67 designed by Moshe Safdie:

Habitat 67
Photo by Taxiarchos228 at the German language Wikipedia

Musei Civici Veneziani

Cleaning out old cards from my wallet and found my museum pass, for the Civic Museums of Venice, from a trip to Italy a few years ago.

musei-civici-veneziani-pass

C for Dummies

I snapped a photo of my C for Dummies books on a visit to my parents place (my apartment is tiny, so a lot of my old books are there). C was the first programming language I took a serious interest in learning. I knew a bit about code prior as I had toyed around with QBASIC and Visual Basic, but I was interested in video games and computer graphics, for which neither of those languages were well suited.

I spend maybe a month consuming these 2 books when I was about 16, going back-and-forth between the pages and MS Edit + DJGPP to write and compile code. When it all clicked (and there really was that moment of clarity as everything went from looking cryptic and indiscernible, to elegant and natural) it was incredibly exciting.

These books were a great introduction to the C language, and programming in general, and Dan Gookin deserves a lot of credit; technical writing is hard, even more-so when your audience is the absolute beginner.

C for Dummies

Vedas

Vedas by Nicholas Alan Cope and Dustin Edward Arnold

Vedas by Nicholas Alan Cope and Dustin Edward Arnold

From their blog:

Vedas is an ongoing project broadly based on the theme ‘knowledge’. Specifically the changes in thought established by Copernicus’ De revolutionibus orbium coelestium (On the Revolutions of the Celestial Spheres). One of the earliest documents of the scientific revolution. It re-assessed man’s place in the cosmos and placed him at no greater value than other creatures on earth.

Knowledge, it seems; is at once both expansive and contractive. It is a value exchange. For some it shakes foundations, de-stabaizes values and opens up the sheer terror of possibility. For others it signifies hope, advancement and discovery.

MegaRace

One of the earliest computer games I played was MegaRace, which came bundled with a Quantex Pentium 60Mhz PC by dad bought sometime around the end of 1994. It was a cheesy game (really cheesy), but it was fun to play. The FMV race tracks were visually impressive for the time and the combat racing was exciting despite only being able to move cars side-to-side.

MegaRace: Particle Accelerator

The chiptune soundtrack, composed by Stéphane Picq, was particularly memorable. For those interested, this fan site has Ogg Vorbis encodings of the music for the race tracks as well as an MP3 of an FMV ending sequence. Well worth a listen.

Master disks for Doom

Caught this tweet from @idSoftware showing the original master disks for Doom:

Doom master disks

Native vs. HTML5 hybrid

Facebook recently released a new version of its iOS app in order to fix a number of issues with the previous releases. The Facebook app has been notorious for being slow, buggy, and simply lackluster overall. The problem touted by many was the fact that it was not a native iOS app in that it relied on UIWebView containers to display content; this post brings such speculation front and center. However, I’m not sure I agree that the blame lies with UIWebView. The problems with the Facebook app, as far as I could tell, centered around lag in loading content, or or simply not loading content due to connection timeouts. Two comments in the post, I think, point out the real issues:

This article is ridiculous. Not caching data is [the] fault of the developers, not Uiwebview. And seriously, blaming the slowness on HTML? What does the format of the data have to do with anything? There is no reason their dev cycle isn’t compatible with a decent iOS app. iOS development at Facebook is not a priority. Period. That is the only reason the app sucks. It sucks because they wrote a shitty app. Not because of Uiwebview. Not because they use HTML. Because they wrote a shitty app.

Late to the conversation here but Robert Jacobson makes an excellent point: your criticisms are specific to the implementation of the FB app and not the concept of hybrid HTML5 apps. You specifically point out inefficient and inconsistent web service calls that cause many of the problems. Even a native app will be at the mercy of a poorly written web service. I appreciate all the research you’ve done for this article but it is disappointing that it is getting referenced elsewhere on the web for an example of why HTML hybrid apps are bad. You’ve got a good critique of the Facebook iOS app implementation here. This does not even come close to a fair analysis of HTML5 hybrid mobile applications as an implementation strategy.

The last quote brings up an important point, many are now soured by the idea of a HTML5 hybrid mobile application, which is unfortunate because it’s a architecture that would work well for many developers and alleviates the burden (at least to some degree) of supporting multiple mobile platforms.

Looking ahead, I’d bet on HTML5 and web technologies in general. You’ll never get native performance, but as mobile devices become more powerful the tradeoff, platform flexibility and ease-of-development in exchange for lower performance, will become a non-issue for all but the most intensive applications (e.g. games). I toyed around with PhoneGap (before it was bought by Adobe and split off into PhoneGap and Apache Cordova) last year and was pretty happy with the results. I did have a number of frustrations, but those weren’t due to performance, but to bugs and rendering issues in a number of HTML5 mobile frameworks (jQuery Mobile, jQTouch) and webkit mobile itself (support for position:fixed; not available in iOS 4 at the time, supported in iOS 5 which had just hit the market); I’m not pessimistic here, these are things that will improve (or have already improved) as mobile software development matures.