Archive for the ‘mashup’ Category

Twune: Tweet your tunes

Monday, April 6th, 2009

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

Thursday, April 2nd, 2009

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..

Walking the talk — OIO Rest

Wednesday, May 28th, 2008

I wrote about the huge potential in government as a service the other day, and apparently i’m not the only one who has seen the opportunity. The only difference is that while I just wrote a few thought and did nothing, others have actually done exciting work on this front. Some articles in English:

And more in Danish

Public formats in more than one sense

Saturday, May 24th, 2008

ReadWriteWeb just posted an intriguing article about the next generation of e-government. The post basically lists the arguments from an upcoming scholarly article about the subject. The main argument is simple: Government shouldn’t spend it’s time building web sites, instead it should “focus on creating a simple, reliable and publicly accessible infrastructure that exposes the underlying data”. Rather than building and maintaining a website of upcoming bills at ft.dk the Danish parliament should make the data available and have others mash it up in usable ways.

Now, I’m not a deregulating liberalist, and I’m absolutely certain that a strategy of only making data available to private entrepreneurs simply wouldn’t work in a Danish contexts. But I’m also convinced that a mandated policy of making data easily available to developers has explosive potential.

Let me list a few examples. The best Danish mapping service, Findvej.dk is a mashup of both publicly and privately owned data. It was built by one guy in with a good idea and access to the necessary data. The data was probably hard to find, and the service would be much better with even more accessible data. But you get my point.

There are hundreds, if not thousands, of possible counter-examples and I’ll just pick one. The weather. Denmark has a tax-funded, public weather service, which generates plenty of data every day, and this data is available to everyone through a web browser. Now, given all the data from the weather service, would I be able to build a better website serving all the same user groups as DMI? Probably not. But given access to that data I would be able to build a service which suits my needs much, much better that DMI.dk. And most likely, my service would serve others as well.

Why isn’t there an Danish version of EveryBlock? The reason isn’t lack of interest. The reason isn’t lack of data, because statistics and incident reports are being kept by the police. The reason is that the data isn’t accessible as an open building block (that metaphor didn’t work).

This presents a major challenge to government, and even if I’ve used Danish examples, those challenges are probably both very global and very local. The past few years have shown convincingly that web developers are hungry for interesting data to reinvent by merging across data sources, and this potential could be easily harvested by some sly government initiatives.

Fire Eagle is in beta

Wednesday, March 5th, 2008

I’ve written about Fire Eagle before and it’s no secret that I had high hopes for the projects. A few hours ago the nice people at Yahoo sent me a beta invite, and greedily read through the developer docs to see what goodies awaited… The result, sadly, is that there aren’t many goodies at the moment.

Most importly, Fire Eagle doesn’t come with any applications yet, so it’s really hard to test the actual UI. I typed in my current location and it registered it. That’s it. Disappointing.

On the API front Fire Eagle doesn’t push too many boundaries either: You can set a user’s location, and you can get the user’s location. As has been reported before, Fire Eagle handles privacy in two ways. First, you need to verify an application’s access level (just as when you use the Flickr or 23 API), and depending on that level of access locations are returned more or less precisely. If, for instance, you only want a Facebook app to know your current city rather than the exact coords, Fire Eagle allows for that. Which is cool. It’s nice that you can upload coords from a GPS tracking thingy and still retain some intimacy.

I won’t make a point-by-point comparison of Fire Eagle to the Plazes API — but they are really similar in scope and ambition. The only difference is that Fire Eagle will see support in fifty apps by April 1st. Plazes won’t. Also, Fire Eagle is not trying to be a social network as well as a backend interface. It’s only the glue between locator apps and location apps.

As I probably mentioned in my previous post I have great hopes for Fire Eagle, but I’m largely underwhelmed by the beta. Hopefully, nice people on the interweb will prove me right in the upcoming weeks?

Update: Nice! While I was bitching about not being able to use Fire Eagle for something useful, Dopplr released support for the Eagle.

Playing silly games [spilletmedbyer.dk]

Thursday, February 14th, 2008

Yesterday I spent about ten minutes assembling the map of the s-trains in this nice mashup game. It gave me an urge to do something silly and utterly pointless myself, and the result is stunning: Spilletmedbyer.dk

If you clicked the link, you’d know exactly what I did: Something Google Maps and a bit of data, and you can now guess the location of Danish cities and towns. You’re welcome.


Cheat mode:

javascript:answer(new GLatLng(currentQ.latitude,
  currentQ.longitude))