Link: Why We Can't Solve Big Problems - MIT Technology Review
The article that is featured on MIT TR's cover for this month very much aligns with my thinking about innovation. We are not innovating at the level that humanity did in the not-so-distant past. We are working on short-term ideas that are only incrementally better than what was available previously rather than creating solutions that transform society. The major problems that humanity faces are widely acknowledged, but nobody is solving them adequately. The article argues that the reason we are not solving these large problems is because society both lacks the environment needed to develop and test ideas for these hard problems and we are using the wrong tools to solve problems. Furthermore, the challenges we face now are different from the ones in the past and require theoretical underpinnings that we are still developing — in short, these problems are much more complex.
One interesting idea that I took from the article is that not all problems are technological in nature — specifically the example given about Amartya Sen 's work which states that the cause of famine is not from an actual shortage in the food supply, but a problem with food distribution which is more likely caused by economic or political reasons rather than simply agricultural inefficiency.
In other news, I just found out that the magazine had decided to go digital first in June.
This perplexing video uses some rather clever camera tricks and simple physics. The link gives an explanation of how it is done, but not why. :-P
Video Description:
Fishing under ice (ORIGINAL)
Uploaded by juusdo on Jan 2, 2012
Some under ice views from beautiful lake Saarijärvi in Vaala, Finland
Divers:
- Fisherman: Eelis Rankka
- Fisherman's friend: Tommi Salminen
- Boy with the balloon: Jukka Pelttari
Camera and editing: Juuso Mettälä
Manuscript by Juuso Mettälä and Eelis Rankka
Safety divers: Esa Vuoppola and Juhana Heino
Music: Stefano Mocini: The end of the doubs
Couple of things about this video:
Camera I used was Sony HDR-SR11 with Amphibico HD Elite housing.
The Wheelbarrow was saved from the bottom of the lake and I have used it many times after that.
The rubber duck and the balloon are also home with me.
None of the divers got any permanent damage either.
And yes, we had a lot of fun making this video.
-Juuso
Link: Finnish Underwater Ice Fishing Mystery Finally Solved : Krulwich Wonders... : NPR
 |
About a year ago (October 2011), I wrote a small tool (git repo) that has really made using my e-mail a much more enjoyable experience. My personal e-mail inbox is on Google's Gmail service; however, I find the web interface gets in the way of reading and organising my e-mail. I make heavy use of the label and filter features that let me automatically tag each message (or thread), but having labels that number in the hundreds gets unwieldy since I can not easily access them. I use the IMAP interface to reach my inbox through the mutt e-mail client; this is fast because there is almost no interface and I can bind many actions to a couple of keystrokes.
The main problem I had with using IMAP was that, although I could see all the
labels presented as IMAP folders, I had no way to know which labels were used
on a particular message that was still in my inbox. I had thought about this
problem for a while and looked around to see if anyone made proxies for IMAP,
but there was not very much information out there. I had originally thought
that I would need to keep a periodically updated database of Message-IDs
and labels which I would query from inside mutt and I had in fact written
some code that would get all the Message-IDs for a particular IMAP folder,
but this was a slow process. I didn't look into it again until I was talking
about my problem with a friend (Paul
DeCarlo) and he pointed me towards the Gmail
IMAP extensions. This
was actually going to be possible!
I quickly put together a pass-through proxy that would sit between the mutt client and the Gmail IMAP server. Since Gmail's server uses SSL with IMAP (i.e. IMAPS) to encrypt the communication, I would need to get the unencrypted commands from mutt and then encrypt them before sending them to Gmail. Once I had this, I could log the commands to a file and study which IMAP commands mutt was sending. At the same time, I had a window open with IETF RFC3501, the IMAP specification document, so that I could understand the structure of the protocol. Once I saved the log to a file, I didn't actually need a network to program the filter that I was writing — in fact, I finished the core of the program on a drive back from the ACM Programming Contest in Longview, TX! When I got home, I tested it and it worked almost perfectly except for another IMAP command that mutt was sending that was not in my log, but that was just a small fix.
Not very long after I first published the code on Github, my code was mentioned on the mutt developers mailing list on 2012-02-01.
Todd Hoffman writes:
I read the keywords patch description and it definitely sounds useful. One reminder is that gmail labels are not in the headers and can only be accessed using the imap fetch command. Users of offlineimap or some other mechanism to retrieve the messages and put them in mboxes or a maildir structure will not be able to extract them from headers, in general. Of course, a patched version of offlineimap or an imap proxy (see https://github.com/zmughal/gmail-imap-label) that assigns the labels to a header could be used also.
It was good to know that people were finding my project. Also, over the summer, I received my first ever bug report from Matthias Vallentin, so I knew that somebody else actually found it useful. \o/ This was a great feeling, because it closed the loop on the open-source model for me: I was finally contributing code and interacting with other developers.