MTV Party Noise using QR codes

Tomorrow is the 4th edition of MTV Party Noise, an exclusive party for Generation MTV customers (and their friends) only. This time it’s in my home town Ghent, so I’m really looking forward to it (free drinks, no driving, you get the picture).

It’s also the second time we integrated QR codes in the registration process. Once registered, people receive their ticket by email. The ticket contains a QR code which is then scanned at the entrance. We made some improvements since previous edition to make the scanning process faster and more reliable. However, it’s definitely not as fast as conventional laser scanners, but for the size of this party (around 2000 people) it should do just fine.

My MTV Party Noise ticket with QR codePreparing the notebooks for the entrance desk

REST output format: XML or XHTML

Last week I visited the PHPUK2010 conference in London and it has been a great time spending with colleague developers and fellow web addicts. I’m not gonna go into detail about every single talk because it’s probably easier and more interesting to head over to slidehare.net or phpconference.co.uk and check it out for yourself. Just let me say that it was a very well organised conference with a load of great speakers at a superb location. So great job PHP London!
Having said that, there was one specific talk I was really looking forward that. Lorna Mitchell of iBuildings was going to explain us “Best practices in web service design”. I’m currently working on a REST web service and there are some aspects of it that still raise some questions. For instance, unlike SOAP, REST does not really have a description language, a language with a vocabulary that can describe the service. So how do you deal with that? Another thing is the output format. A web service can offer a variety of formats. JSON and XML are the most popular ones, but in the case of XML, would you define your own tags, or would you rather pick XHTML.
It’s the latter issue I’d like to focus on in this blog post.
Lorna’s talk was really interesting, and she obviously has quite some experience with building web services. Unfortunately she didn’t mention anything about the XML/XHTML format. Very understandable of course, as her time was very limited and there are so many aspects about web services.
So afterwards I went to see her to check what her opinion was about the XML/XHTML output, and I must say I was a little bit surprised by her answer. Her reasoning was that no markup should be used in the output of a web service, so one should definitely use general XML.
I kind of had a problem with that argument, as to me XHTML is in the first place XML (though with tags that are predefined and limited) and the markup is achieved by defining CSS for the tags. Remove the CSS, and you end up with a document that looks exactly as if it was a custom XML document. So stating that you should not use XHTML because then you output markup seems incorrect to me. You will output semantical XML tags, but that’s something completely different than markup.
So I can’t see any arguments why not to use XHTML. On the contrary, this is why I think XHTML is in fact the better format:
- XHTML tags, although predefined and limited, will fit all your needs for structuring your data. If the whole web is built with that limited set of tags, you could expect it to be sufficient for your service.
- XHTML tags are semantical, and since every developer knows their meaning they are easy to interpret and read. You can easily use a <dl> for key-value pairs, <li> to represent a list, or a <span> for example if nothing would fit. A “class” attribute for the latter can be used to give more meaning.
- As Lorna mentioned in her talk, documentation is extremely important. When using XHTML, you can just check out a web service in your browser and actually see how it works. The browser will know exactly how to render the responses. And if the service respects a ROA approach, you can even browse from one resource or service to another by clicking around. The web service would almost become the documentation on its own.
- if every web service uses the same (XHTML) tags, it would save a lot of developer work in terms of parsing the response
To finish my point, let me just give you an example of a service respons in both XML and XHMLT, and judge for yourself. I took an extract of a Twitter response, giving you some user information:
I added some hyperlinking to link different services together, so therefore the XHTML version is a bit longer. But is it more complicated? Is there more overhead because of markup? Would it be more difficult to parse? And just try rendering both versions in your browser and tell me which one learns you the most.
If you’d like to read more on this matter, and especially the ROA approach for RESTful services, I would recommend “RESTful Web Services” by Leonard Richardson and Sam Ruby (O’Reilly). The idea behind the book is “web services are web sites for robots”, which is really an interesting way of looking at it.

Last week I visited the PHPUK2010 conference in London and it has been a great time spending with colleague developers and fellow web addicts. I’m not gonna go into detail about every single talk because it’s probably easier and more interesting to head over to slidehare.net or phpconference.co.uk and check it out for yourself. Just let me say that it was a very well organised conference with a load of great speakers at a superb location. So great job PHP London!

Having said that, there was one specific talk I was really looking forward to. Lorna Mitchell of iBuildings was going to explain us “Best practices in web service design”. I’m currently working on a REST web service and there are some aspects of it that still raise some questions. For instance, unlike SOAP, REST does not really have a description language, a language with a vocabulary that can describe the service. So how do you deal with that? Another thing is the output format. A web service can offer a variety of formats. JSON and XML are probably the most popular ones, but in the case of XML, would you define your own tags, or would you rather pick XHTML.

It’s the latter issue I’d like to focus on in this blog post.

Lorna’s talk was really interesting, and she obviously has quite some experience with building web services. It’s also great and inspiring to hear someone talk in such a passionate way as she did. Unfortunately she didn’t mention anything about the XML/XHTML format. Very understandable of course, as her time was very limited and there are so many aspects on this subject.

So afterwards I went to see her to check what her opinion was about this, and I must say I was a little bit surprised and confused by her answer. Her reasoning was that no markup should be used in the output of a web service, so one should definitely use general XML.

You can’t really agree with that argument because XML is a markup language as well. So then I was thinking that maybe I misunderstood and she actually meant there is no need to use a language that has ‘styled’ tags, but that wouldn’t make much sense either because robots that consume web services don’t apply styles to tags, only browsers do. Or maybe she meant that (X)HTML results in too much tags compared to custom XML, but even that could be easily proven incorrect.
Unfortunately since I had a couple of other question to ask her and other people were waiting with more questions, I couldn’t continue the discussion.

To me XHTML is in the first place XML, though with a predefined and limited tag set, and I can’t see many arguments why not to use it. On the contrary, this is why I think XHTML is in fact the better format:

  • XHTML tags, although predefined and limited, will most likely fit all your needs for structuring your data. If the whole web is built with that limited set of tags, you could expect it to be sufficient for your service.
  • The “HyperText” feature of XHTML, or in other words the possibility to link content together, could actually be very useful for web services as well (see code sample below).
  • XHTML tags are semantical, and since every developer knows their meaning they are easy to interpret and read. You can easily use a <dl> for key-value pairs, <li> to represent a list, or for example a <span> if nothing would fit. A “class” attribute can be used to give additional meaning.
  • As Lorna mentioned in her talk, documentation is extremely important. When using XHTML, you can just check out a web service in your browser and actually see how it works. The browser will know exactly how to render the responses. And if the service respects a ROA approach, you can even browse from one resource or service to another by clicking around. The web service would almost become the documentation on its own.
  • If every web service would use the same (XHTML) tags, it would save a lot of developer work in terms of parsing the response.

To finish my point, let me just give you an example of a service response in both XML and XHMLT, and judge for yourself. I took an extract of a Twitter response containing some user information:

XML (actual Twitter response):

<?xml version="1.0" encoding="UTF-8"?>
<user>
<id>1401881</id>
<name>Doug Williams</name>
<screen_name>dougw</screen_name>
<location>San Francisco, CA</location>
<description>Twitter API Support. Internet, greed, users, dougw and opportunities are my passions.</description>
<profile_image_url>http://s3.amazonaws.com/twitter_production/profile_images/59648642/avatar_normal.png</profile_image_url>
<url>http://www.igudo.com</url>
<followers_count>1031</followers_count>
<friends_count>293</friends_count>
<favourites_count>0</favourites_count>
<statuses_count>3390</statuses_count>
</user>

XHTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>User 1401881 - Doug Williams</title>
</head>
<body>
<dl class="user">
<dt>id</dt> <dd>1401881</dd>
<dt>name</dt> <dd>Doug Williams</dd>
<dt>screen_name</dt> <dd>dougw</dd>
<dt>location</dt> <dd>San Francisco, CA</dd>
<dt>description</dt>
<dd>Twitter API Support. Internet, greed, users, dougw and opportunities are my passions.</dd>
<dt>followers</dt> <dt>1031</dt>
<dt>friends</dt> <dt>293</</dt>
<dt>favourites</dt> <dt>0</dt>
<dt>statuses</dt> <dt>3390</dt>
<dt>more</td>
<dd>
<ul class="more">
<li><a href="http://api.twitter.com/1/user/dougw/statuses">tweets</a></li>
<li><a href="http://api.twitter.com/1/user/dougw/friends">friends</a></li>
<li><a href="http://api.twitter.com/1/user/dougw/followers">followers</a></li>
</ul>
</dd>
</dl>
<form id="searchUsers" method="get" action="">
<p>
Search for other users:
<input id="term" name="q" />
<input type="submit" />
</p>
</form>
</body>
</html>

I added some hyperlinking to link different but related services together, so therefore the XHTML version is a bit longer. But is it more complicated? Is there more overhead because of markup? Would it be more difficult to parse? And just try rendering both versions in your browser and tell me which one learns you the most.

If you’d like to read more on this matter, and especially the ROA approach for RESTful services, I would recommend “RESTful Web Services” by Leonard Richardson and Sam Ruby (O’Reilly). The idea behind the book is “web services are web sites for robots”, which is really an interesting way of looking at it.

Installing Kaltura CE on Fedora 10

Kaltura

Kaltura is an open-source video platform that gives you all the tools you need to publish your own videos: asset management, transcoding, video processing, batch uploading, streaming, widgets …
Kaltura offers a premium solution that includes full service, full support and full customization, but besides that they also released a free community edition (KalturaCE) of their server side application last year which looks very promising.

For a new project I’m working on I wanted to test drive KalturaCE and investigate all the tools and features, and especially their API.
After going through the installation guide I was a bit disappointed that the application was only guaranteed to work on Ubuntu or Debian Linux distributions. No Fedora, no CentOS (although there are some 3rd party instructions to get it working on CentOS). On the other hand, the software has only been released like 7 months ago, so I shouldn’t be too demanding yet I guess.
Our production server runs on CentOS, but obviously I prefer to do the testing on the local server which runs on Fedora 10. So I decided to just give a try. Who knows I was having a lucky day.

The installation guide instructs you to unpack the application in the webroot. However, to prevent messing up my accurately ordered web server (ahum…) I preferred to run Kaltura it in its own virtual host.
This is how my VH looks like:


<VirtualHost *:80>
DocumentRoot /var/www/kalturaCE
ServerName kaltura
RewriteEngine On
<Directory "/var/www/kalturaCE">
Options Indexes FollowSymLinks ExecCGI Includes
AllowOverride All
Order Deny,Allow
Allow from all
</Directory>
</VirtualHost>
 
 

 

 

When using a virtual host, you might want to add a line to your hosts file so you can browse it afterwards.

If you unpack the tar file (tar xvfzp [source] -C [destination]) in another location than your document root and you move all the files afterwards, DON’T FORGET to explicitly move the .htaccess file located in the application root. Just doing for example a “mv ./* ../” will skip hidden files, and without the .htaccess file the application won’t be very amusing to work with I can tell you.

Kaltura also needs a MySql database, so create one, and make sure that the database user has all the required permissions as instructed in the installation guide!

Once the files and the virtual host are in place (don’t forget to restart Apache) and a database is created, it’s time to run the installation script by browsing to the virtual host.
The process is a piece of cake. Fill out some forms and that’s it. However, when arriving at the final page, I got this message:
“Kaltura Community Edition Server installation failed”. Bummer!
I remembered that in the last step, I checked the “Free Registration with Kaltura.com” option, so I decided to repeat the installation process and skip that option. Result: Server up and running!
Don’t know exactly why the registration option messes up the installation. The error did not specifiy any details. But who cares, it’s running :-)

However I could still not preview any videos in the application. I kept receiving errors like “THE FILE DOES  NOT CONTAIN LAYOUTS ELEMENTS …”. Running the script “run_replace_root.sh” (located in the install directory) fixed this issue though.

After adding and editing some content it seems that Kaltura runs smoothly on Fedora.
Next steps are enabling H.264 encoding, and investigating the possibility to run the platform in the Amazon Cloud. To be continued.

Create QR codes in vector format

As I’ve explained in a previous post, I was working on a Zend Framework component to create QR codes with the possibility to save them in a vector format. Vector formats allow the image to be scaled as much as needed, making them more suitable for print work.

Although the component is not 100% finished yet, it’s perfectly capable of generating the matrixcodes in different file formats, with different parameters. The file formats are png, pdf and svg (gif and jpeg are possible as well, but are not very relevant).

To give the component a try I’ve set up a code generator page. So go ahead, generate your codes, and feel free to leave me a comment with feedback.

The new Drupal 7 interface

I must confess, I’ve never been a huge fan op Drupal. I know it’s a powerful application framework. I know it is very extensible. I know there are lots of free modules around that fit almost every need. So what’s not to like then? I’ll tell you: the interface. I’ve used all major content management systems in the last couple of years, and Drupal is the clear winner in terms of clunky and annoying interface. It was clear that the user experience was not much of a concern for the Drupal team.
So for that simple reason, I never really considered Drupal when starting a new project.
But when Drupal 7 was announced, it got me interested again. A Drupal User Experience Project was set up to improve the, eeeehm… user experience, so it looked like they were aware of the problem and were getting ready to tackle it.
2 years of development later, Drupal 7 Alpha is finally released, so time to forget about the past and give it another try.
The install procedure is very nice and easy, and is pretty similar to other systems. Then, once installed, the interface showed up, and it was… a fail!
Maybe my expectations were too high. But, you see, I’m a hug fan of Metalab. They do fantastic jobs on web interfaces. Simple, beautiful, and efficient. Or take for example CampaignMonitor. It shines in simplicity and user friendlyness. If you are getting used to working with those kind of applications, Drupal 7 is pretty disappointing. I do realize that Drupal is a much more complex system then most other applications, since Drupal is more ‘generic’ and closer to a framework. But still, I believe they could have done a much better job. So I’m afraid that even the new interface will continue to scare beginners, and not much progress will be achieved in this field.
So for now I’m still not going to use Drupal 7 for regular websites, and maybe when the stable version is out I’ll give it another go. Until then I’ll stick with WordPress or Expression Engine.
P.S. I’m evaluating Drupal here primarily as a CMS system for websites, not so much as a framework for building applications. For websites, you just want it work out of the box, looking good and simple for the client, without the need for custom coding.

drupalI must admit, I’ve never been a huge fan op Drupal. I know it’s a powerful application framework. I know it is very extensible. I know there are lots of free modules around that fit almost every need. So what’s not to like then? I’ll tell you: the interface. I’ve used all major content management systems in the last couple of years, and Drupal is the clear winner in terms of clunky and annoying interface. It was clear that the user experience was not much of a concern for the Drupal team.
So for that simple reason, I didn’t consider Drupal that often when starting on a new website project.

But when Drupal 7 was announced, I got interested again. A Drupal User Experience Project was set up to improve the, eeeehm… user experience, so it looked like they were aware of the problem and were getting ready to tackle it.
2 years of development later, Drupal 7 Alpha is finally released, so time to forget about the past and give it another try.

The install procedure is very nice and easy, and is pretty similar to other systems. Then, once installed, the interface showed up and, it was… a fail!

Drupal 7 interface
They did a good job on better organizing the different actions in categories that are clear and make sense, but what keeps annoying me is the fact that the interface is still not intuitive and in my opionion a bit of a mess. I don’t know really. When I saw the new WordPress 2.7 interface some time ago, I was really excited by the huge progress they made. With Drupal 7, I can’t say I’m impressed.
Maybe my expectations were too high. But, you see, I’m a hug fan of Metalab. They do fantastic jobs on web interfaces. Simple, beautiful, and efficient. Or take for example the CampaignMonitor software. It shines in simplicity and user friendliness. If you are getting used to working with those kind of applications, the Drupal 7 interface is pretty disappointing. I do realize that Drupal is a much more complex system then most other applications, since Drupal is more ‘generic’ and closer to a framework. But still, I believe they could have done a much better job. So I’m afraid that even the new interface will continue to scare beginners, and not much progress will be achieved in this field.

So for now I’m still not going to use Drupal 7 for regular websites, and maybe when the stable version is out I’ll give it another go. Until then I’ll stick with one of the alternatives.

Final note:
I’m evaluating Drupal here primarily as a CMS system for websites, not so much as a framework for building applications. For websites, I just want it to work out of the box, looking good and simple for the client, without the need for custom coding.
I’m also aware that you’re free to design your own interface, but not having to do that looks as one of the major advantages to me.

Go to Top