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.
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.
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:
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.
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);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.
The Internet Explorer 6 Countdown
"It's the final count down!"
Good that it happened, but *a little* too late.
And to be honest - Microsoft should do the same thing about IE7. And IE8 once IE9 is available.
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.
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
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.
