“Passion burns most fiercely when fuelled by success”
The various videos of the speakers from Tech2020 – including yours truly – are up and available for Skillsmatter members. Going back to my previous blog post, I can heartily recommend the speakers who I was excited about, but have to say, I was blown away by the overall quality of the conference. Even those topics I didn’t think would hold much interest or news for me turned out to be incredibly interesting, and I daresay the next editing of this conference will be something to watch out for.
For a while now, I have been waxing lyrical (to those who will listen) about the variety of new tools and analyses available to people who want to prognosticate. If nothing else, the current craze for data within most businesses has resulted in people almost literally swimming around in the stuff without an awful lot of an idea about what to do with it, and while this has lead to some unspeakably shambolic practices (those who know me will likely have heard me on my hobby horse about proving models with actual experimentation) it has also opened up new horizons for people like me.
Not that long ago, I did a switch on my Android phone: against all the promises I made to myself beforehand, I switched on the Google account and allowed it to sync up to GCHQ/NSA the cloud. I did this for one main reason: I had just got an Android tablet, and I despised having to do the same stuff on each device, particularly since they weren’t running the same versions of Android, and one was a Nexus – so not all the UI was the same.
In my previous post about virtualenv, I took a look at a way of making python environments a little bit more generic so that they could be moved around and redeployed at ease. I mentioned docker.io as a new tool that uses a general concept of “containers” to do similar things, but more broadly. I’ve dug a bit into docker, and these are my initial thoughts. Unfortunately, it seems relatively Fedora un-friendly right now.
Recently I’ve been trying to bring an app running on a somewhat-old Python stack slightly more up-to-date. When this app was developed, the state of the art in terms of best practice was to use operating system packaging – RPM, in this case – as the means by which the application and its various attendant libraries would be deployed. This is a relatively rare mode of deployment even though it works fantastically well, because many developers are not happy maintaining the packaging-level skills required to maintain the system.
I’ve been a Zend Framework user for a while. I’ve been using PHP long enough to appreciate the benefits of a good framework, and developed a number of sophisticated applications using ZF, to have grown a certain fondness for it. Although it has a reputation for being difficult to get into, being slow and being overly complicated – not undeserved accusations, if we’re being honest – there is something quite appealing about it.
This morning was the big “Dart language” unveil – the Dart websites are up at http://dartlang.org and http://dart.googlecode.com. And already many seasoned Javascripters have the knives out. I’m surprised for a couple of reasons: the first, this isn’t quite as big a deal as many people thought it would be (me included), both in terms of the scope of the system and the distance to Javascript. Second, the system isn’t quite as finished as many predicted: this isn’t going to be usable for a little while.
(For those looking for an rpm rant, sorry, this isn’t it….!)
Currently there’s a ticket in front of FESCo asking whether or not alternative dependency solvers should be allowed in Fedora’s default install. For those who don’t know, the dependency solver is the algorithm which picks the set of packages to install/remove when a user requests something. So, for example, if the user asks for Firefox to be installed, the “depsolver” is the thing which figures out which other packages Firefox needs in order to work.
