MIT Laboratory for Automation, Robotics, and Society
Directed by David Mindell
Visualization Design: Yanni Loukissas
Research Assistant: Francisco Alonso
The Apollo 11 visualization draws together social and technical data from the 1969 moon landing in a dynamic 2D graphic. The horizontal axis is an interactive timeline. The vertical axis is divided into several sections, each corresponding to a data […] Specific events are labeled, such as computer program changes and program alarms. During a real-time playback, the white line moves across the horizontal axis as audio plays, and the crew’s specific utterances are spelled out to the right. In sync with the human dialog, the AGC and DSKY display values and modes. In these dynamics, one can trace the trading of workload and authority during the critical final phases of landing, and how that workload was offloaded from the LEM to Houston in response to the program alarms.
In 2011 I started my adventures in the perilous lands of bigdata, so I’ve begun harvesting literature on the subject. Extremely interesting and relatively young field. I have an almost finished review of “Data Analysis with Open Source Tools” which I hope to publish soon.
Novels
My first encounter with Douglas Coupland. I particularly liked Microserfs, that somehow seemed to be speaking directly to me. Perhaps not for everybody.
Five minutes after Games of Thrones s01e01 I realized I couldn’t wait an entire week to know the rest of the story. Still entertaining, after ~3000 pages and already in the fourth book.
I’m a hardcore Neal Stephenson fan. I also have Anathem in my stack, but I decided to read Reamde first, because it seemed less dense. It was, and also more fast-paced than usual.
Last weekend, I went to London to participate in the Music Hack Day.
This particular hackathon is growing with a very fast rhythm. Consider what follows, for example: my very first MHD was Barcelona in October 2010, and from that moment I had the opportunity to partecipate in three other editions (New York, San Francisco, and another time in Barcelona) and to be among the public during the Cannes’ edition. That, and I also managed to skip another twos. After less than three years since the entire initiative started, it has demonstrated a relentless pace in proposing new events and building a community of music hackers (more on that later).
Spotify App Store, and MXM’s hack
I think one of the main themes during this MHD was the recently announced Spotify App Store. Most appropriately, a group of Spotify developers was present at the conference, which proved to be an inestimable source of help and encouragement during the 24H sprint.
Despite some minor glitches and random problems with the development environment, I have to say that writing software that has to be deployed into the Spotify client is a pleasure. It all boils down to write one or more web pages, using Javascript to make it live, via Spotify’s API and maybe another third party service to do something interesting.
In fact – after all, I’m a musixmatcher – we spent the weekend working on a lyrics app. I think the aim of such a project is obvious, anyway here a screenshot.
Next?
I’m not sure where next MHD will be. There will be a new “proof of concept” during Midem early in 2012, and I heard about another full-fledged edition in Amsterdam soon. I have the feeling, also, that Dave Haynes, our über-organizer, is almost flooded with cities offering to host next MHDs. That’s good news.
I think the majority of the attendants are employed in companies operating in the digital music ecosystem, but I also met many “solo” developers simply attracted by the coolness of the event. More importantly, I can’t help but seeing people helping each other and collaborating even if they’re not coworkers or members of the same masterplan to conquer the music industry. In other words, a true community is growing.
I’m not sure what’s the best way to keep nourishing this community: certainly there’s no shortage of opportunities to meet, but I think more can be done on the online part. Food for thought.
I wrote a very small utility to gather LOC counts from a git repository. Called gitsloc, it’s based on Cloc, with some extra goodness provided by Sysadm::Install (a rather inaptly named module, if you ask to me, but full of useful gems).
I guess it could actually have some uses, who knows?, but I wrote it mostly because I wanted to see how fast repos are growing, and R is the obvious tool to tinker with the results.
I’m less than a beginner with R, and I have to admit plotting data from a multi-column CSV file is less straitghforward than I expected: I had to use xyplot from the lattice package, like this:
Here the result, with data provided analysing the Dancer github repository (branch devel).
With my current employer, we decided telecommuting was worth a try.
Our office is distributed between Barcelona and Bologna, with occasional incursions by traveler colleagues who happen to be in some random coffee house around the world.
One of the key elements for this setup to be practical and effective is Skype, which I don’t particularly like but I have to admit works pretty well in this scenario. In our headquarters in Bologna there’s an USB microphone/speaker, which my colleagues connect in shifts to their laptops, or to a spare Android tablet. On my side, I use the Macbook Pro internal mic and headphones.
The Skype audio chat is always on, meaning that it’s almost like being there: I only miss lunch and coffee breaks.
Actually, it seems it’s even more vivid than the real thing. It’s not unusual some of them shout “MUTE!” in my direction: the internal microphone on my parts takes in too much consideration the tik-ke-ti-tak of the keyboard, which in Bologna becomes an unsolicited, thunderous and rather unpleasant proof I’m really at my desk.
Of course I could use the handy HUD window with all the Skype controls, but that requires 1) finding its position on the screen, 2) moving my hands from keyboard to trackpad, 3) click the mute button. I’m lazy, and I wanted something less cumbersome. Something like a keyboard trigger to toggle the mute status of the current Skype call. Triggers? Quicksilver to the rescue.
I knew Quicksilver permits to assign arbitrary actions to hotkeys, and those actions can be anything you can do with Quicksilver: for example, running an Applescript program. Unfortunately, a quick inspection in the Skype’s Applescript dictionary revealed there was no direct and simple access to the Mute toggle. Here the first program I wrote to solve the problem:
This is largely based on a piece of code by Jacob Rus I found in a hold post on Macworld. It accepts a single parameters (“Mute” or “Unmute“) and it will work only if you use the English Skype localization. I don’t think there’s something particularly interesting in this program, except the useful code I borrowed from Jacob, the trick with frontmost application to re-activate the application which had the focus before switching to Skype and, yes!, the fact is remarkably long to perform such a simple task. Also, I’m not set with only this script: I’d need to create two different hotkeys for muting and un-muting, and assign them to two different ways of calling the script itself.
There must be a shorter path.
To a closer inspection (silly me!), I noticed the menu item I’m using keeps the same hotkey (I mean hotkey from Skype’s standpoint): no matter what the current mic status is, it’s always ⇧⌘M. Let’s try to shorten the program.
No need to differentiate the mechanism, and there is so much less code!
I just unboxed my Kindle. I played with it for a few hours only, but I’m satisfied with the choice so far.
First of all, to the zealots that may happen to read this article and feel compelled to whine on “scent of paper” and other oddities: I’m not planning the disposal of all my “real” books, neither I’m considering buying only digital contents from now on.
I decided to buy an ebook reader because I wanted to see on my own what can be done with this technology, which I consider immature and yet to be completely exploited. I think I am an early adopter, even if Amazon Kindle and its competitors hit the market several years ago.
Also, I think having an ebook reader is nowadays the most practical solution to the eternal problem “What books should I bring with me during the journey?”. Being able to answer “All!” is a wild dream that comes true (but I understand this can be a problem as well).
Anyway, here a few impressions from a very very beginner.
The device itself looks beautiful. It’s not heavy and it seems prolongated use will not be tiring. On the other hand, I have the impression it’s not particularly sturdy. Again, this is something I can say only in a few months (or in a few hundreds kilometers).
I think the slogan “it’s like paper” is inaccurate. Whatever appears on the screen seems printed, but it does not recall paper to me. Besides that, fonts are very crisp and readable, so Kindle hits on the spot for what is supposed to be its main use.
I am positively surprised by the refresh delay. Maybe because I expected it to be even worse, I think it’s bearable, at least for the kind of books you read cover to cover in a sequential fashion. In other words, good for novels, articles and stuff like that; maybe not practical for manuals, documentation… in general, things you want to study, or browse randomly.
I suspect I will eventually feel hampered by the position of buttons on the device. Anyway, this can’t be but a speculation.
I’m currently at my parents’ place, and there are problems with the Internet connection, so I couldn’t try its wifi capabilities yet. A pity: one of the things I was more eager to try was Kindle’s use in conjunction with Instapaper.
The Italian Perl Workshop. This year, for a change, we will be in Turin. The conference will be held on September 8-9, with my Introductory Perl Class the day before. I’m linking the material for last year’s class, but I have slightly different ideas for the incoming version.
I would like to go faster on basic syntax – spending a reasonable amount of time dispelling doubts about data structures, which proved to be useful – and to present Moose as “the way you should do OOP in Perl”, probably mentioning the old way as historical curiosity.
In the middle of August there will be YAPC::Europe, in Riga. It may seem odd to say that in January, but I’m looking forward for a climatic detour from the hot days we’re likely to have in Spain. And it will be great to meet friends and Perl hackers, as usual.
For the past two years I missed the London Perl Workshop. I think its single day model works very well and should be copied more avidly. And I love to spend time in London.
Today I attended the first half of the Music Hackday, in Barcelona. Here some pictures:
I should certainly spend many more words about this great event, but in short:
Congrats to the orgas for the smooth and enjoyable day: plenty of space to hack, nice location, and the internet connection was just working
There’s a lot of interesting APIs and products outside to explore, more than I expected: besides the big and very-well-known players like Last.fm, I discovered The Echo Nest, Canoris and MuseScore, just to mention a few.
I never tried this unconference formula before, but I think I’ll look for more: even if I didn’t hack very much (just polished some bits of my MusixMatch APIPerl client), I really enjoyed the general atmosphere, and I can’t wait to see what the other attendees will present tomorrow.
I recently attended YAPC::Europe 2010 (and helped a bit organizing it), and I’d like to share some advices I was thinking on, for those speakers who will present at technical conferences in the future. These advices are mostly about how to prepare your slides, with something on how to deliver your presentation. There’s plenty of stuff available on the net about this topic, but I feel like stressing some points.
When you decide your colour palette, don’t consider its impact only on your own display. As a matter of fact, I think this should be the last of your concerns. Your slides will be projected with a beamer, or reproduced on a big monitor: they could both spoil the colours you spent lots of hours on.
If you can’t make up your mind about the colours, keep it simple: black text on white background is very likely to perform well on every situation.
Enlarge the font-size.
Again.
Ask the conference staff to check your equipment, and verify the impact of your chosen colour scheme. Check it also from the rear rows, if you think the room will be crowded. Check nevertheless: there could be people entering the room late, staying behind to avoid disturbing the other attendees.
Use the right tool to make your slides: if, after the check, you think your choices (colours, font size, etc) were not that sound, you should be able to change them rapidly. Styles are great.
If you think you are going to give a live demo, think twice. If you’re still convinced, you have to plan carefully also this part. First advice: the 190×100 terminal window that’s so practical for your daily job will be almost unreadable for the audience. Even more with the usual black background many hackers seem to favour. And a total failure if the organizers will record your talk. I suggest keeping a terminal setting designed specifically for demo delivery: 80×25, big font, high contrast, possibly white background.
You’re surely familiar with what I call the “demo effect”: something you rehearsed so carefully at home, will miserably fail during the real thing. Especially if you want to write code on stage to demonstrate a technique or a library. A nice trick I saw to avoid this problem is based on version control (dakkar++). Write the code in advance, keep it in your favourite version control system, and tag the relevant steps of the development. During your talk, checkout those tagged revisions while you proceed with the explanation: doing so, you can still show the audience how the mini-project is evolving, but you won’t need to write any code “live” (with a considerable probability of messing it up). Also, you can go back and forth if someone ask to clarify some point.
About