Latest Articles

Ooshirt review

Wednesday, January 4, 2012 0 comments

A few weeks ago, I received an offer for a sponsorship by Ooshirt for two custom t-shirts. Funnily, their e-mail looked liked spam for me in the first moment, but I contacted them and it showed up as not being spam but a real offer.

So I took their offer and quickly created a t-shirt design with my logo on the front and the ZCE logos on the back. I couldn't align them perfectly myself in their online editor, so I marked it for review and one of their designers did that task for me. After receiving a sample image of how the shirts would look like, I confirmed the order.

As they are based in the USA and I'm in Germany, the shipping took a while to arrive here, but that is kinda normal. Eventually the t-shirts arrived today and the quality of both the shirts and the print look very well:



Thanks again to Ooshirt for their sponsorship and I can highly recommend them to anyone who wants to print their own clothes.

Green Zend Framework Elephpants

Saturday, November 5, 2011 6 comments

Since I was asked a few times about the green ZF elephpants, I'm clarifying this now. I'm in the process of creating ZF branded elephpants and everything is ready for now. The only thing missing is a total purchase quantity of at least 1000 small ones. The large elephpants have no minimum quantity after that. With a quantity of 1000 small elephpants, their price will be 7€.

I'm now taking pre-orders, which have to contain at least 50 small elephpants, and optional any amount of large ones. As soon as I have the total purchase quantity, production will begin and take between 3 to 6 months. If you want to make a pre-order, send an e-mail to mail@dasprids.de, telling me your shipping address and the quantities you want. Elephpants will be send from France, so there will be additional shipping costs. You will surely receive an invoice together with the shipping.

For those who like to order, here is a mockup of the green elephpant:


Also, I was just asked about the size of the small and large elephpants. Just take a look at this picture:

Zend\Ical – A long term journey

Wednesday, August 31, 2011 7 comments

About four years ago, I proposed Zend_Ical to the public, a component, which should enable everyone to read, create, and work with iCalender files. At that point, I had no idea about how complex the entire topic is. I were interrupted multiple times by other components with a higher priority, so I only worked on it from time to time. I where asked a lot about when the component would be done, and my usual answer was "I am working on it". Surely, most of the time, that was a lie.

Since creating the proposal, I refactored the Zend\Ical component about five times, especially the parser itself. About two weeks ago I started working on it again. I don't exactly know why, I somehow felt motivated. So I started finishing the parser and creating a complete new data structure whithin just two days with the help of libical, the official reference implementation. I occasionally noticed that I was working against the old RFC 2445, which was superseded by RFC 5545 in 2009. Fortunately it only added a few minor restrictions, but also a lot of clarifications of yet vague topics. After upgrading Zend\Ical to reflect the new RFC, I had to notice that there was a second, and also very important, RFC 5546, which adds further restrictions based on the calendar's METHOD property. This resulted in the data structure and parser being completly useless, so I had to make a final rewrite of it.

A week ago, I was able to finish the parser to a certain amount, enough to start testing the different value types. I adopted the recurrence iterator from libical, but fixed a few bugs and added missing restrictions. It is not complete by now, but it contains enough logic to work with most timezone definitions. After that, I searched for a way to create timezone components from timezone identifiers. The solution was the Olson TZ database together with vzic, which converts the Olson timezones to iCalendar timezones.

Right now I'm working on the timezone functionality, to be able to convert local dates to UTC timestamps and vice versa. If you are interested in the current code, you can take a look at it in my GitHub repository.

Decoding JamLegend tracks

Wednesday, December 22, 2010 3 comments

About half a year back in time, I was playing a bit JamLegend, and was a bit annoyed by the bad performance of the Flash-based frontend on Linux. Thus I raised a feature request and created a prototype of the Flash-frontend in HTML5. At that time, I didn't had any time to create an actually playable version, also because I didn't had any so called jam-tracks for any song.

A few days ago, I was looking at the prototype again, and I thought that an actually playable version would be pretty cool anyway. So I tried to download a song from JamLegend together with its track.jam file. This was not that easy, as every request to the song-page limits the access to the song and the track.jam file to a single download. That was pretty easy to work around, as I simply canceled the flash player and thus was able to download both the song and the track.jam file. The song is a simple MP3, so there's no magic there. The interesting part is the track.jam file.

After looking around how to contribute to JamLegend and investigating the decompiled Flash player (the resulting code was mostly garbage), I found out, that the track.jam file had to be some kind of MIDI. After analyzing the track.jam file, I found out, that it wasn't a MIDI, so I looked at the decompiled code again. Apart from many crap lines, I finally found an AES encryption integrated in the MIDI parser class. As the cipher and the key were both nicely readable, I was able to create a small decryption script:
$cipher = 'rijndael-128';
$mode   = 'ecb';
$key    = pack('H*', '280f9d1a5eb28306c15a0bf40a2554e82d5134388bc1a144dcf3aed93d71ce50');

$decrypted = mcrypt_decrypt($cipher, $key, file_get_contents('track.jam'), $mode);
This isn't the entire decoding. As I had to find out, the data were also padded with PKCS#5, which is not supported by mcrypt. Thankfully, a user had already posted a workaround in the PHP manual comments:
$pad = ord($decrypted{strlen($decrypted)-1});

if ($pad > strlen($decrypted)) {
    exit('Padding is larger than data');
}

if (strspn($decrypted, chr($pad), strlen($decrypted) - $pad) !== $pad) {
    exit('Could not unpad data');
}

$unpadded = substr($decrypted, 0, -1 * $pad);
But this wasn't the end. After looking at the decrypted data, I could still not recognize a MIDI file. So, back to the decompiled code and after another hour, I found out that the MIDI data were appended to some other data, which I couldn't clearly identify. But since MIDI files always have a header at the very first byte position, I could simply truncate everything which comes before it:
$headerPos = strpos($unpadded, 'MThd');

if ($headerPos === false) {
    exit('No MIDI header found');
}

$midi = substr($unpadded, $headerPos);
The result finally was a playable MIDI file. Now I only had to identify, how the notes were stored for the player. I first looked at Frets on Fire, on which track.jam files by JamLegend are based on, but that didn't completely match. So I opened the MIDI file with Rosegarden, and the result was the following: Tabs for normal difficulty are on C3 and the two following notes, skilled difficulty on C4 and the three following notes, and so on.

With this knowledge, I should now be able to create a fully working prototype. As soon as there is something to play with, you'll surely read a tweet about it.

Modern Application Design - Part 2

Wednesday, October 20, 2010 16 comments

Introduction
I know it was a long time ago when I wrote part one of this serial, and I promised many times to write the next chapter. Now I finally found some time to tell you a bit more about modern application design. In this part I'm going to write about the service layer and the model architecture used in my website. As usual, you can find the entire source code in my SVN repository.

General overview
Everything has to start somewhere, and in programing languages, that usually means some common classes which are used by your entire application. In my website, those common classes classes can be found under /application/library/App. Concrete implementations of models and services can be found in the appropriate module folders. For now, let's start with something just partly related to both of them.

Forms, or, how input flows
A user has generally two options to communicate with your application. Either via simple hyperlinks, or via forms. The first case is pretty regular, so let's focus on the second one. Zend Framework comes with a great component, called Zend_Form. This component does not only take care of generating nice HTML for you, but does also help you filtering and validating input coming from your evil user. The service layer is going to take advantage of this, by using it to validate input before processing it. There are many great tutorials about Zend_Form on the internet, especially by Matthew Weier O'Phinney, so I won't go into detail about them.

All you have to know is, that every individual form in my application is its own class, extending a base form class in my library folder. Every concrete implementation sets up its own form elements in its init() method, for example my login form.

The service layer
Most people new to the Zend Framework usually start to access their data with components like Zend_Db_Table directly in their controllers, and even some of them in their views. This is generally not very good, as you hardcode your storage backend into your entire application. This not only makes it very hard to swap the backend when required, but also blocks your from doing good unit testing (you do unit testing, don't you?).

The service layer comes to your rescue. It generally consists of a collection of classes around your models and data abstraction. Usually you should have about as many service classes as you have entities to represent in your application. In my case, I have services for users, articles, tags, guestbook entries and so on. Before I tell you more about a concrete service, let's see how the base for it looks like.

The abstract class for every service is App_Service_ServiceAbstract. It implements the Zend_Acl_Resource_Interface, so it can be used as an ACL resource as well. The abstract class is not only a base for concrete implementations, but does also offer retreiving services on-the-fly, also known as lazy loading. Each modules' bootstrap can attach services or injection containers into it, so that the abstract class knows, how to load the services. For the conrete implementations, it offers some helper methods for setting and checking ACLs.

Concrete implementation
Now, after I wrote enough about the base, let's take a look at the article services. When the article is instanciated, it gets passed a data mapper (more on this later). It uses this data mapper to create, update and read data from the storage backend. It overrides the _setupAcl() method from the abstract class, which tells the local ACL instance, which roles are allowed to do specific stuff. Another important method is getForm(), which creates and always returns an identical instance of the form.

For data manipulation, the service offers three methods, insert(), update() and delete(). The insert() method takes an array of data, usually the $_POST array. The update() method takes the same, but additionally an ID to update. The delete() method just works with a simple ID. The insert() and update() methods work almost the same:

First they get the form and validate the input with it. Then they get the (filtered) values and create a tag collection out of the supplied tags. Then a new instance of Blog_Model_Article is create, which is instantly filled with with the given values. After that, the article instance is passed to the data mapper, which does then some magic in the background. When the validation failed, the methods will return false, so that the controller knows to re-render the form (which will automatically be filled with the error messages then, since it comes from the same service). The insert() method will also take care to inform all my twitter followers about a new article through the twitter service.

The delete() method is quite simple. It gets get article via the supplied ID from the data mapper and checks if it actually exists. Then it is passed to the data mappers delete() method again. This does not only give you the advantage that you know, that something was actually deleted, but also allows you to restrict deletion on certain condition.

The service also coems with some helper methods to retrieve data. In this case we have search(), fetchAll(), fetchBySlugAndDate(), fetchById(), fetchByYear(), fetchByTag() and fetchYears(). They all proxy to certain methods in the data mapper, some of them will do some magic before doing a proxy call. While data manipulation methods just take plain data to do their work, the fetch*() methods will return either an ArticleCollection or just a single Article. An exception is fetchYears(), which will just return an array of years where articles were written in.

Data mappers
When it comes to data manipulation, this has to be done somewhere. I'm personally not a big fan of existing ORM systems like Doctrine for some reasons, so I wrote my own small data mapper structure. The base implementation of my data mapper is App_Model_Mapper_MapperAbstract. It does not much more than allowing to pass in a database adapter and setting or getting a default adapter via static methods.

This is not very much, so let's head to the article data mapper. This data mapper also does some lucene logic for indexing articles, but that's not very important for now. The data mapper, like many others, offers three methods for data manipulation, insert(), update() and delete()), of which all take an Article instance. The mapper then just takes care to transform the Article object into something the backend can understand. As mentioned in the service layer part, the data mapper also offers several methods for retrieving data from the backend and converting them to Article and ArticleCollection objects again to be used by the application.

Entities and collections
Usually, for each service and each data mapper, there is also always an entity and a collection class. For both of them, there are base classes in the /application/library/App/model folder. Collections do almost work like arrays, except that they restrict containing elements to be instances of specific entities, and also give you the possibilty of lazy loading, more about that later.

The base class for entities is also quite simple to understand. It offers setting and getting of values, as well as inserting values at construction time. Additionally, getters and setters for each value can be overriden to allow additional business logic. To take a look at a concrete implementation again, let's look at the Article entity. At the top it defines an array of possible values for the entity. It also offers two _set*() methods, which take care of generating a slug out of the title. There is also a getter for a permanent URL, which is mostly a convenience method for the view.

Now there's still a last case to cover. What happens with all those comments for articles? That is quickly answered. Every one-to-many relation in my application is covered with lazy loading. This is done through the App_Model_Relation class. When constructing it, it get's supplied a mapper and a method with arguments to call. The Relation class exactly behaves like a Collection class, except that it only loads the inner collection when required, thanks to SPLs IteratorAggregate interface.

When a data mapper creates an article object on retrieval, it will inject an Relation instance into the article object instead of a real collection. In case you want to iterate over the comments or count them, the comments will automatically be loaded.

Lazy loading of services
One last thing I didn't cover yet, was, how services are loaded. My very first approach in the past was to inject an instance of every service into the abstract service class in each module bootstrap. This leaded to a lot of overhead, as 90% of the instances were never used at the specific request. Thus I create dependency injection containers for each module, for instance the blog module injection container. It offers many get<Module>Service<Service>() methods, which will just return a new instance of the requested service.

In each module bootstrap, I attach an instance of the specific injection container into the abstract service class, together with a class prefix. When requesting a service from the abstract class now, it first looks if there already is an instance, else it tries to figure out which dependency injection container to load via the class prefix. Since I want my views slim and nice, I also have a view helper getService(), which is just a proxy to App_Service_ServiceAbstract::getService(). It is mostly used in the views to retrieve data which are not request related or to get and display forms.

To be continued …
I hope this chapter was helpful for you, and that I covered enough to answer all relevant questions. You can surely ask some detail questions in the comments and I will try to answer them. I have not planned another chapter yet, but be sure that I will write something as soon as I find some time and something comes to my mind.