Posterous theme by Cory Watilo

We teach programming wrong

We teach programming wrong. We teach it the way Japanese teachers have been teaching English. We teach about programming and expect that students will spontaneously learn to write from this collection of facts.

Couldn't agree more - I learned my practical knowledge about programming by working on pet projects and just playing around with languages and libraries.

What is not surprising - I'm using more of that self-taught stuff than CS knowledge "learned" at University.

This is why we can't have nice things

So, what can we do now? wxRuby's obviously not at fault, it's

a) pixman that is broken and
b) Debian/Ubuntu that ships broken wxWidgets packages

b) is marked as fixed for Oneiric, but I doubt wheather wxRuby will run
then, because of a) and a symbol lookup error I already described on
Launchpad (this would be c) then I think).

The pixman bug breaks wxRuby on nearly every recent Linux distribution,
and Debian/Ubuntu breaks it a second time due to their package
management, which is especially problementic because of their 
popularity.

To conclude: I'm worried about wxRuby's future, although it seems that
wxRuby can't do much about the mentioned problems.

As much as I would like to continue working on Hubboard (https://github.com/lukaszkorecki/Hubboard/) stuff like this makes me think that it should be OSX-only app.

I really wanted it to be usable at least on OSX and Linux because that's what most developers is using. However if wxRuby can't be easily distributed (or bundled with applications - like I did it in Hubboard) that defeats the whole point of using it.

Ruby's lack of a working crossplatform GUI lib (like wxPython) is a real problem - because of that Ruby will be considered a "webdev language" just like PHP.

OAuth and PIN based authorization in Javascript

Update – following code examples work with 1.1 version of the library, however jsOAuth comes with more helper functions which I had to implement myself at the time of writing this post. Please consult the docs

Let’s do some OAuth communication in Javascript, shall we?

This morning, after a quick research I found three potential libraries that can be used:

  1. Made by Netflix – javascript oauth
  2. United Heroes' – OAuthSimple
  3. Rob Griffiths' jsOAuth

The first one looks quite old, and I couldn’t find any good docs.

Second one, has some docs, but leaks with variables like crazy (the sign() method returns DOMWindow).

Third – jsOAuth is actively developed – and what is more there are some working examples. But again – not many docs.

Fear not, I’ll take you there

Assume you want to use OAuth in your desktop application (or Chrome App) and you want your users to authorize with a PIN as opposing to the standard callback way, which doesn’t really work in our scenario.

You got your consumer key and secret – we can now ask the user to approve our application:

var op = { consumerKey : 'YOURKEY', consumerSecret : 'YOURSECRET'},
    requestParams,
    accessParams;

var oauth = OAuth(op);

oauth.get('http://exmaple.com/oauth/request_token',
  // success
  function(data) {
    console.dir(data);
    openURL('http://example.com/oauth/authorize?'+data.text);
    requestParams = data.text
  },
  // fail!
  function(data) { console.dir(data) }
);

As we can see – we’re requesting URL params which will be used for authorizing our application at the API endpoint.

The openURL method depends on your environment – it can be chrome.tab.create({url : url}) or window.create, whatever works for you.

Once the user authorizes our app (by selecting ‘Allow’ or simillar option) she/he will be presented with a PIN, which we later use to get the access tokens:

// user approved and now we have a pin:
var pin = userApproves();

oauth.get('http://example.com/oauth/access_token?oauth_verifier='+pin+'&'+requestParams,
  function(data) {
    console.dir(data);
    accessParams = getVarsFromQueryString(data.text);
    oauth.setAccessToken([accessParams.oauth_token, accessParams.oauth_token_secret]);
  },
  // fail!
  function(data) { console.dir(data) }
)

Here we notify our endpoint that the user acknowledged our app. You can store accessParams for later use, so that subsequent requests can be made:

// standard GET request
oauth.get('http://api.example.com/timeline.json',callbacks.success, callbacks.fail);

// POSTing some data
oauth.post('http://api.example.com/update.json', { 'body' : 'trolololo'}, callbacks.success, callbacks.fail);

Are we there yet?

That’s all really – the “OAuth dance” isn’t pretty, but once the access tokens are retrieved it’s pretty much standard REST-talk, I hope someone will find it useful.

I’ve tested this code agains Twitter, Blip.pl and Vimeo and it looked good.

PhantomJS

I accidentaly a post... So here's a version from Google Cache

 

This is awesome: PhantomJS.

The whole idea is to use QT’s webkit and make it into a headless browser. Lets add the fact that QT works pretty much everywhere (lets not worry about the look and feel).

To get it to work you’ll have to compile it yourself (unless you’re using Windows… There’s a prebuilt package ready for download).

And then… You can do few cool things.

Since I badly needed some kind of easy way of running QUnit tests from the command line I’ve decided to write a simple test runner:

if (phantom.state.length === 0) {
  if(phantom.args.length === 0 || phantom.args.length > 2) {
    console.log("Simple QUnit test runner for phantom.js");
    console.log('Usage: testrunner.js url_to_test_file.html');
    console.log('Accepts: http://example.com/file.html and file://`pwd`/test.html');
    phantom.exit();
  } else {
    phantom.state = "run-qunit";
    phantom.open(phantom.args[0]);
  }
} else {
  console.log("Running tests");
  setInterval(function() {
    var result_el = document.getElementById('qunit-testresult');
    if(typeof result_el !== 'undefined') {
      try {
        var passed = result_el.getElementsByClassName('passed')[0].innerHTML;
        var total = result_el.getElementsByClassName('total')[0].innerHTML;
        var failed = result_el.getElementsByClassName('failed')[0].innerHTML;
      } catch(e) {
        // SHHHHHH
      }
      console.log('Passed: '+passed + ', Failed: '+ failed + ' Total: '+ total);
      if(parseInt(failed,10) > 0) {
        phantom.exit(1);
      } else {
        phantom.exit(0);
      }
    }
  }, 100);
}

The output is pretty standard:

[10:44][~/dev/Mikrob.chrome master]: phantomjs testrunner.js file://`pwd`/test.html
Running tests
Passed: 14, Failed: 1 Total: 15
[10:44][~/dev/Mikrob.chrome master]: echo $?
1

You can see it/fork it here

It would be awesome to have PhantomJS as a webdriver for stuff like Capybara.

JavaScript

use node.js to create a unified, ajax-based push/pull chat application, distributed across multiple ec2 instances and monitored by a multiplexing smp-enabled erlang script which uses a cassandra-based multidatacenter caching system to offbalance the load from the J2EE terracotta instances.

Usual JS-bashing thread :-/ But this comment is hilarious

Ugly and beautiful code

ALL code is ugly. Yours, mine, everyone's. Code Is Ugly. Just face it. When someone says "beautiful code", hear "beautiful rotten entrails". The only beautiful code, the most clean code, is no code at all. If it's there, it's ugly. The unfortunate fact of software development is that, in order to create beautiful software, we must use ugly code.

The best we can do is make sure that there's as little code as absolutely necessary, and that it is as reliable and easy to interpret as possible. Conventions must be judged based on these standards. Anything that obscures the intent of the software is by definition "unclean", and every line of code is "ugly".

Well said.