Software Engineer / Research position - MIT App Inventor

The MIT App Inventor team is looking for a software engineer with interest in research in education, and, of course, open source.
You can find more information in this thread. If you want to know a little more about what we do, you can keep on reading this blog, or ping me on twitter and I'll be happy to talk to you.

What are you waiting for to apply? do it... now!

Random Hacks of Kindness Boston 2014

The fine folks of the Boston brigade of Code for America have done it again... a fantastic weekend full of hacking, delicious food, and awesome projects!

This was also part of the kickoff of the National Day of Civic Hacking competition, but back to Boston, you can find tons of information in the event's hackpad.

Here though, I'm going to write a little about the project I was involved in, Union Capital Boston. The main idea is to create a system of rewards, similar to the typical restaurant or coffee shop loyalty cards, but in which people accumulate points through good deeds in their communities. This is targeted to individuals and families within lower income brackets, so that they can exchange points for things that can help them make ends meet, such as groceries or travel passes.


On the tech side, the main app is being built on meteor. To be honest, I didn't have a lot of time to form an opinion about how meteor works, but the one thing that took me by surprise is that being a node framework, it has its own package manager, and things are a bit confusing (sometimes you load packages from meteor, sometimes from atmosphere, and there's some support for npm??? dunno, I'm confused!).

I spent most of the Saturday trying to push the meteor app into a Cordova app. After many hours fighting with a few different solutions I found on the net, it turned out that the wifi we were using wouldn't allow two devices to talk to each other; so most of my time was spent trying to fix the unfixable. On Saturday night I arrived home, compiled the app without changing a thing, and it all worked. On Sunday back at GreenTown Labs, it wouldn't work again. In any case, you can check out the app in my github repo at UCapp. The readme file also documents all the research I went through on Saturday, and some failed attempts. You can find the main UC Boston app at Duncan's repo, and a lot more information in our project's hackpad.

It was great to meet new people and see some old friends that I hadn't seen in a while. Looking forward to the next meetup (and hackathon) already!

Closing #RHoKboston @carpeliam and @_beechnut pic.twitter.com/Ta11CcAIqO
— Jos (@josmasflores) June 1, 2014

App Inventor - Related Research

This is another slide deck from an MIT 6.S198 lecture, this time about EdTech in general, and more specifically about the many research influences that App Inventor and other similar systems share.



If you want to know more about the class, feel free to browse (and use, reuse, redistribute, improve, and so forth!) the materials linked from the class' calendar.

JavaScript for Developers @MIT 6.S198 - Fall 13

As part of the App Inventor class we run last semester at MIT, I prepared (or I should say rehashed, cause I had used this same material before for training) this presentation about JavaScript for developers familiar with other programming languages.



If this is of interest to you, you can consult the calendar and all materials for the class here.

A Single Thread of Execution in App Inventor Screens

The development documentation provides a very good example of why certain things in the User Interface (UI) of an app happen in the way they do. In App Inventor we use Screens to lay out components to create the UI of the app.

The main idea is that all actions that affect the UI happen sequentially. Some examples of these kind of actions could be changing the text of a label, or handling users interacting with the app via a button or a text box.

Sequential execution in App Inventor means that different blocks can never interrupt each other.

Different blocks and handlers will always be executed in sequence. Once a block starts executing, it will execute till the end, no matter if there are other blocks reacting to the one in progress, or users pressing buttons in the app. On more technical terms, we say that everything in the UI is executed in one Thread, the UI Thread, which is responsible for all updates and interaction that happen in each Screen of your app. For this to happen, we need some kind of mechanism to keep track of what needs to be done next, and when something should be done. A very simple model would be a Queue, just like the one you join at the supermarket to pay for your shopping. Tasks can be added to a Queue in the same way that people join in the queue from the end of it.

With all this in mind, let's see the example in the documentation. (From How to add a component )

“This gives a simple execution model for users: An App Inventor procedure will never be interrupted by an event handler, or vice versa; nor will one event handler be interrupted by another. This is illustrated in Figure 1:” (Ellen Spertus)

Figure 1: Sample program demonstrating serial semantics.

The example uses two Ball components, one CollidedWith handler that should fire as soon as Ball1 collides with anything, and an extra procedure called wait, which we don't really see what it does, but we are going to suppose that it takes 20 seconds to execute (imagine that it is loading content from the internet and it takes that long). All the code, except for the collision handler, is contained within a Click handler.

When Button1 is clicked, the two balls are positioned in exactly the same place, first Ball1, and then Ball2. Positioning the second ball in the same place as Ball1 should trigger the collision handler for Ball1. Some users would expect this to happen straight away, but if you were to execute this code, you would see that the collide handler will not execute until the click block finishes, and this would take at least 20 seconds because of the call to wait.

Following the same idea as above, you can think about the UI thread as if it was a Queue to get into the cinema; on arrival, ticket buyers will position themselves at the end of the queue.

When Button1 is clicked, we add the following things to the Queue:

• position Ball1
• position Ball2
• wait
• set Label1 text to : '...End of Button1.click...'

When Ball2 is positioned, the CollideWith handler is added to the Queue, but it cannot be executed straight away because the UI thread still has some tasks to do. So, after a couple of seconds we will see a queue such as:

• position Ball1 (DONE)
• position Ball2 (DONE)
• wait (IN PROGRESS)
• set Label1 to: '… End of Button1.click ...' (TO DO)
• CollidedWith (added to the queue when the collision happens)
  • set Label1 text to: '… Ball1.CollidedWith ...' (TO DO)

So Ball2 makes the handle trigger, but that does not mean that it will be executed straight away, instead it means that it will be added to the queue in the UI thread.

In the end, Label1 will always be assigned the value '...End of Button1.click...' first, and the value '...Ball1.CollidedWith...' later.
When both blocks finish, it will always read: “...End of Button1.Click......Ball1.CollidedWith...”.

Please note that having a procedure like wait blocking the UI is a really bad idea in an app, because as we saw in the explanation above, the app will be unresponsive for those 20 seconds, and this is not a pleasant experience for the users. If your app needs to do some expensive processing, it is quite possible that this interaction will block the app for as long as it takes.

From a design and development point of view, it is also important to note that certain blocks in App Inventor were designed with the UI thread in mind, and broken down into two different stages. For instance, the Web component Get call could be considered part 1 of a call to a web resource. This call will not block the UI because it is not performed in the UI Thread. When the response from the Get call is received, then part 2 will execute, which would be the event GotText (or GotFile, depending on how Get was configured). If you are planning on developing a new component for App Inventor, you need to take this into account.

Also related to this idea of sequential execution, a lot of users ask why their timers do not fire on time, for instance exactly every 2 seconds. Actually the timers fire at the time they are supposed to, but this only means that their handlers get added to the scheduling queue for UI updates. If at that particular moment something else is executing in the Screen, then the actions fired by the timer will have to wait for those other actions to finish, before they can be triggered. But once they get next to be executed in the Queue, they will fire one after the other, not waiting for any intervals. The waiting was already done before joining the Queue. 

This is actually something very usual in UI libraries, from Java (Swing) to Android, and even JavaScript. The browser, in which JavaScript executes, also has a single thread of execution, generally called the event loop, and it will behave in the same way as App Inventor does. Same happens if you run JavaScript on the server through something like node.js.

This is all a simplification of what really happens, and Android can create other Threads of execution that do not conflict with the UI thread to carry on with other operations. For a deeper dig in the matter, follow the link in the Android documentation to the Painless Threading article.

Roman Numerals Kata revisited

More than a year ago I wrote a post and recorded a video about the Roman Numerals Kata. To be honest I haven't been doing many katas lately but as I've had this weekend for myself, I went back and revisited the Kata, in JavaScript this time. And also recorded a video:



I am not really sure about how my coding has changed in the last year. There's no doubt that JavaScript uses a very different philosophy to Java, and I'm a lot more confident writing JavaScript now, but other than that, not much seems to have changed.

The only common pattern I see is that TDD is really helpful. In both screencasts you can see me doing something wrong (mixing up symbols last year, and forgetting to set the main function for immediate invocation this year, for instance) and only by having tests failing I realised that they were problems. It really saves you time if you don't have to deploy your code and play around with it to see what you've broken. Also, being the first user of your own code allows you to put a bit of thought in your design.

In this version I was not interested about recursion or Maps in Java, and I decided to skip the outer BDD layer (although Jasmine would allow me to do so). What was more interesting was to go through the different Module pattern incarnations in JavaScript, and using jasmine-node from the command line, although the --autotest option keeps crashing on me so I cannot use it! I am not the biggest fan of autotest utilities but for these kind of deliberate practice they are actually quite nice.

the busiest September in years!

This has certainly been the busiest September for me in many many years. I can even say the busiest in my life.

After finishing August in a high note with the Ruby Ireland Rails 3.1 launch party, September started with a Ruby Project night in amworks in which we were working a bit on Conway's Game of Life.

The following week two events took place, on the Tuesday the dublinjs meetup with a fantastic backbone.js presentation by David and a kata by Wiktor, and on the Saturday I had the privilege to co-organise and co-facilitate the first code retreat in Dublin (and in Ireland as far as I know!).

If that was not enough, on Sunday I took a flight to Madrid to attend XPWeek. The Monday was a full day of talks, and the rest of the week I attended the TDD courses by Carlos Ble.

I have posts coming about some of these events so won't go into details here, but all the events were absolutely fantastic!

We have also been pushing a new release of Open Wonderland for a while and I think there will be some juicy news out very soon, which is very exciting!

And tomorrow, 1st of October I will certainly not be missing the SocketStream session that the AOL Dublin guys are preparing. That is if this stupid cold I've been nursing since I'm back in Ireland allows me to get out of bed!

the summer of busy

So far this summer is being much busier than usual.

A couple of weeks ago I attended the html 5 hack-a-thon organised by the Dublin GTUG guys. It was real fun and got to meet some very interesting people and to hack on a browser multi-user whiteboard based on WebSockets and canvas. All the projects were really good, and the effort during the two days paid off big time.

Last week we were busy working on a rails mountable engine to add feedback forms to your web during the Ruby Project nights at amworks. Only a few hours there but it's great to be able to learn and share socially out of work hours, at least from time to time!

In the meantime all is good to go for the code retreat we are organising for September the 17th. Location and sponsorship is pretty much all we needed, and we are looking forward to the day. Tickets flew in less than 3 days, so hopefully people will turn up on the day. If you are reading this, have a ticket, and know for sure that you cannot attend, please let us know cause we have a growing waiting list.

And finally, all is ready for the dublinjs meet up tonight in which Wiktor will tell us all about CoffeScript and Dom has prepared a Kata for us to go through. Great fun ahead!!!

Dublin JavaScript Group July meet up -- Kata Reloaded!

We are organising another Kata session for the Dublin Javascript meetup this month, which will happen tomorrow Tuesday the 19th at 6.30pm @amworks. You can sign up here.

These are my slides for the event, which are pretty much the same as the ones I used last month.


The initial idea was to have a presentation on Processing.sj although that has been postponed, but I'm sure Nigel will come up with something. And in any case we are going ahead with uncle Bob's Prime Factors Kata.

The solution, in the form of a powerpoint document, can be found here so you don't really have to worry about the solution itself and can focus on practising the Kata instead.
A couple of interesting points I've noticed after practising it a couple of times are the differences between his Java implementation and a JavaScript one, and my mixed feelings to his last refactoring, which I find a bit contrived. I prefer to stop at the level of 'while' structures because I believe it preserves the intent of the algorithm a lot more than if you go the whole way and replace them with 'for' structures. The result has more lines of code but in my head it's clearer. But as usual, this is a personal preference and everyone will have their own, which is a good thing!

The format for this part of the meetup will be the following:
I will go through the slides, which will take me about 3 minutes. Then we will set about 20 minutes for people to work on the Kata. Working in pairs using ping pong pairing would be highly recommended. The idea is that one person writes the first test, the other person makes that test pass and writes the following test, and this goes on until the Kata is solved. If you don't want to pair, that is fine. If you don't want to program at all, that is fine too!
During those 20 minutes I'll be available to help out, especially to any new faces that are not familiar with the concept of a Kata or with Jasmine. At then end of this period we will project one solution and have a short retrospective about it.

And that is all, please feel free to join us from 6.30pm at amworks. See you there!

Sprockets for JavaScript

As a JavaScript newbie, a thing that some times puts me off when I see some libraries out there is the fact that they tend to be just the one big file, with long functions and tons of lines of code that is not that easy to follow.

Sprockets aim is to help out with this situation. As their website reads:

[Sprockets] helps you turn messy JavaScript into clean modules for development and a single file for deployment.

Sounds good to me!!! so how to get started? Reading the manual, of course!

The following is a quick a dirty guide to Sprockets and how to use it from the command line with the sprocketize command. I have created a really silly bunch of sample files that contain only dummy js functions and are here just to illustrate the use.

Installation

Installation is easy peasy through a Ruby gem. The only trick here is that if you are using rvm (and you should!) you will not need to use sudo, and if you are using your system Ruby it will probably be need. So let's do it:

gem install sprockets

And you are ready to go!

What else you need to know? Only two more things are needed: directives and the sprocketize command.

Directives

//=

Comments that start with the symbol above are considered directives, and they are used to pull in other resources that your project will use: other JavaScript files and any assets you use in the form of stylesheets, images, and so on.

There are two directives currently supported in Sprockets, require for other js files, and provide for other related assets. If the files are surrounded by quotes as in "myfile", then sprockets will only look for that file in the same directory. If is used, then all the load path will be searched for. That load path can be indicated to sprockets through the command line option.

So let's see some code: I have two files called my_file_1.js and my_file_2.js and I want them in just the one file for deployment. The contents of the files are:

my_file_1.js

function firstFunction() {
  // I do nothing really!!!
};


my_file_2.js

//= require "my_file_1.js"
function secondFunction() {
    // I do nothing but function one should appear before me
};

The Sprocketize command

There are different ways to use Sprockets being probably the Ruby library the most used. But the gem also bundles a command line tool which is a wrapper for the Ruby library so let's go with that cause it is really easy.

From the previous section we have two files called my_file_1.js and my_file_2.js and I want them in just the one file for deployment. To generate that concatenated file we can do:


sprocketize *.js > deployment_file.js

This will create a file called deployment_file.js with the following content:

deployment_file.js
function firstFunction() {
};
function secondFunction() {
};


You can see that firstFunction has been pulled in before the second one, and in the process all the comments and stuff that you don't need to deploy have also been stripped out. How nice is that!!!???


Hungry for more?
There is more about Sprockets that you can fin about in their manual. It is a great tool that I hope to start using soon.

Dublin JavaScript Group June meet up -- jQuery and Jasmine

In a couple of hours the JavaScript Dublin Group will meet up for the second time. The first meetup was last month, and it was basically a gathering to get to meet other people and talk a bit about organisation.
So this will be the first time for a technical session. Nigel Kelly will be talking about jQuery apps, and I will run a Kata session in JavaScript using Jasmine. I hope people will follow along. We will use the standalone version of Jasmine and the kata chosen for the session is Fizz Buzz.

I came up with the following 4 slides (yeah, want to keep it short!):



The slides will not make much sense on their own, so you better come to the meet up!


This means that I will miss the P2PU SICP study group session on IRC (freenode #sicp room) today at 7pm GTM, 3pm EST, but it's for a good cause, right? :)

learn, laugh and move on!

There's been a lot going on lately and as a professional procrastinator I couldn't let go the chance of putting off writing a new blog post, but with things going back to normal (hopefully!) it's about time for a bit of reflection.

It's been a very social few weeks, ending May with a double bill: The software craftsmanship conference in Bletchley Park, and a coding day with the chaps of codingday.org here in Dublin.

What can I say about scuk11? it was a great day with fantastic sessions and I got to meet a great bunch of Spaniards in red t-shirts. Happy faces all over... yeah, the bar was already open!

The Dublin event was also fantastic and although it was first thought as a coderetreat, the addition of scientists and their real problems changed the nature of the session itself and made of it a fantastic coding day. The group I was working with got a spinning cube in the browser, with three different lights and three particles lighting up the cube with different colours. Great fun using the Three.js library!

The month of June started with @silverspoon organising hack nights in a café near the city centre, that I sadly missed because I was in Barcelona for a conference. Spain was great, as usual, although it was raining most of the time, but that didn't really have an impact on things such as meeting old friends, the great conversations we had, and of course, the fantastic food!

On Tuesday the 14th we had the first meet up for the SICP study group at P2PU. You can see what happened in the new wiki. This is an open group which basically means that you can join in anytime that suits you. We will meet twice a week for the next couple of months, Tuesdays and Sundays at 7pm GMT, 3pm EST. We are hoping to finish a section every two weeks, including exercises. As chapter one of the book has 3 sections, we are hoping for a 6 week period to be done with it. Wish us luck!!! or even better, join in!!!

Last night the first Ruby Project Night happened in armworks. The space is absolutely great and I want to thank Alan for hosting it. We didn't really know what to expect at first, and after a bit of chat and trying to get the projector going, we started hacking away in a rails 3 gem, something that none of us had done before. We didn't get too far but at least we got it packing and installing fine. As soon as the @theirishpenguin pushes it publicly I will share the link here. It was great to meet a bunch of enthusiastic people and looking forward to meeting them again!

This morning I read this 'Help Wanted' message from @oisin in the ruby Ireland list. If you are looking for contract Ruby work you should definitely get in touch with him. His last talk at ruby Ireland was really interesting.
In the thread he mentions that they like egoless programming which brought me back to the this old post of mine. Weingberg's book is a very recommended read even if as myself, you were not even born when it was written!

An finally, more to look forward to as the first 'technical' meet up of the Javascript Dublin group will be next Tuesday 21st at 7pm. A presentation about jQuery for web apps and a kata with Jasmine are in the menu. Are you really going to miss that???

Mutant-Java and the KataLonja

Another month and another Kata with the 12meses12katas crowd. This time the kata is in Spanish, and it was created by the agilismo.es guys for the professional track of XGN2011. If anyone needs/wants a translation, do get in touch and I'll produce one. You can find the original version in github: KataLonja.

The Kata is about a Galician chap who wants to make some money by selling Scalops, Octopus, and Spider Crabs in a hired van. We are given a series of prices that markets in different cities will pay for the goods, alongside with distances, transport costs, and depreciation rates for the food, and we need to provide the most interesting route to get a best sale for our intrepid entrepreneur.

As a Galician immigrant myself, this is the simplest kata ever: I would drive the van right into my garage and the goods straight into my fridge; as easy as that!

Sadly this is not going to happen so let's get back to the kata. I'm certainly nowhere near finishing it, I only gave it a first go last night before bed but some cool stuff is already coming up out of it.
As I mentioned in a previous post, I use Katas to refresh some concepts that I haven't seen in a while, or that although I might use them in my day job, I've never gone deeper at them than the old getting the job done.
Last month I choose JavaScript for the bowling kata, and because I started way too late (the last day of the month!), that was the only implementation that I practised on the day. I will try and get this one practised in both Java and JavaScript, starting with the former.

Java has no associative arrays and it's generally accepted that you will use Maps instead. Maps can be very straight forward if you are using an immutable object as the key for your pair, but can get tricky if you decide to use your own class. So that's exactly what I did. It might not be the best fit for the problem at hand, or yield the leaner and cleaner code possible, but no one will have to maintain this code and it's going to be thrown away anyway so better have a bit of fun with it!

So I have created an immutable class for Seafood that I will be using as a key for at least two maps I'm using in other classes. That means overriding equals() and hashcode(), and being careful with state and escaping references to this. But as I said above, the code is nowhere near written, so what's the point of the post you will be asking yourself? I just wanted to share 3 links that have been helpful in digging a bit deeper in the adventure so far. They are:

• Hashing it out!
• To mutate or not to mutate?
• How to write an equality method in Java

In them you will find good advice on stuff such as when to create immutable classes and how, uses of immutability including the flyweight pattern, overriding equals() and hashcode(), and a great discussion on how to keep the equals() contract on extended classes, adapted from the book Programming in Scala into Java.

I will be digging a bit more, hopefully in the next couple of days, in topics such as choosing the right map implementation and a couple more things that I want to try (I'd like to write my cucumber step definitions in Ruby instead of Java but I'm not sure I can do that, so will have to find out!).
I also intend to write another post if I ever get to practise the Kata in JavaScript. Comparing both implementations would be cool so let's hope for that!

SICP Study group at P2PU

As mentioned in a previous post, I have decided to learn JavaScript in a serious and deep way, and after following Douglas Crockford's advice on reading the little schemer, it's time for Structure and Interpretation of Computer Programs, also known as SICP.

Due to low numbers in the Anglo-Celt SICP Study Group, we have decided to open the group to the world through the Peer to Peer University (P2PU).

The course is still in draft but so far I've had great feedback from some of the core P2PU community members and I'm hoping that it will go ahead. You can see the draft of the course here: SICP Study group.

[UPDATE]: The course has been moved to the new P2PU site and it is now hosted here and open for application.

As usual, this is a peer to peer, community based effort, and everybody is welcome, even those of you that have read the book already. Assuming the role of mentor can be a fantastic experience, especially in terms of communication and other soft skills that are so important in our field.

To join the course all you need is the motivation to read the book and participate actively in the group, writing blog posts about what you are learning and experiencing, and be willing to share your solutions through github.

As in the previous course, I expect to use Open Wonderland for some of the meetings, but the course can be followed in an asynchronous manner too. If you are interested head to the course and apply (once it's open), or give us a shout if you have any questions!

about JavaScript, Scheme and History

I've been doing a bit of JavaScript lately and I am shockingly enjoying it. I thought it was going to be a nightmare and a lot of copy+paste but after a good amount of reading and watching talks, I started to like the language. I've been collating bits an pieces of information in the ossdev-ireland wiki, mainly focusing it towards developers that only have to deal with the language in small doses.

Ossdev.org is a place to share experiences that overlap the different open source groups in Ireland. JavaScript and MongoDB are the two topics that seem to be gathering more interest so far, but it's been less that one week since the wiki was installed, so hopefully more topics will start being worked on soon.
The Irish Penguin is the one to blame for all this sharing craziness, and I hope more people get on board in the next couple of weeks.

As usual, following on links and references in talks and tutorials takes you to a thousand other talks and tutorials that you will never have the time to read and watch. I would recommend the fantastic series on Javascript by Douglas Crockford. I especially enjoyed Part I: the early years, cause although it does not contain any code, it is a great lecture in history of computing, and I totally agree that that is an area that we don't handle very well in the profession.

During that talk, Crockford recommends the little schemer as a book that will change the way you think about programming, so I had to get my hands on a copy of it. I have to say that it was a bit difficult to get started with it, because although it seems to be a book targeting children, there is no explanation whatsoever on how to start with the language itself. A bit more digging on the net and I finally downloaded DrScheme, and got it running. Although the site points to a newer version, namely Racket, DrScheme still exists as a package in Ubuntu systems, so that's what I'm using for now.
So this is my first scheme listing ever:

(define atom?
  (lambda (x)
    (and  (not (pair? x)) (not (null? x)))))
(define lat?
    (lambda (l)
      (cond
        ((null? l) #t)
        ((atom? (car l)) (lat? (cdr l)))
        (else #f))))

(lat? '(chunky bacon))
(lat? '(chunky (bacon)))

The first call to lat? returns true, and the second false. Let's see how long I can keep up with the parenthesis madness... the plan is to follow on to SICP, but I will have to finish this one first!