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!

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.

At the moment I am using Wordpress as a CMS for several websites. Of course this blog is running on Wordpress, not that suprising really since it is a blog. The main site of blendapps.com is all Wordpress, while the acctual chat application that integrates Meebo chat with Ning social networks, run on the subdomain chat.blendapps.com and is implemented on Google App Engine. For Blendapps.com there is both a seperate blog section and a content section, so it is by no means a pure blog. Mashup.se is also running Wordpress, and there I have tried to have more of a newspaper feel than a pure blog. The purest use of Wordpress as a CMS is probably on restillmexico.se (swedish travel guide to Mexico), that site doesn’t even have a blog.

Why Wordpress?
My requirements for a CMS are simple - it should be quick to implement a new site, it should be easy to maintain a site and it should be easy to expand and customize the site when it grows. A plus is if it runs on LAMP, so I can hack it if neccessary and so I can host it anywhere. There is not really any need to support multiple concurrent users since it is mostly going to be yours truley doing the work. Not rocket science really, but evidently damn hard to implement since most CMSes miss the mark by miles.

Let’s take a look why Wordpress live up to these requirements:

• Quick to implement a new site - setting up Wordpress is a matter of minutes. Get the Wordpress files, set up a database and go. For some extra bonus you can add the plugins you need and choose one of 100’s of free well done themes to get the look you want. You can of course also do as I do and get a professional design and just add that on top of an exising theme.
• Easy to maintain - the Wordpress control panel is easy to use, and if you dont like it you can change it around with plugins (see below for some such plugins). Wordpress and most plugins are continously updated and to install updates is a breeze. All you need - such as static pages, blog posts, tagging, categories, multiple users, comments, spam protection (Akismet) etc is all part of the basic Wordpress install.
• Easy to expand and customize - again, the plugins are really great for customization. Also, Wordpress have really powerful and usefull template tags that allows you to customize the theme well beyond recognition. See tips and tricks below for more details.
• LAMP - check. All written in PHP and uses a MySQL database perfectly. Even if I at times have hacked the Wordpress core files it is not really necessary, but the key thing is that it is possible.

Pages and Custom Fields are your friends
Content in Wordpress can be either shown in “posts” or “pages”, where posts are blog posts and pages are static content. Under the surface it is all the same, both posts and pages are stored in the same tables, but they are still treated a bit differently. If you are using Wordpress as a CMS then pages are definitly your friends. I have found that pages are a little easier to organise if you are not writing a blog. You can set a page as the front page of your site in the Wordpress control panel. Go into settings -> reading and choose what page you want as front page.

Custom Fields are data fields that are not part of the core Wordpress installation but that you define yourself. A custom field is attached to a post or a page and can be used to store any extra info that Wordpress or plugins dont handle. For restillmexico.se I use it to store the URL or the images for each page, as well as the attribution of the images etc (a trick from WordPress Custom Fields: Adding Images To Posts).

Plugins to turn Wordpress into a CMS
Even if a basic Wordpress installation works fine as a CMS there are a few plugins that makes your life easier:

• CMS-like admin menu -  all it does is make posts second to pages in the menus, ie puts pages before posts. If all you have on your site is pages then this plugin is a nice touch.
• PageMash - drag and drop interface to order pages. Makes it very easy to change order as well as set parent/child relationship among pages. I especially use this one heavily to organise the hierarchy at restillmexico.se.
• Page Excerpt - adds the excerpt functionality of posts to pages
• Query Child Of - makes it possible to list the children of a page in your theme, great in combination with PageMash mentioned above
• Admin drop down menu - it gives the control panel a drop down menu, which is quicker and easier to use than the standard control panel menu. Not really unique for using Wordpress as a CMS, but I really like this plugin.

Tips and tricks
To hack a wordpress theme to work as well as a CMS there are a few tips and tricks. The first tip is to not hack at all, just use the great CMS2 theme. It already has a page focus and most of the organisation needed for a static web site. For the sites I have on Wordpress I have either customized this theme or one of the themes that comes with the basic Wordpress install.

When customizing a theme there are some Wordpress template tags that will save you a lot of time:

• wp_list_pages - allows you to list the pages you have in your site, pefect to create a menu with. You can include or exclude any pages you want.
• query_posts - get the posts you want by using the parameters to this tag. Since pages and posts really are the same thing this tag can be used to list pages when wp_list_pages doesn’t do exactly what you need.
• get_post_meta - get the value of a specific custom field for a page or a post, necessary to be able to get the most out of custom fields.

Summary
Wordpress is a very good option as a CMS, not just for blogs but for static sites as well. With the great choice in plugins and the open source code of Wordpress you can get it to do almost anything you want without serious hacking. The huge installbase ensures that you can find help and resources if you need it.

Hopefully I can create a good collection of swedish mashups and APIs and at the same time get to know more what is going on in Sweden. Since I am not only going to write about specifically Swedish stuff, but also US APIs that are of interest to Swedes, I think that it will also help me write more posts for digitalistic.com. After all a mashup built with Yahoo’s BOSS mashup framwork is of interests to geeks everywhere (at least if you are the kind of geek I am).

Some general lessons I learned before we jump into the actual code:

• iPhone pages are all about lists, the more lists the better apparently. On the smaller screen you can not really do much more than lists, and if you want to do more then just let the iPhone user browse your normal web page.
• Write a seperate page for the iPhone, do not detect if a site visitor is using the iPhone and automatically server up the iPhone page. One of the cool things about the iPhone is that it is possible to interact with normal web pages quite well on a small screen, dont take this away from the iPhone user. Instead create a subdomain specifically for this, for example iphone.enlatele.com.mx, or m.enlatele.com.mx.
• The iPhone connection is not always the best, so do not serve lots of images etc if there is not a real need for it. This might not be true with the new 3G iPhone in the middle of New York or Stockholm, but writing an iPhone page for Mexico I’d rather be safe than sorry and keep the number of images to a minimum.

I used just HTML, CSS and JavaScript, packaged up very nicely in the IUI framework. Basically all you do is download a CSS file and a JavaScript file, import them into your HTML page and write lists with certain CSS classes and IUI takes care of all the rest. IUI even has minimized versions of the CSS and JavaScript file you can use to make the page even smaller (and thus a quicker download to the iPhone). This is what I have in the header of my page:

<meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>
<style type="text/css" media="screen">@import "iui/iuix.css";</style>
<style type="text/css" media="screen">@import "styles.css";</style>

The meta tag “viewport” is needed to let the Safari browser on the iPhone know how to deal with the content, without that tag you risk that the page acctually looks worse in the iPhone than in a regular browser.

In the body of my HTML document I specify the menus of my iPhone, ie lists lists and more lists. The code for the start menu is:

<ul id="home" title="Enlatele.com.mx" selected="true">
<li class="group">Canales</li>
<li><a href="channelgroup.html?=canales_abc">A-B-C</a></li>
<li><a href="channelgroup.html?=canales_def">D-E-F</a></li>
<li><a href="channelgroup.html?=canales_ghi">G-H-I</a></li>
<li><a href="channelgroup.html?=canales_jkl">J-K-L</a></li>
<li><a href="channelgroup.html?=canales_pqr">P-Q-R</a></li>
<li><a href="channelgroup.html?=canales_stu">S-T-U</a></li>
<li><a href="channelgroup.html?=canales_vwxyz">V-W-Y-X-Y-Z</a></li>
<li class="group">Proveedores</li>
<li><a href="#sky">Sky</a></li>
<li><a href="#cablevision">Cablevision</a></li>
<li><a href="#mastv">MASTV</a></li>
<li><a href="#tvabierta">TV Abierta</a></li>
</ul>

And this results in this page (as can be seen on iphone.enlatele.com.mx):

IUI styles it all nicely. The key parts of this list is:

• the id “home” on the ul tag. Ids like this are used throught IUI to identify submenus etc. For example the link to Sky is <a href="#sky">Sky</a> this links to another ul list on the same page with the id “sky” - <ul id="sky" title="Sky">. This means that I can have most of my menu structure, submenus and all, on one page. So once this page is downloaded to the iPhone the phone do not need to access the internet just because you click on a link to a submenu.
• title="Enlatele.com.mx" is the header of the page
• selected="true" on the ul means that this is the first menu to load.
• <li class="group">Canales</li> creates a grouping in the menu, a nice way to make things look fancy without acctually doing any work
• now to a really nice thing about IUI, it takes care of loading content dynamically into your current page seamlessly. For the enlatele iPhone page there are listings of TV channels that are not loaded to the iPhone unless the user clicks on a link in the menu to do this. So if a user wants a list of all channels that starts with A, B or C he would click on the following link in the menu - <li><a href="channelgroup.html?=canales_def">D-E-F</a></li>. IUI would then insert the content of channelgroup.html into the page basically using AJAX (don’t worry about the ?=canales_def - that is just so that the enlatele backend knows what to load). The channelgroup.html page should _only_ contain a list of channels to show once this link is clicked, nothing else:

<ul id="canales_abc" title="Canales A-B-C">
<li><a href="channel.html?canal=a_e_mx_west">A&E MX West</a></li>
<li><a href="channel.html?canal=american_network">American Network</a></li>
<li><a href="channel.html?canal=animal_planet_latinam">Animal Planet LatinAm</a></li>
<li><a href="channel.html?canal=animax">Animax</a></li>
</ul>
So no HTML start tags or BODY tags or anything else, just the list you see above, that is the whole of channelgroup.html.

IUI also deals with other things you really want on an iPhone page, such as automatically inserting a back button (that only looks good in Safari since it is using Safari specific functions, so if it looks crappy when you test in Firefox do not worry), showing a nice loading graphic etc. There are also a lot of more fancy stuff that can be done with IUI, but just the basic can get you a long way. This is pretty cool stuff I think, and it makes is really quick to implement something that works great and looks great on the iPhone. Of course there is a big part missing here, and that is the backend acctually filling these pages with content (in the enlatele case dynamically creating the channel list based on what is in the enlatele database), but that is standard programming stuff so I wont cover it here.

If you are interested in doing more mobile content, especially design, check out Yahoo’s Design Stencil Kit for mobile. It contains all the building blocks you need to do mockups and designs for the iPhone and other mobile platforms.

• You have to trust the API providers to keep that API up and running. Anyone that has done Twitter mashups know how much keeping an API up and running is worth.
• You have to trust the API providers to keep the API (somewhat) stable and to not remove features that you are depending on, or add features you really dont want. An example of this is all the mashups built on Google Maps, and we all know that there are way too many of those. Have the developers of those mashups really thought about what happens when Google puts ads on the Maps (and they will, they have already started in parts of the US)? I dont think so, the developers just trust Google to keep on going. If you have a commercial site using Google Maps you probably do not want ads for your competitors on those maps.
• If your mashup becomes a success you have to trust the API providers you are depending on not to change their terms of service so that your mashup suddenly becomes an illegal use of the API. Also, you have to trust the API provider not to use the fact that you are depending on their API for your business against you in a business negotiation.
• If you use web scraping you have to trust the site you scrape not to change to often (or at least trust your own ability to roll with the punches and update your scraping so it works with the new version of the site as well) etc. That is a lot of trust, and when mashups move from toys into real applications this becomes an issue.

All these things makes me a bit nervous, as I am a bit paranoid (note: this has not been clinically proven, I still think that THEY are out to get me). So how to mix a healthy bit of paranoia into my mashup building and get something good out of it all? What I do is that I always try to be aware of that I might have to switch API provider. Are you building a Twitter mashup? Why not also take a look at Jaiku’s API, or Pownce’s API (or Plurk or FriendFeed etc etc). You dont have to build your mashup so you can switch API provider in a matter of minutes, just be aware what else is out there so that you see the commonalities and don’t use to many features unique to one provider. This is the approach I am currently using when I am building mashups, at least I know that if shit hits the fan I can always go with somebody else. It will hurt a bit and take some effot, but I am not dead in the water. For the Google Maps example this would mean looking at Yahoo Maps and see what features the Yahoo Maps API have in common with the Google Maps API, and just use those common features. This can also come in handy if you hit the maximum number of requests on Google Maps, then it would be nice switch to Yahoo Maps automatically.

The risk with all this is of course to spend to much time preparing for something that won’t happen. It is the same situation as developers spending so much time making their code perfectly scalable and optimized that they acctually never ship anything in time. So dont go too far, but be aware of the situation. Trust is nice, but trusting several API providers to always do a good job and to not be evil in order for you to survive is quite risky.

But thanks to Google anyone can now run their own CDN for free on Googles servers. It is really easy to set up and storing files for downloads, stylesheets etc on Google instead of on your own site takes the load of your servers (and consumes much less bandwidth of your hosting account) and speeds things up for the end users. It’s a win win situation, and it is also really really cool! If you are interested in more information about how to get the maximum performance from your web site then I recommend you read the excellent post Performance on a Shoe String on 24ways.

What is Google App Engine?
Using Google App Engine you can run web applications on Google’s servers. That means that you can benefit from Google’s huge world-wide server farms, it means that it is really easy to scale and to integrate with othe Google applications (for example using Google authentication in your applications). At the moment you have to write your applications in Python (don’t worry: no coding at all needed to use Google App Engine as a CDN, just keep reading), but hopefully they will expand it to other languages soon (personally I want to run PHP and CodeIgniter on Google App Engine!). The App Engine is Googles response to Amazons very successfull web services S3 (for storage) and EC2 (for computing). Amazons services are very powerful, but they do require a deeper level of technical knowledge to use than Google App Engine.

Currently Google App Engine is in a Preview Release (= beta), but it is free for anyone to join, all you need is a Google Account and a cell phone (more about this later). What you get is 500MB of free storage and around 5 million free pageviews a month, if you use more than that there is a small cost (see the Google App Engine blog for more details). The cost for these extra resources are almost the same as for Amazons Web Services, and with the freebies and ease of use thrown in Google App Engine is a bargin.

How to set up your own CDN
To use Google App Engine as your own personal CDN you need to install some things on your computer and edit a few configuration files. All this work is a one time thing though, after that all you need to do is run a simple program to upload new files to Google. Sorry to say that the scripts you download is for Windows only, if you are on a Mac or using Linux then you need to make your on script to do what deploy_digitalistic_cdn.bat does (if you do so please add this to the comments of this post for any one else to use).

1. Since Google App Engine only works with the programming language Python you need to download and install Python on your computer. If you have a Mac or run Linux you most probably already have Python installed, so you can skip this step. Download the correct installation file for your OS from Python 2.5.2 from http://www.python.org/download/ and install it. Use the default settings, except install it under “Program Files” instead of directly on the C: drive (or install it wherever you want, but in then you need to modify the scripts below.
2. Download the Google App Engine SDK from http://code.google.com/appengine/downloads.html and install it. During the SDK installation it will check if you have Python or not, so if you have a Python installation problem you will know it already here. The Google App Engine SDK is needed to be able to write and upload applications to Google. Just use the default settings when installing the SDK.
3. Sign up for Google App Engine at appengine.google.com. For this you need a Google account (your GMail address for example, if you dont have one it is free to create one).
4. Once you are signed up you need to create an application, so just click on the button “Create an Application” and give your application a name (called “application identifier”). This name needs to be unique among all users applications, so it might take a while to find a unique one. In my case I used “digitalisticcdn”. Save your new application. After you have created your first application you need to specify your cell phone number. Google will then send you a SMS with a code that you enter into their site. This confirms that you are the owner of this Google App Engine account (so don’t use it for spamming ;).
5. Download the file http://digitalisticcdn.appspot.com/files/digitalisticcdn.zip (hosted on my private CDN!) and unzip it to your harddrive. If you want you can rename the unzipped directory from “digitalisticcdn” to whatevery you want, for example the name of your own application. It doesnt really matter, it just makes easier for you to keep track of things in the future.
6. Use a text editor to edit the app.yaml file in the digitalisticcdn directory. Change “application: digitalisticcdn” to “application: <your application identifier” and save the file. This will tell Google App Engine what application to upload your files to.
7. Now it is time to add all the images, stylesheets, files, videos etc you want to upload to Google to the folders in the digitalisticcdn directory. Put all images into the /images folder etc. You can create any number of subfolders inside the images, files, stylesheets etc folders (for example /images/webhostninja.com/ninja.gif). You can always add more files at a later time, so if you just want to set things up to work you can skip this step for now. There is already an image in the /images folder for you to test that all is working as it should be.
8. Download http://digitalisticcdn.appspot.com/files/deploy_digitalistic_cdn.bat and edit it in a text editor. This file needs to point out your Python installation, your Google App Engine installation and your digitalisticcdn directory. If you installed the Google App Engine SDK in the default directory and Python in C:/Program Files/ then you don’t have to worry about those settings. Just change the last part of the file to point to your digitalisticcdn directory. Keep in mind that all paths with spaces in needs to be surrounded by quotes.
9. Double click on the newly changed deploy_digitalistic_cdn.bat file to upload all the files in the digitalisticcdn directory to Google. The first time you do this you need to specify your Google username and password.
10. You now have your own private CDN! Go to <your-application-identifier>.appspot.com/images/ninja.gif (in my case digitalisticcdn.appspot.com/images/ninja.gif) to see that it works.

How to use your private CDN
To use the files you upload to your Google App Engine CDN you just need to use the URL to the file on your site. If you want to show an image of a cool ninja from WebHostNinja.com you would just use digitalisticcdn.appspot.com/images/ninja.gif as your image source in your HTML. The same goes for stylesheets, files to download or whatever else you want to share on your CDN.

At any time you can add new files to your digitalisticcdn subdirectories (/images, /stylesheets etc) and run the deploy_digitalistic_cdn.bat file to upload them to Google. If you remove files from your digitalisticcdn directory and then run the bat file they will be deleted from your Google application.

You can check the statistics of your Google Application at appengine.google.com. For example you can see how much bandwidth and disk space you are using. It will take quite a lot of files and usage for you to use up the resources you get for free, but if you have a super popular site then it is worth taking a look here every now and then.

If you have read so far and found all this usefull then please Digg it. Thanks!

There are still some bugs to work out, I want to add a lot more web hosting providers to the index and of course there are also loads of features I want to add. In my database I do have quite a lot of information about each hosting provider and their plans, so it would be cool to mash that up with some other data, but at this point in time my mind is blank what to do. If you have any ideas about this please let me know!

Another project that I am involved with is the Mexican TV-listing site enlatele.com.mx (”en la tele” = “on TV” in spanish). We have just finished an iteration in our continous development, and vastly improved the search and added other nifty things like channel logos and filtering channels based on your cable provider. I have several entires about writing widgets/gadgets for enlatele.com.mx for sites like MySpace etc, so that will give me a good excuse to soon dig deeper into the OpenSocial specs.

I have more things up my sleeve, projects that have much more to do with mashups. As soon as there is something I can tell you about I will, so watch this space.

Now when I am writing some of my own web apps I would like to avoid spam to overwhelm me, both via contact forms and comments. Lo and behold, Akismet is available as a web service, and via some ready made libraries it is very easy to use from outside Wordpress as well. I am using Elliot Haughin’s CodeIgniter Library, but there are also libraries for PHP, .NET, Ruby on Rails, Drupal etc etc. All you need to do is to get a Akismet API Key from Wordpress.com (register, then go to My Account and Edit Profile and you will find the key), download a library (or start writing your own from Akismets API) and start sending all comments to Akismet. The API Key is free for personal use, cost $5/month if you make more than $500/month from your site and cost a bit more for Enterprises. Well worth it I say, it will save you time and frustration all around, and make your website so much cleaner. There is no longer any excuse to suffer comment spam.

Thanks Akismet for one of the best and most usefull web services around!

• It is PHP, this might be a dealbreaker for some, but for me that is a huge plus. Primarily the advantages of this is that I can easily host my creations on basically any cheap web host, that there are plenty of libraries and resources out there to make my life easier and also that I know PHP. For the last reason I could have gone with Ruby on Rails or Java as well, but it put all Python frameworks out of the competition.
• CodeIgniter is very easy to install and as easy to deploy. All you need for things to play nicely is an Apache server, a MySQL database and a copy of the CodeIgniter files. Deploying and setting up things are the most boring thing when it comes to writing your own apps, so it is a must for me that it is a breeze, I just dont have the patience to deal with deployment problems.
• Great documentation, the CodeIgniter user guide is excellent. This is a huge difference from many other frameworks and platforms, especially the ones developed by an open source community (CodeIgniter is developed by Ellis Labs, the guys behind the Expression Engine blogging platform). The developer community is also very active and knowledgable, so what isn’t in the user guide is in the CodeIgniter forums.
• Finally, a framework that improves my productivity. Most frameworks tries to do to much and are so huge and rigid that there is a huge learning curve if you want to doing anything but a “Hello World” app. CodeIgniter helps me with the stuff I need help with and doesn’t meddle in the rest. There is no need to hack 10 plugins of different qualities together to get what I need (like in Drupal), and that just makes developing fun as it should be. It is also the first MVC (Model-View-Controller) framework that helps me organise my code in a good way, something that I usually suck at otherwise.

In short I recommend that anybody that knows PHP and want a light weight, good framework checks out CodeIgniter. A good place to start are the CodeIgniter video tutorials, and if you get a bit deeper into things Elliot Haughin has a great blog that often covers CodeIgniter and he also have some great libraries that are well worth looking at (CodeIgniter libs for Twitter, Flickr and Akismet for example). Another great resource is the blog of Derek Allard, Technology Architect at Ellis Labs.

Forrester divides mashups into three types:

• Presentation layer mashups - merge content from seperate sources into one view, the simplest type of mashups.
• Data mashups - more complex data driven mashups that get data from several sources and present them in one view
• Process mashups - mixes business processes and users with data from several data sources.

Presentation mashups and data mashups sound very much similar to me, but then again I dont get payed by Forrester… But Forrester has a lot of influence over this so unless Gartner comes up with another definition this is the ones we have to live with.

I am glad to see that Forrester also realized that enterprise mashups will be huge. It is kind of a self realizing profecy - there will be a lot of men in ties reading this report so it is going to help Enterprise Mashups grow. It is really the next wave in enterprise software. And if you are reading my humble blog you are already years ahead of the mashup wave

For more info about this report see Forrester: Enterprise Mashups to Hit $700 Million by 2013 on ReadWriteWeb.

It is quite easy to post to several microbloggins services at once. Jaiku does a great job of importing RSS feeds, so posts to Twitter or Pownce can easily be imported to Jaiku. Via Twitterfeed it is easy to get an RSS feed into your Twitter as well. I haven’t found any easy way of getting an RSS feed into Pownce. Also there are apps like Twhirl that let’s you post to all 3 platforms at once. In my case I also use the Twitter Facebook app to get my tweets into my Facebook status and I am looking for a way to do the same with LinkedIn (no success yet). So posting cross-platform is not a problem, even if it means that you need to do some configuration and that all your posts gets trippled or quadrupled.

Reading friends posts from several platforms could also easily be done. I could of course go to all the different services and read each posts on each one, but since I want to do other things with my day than that I would rather use services like FriendFeed or SocialThing that aggregates it all into one place. FriendFeed imports from most sources and have some nice comment features, but the UI really desperatly needs a designers touch. SocialThing imports from just a few places so far (please please add RSS now!) but I still prefer it to FriendFeed. These services and others make it easy to see your friends posts from several platforms in one place. What is missing is a way to naturally post back to the microblogging platforms from these services.

What is needed, and what will come very soon I am sure, is a mashup of all these microbloggin platforms to allow users to be active on several platforms at once all from one place. I would like to see an app that allows me to interact with Twitter, Pownce and Jaiku completely. This means reading other peoples posts, replying to posts to have a conversation going cross-platform and posting to all platforms at once. Since all of the platforms have APIs this should be possible to implement (and for all I know it already exists somewhere, if you know of such an app please let me know through a comment on this post!). This would be a great mashup that would breach the community silos that exists today. Short of everyone moving to one platform a mashup is the best answer to this problem.

Btw, I have some extra SocialThing invites so if anybody wants one please let me know via a comment on this post.

Now I will concentrate on creating something of my own, and I will be sure to keep you in the loop of what that is. Of course it will involve mashup technologies and remixing data, as that is what I am good at. Also I think that there are good possibilities to spread the word of mashups in Sweden, I have already done some of that, for example at the Web Service Awards last year in Stockholm.

So… Goodbye Kapow and thanks for all the fish, but now it is time for me to live the life without paychecks but with endless possibilities. Part of that life is making Digitalistic.com looking better, something that I hope you have already noticed. Thank you very much to Kemie at Monolinea.com for doing a much needed upgrade of the site!

The API Provider
You have this great service that lifts humanity to a new level, makes the sun shine brighter, makes TV sucks less and give the gift of limitless bandwidth to the people (or at least it is really cool). You have even added this great API, now what? How do you get developers to start using the API and spread the word of your great service to everyone and their grandmother?

Well, let’s back up a bit. First of all, do you really have a great service? If you do, then do you really have a great API? Without a product people want to use there is no need to go through the hassle of promoting it. Make sure that the API actually is usefull for developers, that it will enable them to do cool and usefull stuff easier than if they would just hack it all together from scratch. Also make sure that there are plenty of documentation, examples, code snippets etc for the developers to get their hands on to minimize the barrier to entry. Hack together some mashups yourself with your API included in the mix, to give people and idea of what can be done. The key to get an API used by developers is to get the developers excited about the possibilities and get them talking. So give them something to be excited about and something to talk about.

Once all that hard work is done then you can promote your API via directories such as programmableweb and webmashup so that developers can find you. If you have made your own example mashups, then go through the steps below to market that, that is a good way of getting some recognition.

Last, but not at all least, show some love for the developers that has taken their time and built something using your API. Have an example gallery where they can list their creations. Blog about them. Talk about them at conferences. “Link love shall be bestowed upon those who link love showeth”.

The Mashup Developer
For the developer of the mashup there is Google AdSense money on the line, or maybe just recognition from peers. Most mashups result in web pages anyway, so make sure to do all the SEO stuff - have good page titles, have a good copy, have validating HTML, have a sitemap available etc. If there is money down the line for you then also throw some money at advertising (Google & Facebook makes this a walk in the park). All this is standard, but as there are differences between mashups and a regular web page you should also use that to your advantage.

What APIs do you use? What tools have you used to piece things together? Explain how you made your mashup, what the moving parts are. If you used Yahoo! Pipes, then link to the pipes used and explain how they were done. If you used Google Maps (and if you are a mashup newbie then I guarantee that you have, just admit it… “my name is Andreas, and I am a Google Maps addict”) then explain how. If you used openkapow robots, then explain how you developed them. Since API providers are suckers for traffic, just as everyone else, it is not unlikely that they would be interested in adding your mashup (assuming it kicks-ass, which of course it does) to their example gallery. All this creates more link love, more Google baits and really increases the chances of your mashup being found and appreciated by fellow developers. Another plus is that all this also increases the chances to be blogged about, do not forget that bloggers are suckers both for traffic and content.

There’s both money and recognition in entering your mashup in a contest, see programmableweb for a good list of what you can enter right now. You might not have to redo the mashup from the ground up, just add another API to the already great mashup you have made and you could already be a winner. If you go to Mashup Camp you could enter the traditional Speed Geeking (like speed dating for mashups basically) and go home with a shiny new Macbook.

Of course also list your mashups in directories such as programmableweb and webmashup , but by now you should know that already

Thanks for everyone that discussed this with me at Mashup Camp! For the notes from this session check out the Mashup Camp wiki.

• 7 % had very good knowledge of Mashups
• 13% had good knowledge of Mashups
• 12% had some knowledge of Mashups

Even people that knew nothing about Mashups apparently follows what happens, since 41% are following Mashups. On the other end of the spectrum only 1% of the people responding had acctually implemented and evaluated Mashups (they didn’t ask me, so I have no part of that lonely percentage). I am looking forward to seeing next years Web Service Award numbers, hopefully Mashups have become more mainstream by then.
Richard Gatarski on weconverse.com has a more detailed report on the different questions and answers in the poll.

• Do not be shocked when somebody mashes up your site, it will happen if it hasn’t already. It is a great possibility for marketing your services and not a threat!
• Use mashups to quickly create unique and usefull user experiences to enrich your web sites.

Here is my presentation (in Swedish only):

| View | Upload your own

The presentation went very well and I got a great response to it. It seems like I did at least tickle the interest of the audience and at least some of them will play with mashups and hopefully all of them will see mashups as an opportunity and not something weird and dangerous. I think that Sweden is getting ready to embrase the Mashup wave.

You can find all the presentations from the Web Service Awards here, I especially recommend the usability presentation from Johnny Mellgren at Vinnovera.

Thank you to Richard Gatarski for inviting me to do the presentation and thanks to all of the people I queued with for the food yesterday

• Microsoft Live Search will be integrated into Facebook and the Microsoft-Facebook allience will start to seriously compete with Google for the search market.
• Enterprise Mashups will be on the top of the hype cycle in the end of the year and big companies will start to seriously invest in it (and not just talk about it).
• The Web 2.0 bubble will burst, but that really just means that some big famous companies will go bancrupt (bye bye Technorati). It won’t really have any similarities with the .com bubble, instead it will mostly be something created in the buzz obsessed blogosphere and then be writen about in mainstream media.
• Microformats will be integrated into Wordpress, Blogger, Flickr och other major sites, and be the basis for many interesting integrations and mashups.

Some predictions specific for Sweden:

• There will be a lot of talk about mashups in Sweden, but not much action.
• Schibstedt will try to make a Swedish social network - “a Swedish Facebook”. Be prepared for a major ad campaign.

You can find more Swedish predictions in the latest episode of the whatsnext podcast (sorry, swedish only).My last prediction is that Digitalistic soon will have a new design and a section all in Swedish, I really hope that I am not wrong about this one!

Yesterday
Programmers were building applications and integrations by programming. There were very little finished modules to reuse and combine, so a lot of logic had to be written from scratch (most talk about code reuse is nothing but talk). This was not only Mainframes and Cobol, but also a lot of Java, C++ on Windows and Solaris etc.

Now
Programmers building applications using ready made modules. These modules might be full applications, libraries or, in some cases, widgets. This means that less logic needs to be written from scratch (Apache Jakarta projects have changed the lifes of most Java programmers for example).

In 1-3 years (early adopter geeks today)
Programmers and early adopter business users are assembling solutions using ready made components. These solutions are called mashups today, but are probably not going to have that name in a few years, instead the “mashup style” of solution development are going to have become mainstream and be a natural part of applications (just see how mashups are built with Facebook Applications today). The components are widgets that have been developed by programmers to function as building blocks in bigger solutions.

In 3+ years
Business users are assembling solutions, programmers are building widgets.

From Hacking to Assembling
Of course there will always be programmers that are programming low level solutions like kernels and compilers (at least those are low level to me) and business users that just want their problems solved without them having to deal with any technology. But overall the focus for programmers will go from building the solution to building the building blocks (aka widgets). For business users the focus will go from waiting for a program that solves their problem to be developed to being able to assemble a solution (aka mashup) that will address their problem. Overall the focus will move from hacking to assembling.

Great Tools for Business Users Needed
This means that business users need to be more aware of what building blocks are available. Currently there are a few early attempts to develop systems to handle this - IBM’s Mashup Hub is a good example. Furthermore there is a need for easy to use systems for business users to combine all those widgets. This is probably the hottest area in mashups right now, with everyone wanting to be in on this - BEA Pages, IBM QEDWiki, PageFlakes and iGoogle to just mention a few. But so far it has been with very limited success and just a little more than proofs of concepts or cool AJAX playgrounds. Let’s see what will happen in 2008, I for one if looking forward to seeing new cool innovative solutions to these problems.

What is Google Knol?
Google Knol will allow you to write an article about a specific subject. Google will host the article and hightlight it when somebody search for releated keywords in their search engine. If there are several related Knol’s then the users will help rank them and in that way provide quality assurance. The writers of a Knol have the option to get a share (50% is the speculation) on all advertising revenue Google makes from the article.

Read more about Google Knol in the Official Google Blog, Read/Write Web or TechCrunch.

Why the Paranoia?
The paranoia around Knol is that Google will kill Squidoo (whatever) and Wikipedia (yeah, right) by rolling over them with their user base and Mr. Burns-like piles of cash. The irony is that by doing all the complaining about Knol the blogosphere are once again giving Google lot’s of free publicity. I agree that it is a bit sad that Google can kill off complete ecosystems of startups just by releasing a semi-done project to their gigantic user base, but sorry to say that is the name of the game. Microsoft did the same for years, and before that it was IBM. Even Saint Jobs at Apple does this. It is nothing specific to the internet industry either. The key is that in the Web 2.0 world it is possible for startups to move and innovate smarter and quicker than the big boys, so if Squidoo and Wikipedia do not adapt and join the deadpool because of that then all I can say is R.I.P.

Another big reason for all the writing about Knol is of course that posts about Google gets a lot of attention and traffic, and thus make more money to the writer via Google AdSense.

Knol is just an extension to what Google is doing already
Google is already based on user generated content. Even their revolutionary Page Rank algorithm is based on user generated content. Think about it - every time you make a hyperlink to a page you tell Google that this page is a little bit more important than before and that it probably has something to do with the page you link from. If you make money from your page it is very likely that you do that via Google AdSense, so Google is already paying you for your content.

For Knol Google will host the content themselves, and that is basically the only difference. The content is still user generated and you can still make money on the content via Google. The only thing you really need to be aware of when adding content to Knol is that Google and not you will own that content, but other than that I see no reason for the paranoia.

First mover advantage
While the still unreleased Knol gets hyped I suggest that you start writing some Knol articles about your area of expertise to be ready to add them to Knol ASAP when it launches. Of course you need to give the article an angle that promotes you and your site. Since you will be one of the first Knol’s out there you might use this to get more traffic. Another good SEO tool.

Update: Read this very interesting article from TechCrunch analyzing Google Knol