Author: Andreas

MashupCrowd – tracking who is talking about mashups

Standard

The other day I launched MashupCrowd.com. It is a page that tracks who is talking about mashups on Twitter. I have been sitting on mashupcrowd.com and some other mashup .com domains for almost a year now, so it was about time to do something with (at least a few of) them. Inspired by svpt.nu – a very cool site that tracks Swedish Twitter users – I figured that I could do something similar but for mashups. That also gave me an excuse to finally dig into the Twitter API.

MashupCrowd - who is talking about mashups on twitter

It was extremely easy to get the interaction with Twitter to work using Twitters super simple Search API. As a basis for my PHP code I used Simon Maddox’s Codeigniter Twitter library to speed up development even more. Basically the backend is nothing more than a cron job pinging Twitters Search API every few minutes for new tweets and then saving them in a database. Considering doing something more with this data at a later stage, but for now I just show it on the site. What took the most time was not figuring out how to use the Twitter API or to write the few lines of PHP needed. What took me time was to get the site to look good using CSS, but I am quite happy with the end result. Hopefully I can do some more of my own CSS work in the future.

MashupCrowd has already proved usefull for me in finding new innovative mashups. Today I found a cool use of Twitter to track the snow depth in the UK.

Google is Evil

Standard

If it was not enough that Google massacres deers with their Street View truck I now have further proof of that they are part of the Evil League of Evil. Google Reader more or less costantly giving me bad conscious by letting me know that I haven’t keept up to date with my RSS reeds. The other day this was what meet my innocent eyes in the morning when I sat down at the computer:

666 - a street address in Mountain View

Google redeem yourself quickly and give us the gift of an unlimited GDrive service (also, please do not look at the files I store there).

Projects 2009

Standard

2008 was an eventfull year for me, I left Kapow to start my own company just to mention one thing. But now it is a new year, with new projects and new things to learn. My plans for 2009 include at least these projects:

  • Blendapps.com – this chat solution started in 2008 and has gone quite well, so far we have Meebo and Userplane chat rooms seemlessly integrated into Ning and Facebook. In 2009 we will add more platforms, more features etc. The last few days we have gotten some nice attention for Blendapps – feedmyapps, killerstartups and eHub have all written about us. Hopefully this is a sign that 2009 will be the year for Blendapps!
  • gefeedback.nu – in just a week it is time for 24 Hour Business Camp, a Swedish conference where everybody has 24 hours to implement a web application/business idea. I will do this with Mattias Järnhäll and our project is gefeedback.nu (in swedish this means litteraly “give feedback now”). The goal is to make a customer service service to help ourselves and others to make customer service for internet projects as efficient and easy as possible. My aim is to go with Django and Pinax for this one, since we that way can get lots of functionality for free, something that is desperatly needed since we only have 24 hours!
  • The worlds best F1 site? (name & domain TBD) -Yes, you heard it right, I am going to do something with sports, however unlikely that sounds. Teaming up with a very dedicated F1 fan I will launch a F1 site during 2009, one that really is for the hardcore F1 fans that love statistics. Considering Adobe Flex for this one, would really love to have a Flex project to give myself an excuse to get deeper into Flex (and Flash seems to be the right choice of tech for the project as well ;).
  • Big Project X – my most ambitous project is a swedish niche site, it is still in stealth mode (at least until we have decided on a name and got a domain) so i will keep the details for myself for now. Probably another Django/Pinax project (even if I plan to spend lots more than 24 hours on this).

Those are the ones lined up so far, but I suspect I am going to add more to my plate. During 2009 I will really try to do fewer projects and spend more time on the ones I already have going – like enlatele.com.mx.

One thing I do not promise for 2009 is to be a more frequent blogger, I do not want to promise things that I am not sure I can keep…

Django installation gotchas

Standard

In this blog I have earlier declared my love for both CodeIgniter and WordPress, but I am very unfaithful when it comes to frameworks and programming tools, so now I am testing out the Python framework Django instead (but I am still a newbie). It’s my experiences with Google App Engine that lead me into the Python/Django world, and when I am now considering what framework to use for an upcoming big project Django is definitly on the shortlist. It will not be a Google App Engine project due to that some of the limitations of that platform makes it a bad fit for the project in question, so it would be my first standalone Django project. So far I have only installed all the stuff I need and got it to play nicely together, but that was a real learning experience in itself, and by sharing it in this post I hope to save some other fellow geek some time and peace of mind.

Before getting started I want to thank Alexis Bellido at ventanazul.com for his patients with my Django questions, check out his post Django questions and answers with a Swedish guy for some more info on Django setup (if you didnt figure it out I am that Swedish guy).

Installation guides
When I set up Django locally I wanted to make my local development environment as similar to a production environment as possible, it will hopefully make production deployment easier down the line. To do this I am running Python 2.5, Django 1.0, PostgreSQL 8.3 (and thus the neccessary python driver psycopg2) and mod_python on Apache. There are some good installation guides out there, so setting up this stuff was mostly a walk in the park, check out the install guide in the Django Book, the quick install guide at Django Project or the install guide at WebMonkey. Of course there are some gotchas that took me quite some time to figure out…

Uninstall old versions of Django
Before getting started I already had Django 0.96 installed, and I  just installed Django 1.0 over it assuming that it was going to replace the old version. I was wrong and when I tried to run my new Django installation I got errors like “NameError: name ‘url’ is not defined” and “ImportError: cannot import name WEEKDAYS_ABBR” – neither which made much sense to me. It turns out that if you do not uninstall an old Django installation first you get a mix of new and old Django files, and that just do not work very well. So take care to acctually read and follow the instructions at Remove any old versions of Django.

Use the right version of the db driver (duh!)
To get the PostgreSQL working correctly with your Python install you have to use a version of the driver Psycopg2 that matches both your Python version and your Apache version, otherwise things just do not work and you do not really get a helpful error message. You can get the window versions of Psycopg2 here.

Configure Apache for mod_python
Once Django and Apache are installed you can create your new Django project (via django-admin.py startproject myNewProject) where Apache can find it (in htdocs for example). To be able to use Apache as your webserver you also need to install and configure mod_python. Installing is straight forward (see the install gudies above for more info), but configuring Apache took me some time. You need to edit httpd.conf and add the following to the end of the file:

<Location "/myNewProject">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE settings
PythonOption django.root /myNewProject
PythonDebug On
PythonPath "['C:\Program Files\Apache Group\Apache2\htdocs\myNewProject'] + sys.path"
</Location>

myNewProject is of course the name of your own Django project.

Hopefully this is of use to someone other than me, if not, then at least I have my notes organised for the next time. If I have missed anything or gotten anything wrong I would very much appreciate your feedback!

Google App Engine limitations, and how to get around them

Standard

Using Google App Engine has great advantages, but there are also serious limitations in the platform that it’s important to be aware of. Not all applications can be implemented and executed with Google App Engine. Google is working hard on removing a lot of these limitations, and they will probably do so eventually, but in the meantime that isn’t really any help if you are writing a web app today.

This post was originally published in swedish on Mashup.se, my blog about swedish mashups and APIs.

Only Python
If you don’t know Python you don’t have choice if you want to use Google App Engine, you just have to learn. It’s not a difficult programming language to learn if you already know how to program. Django, the Python framework that really speeds up writing applications for Google App Engine, is also quite easy to pick up (tip: Use the Google App Engine helper for Django). Before I started with Google App Engine I hadn’t written a single line pf Python and after a few intense days of concentration and coffee consumption I knew Python, Django and Google App Engine quite well.

Most 3rd party python libraries work perfectly on Google App Engine (Django is just one example), but there are limitations. Only libraries that are 100% Python can be used, so if the library has any code in C it can’t be used on Google App Engine. If a librarry has any code that makes a HTTP request or similar it can’t be used on Google App Engine either. All HTTP requests have to be done via Google App Engines URL Fetch API.

Differences between local dev environment and the production environment
One of the advantages with Google App Engine is that there is a local development server that simulates how Google App Engine works when an application is in production. This makes it easy to develop an application locally and then deploy it to the live servers on Google App Engine. As a developer it is important to pay attention to the differences between executing an application on the local server compared to the production environment. It’s no fun to spend time writing code that just don’t work once deployed.

The biggest difference betweent the two environments are that the requests made to 3rd parties work differently. If you have an application that uses the Delicous API it will work fine locally, but once deployed it wont work at all. The reason is that Delicous is blocking all requests from Google App Engine IP-addresses. Same thing is true for the Twitter API due to some HTTP headers that Google App Engine sets (Twitter claims to have fixed this now, haven’t had a chance to test yet). To avoid these problems you need to test your application often in the live environment, especially when you use APIs to call other services.

Datastore
The Google App Engine datastore has some limitations due to being a distributed database. The most obvious limitation is that there isn’t an “OR” operator in GQL (the Datastore version of SQL), but that is easily handled when coding. A more annoying limitations is that it is not possible to create a new entity (data object) in the Datastore via the Google App Engine dashboard unless there already exists an entity of this type, and that there is a real noticable delay between what one can see in the Datastorer in the Dashboard compared to what really is stored in the Datastore. This makes it very hard to really check what data that is stored in the Datastore in any given moment, which makes debugging more difficult.

No scheduled processes
One of the most restrictive limitations with Google App Engine is that there is no way to start a process, other than via a HTTP request. There is no type of recurring scheduled process (like a cron job) and no triggers or hooks to use to start a process when a special event occures. Almost all web applications need som kind of scheduled process to function correctly – to clean up old data, send emails, consolidate statistics or fetch data from an RSS feed once an hour.

The easiest way to get around this limitation is to create a cron job on another server that calls an URL in the Google App Engine application. If you have a lot of visitors you can also perform the background process as part of a user request. For example you could import data from an RSS feed when a user logs in to your application. This will of course make the user experience slow and there is no guarantee that users will perform the action to trigger the background process att the right times.

No matter which solution is implemented one will quickly bump into the next limitation of Google App Engine, that only short processes are permitted.

Only short processes
Something I have learned the hard way is that Google App Engine only is built to handle applications where a users makes a request and quickly gets an answer back. There is no support for a process that  executes for a longer time, and for the time being this limitations seems to be approximatly 9 secondes/process. After that an exception is thrown and the process killed. It does not end there, even if you are nowhere close to use the assigned CPU resources you can quickly use too many resources with long running processes since they have their own unique resource pool. If you use too many resources you application is shut down for 24 hours, and right now there is no way to buy extra resources.

This is a really serious limitation in Google App Engine that it is really difficult to get around. If you need heavy processes it is recommended that you use Amazon EC2 or something similar. To handle (not get around) the limitation you have to handle exceptions in a nice way and use transactions. More about this in William Vambenepe’s very informative post Emulating a long-running process (and a scheduler) in Google App Engine. He has some tips on how to get around this limitation, even if it is not recommended since you risk that your application is shut down.

More limitations
There are more limitations, read  Google App Engine: The good, the bad, and the ugly? for a longer list. Just keep in mind that some of the limitations mentioned in that post already have been addressed by Google.

To summerize you need to really know what limitations there are in Google App Engine before you spend time and energy on developing an application. If the limitations are not a problem then there is a lot to gain by using Google App Engine.