The location by the harbourside was great, and the lack of internet was not really a problem, with phone tethering and MiFi as options these days. There was also a good mix of people, at different levels of JavaScript skills, and from different backgrounds; next to front-end developers, people from software engineering who were keen to learn more about web technologies. Many of the presenters also stayed on after they had spoken and followed the other sessions. I had not been sure at first whether to attend this event because I am not really a candidate for the user group as I neither live in Southville, nor am I that proficient in JavaScript (when are you a Javascript user?) But I am glad Gicela and Nigel convinced me to take part. Also it turned out that there were a lot more people outside that category, in fact, the workshop might not have run otherwise, I guess!

So here an overview of the presentations:

Node and the Express framework

Jack Franklin kicked off the workshop with a session on Node and the Express web app framework, which is available as a node package. He started with using node's REPL, showing that you can run normal JavaScript and execute files in it. This included a script to set up a server and make content available through it; you wouldn't normally write that yourself, though, as it would be part of a library. One of the nice things about writing JavaScript server side is that you can use all the latest JavaScript functions and don't need to worry about different browser implementations. We also installed a sample Express app, looked at the structure including the package.JSON file to install dependencies, and wrote some code to set up some pages in it. You can find lots of information about JavaScript on Jack's blog JavaScript playground. He has also recently published a book on jQuery.

Modular JS

Next up was Nico Burns. He explained the benefits of writing modular code and the different methods available (AMD, CommonJS, EC Harmony). The presentation made perfect sense to me, and I could see the benefits of this approach especially in large projects. But when it came to restructuring some code that we were given, and make it modular, I struggled a bit. Luckily in the sample code we got, there was a folder with a solution included, and by transforming the original script into multiple files that depended on each other as in the solution, I could understand the structure and how you got there.

Socket.io

Mark Withers introduced socket.io. Web Sockets are one of the new HTML5 APIs, and not fully implemented in all browsers (for IE only from version 10). They enable a persistent connection between client and server as opposed to the HTTP request/response model. This is important for real-time interaction, for example in multiplayer gaming. Using a library like socket.io, you can achieve such a connection across browsers, as it falls back on technologies other than Web Sockets in browsers where those are not available. The practical example involved writing a script that sets up a server (using the Express framework from before), and binds two sockets to two different ports of that server. Next was a client-side script that enables the client to connect to one of the sockets and communicate through it, while receiving the web page through the other socket. In the example, the server sent a message to the client which was then appended as a list element on the page, among other things. The sample code is available on Mark Withers's github.

XMPP-FTW

Socket.io was actually used in the next project, too. Lloyd Watkin presented his library XMPP-FTW, which he wrote to make it easier for developers to enable interaction with XMPP (Extensible Message and Presence Protocol) through a browser. XMPP is an open standard for real-time communication and mostly used in Instant Messaging services, but also in applications like Google Talk (recently replaced by Hangouts) and Facebook chat. An interesting aspect of XMPP is that you can have different 'resources' - which would normally represent different devices - and can set one as priority. Somebody sending a message to your account can either specifiy the resource they want you to receive a message on, or - if they don't specify it - it will go to the one you have set as priority. We got to try out XMPP by connecting to an XMPP system set up by Lloyd on his laptop. We each got an account on that system. Then we wrote some code to connect, and sent little messages to each other, logging them to the recipient's console. We also sent messages to a public messaging wall. Not everybody (including me) did get the code for that right so easily, but we got there in the end! You can find Lloyd's slides online, and here is XMPP-FTW and the pub-sub demo.

Refactoring (and testing)

I won't write much about the last session of the first day, which basically consisted of watching Jack Franklin expertly refactor some jQuery code and explain it as he went along, including the use of unit tests with QUnit, running through PhantomJS. Great stuff. There are posts on his blog on both refactoring and using QUnit.

And after that it was off to "Pub.js" as the agenda stated, but not for me. I think it was better that way, my brain was at that point already quite frazzled without any drinks!

Coffeescript

On Sunday morning, we all turned up again at the boathouse and enjoyed the view onto the Floating Harbour. And then we did Coffeescript. It is a programming language that compiles into Javascript and is much more concise to write. It can be installed as a node package. I quite enjoyed this session, although it will probably be a while before I use Coffeescript, just because I want to get to know Javascript better first. Coffeescript has a lot going for it though, as you can read on this document by Adam Butler who led the session. Adam talked us through the syntax, and the benefits of Coffeescript over JS. We then got some time to try writing something ourselves. Coffeescript works seamlessly with any Javascript libraries, and I tried a little example ivolving jQuery. One of the best ways to learn Coffescript is "backwards" it seems, by using the js2coffee tool. All in all, it was quite rewarding getting some things written in Coffeescript to work, though I did not finish the whole thing. Indepent of Coffeescript, the Dash docsets mentioned by Adam (which you can use with zeal on Linux) were a great discovery.

Angular

There was also one session about a Javascript MVC framework, Angular, presented by Maff Rigby. There is a vast number of frameworks around to build single-page apps, and one conclusion at the end of the session was that the choice you make depends on what specific needs you have for a certain app, but also personal preference. There is not one that is best - they all have different things that they are particularly good at.

Also, there are "opinionated" frameworks that are quite prescriptive in the way you have to structure an app, and those that leave you more freedom. As I understood it, Angular is not very prescriptive. Maff has created a website monitoring app called getTestr with Angular and was showing us how to get started with building an app. At least some of the approach seemed familiar from PHP-based MVC frameworks. I had some stupid difficulties getting things to work though. I say stupid, because they were so obvious in hindsight, and I feel a bit sorry that I bothered both my neighbour and Maff with it. - There was a lot of typing things off the screen in this workshop, and I fell behind with this quite a few times. But I do think it is good practice typing the code yourself. Still I was glad that the speakers also provided the finished examples. (Here you can download Matt's code and presentation).

Leap Motion

In the last session (read a great explanation of what we did on Dave's own website) we got to play with a Leap Motion device. Similar to the Xbox Kinect, it detects shapes and motion through optical sensors. Dave Taylor, who presented this session, had brought a number of these devices and people could work with them in groups of two or three. You can see a schematic and artful representation of your hand on the screen, and the software can also recognize a hand and fingers as well as certain gestures like swipe, circle or a keytap. (It can not always track individual fingers, and they seem to appear and disappear a lot of the time.) One interesting thing is that it also calculates the centre of a sphere that would fit in the palm of your hand.

We could see all the data that the Leap generated in real-time by accessing a file in the browser that displayed the data as JSON. It was quite interesting to see when a gesture was recognized, or seeing the number of hands and fingers change, also finding out the range where the Leap was able to "see". We then got to play a game of Space Invaders where you could move the ship by moving your arm and use your finger to trigger shots. (I love Space Invaders - I really do think it was the first ever computer game I played, on my cousin's Atari.. yes, I'm that old..). We also got to play a multiplayer version (Web Sockets, again!). We then looked at a JavaScript wrapper with the functionality for controlling the ship through movements. We started manipulating the code by making it stop on a certain condition (like a certain gesture). In the process, I learned a useful trick: You can introduce a breakpoint by putting the word "debugger" into a function call. The plan had been to write a better controller class, but it seemed everybody was more keen to play around, and I think we were at that point also lacking a bit in concentration! It was anyway a great session.

So, that was it. It was an intense and enjoyable two days, and going through the sessions again (I actually looked at the code of all of them where I had it!), I find it has been really useful to me. I wonder what will actually come out of it. I have in any case at least one project where I want to try things out, but I am sure it will benefit my work in general.

Thanks to everyone who made this event possible, especially Andrew McGregor and the speakers!