Skip to content

Kaltura DevConnect

2012 April 1
by Richard Harrington

Tomorrow I’ll be going to Kaltura DevConnect, a one-day conference on html5 video. The topic of the conference is the web video platform created by the main sponsor, Kaltura, and most of the talks will be on Kaltura’s own open source html5 video platform, but there will be some more general talks on html5 video and the production and distribution of online media in general.

Kaltura’s director of community development, Zohar Babin, is the (incredibly friendly, helpful and encouraging) organizer of the Javascript Meetup I go to, which is how I found out about it.

The info is here, if you want to go. It looks to be a good quick immersion into what the kids are all talking about with this html5 video, in case you’re worried you’re about to be left behind.

Draw

2012 March 27
by Richard Harrington

Time to get serious about this blog, and about my drawing project, which I have called ‘draw.’

You can find the current version at www.turtleherder.com/draw. It came from a class project in a JavaScript class I took in November 2011 with Pedro Ha at NYU’s SCPS (School of Continuing and Professional Something). The original version of the app was written by Ha, but I have expanded it since then, primarily by adding the ability to grab color palettes from the API of a website called colourlovers.com. You can find more info about ‘draw’ on its github page.

It’s basically meant to be a simple but effective demonstration of what can be done with the Canvas API. Canvas is an official piece of HTML5 now, and many browsers have supported it for years. It’s pretty cool, and easy to use if you know any JavaScript.

Canvas is based on a very simple concept, which is that most of the screen painting is done by function calls that move a cursor from point to point. It almost reminds me of the turtle graphics programming I did in the late seventies and early eighties in Logo and GraFORTH, although that was a bit different in that the cursor movements in turtle graphics are relative (Move forward 10, turn right 45 degrees, Move forward 14.1421, etc.) as opposed to Canvas’ absolute positioning (Move from point [10, 20] to point [10, 10], Move to point [20, 0], etc.). Back then there were a lot of unusual programming paradigms being foisted on children by academic purists championing their favorite obscure language — Logo was a version of Lisp, and GraFORTH was a version of FORTH. GraFORTH is in fact currently so obscure that it doesn’t even have a Wikipedia page.

But I digress. Another post will delve more fully into the early years, and the relative virtues of functional and stack-based languages. Today I want to talk about what I’m going to do next with the ‘draw’ project. Since the class ended, I have made a few minor tweaks to it, but the reason I have continued to work on it at all is so that I can one day make it into a multi-user real-time app.

If you search around for two seconds you can find any number of much more elaborate drawing apps using Canvas, like this one for instance, which looks like frickin’ Photoshop. But ‘draw’ has the virtue of being really simple, as in something a very small child might be able to use on an iPad, as in something my niece and nephew in California might be able to use at the same time as me, drawing on the same canvas (I live in New York).

To accomplish something like that I knew I would need Node.js, and probably socket.io as well. I just barely have a handle on those technologies, but I have been to a couple of hackathons and worked doing front-end coding on teams of people who knew Node really well, so I have a good idea of what it can do, and I figured this was the perfect project to learn it on, from start to finish.

So a couple weeks ago I made myself a list of steps I’ll have to take:

  1. Set up the ability to have multiple simultaneous brushes.
  2. Set up a Node.js server that receives and sends brush move events to and from multiple clients.
  3. Set up hosting for that server on the Internets.
  4. Set up a history object, so that when a new user opens their browser to the drawing app, everything that has happened so far is reflected on their canvas. (This is an important point for those who may not be familiar with Canvas, because it’s pretty low-level. Unless you use some kind of abstraction layer on top of it, all Canvas knows is the current operation, plus the pixels that have already been displayed on the screen. If you want to recreate the drawing history, you’ll have to keep track of it yourself.)
  5. Set up a way to create multiple canvases, each with their own name, so everyone in the world isn’t drawing on the same canvas (all with the ability to clear the screen at any moment!) People can start new ones or click on links or go to previously defined URLs for the old ones.
  6. Various UX and design changes and fixes, most notably the ability to handle touch events.

I actually did #1 and #4 pretty quickly. For a proof of concept of #1, I added a second brush that is operated by the keyboard, so that I can use that one and the mouse one at the same time. For #4, I set up a ‘restore canvas’ button so that I could clear it and then test the browser’s ability to reconstruct it from the history. It does so in the blink of an eye. I was surprised. Computers these days!

So for #2, which is of course the heart of the matter (although #3 might be kind of tricky…), I am plowing through the partially-published Manning book “Node in Action,” and of course all of the excellent information available online about Node.js. I should have something to show for myself in a week or two. Wish me luck.

What’s that blocky green logo?

2012 January 31
by Richard Harrington

A few weeks ago I went to a tech Meetup in Soho at the offices of Cyrus Innovations, hosted by a guy who works there named David Newell.

I’ve been going to a lot of Meetups lately. This one was on CoffeeScript, a clever little language (and ‘little’ is a word that it proudly uses to describe itself) which compiles down to JavaScript. It’s basically syntactic sugar on top of JavaScript.

As far as I can tell, Coffeescript has two main purposes:

  1. The creators have tried to eliminate most of the pitfalls that can trip up the unwary JavaScript programmer by simply not including the worst aspects of that language. (I’m not impugning the abilities of Javascript’s creator here, who apparently he had 10 days (!?) to create the whole thing — more on that in a later post.) And
  2. To add a bunch of syntactic sugar (comprehensions, splats, etc.) to make it look more like python or ruby. Thus also having the secondary effect of making it a lot shorter to write.

We were there all day for what David called a ‘code retreat.’ With my primitive Unix skills, I had just barely managed to install CoffeeScript on my laptop, a feat which first involved installing Node.js, the technology all the kids are talking about these days but only the lucky few actually know. By the time I got done I had about an hour to go over a tutorial, so that was the extent of my Coffeescript knowledge.

I’m not sure what I expected but we all got thrown into working in pairs creating implementations of Conway’s Game of Life (wikipedia that shit) in CoffeeScript. 45 minutes for each pair, then you ERASE all the code you’ve been working on (which was super-painful), come back to the group to discuss it, pair off with someone else and do it all over again, all day. David says that every time he needs to learn a new programming language, he makes the Game of Life. We didn’t ever get very far, but that wasn’t the point. The idea was to keep refining the way you thought about the problem.

It was an interesting experience. David was a very nice guy and did a great job running it, and I learned quite a bit about the concepts behind test driven development, which I’d also never had any experience with.

The verdict is still out on CoffeeScript. I basically like it, but I’m not swayed by it being shorter to write than JavaScript, as I work out code in my head a lot slower than I can type. If that ever changes, I’ll be jumping on the CoffeeScript bandwagon. In the meantime, I’m glad I have enough of a surface familiarity with CoffeeScript now so that if I ever had to learn it, I know how long it would take me to do so.

Well, that about wraps it up for today. Oh but wait, you ask, what about the logo? Well, when I got home the night after the Meetup, I sat down and wrote an implementation of the Game of Life in good old JavaScript. It can be found here. The shapes in the logo are the four forms of a moving pattern in the Game of Life known as the ‘glider’ (one form is repeated in the logo). Again, wikipedia that shit.

Hello world!

2012 January 30
by Richard Harrington

Welcome to my new tech blog, in which I detail my successes and frustrations on the road to becoming a programmer.

I’ve been coding on and off — mostly off — since I first started with BASIC, Logo and GraFORTH (huge bonus points if you remember that one)  on the Apple IIe in the early 1980s. I was strong in middle school and then dropped it in high school because I was afraid to be a computer geek. Then I didn’t pick it up again seriously until twenty-five years later. I made a few abortive attempts over the years (other languages I have learned a little bit of and then forgotten completely include Pascal, 6502 Assembly, C, C++, Perl, PHP, and Scheme) but only really started delving into it in earnest in the past few years, mostly into JavaScript. Which is, as many have discovered, a lot more interesting than the horrible buggy scripting language it appeared to be during the browser wars of the 1990s.

This blog will be not so much a catalog of tips and tricks and best practices — for that, go to stackoverflow.com — but rather more of a memoir of how and why I got back into this stuff. My goal is to share what I have learned about coding and about learning, and to provide some moral support to people who stumble across one of the posts here and think, now I know I’m not the only one who had <x> problem, or who couldn’t understand <y> concept.

Time to get some sleep. Tomorrow, we begin at the beginning. Or in the middle. We’ll probably keep jumping back and forth, actually.