@steffentchr

The LBJ Book Club: New job, New deal / discussion of Path 13-16

Sun, 25 Dec 2011 23:06:00 +0100

The LBJ Book Club: New job, New deal / discussion of Path 13-16:

Our LBJ Book Club is getting interesting…

Random observations:
- Johnson giving dictation on the toilet is one of the most told stories about his time in the White House, and its genesis is revealed here. I wonder if anyone has tried to emulate this tactic?

- Johnson felt that coffee would distract Latimer and Jones — not only making the coffee, but also the small act of drinking it would waste valuable time.

- “Burn this — others probably won’t understand the personal references” is a great way to end personal correspondence.

Are you following along?

The LBJ Book Club: Is this the trap?

Thu, 01 Dec 2011 18:33:49 +0100

The LBJ Book Club: Is this the trap?:

Guan and I are teaming up to bring you an online book club over the next few month. We’ll be reading the Robert Caro’s series of biographies of Lyndon B. Johnson to celebrate the forthcoming release of the fourth book in the series, The Passage of Power.

If you aren’t rushing out to buy the books just for the pleasure of our company, here’s the pitch for why you need to do so anyway.

Is it a box or a TV? Yes...

Wed, 16 Nov 2011 21:58:00 +0100

There’s been much speculation about Steve Jobs’ “I finally cracked it” remark on Apple’s role in the TV industry. I am not following the Apple blogs closely, but the future Apple TV strategy has been a recurring topic on my weekly soaps.

Mainly, the discussion has centered on whether the product will be a new box (as the current Apple TV) or a full-fledged television set? (Consensus: A TV.) And on how the product will get its content? Obviously, it will be hooked in to the iTunes infrastructure, but will it have a cable connection for ordinary TV watching? (Consensus: Probably not.)

The conversations though have missed a few pretty obvious options, and I thought I’d gather my predictions here. If for no other reason that to be wrong on the record.

It will be both a box and a TV: Apple will release both an iTV Mini (essentially a new version of the Apple TV box) and an iTV Cinema, a large and beautifully designed LCD screen with the same hardware built in as the box. Both the Mini and the Cinema will run the same iOS based software, which will account for the entire user experience.

(Relatedly, the PC media will ridicule Apple for shipping the large TV screen without the ability to change and upgrade the hardware box — because the company has chosen not to simply build the Cinema with a replaceable Mini box inside.)

You can connect your cable: How is Apple going to get sufficient content penetration has been the biggest question so far. The strategy might require an AT&T-like partnership with Comcast (or whatever other cable provider is willing to play), but generally the idea is this: You hook up your cable to the Mini or Cinema, you put in your cable card, and you will have access to content based on your cable subscription. Live TV is played directly from cable, and the electronic program guide will look purdy and Apple-like.

Recording is done through iCloud: The magic is in the recording of shows though. Rather than shipping the hardware with hard drives, any piece of content available through the cable package can be recorded to iCloud — and playback in done over IP. Since you’re technically just recording the content available in the cable package, content availability is eliminated as a problem. The content you current get through TiVo will be available on the Apple solution, and you might even be able to record two or three simultaneous shows with a single cable card.

(On the server side, Apple would need to store massive amounts of data; but much less than you’d expect on first glance. De-duplication to the rescue. Apple would be recording everything from a few thousand channels/live feeds, and making this single version available to everyone who’d thought to record the show.)

There will be iTunes and there will be apps: I think this goes without saying, but the iOS SDK is coming to the iTV. And all the standard iTunes content will be there as well.

This strategy seems to solve the pricing problem: Rather than having to choose between an inexpensive product (the Mini) to get market share and an expensive one (the Cinema) to maximize profits, the dual strategy achieves both. The Cinema will be a 5% thing, but it probably would be in either case.

This strategy also seems to solve the content problem: Yes, Apple is still relying on the cable companies (just as they rely on mobile carriers to sell iPhones), but the compromise maximizes content. Over time, the iTV will pop up in more and more homes and cable will become less important while Apple’s negotiating power with content providers increases.

The iTV Mini will be $149 and the iTV Cinema is $2000.

[DK] Podcast med @jacobchr, @guan og jeg selv om perspektiverne...

Wed, 07 Sep 2011 21:21:00 +0200

[DK] Podcast med @jacobchr, @guan og jeg selv om perspektiverne i den nuværende valgkamp. Det er spændende og heldigvis bredere end blot, hvem der har vundet i meningsmålingerne i dag.

Du kan downloade eller abonnere som podcast og i iTunes

A call for a progressive IT agenda

Tue, 06 Sep 2011 10:53:00 +0200

Version2 is using the upcoming Danish election to run a series on the IT policies of the individual parties running for Parliament. The first two articles interview the IT spokespeople for the two largest parties, and frankly the outcome is disheartening. In each interview, fifteen questions are asked and the result is vague and non-committal statements on issues affecting us all — both in how we interact electronically with the government and more broadly how we conceive digital democracy.

Asked about the value of software patents, on legislation limiting the use of cookies and on personal data protection, Yildiz Akdogan (Social Democratic Party) argues both sides of the issue and then leaves the question unanswered. Michael Aastrup Jensen of the Danish Liberal Party isn’t much better. Software patents? Yes and no. Cookie legislation? Yes, but it’s not our problem. Blame it on the European Union. Personal data protection and cloud computing? Yes, no, whatever.

We deserve better. We deserve a political system where important digital democracy questions are actually handled by people with a clear vision of where we’re being taken. Not by catch-all answers amounting to barely muddling through. The Internet and the society revolving around it is too important a force to be discussed in such general terms. So what should we think?

Do you support software patents?

Whether you want to answer Yes or No to this question, you should have a clear answer ready. Software patents and their selective application has been the subject of a lot of stories over the past few months: NPR’s Planet Money team has done a number of great overview stories about patent. The indie mobile developers have been hit by Lodsys. And we’ve seen Apple, Google and other giants in a land grab for patents with a $3.14B price stamp.

Whether you find the arguments for patenting software compelling or not (I don’t, but that’s not the issue here) you should and must have made up your mind as a Danish political party acting in 2011. Nuanced views are more than welcome, non-committal ones aren’t.

Do you support the EU “cookie directive”?

The EU cookie directive is a policy which should have taken effect in May of this year, but has been postponed until 2012 due to implementation and guidance issues. Put simply, the policy mandates that web publishers must inform users about their use of cookies and other tracking technologies — and can only make use of such technologies in an opt-in fashion.

This is an amazingly stupid idea. The directive is based on a fundamental misunderstanding of how the internet works; cookies do not track individual users on a personal level, they track visitors anonymously on the level of usage patterns. Through tracking within a web page, web publishers can build a persona and track usage of a site in order to make it better. For example, we use cookies with 23 Video to track video usage and present aggregated statistics to our customers — we don’t use it to track named users. In an opt-in world, all such legitimate usages of cookies to improve the web experience for users would be outlawed (at least in practice since opt-in will never work).

Cookies are not the enemy here. Cookies are necessary for the Internet to work. The enemy might be particular uses of cookies to track behavior across domains, but even that evil doesn’t warrant this policy.

So what do the Danish parties say? On the one hand, consumers should be informed. On the other hand, it shouldn’t burden publishers. Please, please, please don’t make me have a real opinion about anything!

(Also, see the somewhat annoying interactive guide to the policy.)

Should internet traffic from open hotspots be logged down to the individual and personal level?

Here, there’s actually some clear answers. Unfortunately those answers are wrong. The Social Democrats want to allow personal logging of traffic, while the Liberals only want to log terrorism while minding our civil rights. It’s unclear how that distinction should be made without actually logging all traffic, but Michael Aastrup Jensen worked in an IT company before being elected to Parliament, so he probably knows.

The built-in contradiction is that web publishers are not allowed to track anonymous usage, while government can access personalized and detailed information about how we all use the web.

There’s a fundamental disrespect for the Internet inherent in such as view: To me, the Internet is a democratizing force with a potential to stand above any individual person or individual government — and realizing this potential, we also need to respect the neutrality of the Internet. Open societies have downsides, but those must be embraced to capitalize on the much bigger upsides.

Should ISPs be forced to block site access through DNS?

Both parties answer with a heavily qualified Yes, and I’m guessing the only qualification is bound to court mandates.

The correct answer though is No. DNS is designed to allow propagation or caching of internet addresses in order to make for a faster and more resilient browsing experience. TDC, Telia or whichever name server provider you’re using is a caching relay for information published by other nodes, and the view that Danish ISPs are responsible for the IP addresses served up by their name servers is ludicrous. We need to protect the web from intrusion of political idiocracy, and whenever this line is breached we become a less democratic society.

Should public IT projects be open source?

None of the spokespeople want to mandate open source in the public sector, and here we agree. Of course, public IT projects shouldn’t utilize open source project just for the sake of it. Open source can stand on its own, and if it isn’t the best available option for the job, the commercial alternatives should be chosen. Of course.

The politicians miss the larger point of the question though. It isn’t a matter of using other people’s open sourced code — it’s a matter of open sourcing code themselves. I couldn’t care less which office suite is being used in the halls of the public sector, but the truly interesting potential is to open source the code being written for tax money. Whenever a new service, a new piece of software, a new integration is developed, we should all be able to evaluate the code — and both other public institutions and private ones should be able to reuse and improve on the code.

To summarize, I’ll reiterate my sense of disillusion: It isn’t that either of the politicians asked in the articles are particularly wrong. Rather, this is a missed opportunity. IT policy is faced with a number of really interesting issues that could potentially propel us forward with a progressive IT agenda. But when our leaders cannot even muster a modicum of interest in those issues, we’re failing ourselves.

[Danish] Tryk Optag #3: Men drømmen slutter jo ikke dér,...

Tue, 23 Aug 2011 14:59:00 +0200

[Danish] Tryk Optag #3: Men drømmen slutter jo ikke dér, Morten

Jeg og Morten Saxnæs tager fat i de højtflyvende emner, som cyborg tattoveringer, rumturisme og flydende lande, men slutter af med en mere jordnær debat om open source-bevægelsen og fængselsstraf for Facebook opdateringer.

Du kan downloade som MP3 eller abonnere som Podcast eller i iTunes.

"Android has been so successful through a) hard work by engineers and b) a disruptive and very..."

Sun, 21 Aug 2011 23:45:06 +0200

“Android has been so successful through a) hard work by engineers and b) a disruptive and very different business model. Java is yesterdays technology though, and if we saw webOS at Google I think that Android would have been even more than it is today.”

- Dion Almaer on webOS’ troubles at Palm an HP, because going on to make a pitch for Facebook to take over

Deploying on stage for the hell of it sound like fun.

Fri, 19 Aug 2011 00:49:05 +0200

Deploying on stage for the hell of it sound like fun.

[Danish] Denne uges podcast fra hr. Morten Saxnæs og jeg selv...

Tue, 16 Aug 2011 10:14:00 +0200

[Danish] Denne uges podcast fra hr. Morten Saxnæs og jeg selv under den fine titel Det er jo klart, de skal sige det. Vi snakker om ytringfriheds og politik i sociale medier, og åbenhed i Android og om min nye titel som JACSHT developer.

Du kan downloade som MP3 eller abonnere som Podcast eller i iTunes.

"HIRING MANAGER: So, do you know JACSHT? CANDIDATE: No, sir, I don’t know JACSHT. HIRING MANAGER:..."

Sun, 14 Aug 2011 23:37:25 +0200

“

HIRING MANAGER: So, do you know JACSHT?

CANDIDATE: No, sir, I don’t know JACSHT.

HIRING MANAGER: How can you expect me to employ you if you don’t know JACSHT? The whole world is moving towards JACSHT.

CANDIDATE: Sir, I wish I knew as much JACSHT as you.

”

- HTML / CSS / JavaScript – We Need An Acronym

Org-Mode: Your Life in Plain Text

Sun, 14 Aug 2011 20:46:25 +0200

Org-Mode: Your Life in Plain Text:

It’s one if the joys of being an Emacs user that you will always find another hidden gem in your text editor. Here’s a plain-text todo list mode for Emacs which seems built for the world git and Dropbox.

I'm a developer and I hate "networking". Here's why.

Sun, 24 Jul 2011 12:49:00 +0200

Tine Thygesen, a previous colleague from 23, declares provocatively that developers hate networking for the wrong reasons:

The reason developers, and many non-business people, hate networking because the terms is largely misunderstand and misused! … The reason [is] they think they have to entertain hot shots they have nothing in common with with witty oneliner or deep business insights.

Tine is absolutely right. As a breed, we don’t really like chatting for the sake of chatting. (And we absolutely don’t have neither wittiness nor insight when let out of the cave. By then the uncaffeinated climate has shocked our systems enough to keep us quiet in the corner.)

To the developer mind, networking changes any focus from short-term action to the long-term talking. Networking challenges us to talk our way into key relationships - rather than to act, build, do. And above all, any good developer will prefer to do.

Tine’s call for a different way to talk about networking is spot on, but she is aiming her arguments in the wrong direction. It’s a mistake to try to teach developers the value of community and of relationships though. Ask any developer how he or she learned to code, and I guarantee you that the answer is through tutorials and questions on blogs and forums. And by reading open source software.

The interesting bit is that the social web (take Twitter as an example) is teaching The Network People to network the same way that developers have been doing for ages: By showing yourself to knowledgeable and interesting within an accessible and flat structure. It’s modern networking through content and personality, rather than through access, status and position.

Twitter creates informal bonds and provides ample room to listen in to a conversations form the side-lines. And then to contribute. It starts off with an open invitation and slowly encourages people to get involved. This is very similar to how geeks have been setting up well-functioning open source and crowd-sourcing projects through the ages.

I think we are teaching the bizzies to network, not the other way around.

Fault-tolerant HTML5 uploads with Resumable.js [Open JavaScript]

Sun, 10 Jul 2011 15:46:00 +0200

With 23 Video we (at 23) receive a large number of really, really large files every day. At times, we get files of several gigabytes transferred over a simple HTTP connection. Usually, this works out alright, but we’ve wanted to make better use of some new features in modern browsers to make uploads more stable — specifically, to allow users to pause their uploads and have the uploads automatically resume if the internet connection fails (either locally or to our servers).

This approach is fairly new and is only available in Chrome (11+) and Firefox (4+), so no one has packaged the feature-set we wanted nicely yet. This calls for open sourcing a few hundred lines of code and a victory lap:

We bring you Resumable.js as our answer.

Resumable.js is a JavaScript library built on top of the HTML5 File API to:

Allow selection or dropping of multiple files.
Handle queuing and progress indications during upload.
Uploads files in small chunks, rather than in a single big batch.
Automatically resume uploads if something fails, for example if the network connection drops.

The first two features have been available through Flash and related tools for quite a while, but I’m pretty excited about the latter two. Chunking and auto-resuming will allow for a degree of stability in HTTP uploading we haven’t seen before: Resumable.js will simply keep uploading until all the bits of a file has been sent. And it all happens transparently to the user.

The Resumable.js-based uploader will make its appearance in 23 Video later this summer, but we will also add support for this method in our API for direct browser uploads — in fact the prototype uses this API method behind the scenes.

Paranoid

Sat, 12 Feb 2011 14:22:09 +0100

Guan is paranoid, but it’s probably a good list to consider. My own strategy is much simpler and involves both a trade-off in terms of immediacy and restorability:

I’m running Backblaze to do an almost full back-up. It doesn’t include my VMware machines or my system files so I won’t be able to restore immediately — as Guan would from his SuperDuper! drive once he’s opened his safe deposit box. This means that I keep no data on my virtual machine that I actually couldn’t live without.
I’m using Dropbox for all my actual documents — including symlinking in my Desktop and other system folders I use frequently. And an encrypted Notational Velocity notebook of my every thought and secret. This means that I can install a clean OS X and have access to 95% of my documents just by installing Dropbox.

The major upside in this much simpler approach is that everything happens automatically, and there are very few moving parts. In fact, I’m relying only on two excellent and stable services. I’m always backed up at least to within 24 hours of my machine crashing, which is frankly better than I’d manage if I relied on myself remembering to connect physical devices to my computer.

The major downside is that I don’t have either a full backup or an offline backup. If my machine crashes, I can restore everything I care about — but it will probably take about 10 hours of hard work. When it happened last in late 2009, this was the approach:

Get a new machine.
Power up a clean Mac OS X and install all the software I needed.
Start up Dropbox which within about two hours managed to restore most of my documents. With 20 minutes of linking, I had my Desktop and other bits and pieces in working order.
Identify the last 5% of files. Most of these files, I was able to restore from my previous machine’s hard drive, although this might not be an option if the computer is stolen.
Retrieve the last missing pieces from Backblaze. This was in fact the hardest part. Backblaze is amazing for backing up, but a bitch to work with for restoring: I spend a few days generating and downloading zip files with music, podcasts, audiobooks and other lost bit and bytes.

Updated stalkering

Sat, 13 Nov 2010 23:06:18 +0100

I’ve managed to add a few bonus features to Stalkify tonight. So far, Stalkify has been awesome at keeping Spotify in sync with your Last.fm account, but I wanted to add a bit of music discovery to the site as well.

To accomplish this, Stalkify now lists top artists for any user:

… and Stalkify will now also recommend other people for you to follow based on you musical taste:

Finally, there’s a new type of playlist on Stalkify called ‘Loved tracks’. This obviously includes all the tracks users have marked as loved on Last.fm.

Be sure to tell a friend…

Stalkify: Last.fm + Spotify = ♥

Sun, 02 May 2010 18:18:27 +0200

I’ve been playing around with a new web service called Stalkify for the past week or so. The notion is simple: Stalkify makes the social graph from Last.fm available in Spotify. So all the tracks you’re scrobbling to Last.fm (and have been for the past decade or so…) suddenly makes sense in the brave new world of Spotify.

Stalkify was inspired by @Claus’s Spotify DJ, which allows you to have peers listen into DJ sets. Classy clever used spotify: URIs and some Adobe Air magic to patch this piece of software together, but I figured that you could build the same live experience by using tracks recently scrobbled to Last.fm — and making a live-updated playlist in Spotify.

So that’s the first feature: You’ll key in a username (or your username) and you’ll get a live playlist of what’s being played by that user.

An awesome upside of using Last.fm as the data exchange is that you’ll also be able to stalk non-Spotify users. For example, my good friend PolleTheWonder is a heavy Last.fm user with a list of almost 20.000 listened tracks; but he isn’t a Spotify user. With Stalkify, I’ll still be able to listen live to what Paul is playing.

I have four years of Last.fm usage and 22.559 plays to my name, and Last.fm is pretty good at collating this information into a sense of my musical taste. For example, they compile lists of my favorite tracks (from both my Winamp, my iTunes and my Spotify days), which is something I’d love to have ready at hand in Spotify. Stalkify does that: It give me a list of daily updated list of what I’m listening to the most.

(I’ll be updating Stalkify to use more features from Last.fm in the future: Top albums, Recommended artists, Neighbouring users…)

For the geeks…

Stalkify is pieced together from The Last.fm API using pylast, from libspotify (0.0.3 because 0.0.4 is buggy in playlist handling) using greenstripes and Spotify’s Metadata API using spotimeta.

All the code is a) ugly and b) available at github.com/steffentchr/Stalkify.

Taking out node.js for a spin with Bomber

Sat, 02 Jan 2010 22:39:59 +0100

The node.js project has been getting a lot of good press and positive attention over the past few months. With good reason. If this is the first you’re hearing of node.js, it’s officially an “evented I/O for V8 JavaScript” but more generally it is used as a tool for writing non-blocking network servers. This means that it can easily be made into a JavaScript-based and highly efficient web server. If you’re curious, have a look at Simon Willison’s nice write-up.

Node is still in it’s infancy. For example, there’s is still a lot of discussion going on on the mailing list about core API (i.e. how to handle communication between and chaining of events or even how the final file API is going to look). Since node isn’t designed explicitly as a web server, there’s only low-level http support — and of course, there is no standard web application framework for handlings requests, sessions, cookies, and users.

The first question to be answered is if you’d actually want big web applications to run solely on node.js? But for now I’ve skipped that question entirely and simply asked how I’d approach writing such and application (hopefully reusing some of the code being currently being pushed by the node community)?

It seems as if every person in that community has written her or his own lightweight library for handling web requests. To name a few, there’s Djangode, Express, Coltrane, Vroom, and node-router). A lot of these are obviously inspired by the approaches taken by either Django or by Rails (it’s right there in the names), but taken as a whole they’re very limited in how they approach the task. Most of the frameworks are just different syntaxes for binding a JavaScript function() {} to a URL — without the modular approach taken by their more mature counterparts.

This means that you can easily use any of these frameworks if you need to write up a simple — and fast! — web app in a single file with a few hundred lines of code (in that case, I’d opt for Djangode), but you’d be stomped if wanted different, re-usable applications meshing into a single project. Benjamin Thomas has gone in designing mode in order to come up with a mini-framework which isn’t quite as mini as the ones listed above. His ambition is to build…

- The ability to bundle up a collection of controllers/views, models and templates into “apps” for easy portability and reuse.
- Smart defaults that hide a lot of the options/power/complexity. I think this is important for getting up and running quickly.
- A code base that is as small and simple as possible.
- I want it to feel javascript-like. Whatever that means.

The end result is Bomber. I like how Bomber creates simple URL routing to file-based (or rather node.js module-based) views, and how it lightly extends the core http.ServerRequest and http.ServerResponse objects. It feels almost native, but you see that enough of a foundation exists for this framework to actually include the ability to handle POSTs, sessions, cookies, multiple applications within a project and so on. There are no great ambitions where the framework will suddenly include a native XML parser (just a random example, sorry), but there’s enough room to grow and spread the webby wings a bit.

The Bomber project is very much in flux. In fact, it might even be dead since the last commit is a month old. And the entire project is build around an Action API which about to be deprecated. Hopefully to be replaced with DOJO-style, native Deferreds.

I’ve been playing around a bit by adding some extra stuff to Bomber through my own fork at github. I’ve already tweaked a little with the app structure to allow for multiple projects to be bootstrapped with different configurations from the same Bomber library, and there is some copy-paste and bug fixes in there as well. This will likely include experiments with multi-application projects, per-application media directories, cookie and session handling and templating (although I disagree with Benjamin that Bomber should include its own templating system; this could probably be left for the programmer to choose).

And now, back to Jersey Shore, bitches!

Using the keyboard to navigate a web site [KeyboardFocus]

Fri, 16 Oct 2009 22:22:00 +0200

I’m beginning work on a project which requires users to be able to navigate the content of a web page using only the keyboard, and where switching focus using the standard method of tabbing is not an option either. To solve this problem, I’ve pieced together KeyboardFocus.

KeyboardFocus does one thing: Look through all elements on a web page with a given class name and make those elements selectable and clickable through the keyboard — using the arrow keys and the enter key.

Using the code is really quite easy:

Add the CSS class name focusable to all the items you need to be addresseable with the keyboard.
Add some CSS style for .focusable, for .focused and possibly for .hovered.
Include the Prototype and KeyboardFocus scripts in your header.
Add the line var kf = new KeyboardFocus(); somewhere in your code.

It could look something like this:

<html>
  <head>
    <script src="/script/prototype.js"></script>
    <script src="keyboardfocus.js"></script>
    <style type="text/css">
    a {color:#06c; text-decoration:none;}
    .focusable {border-bottom:1px solid #06c;}
    a.focused {background-color:#06c; color:white;}
    </style>
  </head>
  <body>
    <ul>
      <li>A link <a class="focusable"
          href="http://www.google.com">Google</a></li>
      <li>A <a class="focusable"
          href="http://refresh.dk">different link</a></li>
      <li>A <a href="http://www.yahoo.com">
          non-focusable link</a></li>
      <li>And something <a class="focusable"
          href="http://xkcd.com/">completely different</a>.</li>
    </ul>
    <script>
      new KeyboardFocus();
    </script>
  </body>
</html>

There’s also an example with random boxes.

Twune: Tweet your tunes

Mon, 06 Apr 2009 12:38:19 +0200

A while back a spent a little time creating a simple service that allows tune-tweeting with legible, short URL. For example, twune.net/DioDiver will play Holy Diver by Dio. And twune.net/BeatlesHand will give you The Beatles’ I Want To Hold Your Hand.

The scheme was inspired by some of the cool work that Morten Just has been doing by mashing up YouTube videos with different data sources — and I was happy Morten let me re-use some of his code.

The service works by parsing the search string from the url (using WikiWords or whatever you’d call them). It then tries to find a perfect match on Yahoo! Music which will be played in Yahoo’s video player. If that doesn’t work, the search is passed on to YouTube with the help of Morten’s player. It’s that simple.

The name of the service was suggested by @guan. I had originally wanted to call it Twack. Still unsure which is best?

Announcing TwitterEngine: Your own twitter aggregation site on AppEngine

Thu, 02 Apr 2009 11:27:41 +0200

About a week ago some friends launched Twittertinget.dk, a sleek app that aggregates tweets from politicians in the Danish parliament. In the name of democracy, the web application has a vital flaw though: It only lists tweets from politician, not to them. That makes for one-sided communication.

As a friendly gesture, Socialsquare asked me to create a complementary service, which does the exact opposite thing: Let’s you know what people are tweeting to their elected representatives. This ended up in Folketwinget.dk, a simple site hosted on Google AppEngine.

Now, aggregating tweets to and from the Danish Folketing seems like a faily specific, but it turns out that such an aggregator of can easily be used by any other group — so we’ve open sourced the code over on Github. The code runs directly on AppEngine so it’s easy to host and have running in a few minutes.

For example, if you have a company called 23 with a few employees on Twitter it might be cool to show all the incoming and outgoing tweets from the company.

Get started by installing the Google AppEngine SDK, start up a terminal and browse to the AppEngine folder on your local machine. Then…

1. Get the code
Run this command to download the code. (Obviously, you’ll want to change the folder name from 23tweets to something else.)
git clone git://github.com/steffentchr/twitterengine.git 23tweets

2. Update app.yaml and create config.yaml
Open up the file called app.yaml in the newly created folder and change the application name in the very first line of the file. In this example, we’ll change it from twitterengine to 23tweets

Also, rename the file called config.yaml.sample to config.yaml

3. Create an AppEngine project
Open up GoogleAppEngineLauncher (it’s called that on Mac anyway). Right-click in the window and select “Add existing..”. Now select the folder we’ve just created and click OK.

This is all you need to actually get the application up-and-running. Click the Run icon to start your development server and open up http://localhost:8000 in a browser.

4. Configure the application for your dirty purposes
Before you can import some tweets into your application you will need to update the configuration. Open up config.yaml in a text editor and change what you think is necessary. For my example, I’ll use this configuration:

site_name: 23 tweets
site_tag_line: What is up with 23?
site_domain: 23tweets.appsport.com

twitter_username: 23pull
twitter_password: secretpassword

users:
- steffentchr
- mygdal
- mmmmmariaaaaa
- abemad
- guan
- burtblancher
- 23

hashes:
- 23
- 23hq
- twentythree

Basically: Use the user account of 23pull to get all tweets to and from @steffentchr, @mygdal, etc and all tweets with the hash #23. Then call the site “23 tweets”.

(This could just as easily have been used to create a Folketwinget-sibbling for the Norwegian parliament or for aggregating conversations of everything involved in a specific open source community.)

4b. Import the tweets
Now, go to http://localhost:8080/import to trigger an import of everything specified in the config file. When you return to http://localhost:8080/ you should see all a batch of the latest twitterings.

When you’ve finished step 5., the application will automatically import tweets every five minutes. The frequency can be changed by editing cron.yaml.

5. Deploy your app
Before you can deploy your new twitter aggregator to the wide web, you will need to create the application with Google. Go to the AppEngine dashboard, click the “Create an application” button and fill in the form. Remember to use the correct application identifier, i.e. 23tweets.

When your application has been succesfully created, go back to GoogleAppEngineLauncher and right-click your project. Then select the deploy option and sign in to your Google account. That’s it. It’s online.

Again, you’ll need to visit http://projectname.appspot.com/import to import tweets into the online database and then go to http://projectname.appspot.com/ to see the result.

6. Customizing the design
You’ll find that your site is in Danish and generally doesn’t look the way you want it to. Changing the design though is fairly easy: Modify index.html and resources/style.css for your purposes. If you need anything fancy, the html file is structured using the Django templating system.

Update April 24th 2009: Originally, this post contained information for running external cron jobs to import tweets. Today, the code has been updated to utilize AppEngine’s new native cron feature which makes it all happend automagically..