Setting goals for learning for 2014

by Oliver on Tuesday, February 18th, 2014.

Perhaps a little late in the year to be conducting a personal retrospective on the years past, but I feel at this point I’m starting to wonder about the challenges ahead. The last two to three years I’ve distinctly changed my career direction from systems engineering, to “DevOps” (whatever that means anymore), to developer. Sure, I’m technically a Computer Scientist by tertiary education standards but I’ve been outside of that field for a large part of my professional career. I’ve now almost completed the book Seven Languages in Seven Weeks – not just reading through it, but dedicating enough time to absorbing the material and implementing all of the problems given. In actual day-to-day programming terms I keep myself busy largely with Golang, occasionally Ruby, and occasionally ActionScript. Perhaps with exception of ActionScript I find myself solidly in the realm of “backend languages”.

That’s a pretty fair assessment, as I am employed as a backend engineer. From time to time I do need to delve into Javascript and front-end tasks, and I feel like everything goes to pieces. It conjures up the same feelings I had when working as a systems administrator, seeing an error and diving into the (usually C) codebase, only to stare at the screen utterly confused and not knowing what to do. The spirit was willing but the flesh was weak: and I feel the same way when getting into Javascript and/or front-end development territory.

Not influencing my thoughts around this, but also not entirely unrelated is this blog post by Ian Bicking (of SQLObject, Paste, virtualenv and pip fame (as well as many other excellent pieces of software)). Ian expresses some interesting points including “the browser seems like the most interesting platform” which does resonate with me – the HTML5 media realm is where a lot of my time is spent but without really understanding what is going on. For that reason I’m dedicating (at least a significant amount of) my mental space in 2014 to Javascript and front-end development learning.

If you’ve been writing a personal web page (or perhaps on behalf of a friend) and been stuck using tables or frames, or resorted to using Twitter Bootstrap out of frustration and even then not really knowing what you are doing, you’ll understand the desire to know more of how all that web magic works. I’m totally happy writing an API in some of the previously mentioned languages, but when it comes to actually making something that works in the browser that doesn’t look like it’s been transported from 1995, well – there’s something more to be learned.

Tags: , , , , ,

Tuesday, February 18th, 2014 Tech No Comments

Seven Languages – Io

by Oliver on Saturday, January 12th, 2013.

I’ve mentioned a couple of times that I started reading through Seven Languages in Seven Weeks, and even though I’ve recently been heavily sidetracked by Learning Go I just finished chapter two which dealt with Io.

The book gushes over the language, and I’ve read a lot of other people’s blogs where they seem quite excited about it. In the end I couldn’t finish the last exercise, even having a working example to go off. It was just a bit too painful trying to find the right object context, navigate around the strange method syntax and other oddities in the language. Of course, it would be wrong to blame the language, so I’m just going to leave it saying that Io didn’t resonate with me.

Interestingly, even though I haven’t used a great deal of Javascript I wasn’t too bothered by the prototyping paradigm of the language. The main confusion (aside from general syntax) was the control you had over in whose context the method arguments would be evaluated – the sender’s or the target’s. It took a bit of playing around to figure out which was the correct alternative in all instances.

For now, I’m conquered. Maybe I’ll come back to that exercise and solve it, but probably not. On to Prolog, which I did get into briefly around 2001 (with fairly awful results). Hopefully the experience will be better this time.

Tags: , , ,

Saturday, January 12th, 2013 Tech 1 Comment

On Service SDKs and Language Support

by Oliver on Wednesday, November 21st, 2012.

As I’ve previously mentioned, I’ve been doing a lot of work recently with various aspects of AWS on a daily basis (or close to it). My primary language these days is still Ruby, but I’ve been labouring through the excellent Seven Languages in Seven Weeks book in the hope I can broaden my horizons somewhat. I’m fairly comfortable with Python, somewhat familiar with Javascript now after playing with NodeJS and I have a cursory ability still in C/C++ and Java but it has been over 10 years since I’ve done anything significant in any of those languages.

Suffice to say, I’m far from being a polyglot, but I know my current limitations. Go has been increasingly noticeable on my radar and I am starting to familiarise myself with it, but this has led me to a small realisation. When service providers (like Amazon in this case) are providing SDK support they typically will be catering to their largest consumer base. Internally they largely use Java and that shows by their 1st class support for that language and toolchain.

Using the example of Elastic Beanstalk and the language support it provides, you can quite easily determine their current (or recent) priorities. Java came first, with .NET and PHP following. Python came about half-way through this year and Ruby was only recently added. Their general-purpose SDKs are somewhat more limiting, only supporting Java, .NET, PHP and Ruby (outside of mobile platform support). These are reasonable, if middle-of-the-road options.

Today I was attempting to run some code against the Ruby SDK, using JRuby. The amount of work it has to do is significant, parallisable and doesn’t exactly fit Ruby’s poor native support (at least in MRI) for true concurrency. I’m not going to gain anything by rewriting in PHP, cannot consider .NET and Java is just not going to be a good use of my time. I feel like there is an impedance mismatch between this set of languages and the scale of what AWS supports.

You are supposed to be scaling up to large amounts of computing and storage to best take advantage of what AWS offers. Similarly, you best make use of the platform by highly parallelising your workload. The only vaguely relevant language from this point of view is Java, but it’s just not a desirable general-purpose language for many of us, especially if we want to enjoy low-friction development as so many newer languages provide.

To be more specific – languages like Go, Erlang (or perhaps more relevant, Elixir), Scala etc offer fantastic concurrency and more attractive development experiences but these are not going to be supported by the official SDKs. It makes perfect sense from the point of view of the size of the developer base, but from the point of view of picking the right tool for the job it doesn’t. Perhaps in a few years this paradigm of highly parallel computing will have gained momentum enough that these languages move to the mainstream (ok, Heroku supports Scala already) and we start to see more standard SDK support for them.

Tags: , , , ,

Wednesday, November 21st, 2012 Tech 1 Comment