Hacks from the kitchen

Machine Learning study group in Copenhagen

We just ended the founding meeting of a Machine Learning Study Group here in Copenhagen. We're planning to meet approximately once a month to discuss machine learning algorithms. In between meetings there's a Facebook group where we hang out and discuss our current pet machine learning problems and a Google Docs repository of machine learning resource (still to come).

Here's how we're going to run the group: The goal is to get smarter about machine learning. We're narrowing down on a couple of stacks we care about. Big data using databases - we're going to have a look at Madlib for Postgresql. Or something based on Map/Reduce. Some of us occasionally work in Processing using OpenCV - which is neat, because it's also a good choice on the iPhone/in XCode/Openframeworks.
Some of us are probably going to be looking at Microsoft Solver Foundation in C# at some point. Some of us might be looking at implementing algorithms for one of these environments if no one else has.

We'll be building out our knowledge on configuring and setting up these stacks. The idea is for everyone to work on a pet problem with a machine learning element. We'll share our ideas on how to proceed, share how to approach the stack of software.

The typical approach to a machine learning problems involves

• Identifying the problem - figuring out where machine learning is relevant


• Working out how to get from problem to symbols - i.e. how to turn the data inherent in the problem into input for the textbook algorithms. As an example, in image processing this means coming up with some useful image features to analyze, and figuring out how to compute them efficiently. This can be really tricky, and we expect a lot of the discussions in the group will be about building out our skills in this area.


• Picking the best algorithm - we'll be studying the core algorithms. Not necessarily implementing them; but learning about what they mean - and how they behave

Just to give a little landscape: The founder members are primarily interested in the following spaces of problems: Image analysis - with a little time series analysis of sensor data thrown in for interactive fun - and "big data", running machine learning algorithms on web scala data.

If you're into this problem space, and this style of working - project driven, collaborative and conversational - feel free to join. If there's simply something you'd like to be able to do with a computer, feel free to join as well - maybe one of the more technical hangers on will take an interest in your idea and start working on it.

Creating websites with builtin APIs

Whether or not its RESTian kosher I don't know, but the live Apollo 11 transcript is built natively around a JSON API. If you don't like mine - feel free to make your own.

Details: The API is at

http://www.classy.dk/cgi-bin/apollo_transcript.pl?q=transcript&jsonp=somejsonp_prefix

- note the jsonp parameter, which lets you call the api from JQuery and similar libraries without cross site worries. Don't need JSONP. Don't know what it is? just use

http://www.classy.dk/cgi-bin/apollo_transcript.pl?q=transcript

instead. If your javascript api needs the parameter, the doc will explain how to use it.
The output is quite simple: There's a 'now' parameter indicating server time (seconds since unix epoch), time of liftoff in same terms and notes from the log. The item 'current' is the latest transcript item before now. The item 'future' a list of the next events to occur.
The format of the events is an array with four elements: time, an id for the speaker, the actual text and a text representation of the time - relative to 'now'
If you build something using this script, please be conservative in how frequently you call the API - the future item gives you an idea of when it makes sense to call.

If something is unclear just view source on http://classy.dk/moon - which explains in source how to use it with JQuery, and gives tables describing the IDs of speakers.

This way of building websites: Presentation with HTML+CSS+JQuery and a pure API backend really appeals to me. Clearly there are fallback concerns for non-modern browsers etc. etc. but the separation of concerns is appealing - as is the instant availability of an API for other's to use.

Getting to the Flash developers

It worked wonders for the ARToolkit to be connected to the Flash developer community. Maybe it will work for Arduino and hardware hacking as well - using the Netlab toolkit.

Demo Dag - vil du være med?

Har du lavet noget der (næsten) virker, så kom og vis det - eller kom og se på de andres ting.
(English? Summary at end of post.)

Første gang: 9/6 kl 20:00. Sted: Egmont, Vognmagergade 11 (kom præcis, så vi kan lukke jer ind)

(location: Egmont HQ, Vognmagergade 11, Kbh K. Be there sharp at 8PM - we need to traverse access control. )
Sign up here (or by leaving a comment on the post)

Jeg ved ikke af at der findes en begivenhed med følgende plan i København: Man møder op med sin dims. Noget man har lavet. Noget der virker*. Man har 15 minutter til at vise det frem og så er der fem minutter til snak. Så er det næste projekt. 5-6 projekter per aften og så en ølpause Demoer er 7 minutter lange, med mulighed for dommerens overtid. Diskussion i pausen og bagefter. Tænk pecha kucha, bare uden slideshows.

Vil du være med til at lave en? Jeg kan ikke se nogen grund til begrænsninger af hvad projektet kan være - web, visuelt, auditivt, mekanisk, elektronisk, til køkkenet, søfarten eller soveværelset - udover nogle grundregler:

• Det virker - det er ikke konceptdag, men demodag.


• Don't tell us - show us Vi vil hellere se hvad den kan, end hvad du lavede den af.


• Ellers ingen grænser Intet er for stort og intet for småt. Kom med dit million-dollar produkt eller din hjemmestrikkede, ørkenhærdede, touch-enablede pandekageopskriftlæser.


• Gem dine slideshows, servicekoncepter og forretningsplaner til en anden aften

Datoen er ikke skrevet i sten. Jeg foreslår tirsdag som en god ugedag - fordi torsdage og fredage for ofte er optaget.
Læg en kommentar hvis du er interesseret. Skriv om du gerne vil se på, eller om du har noget i skufferne du gerne vil vise frem.

English Summary Want to participate in a (software or hardware) demo day in Copenhagen? June 9th. Only running code. Demos are 7 minutes (with negotiable slack) Other than that hardware or software, woodware or anyware, web or desktop, mobile or stationary - anything goes. Leave a comment if you're interested. Include whether you've got stuff to show or want to look.

* Om det er lavet af træ, chips, papir eller bits er op til dig. Det skal være lavet. (næsten) af dig. Man skal kunne demoe det. DET VIRKER er de magiske ord, der åbner døren op. Tvivlstilfælde afgøres af Deres ærbødige overdommer.

How much abstraction does it take to run Twitter

On Twitter, @tveskov asks, how many layers of abstraction does it take to run Twitter.
This is a really hard question, probably intractable - if you want to include the physics and signalling of lasers through the fiberoptic cables that sends Twitter's data to my home. There are simply too many different places along the route where the platform relies on some level of abstraction and comprehension, to do a full enumeration.
Instead, let's tackle a simpler question: How many technologies/abstractions are directly visible in Twitter's source code. I did a view source and tried to find all the technology that I could see from the source would be in use to run Twitter.
The rule here is that it there has to be text in the source file that does not make sense unless I know the abstraction/standard/software/API I'm referring to below.

Here my best shot at the list (in order of discovery (by me, while reading))

• xhtml


• DTD's


• XML namespaces


• XML


• CSS


• Browser DOM


• utf8


• ico file format


• png file format
• 
  
• gif file format


• jpg file format


• HTTP


• RSS


• ATOM


• URI scheme


• HTML4 (I think. Seems the "bookmark" rel attribute comes from there)


• "nofollow" microformat


• "hcard" microformat


• DNS


• Javascript


• JQuery API


• There is some kind of anti-bot posting implementation - but I can't tell what the API for that is like

Notably absent: The email standards. While obviously employed by twitter (as are many other standards if the API is considered), I found no evidence of email in the source of the logged in front page.

Adobe AIR really rocks

To convert the Spotify DJ from a little fun personal hack to something real it was clear that I needed some "consumer grade" way to install the DJing client on the machines of would be DJs.
"Some way" turned out to be Adobe AIR. Adobe AIR can be used with Flash, Flex or just plain old web skills - html and Javascript.
No matter which route you go you end up compiling a one file deliverable that installs as a real desktop application on the system.

I have had no exposure to Adobe AIR prior to today - but armed with online tutorials I started out at around 6 PM and at around 11 PM I was done - with time for UI tweaking and a little webserver work required to make the app work.

Adobe AIR quite simply brings web speed to the desktop. And its a pleasure to work with too. The runtime is a browser, so everything just works. I like JQuery - and of course I can just plug that in.
I haven't done things "properly" - haven't signed properly, haven't used the upgrading framework and so on, but the fact that I can make a useful UI that interacts with the file system and a web server in 4-5 hours is astounding. And it deploys as a 65k file.

News from Johnny Chung Lee

Awesome new videos from the Wiimote hacker extraordinaire Johnny Chung Lee. In this first video he is using the Wiimote again to orient oddly shaped display for adaptive projected displays. In another video here's projection control by automatic calibration of displays with build in light sensing. There's more.

Going down

I really like Sam Ruby's post on scaling down. Scaling down is a key concern of mine too, which is why I'm making this the weekend that my "all the perl I need for a webapp in one use declaration"-module goes onto CPAN.
Microscopic apps with almost zero footprint are a huge idea, it's the luxury version of Jot, the smart wiki that got consumerised into Google Sites.

Here's another super sweet example of scaling down: Jquery can insert the content of a specific DOM element from an external webpage into a specific DOM element on the current page in just one line

$("#links").load("/Main_Page #p-Getting-Started li");

Note the space between url and # - it's not an anchor but a CSS id. Very nice.

Professional screen scraper

Good Jon Udell post on data friction and the strange but understandable fact that data is usually only made available in human consumption form, not machine readable form - making screen scraping a profession..

Genetic algorithm/travelling salesman

3D Travelling Salesman using Genetic Algorithms from Ryan Bateman on Vimeo.

It's intesting how erratic the development is - it's not like large swaths of the final solution are found early and stable for most of the animation.

DTrace Tech Talk

Bryan Cantrill, creator of DTrace, likes to debug, as far as I can tell from this Google Tech Talk. I always loved debugging, the detective work is engaging and the sense of reward when you win is great, but after watching I feel suddenly sad to spend all my time on DTrace-less platforms.

Maybe I should go Nexenta?

Optimized Tour de France TV-watching

Here are some quick geek tips to optimize your Tour de France TV-watching beyond what the broadcast offers.

One of the annoyances of std (Danish) tour coverage is that the reporters suck with numbers. The coverage has improved lately, adding actually knowledgeable former rider Rolf Sørensen to the reporting mix, but still - we don't get the numbers we deserve, so we simply have to make our own.
The first thing we need to do is do our own timing - and why not use this convenient javascript stop watch (or your watch or your cell phone). Secondly, and this is where the reporters really suck, we need proper numbers for how fast the riders are going. The most useful numbers are time/distance instead of the usual distance/time. These numbers are both easier to observe, using the stopwatch, and more meaningful: Tour math is mostly about how much time difference a rider or group of riders can make up during the remainder of a climb or a race.
Third, to make sense of these times we need some sensible ideas about how fast the racers are actually able to go in different terrain. Here are some pointers observed during this years tour:

• Peleton, chasing a group of riders for 30-40km: 50km/h


• Solitary rider, long break: 40-45km/h


• Sprint leadup - final 2 km: 55 km/h from -2 to -1 km and 65km/h for the last km


• Sprinter - (this is actually not so relevant to know up to 80km/h instantaneous speed during final burst


• Moderate climb (5% incline) 25km/h


• Steep climb (10% incline) 15km/h
- what's moderate or steep varies immensely among riders obviously, see below

Below I've compiled a convenient conversion table from km/h to minutes/distance for various speeds and distances. If we use that to evaluate the info above we can tell e.g. that the peleton can gain 5-20 seconds per km on a small group og a single rider on a break, unless this rider is a time trial specialist, so 4-5 min breaks 30km from the finish line are non-events. Danish television used to have a huge problem with bogus excitement about such breaks, but fortunately this has changed a lot.
We also learn why time/distance is so much more telling than distance/time. While a speed difference of 20km/h to 25km/h doesn't sound very dramatic a time loss of 30 seconds per km travelled sounds huge - especially at the bottom of a 15km hill. And these are exactly the kinds of differences that exist between good and great riders.

Geek-optimized tour watching involves timing the front groups as they pass landmarks and/or the official 20, 15, 10, 5 km gates, comparing these speeds to the incline exactly where they are. It then involves comparing time gains per minute to the peleton, figuring out from these numbers the speeds of the different formations on the road, figuring out time to the top, computing plausible total time gains losses. Checking relative performance along different parts of the route also. The many split times of the javascript stop watch are a great help here.

Mountain relevant speeds

km vs km/h	10	15	17	20	22	25	30	35	40
0.5	00:03:00	00:02:00	00:01:46	00:01:30	00:01:22	00:01:12	00:01:00	00:00:51	00:00:45
1	00:06:00	00:04:00	00:03:32	00:03:00	00:02:44	00:02:24	00:02:00	00:01:43	00:01:30
1.5	00:09:00	00:06:00	00:05:18	00:04:30	00:04:05	00:03:36	00:03:00	00:02:34	00:02:15
2	00:12:00	00:08:00	00:07:04	00:06:00	00:05:27	00:04:48	00:04:00	00:03:26	00:03:00
2.5	00:15:00	00:10:00	00:08:49	00:07:30	00:06:49	00:06:00	00:05:00	00:04:17	00:03:45
3	00:18:00	00:12:00	00:10:35	00:09:00	00:08:11	00:07:12	00:06:00	00:05:09	00:04:30
3.5	00:21:00	00:14:00	00:12:21	00:10:30	00:09:33	00:08:24	00:07:00	00:06:00	00:05:15
4	00:24:00	00:16:00	00:14:07	00:12:00	00:10:55	00:09:36	00:08:00	00:06:51	00:06:00
4.5	00:27:00	00:18:00	00:15:53	00:13:30	00:12:16	00:10:48	00:09:00	00:07:43	00:06:45
5	00:30:00	00:20:00	00:17:39	00:15:00	00:13:38	00:12:00	00:10:00	00:08:34	00:07:30
5.5	00:33:00	00:22:00	00:19:25	00:16:30	00:15:00	00:13:12	00:11:00	00:09:26	00:08:15
6	00:36:00	00:24:00	00:21:11	00:18:00	00:16:22	00:14:24	00:12:00	00:10:17	00:09:00
6.5	00:39:00	00:26:00	00:22:56	00:19:30	00:17:44	00:15:36	00:13:00	00:11:09	00:09:45
7	00:42:00	00:28:00	00:24:42	00:21:00	00:19:05	00:16:48	00:14:00	00:12:00	00:10:30
7.5	00:45:00	00:30:00	00:26:28	00:22:30	00:20:27	00:18:00	00:15:00	00:12:51	00:11:15
8	00:48:00	00:32:00	00:28:14	00:24:00	00:21:49	00:19:12	00:16:00	00:13:43	00:12:00
8.5	00:51:00	00:34:00	00:30:00	00:25:30	00:23:11	00:20:24	00:17:00	00:14:34	00:12:45
9	00:54:00	00:36:00	00:31:46	00:27:00	00:24:33	00:21:36	00:18:00	00:15:26	00:13:30
9.5	00:57:00	00:38:00	00:33:32	00:28:30	00:25:55	00:22:48	00:19:00	00:16:17	00:14:15
10	01:00:00	00:40:00	00:35:18	00:30:00	00:27:16	00:24:00	00:20:00	00:17:09	00:15:00
10.5	01:03:00	00:42:00	00:37:04	00:31:30	00:28:38	00:25:12	00:21:00	00:18:00	00:15:45
11	01:06:00	00:44:00	00:38:49	00:33:00	00:30:00	00:26:24	00:22:00	00:18:51	00:16:30
11.5	01:09:00	00:46:00	00:40:35	00:34:30	00:31:22	00:27:36	00:23:00	00:19:43	00:17:15
12	01:12:00	00:48:00	00:42:21	00:36:00	00:32:44	00:28:48	00:24:00	00:20:34	00:18:00
12.5	01:15:00	00:50:00	00:44:07	00:37:30	00:34:05	00:30:00	00:25:00	00:21:26	00:18:45
13	01:18:00	00:52:00	00:45:53	00:39:00	00:35:27	00:31:12	00:26:00	00:22:17	00:19:30
13.5	01:21:00	00:54:00	00:47:39	00:40:30	00:36:49	00:32:24	00:27:00	00:23:09	00:20:15
14	01:24:00	00:56:00	00:49:25	00:42:00	00:38:11	00:33:36	00:28:00	00:24:00	00:21:00
14.5	01:27:00	00:58:00	00:51:11	00:43:30	00:39:33	00:34:48	00:29:00	00:24:51	00:21:45
15	01:30:00	01:00:00	00:52:56	00:45:00	00:40:55	00:36:00	00:30:00	00:25:43	00:22:30
15.5	01:33:00	01:02:00	00:54:42	00:46:30	00:42:16	00:37:12	00:31:00	00:26:34	00:23:15
16	01:36:00	01:04:00	00:56:28	00:48:00	00:43:38	00:38:24	00:32:00	00:27:26	00:24:00
16.5	01:39:00	01:06:00	00:58:14	00:49:30	00:45:00	00:39:36	00:33:00	00:28:17	00:24:45
17	01:42:00	01:08:00	01:00:00	00:51:00	00:46:22	00:40:48	00:34:00	00:29:09	00:25:30
17.5	01:45:00	01:10:00	01:01:46	00:52:30	00:47:44	00:42:00	00:35:00	00:30:00	00:26:15
18	01:48:00	01:12:00	01:03:32	00:54:00	00:49:05	00:43:12	00:36:00	00:30:51	00:27:00
18.5	01:51:00	01:14:00	01:05:18	00:55:30	00:50:27	00:44:24	00:37:00	00:31:43	00:27:45
19	01:54:00	01:16:00	01:07:04	00:57:00	00:51:49	00:45:36	00:38:00	00:32:34	00:28:30
19.5	01:57:00	01:18:00	01:08:49	00:58:30	00:53:11	00:46:48	00:39:00	00:33:26	00:29:15
20	02:00:00	01:20:00	01:10:35	01:00:00	00:54:33	00:48:00	00:40:00	00:34:17	00:30:00

Flat road relevant speeds

km vs. km/h	40	45	50	55	60	65	70	80
0.5	00:00:45	00:00:40	00:00:36	00:00:33	00:00:30	00:00:28	00:00:26	00:00:23
1	00:01:30	00:01:20	00:01:12	00:01:05	00:01:00	00:00:55	00:00:51	00:00:45
1.5	00:02:15	00:02:00	00:01:48	00:01:38	00:01:30	00:01:23	00:01:17	00:01:08
2	00:03:00	00:02:40	00:02:24	00:02:11	00:02:00	00:01:51	00:01:43	00:01:30
2.5	00:03:45	00:03:20	00:03:00	00:02:44	00:02:30	00:02:18	00:02:09	00:01:53
3	00:04:30	00:04:00	00:03:36	00:03:16	00:03:00	00:02:46	00:02:34	00:02:15
3.5	00:05:15	00:04:40	00:04:12	00:03:49	00:03:30	00:03:14	00:03:00	00:02:38
4	00:06:00	00:05:20	00:04:48	00:04:22	00:04:00	00:03:42	00:03:26	00:03:00
4.5	00:06:45	00:06:00	00:05:24	00:04:55	00:04:30	00:04:09	00:03:51	00:03:23
5	00:07:30	00:06:40	00:06:00	00:05:27	00:05:00	00:04:37	00:04:17	00:03:45
5.5	00:08:15	00:07:20	00:06:36	00:06:00	00:05:30	00:05:05	00:04:43	00:04:08
6	00:09:00	00:08:00	00:07:12	00:06:33	00:06:00	00:05:32	00:05:09	00:04:30
6.5	00:09:45	00:08:40	00:07:48	00:07:05	00:06:30	00:06:00	00:05:34	00:04:53
7	00:10:30	00:09:20	00:08:24	00:07:38	00:07:00	00:06:28	00:06:00	00:05:15
7.5	00:11:15	00:10:00	00:09:00	00:08:11	00:07:30	00:06:55	00:06:26	00:05:38
8	00:12:00	00:10:40	00:09:36	00:08:44	00:08:00	00:07:23	00:06:51	00:06:00
8.5	00:12:45	00:11:20	00:10:12	00:09:16	00:08:30	00:07:51	00:07:17	00:06:23
9	00:13:30	00:12:00	00:10:48	00:09:49	00:09:00	00:08:18	00:07:43	00:06:45
9.5	00:14:15	00:12:40	00:11:24	00:10:22	00:09:30	00:08:46	00:08:09	00:07:08
10	00:15:00	00:13:20	00:12:00	00:10:55	00:10:00	00:09:14	00:08:34	00:07:30
10.5	00:15:45	00:14:00	00:12:36	00:11:27	00:10:30	00:09:42	00:09:00	00:07:53
11	00:16:30	00:14:40	00:13:12	00:12:00	00:11:00	00:10:09	00:09:26	00:08:15
11.5	00:17:15	00:15:20	00:13:48	00:12:33	00:11:30	00:10:37	00:09:51	00:08:38
12	00:18:00	00:16:00	00:14:24	00:13:05	00:12:00	00:11:05	00:10:17	00:09:00
12.5	00:18:45	00:16:40	00:15:00	00:13:38	00:12:30	00:11:32	00:10:43	00:09:23
13	00:19:30	00:17:20	00:15:36	00:14:11	00:13:00	00:12:00	00:11:09	00:09:45
13.5	00:20:15	00:18:00	00:16:12	00:14:44	00:13:30	00:12:28	00:11:34	00:10:08
14	00:21:00	00:18:40	00:16:48	00:15:16	00:14:00	00:12:55	00:12:00	00:10:30
14.5	00:21:45	00:19:20	00:17:24	00:15:49	00:14:30	00:13:23	00:12:26	00:10:53
15	00:22:30	00:20:00	00:18:00	00:16:22	00:15:00	00:13:51	00:12:51	00:11:15
15.5	00:23:15	00:20:40	00:18:36	00:16:55	00:15:30	00:14:18	00:13:17	00:11:38
16	00:24:00	00:21:20	00:19:12	00:17:27	00:16:00	00:14:46	00:13:43	00:12:00
16.5	00:24:45	00:22:00	00:19:48	00:18:00	00:16:30	00:15:14	00:14:09	00:12:23
17	00:25:30	00:22:40	00:20:24	00:18:33	00:17:00	00:15:42	00:14:34	00:12:45
17.5	00:26:15	00:23:20	00:21:00	00:19:05	00:17:30	00:16:09	00:15:00	00:13:08
18	00:27:00	00:24:00	00:21:36	00:19:38	00:18:00	00:16:37	00:15:26	00:13:30
18.5	00:27:45	00:24:40	00:22:12	00:20:11	00:18:30	00:17:05	00:15:51	00:13:53
19	00:28:30	00:25:20	00:22:48	00:20:44	00:19:00	00:17:32	00:16:17	00:14:15
19.5	00:29:15	00:26:00	00:23:24	00:21:16	00:19:30	00:18:00	00:16:43	00:14:38
20	00:30:00	00:26:40	00:24:00	00:21:49	00:20:00	00:18:28	00:17:09	00:15:00

Mara-hacka-thon

The Mono team pulled a 21-day 12-16 hour-per-day hackathon to implement Silverlight for Linux that they have dubbed Moonlight. 21 days with a group of good hackers doing double shifts and working on the weekends. Just counting hours, each contributor will have put in about as much work as a regular 9-5 employee does in two months. We're assuming the entire team is composed of clever people - only clever hackers care to work so much. And lets assume there's a handful of people working on it (seems reasonable from the task list). So about a years worth of quality development delivered in 3 weeks by a small committed team with no external constraints and full concentration.

Sounds about right to me. Miguel de Icazas war story blog post is a great read.