A new img.ly feature is on it’s way

June 16th, 2009

Here we go:

Cool eh?!

Attention! Google may harm your computer

January 31st, 2009

At least that’s what they believe they do ;)

Why Microsofts Songsmith could be a success.

January 27th, 2009

You might already know about the notoriously cheesy and badly produced microsoft songsmith ad (also check out the parody). Whatever they intended with that ad, it certainly proves that microsoft marketing totaly fails to catch up to the successful branding strategies of companies like apple or google. In contrast, some of their ads are so bad, that it already has something trashy. (But I doubt that this is the image they want).

Put that aside, songsmith is an interesting piece of software. Sing a melody into a microphone and songsmith will generate a whole song out of it. While one can discuss if this is really a productivity tool,  the entertainment value of songsmith is extremely high - comparable to the popular song star or RjDj.

Note that you can also use acapella versions of popular tunes, and therefore create a “songsmithed” version of that track, which is hideous, as the “songsmithed” version puts the original song in whole different (and mostly cheesy) context.

Take a look yourself, and check out the classic version of radioheads “creep”,  the oldie version of beastie boys “intergalactic”, police’s “roxanne” ragga edition, or - my favorite - a rave version of oasis “wonderwall”.

Songsmith could easily be a killer application for both iphone and android phones. I couldn’t even imagine the press of Microsoft releasing a successful iphone application, and let’s see if there are some fresh minds left at Microsoft that have at least considered this idea.

Rails Plugin DBSerialize

January 20th, 2009

People who have worked with a small team on a project know the problems: “The late night dudes have changed the database and now the live server is unuseable for the early risers.” Few phonecalls later - Ey man next time please email around the latest sql dump if you do some changes.

Though Rails does the best to keep you on track by providing a migration mechanism at a certain point at the development you want to be able to share the contents of the development database, not only the schema.

That’s why we released a plugin - more information on the projects page.

Smile Designer Smile

January 8th, 2009

Have you faced the problem that your HTML/CSS Layouts sometimes do not fit the designers drafts?

We released a small jQuery Plugin helping you getting things done!

Continue reading on the projects page.

Rails and Merb merge

December 26th, 2008

Right before christmas David (with personal follow up), Yehuda and Ezra let it out of the box. Rails 3.0 (Merb inside) will become the uberframework. We’re totally happy with that step and it totally makes sense (though there are different voices).

When we first evaluated merb, we did it, because we needed a lightweight alternative for Rails. But wait! We simply needed a lightweight alternative to ActiveRecord. So we found DataMapper - and with it somehow Merb. With Rails 3.0 you can choose between ActiveRecord, DataMapper or Sequel. Matt Aimonetti pointed ot to me, that a lot of good people are working hard to  make sure, that Rails will be truly ORM agnostic. Actually some people made DataMapper working with Rails month ago.

Having Merb on the radar we tried to build a very little app simultanously, to see the pros and the cons. As others we found out that it’s not that difficult to migrate from Rails to Merb. Especially with the API becoming stable a lot of things felt very Rails like e.g. merb_helpers try to mimic a lot of the rails api. So not merging with Rails a lot of problems in merb could only be solved by reinventing the wheel - ask yourself: Is that DRY?

We also found out that even some major plugins were available for both frameworks (e.g. Paperclip). Also for plugin developers this merge totally makes sense! Who wants to maintain two branches?

Probably with the big version number switch Rails will get some drastic changes. The Merb Router will be ported, the way controllers work will be changed and with some luck, we maybe get some of Sinatras sweetness, when we want to define flat applications. So we all have to upgrade our code - but I think it’s worth to do so.

We will a faster and more efficient framework, we get slices/engines and maybe we are gonna be able to push our code reusability to the maximum.

And for those who don’t want to use Rails, because “It’s the evil empire”, there are still plenty of options left.

Mercurial

July 30th, 2008

Using a distributed version control makes things really easy (sometimes). Having several branches and merging between the branches is like playing super mario. For example if you have three branches:

  1. project-dev
  2. project-qa
  3. project-stable

Using mercurial every branch would be a clone of each other. Pulling and pushing between the branches now looks like this:

CODE:
  1. cd project-dev
  2. pull ../project-stable # mmh get be a the bugfixes from stable

or

CODE:
  1. cd project-qa
  2. pull ../project-dev # get my awesome new feature to QA

Easy huh. But there are also some flaws. Sometimes it happens that a pull results in multiple heads now you will have problems to commit your uncommited changes. Multiple heads are nod bad per se. Then hg tool will recommend you to use "hg update -C" - never ever do this. It will weep out all your uncommitted changes and erase your work. Instead run "hg head" to find out the most actual revision (btw it's always called "tip"). Then merge with "tip" using "hg merge tip". Then commit your changes. Everything of your is save now. Now we try to get rid of our multiple head hydra. Run "hg head" again. Find the other revision (e.g. 12 8) and merge it "hg merge 128". Then commit it "hg ci -m 'killed the hydra'" and push it. Tada.

Other usefull commands:

"hg pull -u" - Pull and update
"hg fetch" - Pull, update and merge (needs to be activated through extension)

PHP: Short Syntax for Arrays

May 28th, 2008

Especially when you develop frameworks you have often the problem to deal with different configuration issues. Image this:

PHP:
  1. function foo($necessary_param, $optional_param1 = 0, $param2 = 1, $param3 = 2) {
  2. ...
  3. }
  4.  
  5. // let's overwrite the third optional parameter
  6. foo('bar', 0, 1, 69);

In PHP there is no such thing as named parameters - so we have to help ourselves:

PHP:
  1. function foo($necessary_param, $optional_params = null) {
  2. if(is_array($optional_params)) {
  3. if(isset($optional_params['param1'])) ...
  4. if(isset($optional_params['param2'])) ...
  5. if(isset($optional_params['param3'])) ...
  6. }
  7. ...
  8. }
  9.  
  10. foo('bar', array('param1' => 0, 'param3' => 4));

Hopefully you get the point here - nicer would be:

PHP:
  1. foo('bar', ['param1' => 0, 'param3' => 4]);

Especially when you go for nested arrays this syntax becomes more readable and even more maintainable. Lucky me, that there's a patch for a short syntax for arrays provided by Ryusuke Sekiyama.

I've written down a RFC about "Short Syntax for Arrays". If you like it support the RFC and drop me a note.

Traits for ActiveRecords next TopModel

May 18th, 2008

In this post, two possible implementations of the ActiveRecord design pattern will be discussed. With the raise of Ruby on Rails, ActiveRecord became very popular to the IT crowd.

To put the concepts of this pattern in a nutshell:

"ActiceRecord = Data + Business Logic."

An ActiveRecord object maps a row in a database table to an object in your webapplication (Data). This record is flavoured with object logic and even some domain logic (Business Logic). I won't repeat too much details as the ActiveRecord pattern is exhaustive discussed elsewhere.

As introduced in Rails, all the object relational mapping code is encapsulated in a very powerful ActiveRecord base class. Following the convention over configuration paradigm, you derive your model from this base class - having all the power of a database at your fingertips.

Implementing the ActiveRecord design pattern in PHP is not very easy. There have been many attempts by various frameworks but none of it has an elegant implementation like in Rails. Flinn Mueller pointet out that because of a lack of PHPs language core features it is impossible to create an such an elegant implementation.

Using the AR pattern typically looks like this:

PHP:
  1. class Blogentry extends ActiveRecord {
  2. }
  3.  
  4. $blogentry = new Blogentry;
  5. $blogentry->title = "Pac Man eats my Panties!";
  6. $blogentry->save();
  7.  
  8. $otherentry = Blogentry::find_by_id(3);
  9. var_dump($otherentry);

Usually the save or find_by_id method is implemented in the ActiveRecord base class. Before we had Late Static Binding (arrived in PHP 5.3) it was almost impossible to have a nice implementation of this pattern. E.g. when you call Blogentry::find_by_id(3), which is implemented in the ActiveRecord base class, it is impossible to derive that the method is statically invoked by the derived Blogentry class.

First I'm going to show you the LSB based implementation:

PHP:
  1. <?php
  2.   class ActiveRecord {
  3.     static function find_by_id($id) {
  4.         $class = get_called_class(); // LSI magic comes from here
  5.         $sql = 'SELECT FROM `' . $class . '` WHERE `id`=\'' . $id"';";
  6.         echo "Generate sql for select by id\n";
  7.         echo $sql . "\n";
  8.         return(new $class);
  9.     }
  10.    
  11.     function save() {
  12.       $class = get_class();
  13.      
  14.       if(!isset($this->id)) {
  15.         echo "Generate sql for new Record:\n";
  16.        
  17.         $sql = 'INSERT INTO `' . $class . '` ';
  18.         $sql_fields = '(';
  19.         $sql_values = '(';
  20.         foreach($this->fields as $field => $type) {
  21.           if($field != 'id') {
  22.             $sql_fields .= '`' . $field . '`,';
  23.             $sql_values .= "'" . $this->{$field} . "',";
  24.           }
  25.         }
  26.         $sql = $sql . substr($sql_fields, 0, -1) . ') VALUES ' . substr($sql_values, 0, -1) . ');';
  27.         echo 'sql: ' . $sql . "\n";
  28.         $this->id = 1;
  29.       } else {
  30.         echo "Generate sql for Update:\n";
  31.        
  32.         $sql = 'UPDATE `' . $class . '` SET ';
  33.         foreach($this->fields as $field => $type) {
  34.           if($field != 'id') {
  35.             $sql .= '`' . $field . '`=\'' . $this->{$field} . '\',';
  36.           }
  37.         }
  38.         $sql = substr($sql, 0, -1) . ';';
  39.         echo 'sql: ' . $sql . "\n";
  40.       }
  41.      
  42.     }
  43.   }
  44. ?>

The magic lies in the get_called_class method - this function returns the class where the function was statically called from.

This is quite elegant but it brings up some problems. As mentioned in Kores rant "Why Active Record Sucks", deriving your model from an ActiveRecord base class will disturb your code semantics.

To solve this problem I used the very promising Traits patch from Stefan Marr. Traits are like interfaces with code - by using them, you can simulate multiple inheritance (Ruby has a similar concept called mixins). And here comes the beef:

PHP:
  1. <?php
  2.   trait ActiveRecord {
  3.     static function find_by_id($id) {
  4.       $class = get_class();
  5.       $sql = 'SELECT FROM `' . $class . '` WHERE `id`=\'' . $id"';";
  6.       echo "Generate sql for select by id\n";
  7.       echo $sql . "\n";
  8.       return(new $class);
  9.     }
  10.  
  11.     function save() {
  12.       $class = get_class();
  13.      
  14.       if(!isset($this->id)) {
  15.         echo "Generate sql for new Record:\n";
  16.        
  17.         $sql = 'INSERT INTO `' . $class . '` ';
  18.         $sql_fields = '(';
  19.         $sql_values = '(';
  20.         foreach($this->fields as $field => $type) {
  21.           if($field != 'id') {
  22.             $sql_fields .= '`' . $field . '`,';
  23.             $sql_values .= "'" . $this->{$field} . "',";
  24.           }
  25.         }
  26.         $sql = $sql . substr($sql_fields, 0, -1) . ') VALUES ' . substr($sql_values, 0, -1) . ');';
  27.         echo 'sql: ' . $sql . "\n";
  28.         $this->id = 1;
  29.       } else {
  30.         echo "Generate sql for Update:\n";
  31.        
  32.         $sql = 'UPDATE `' . $class . '` SET ';
  33.         foreach($this->fields as $field => $type) {
  34.           if($field != 'id') {
  35.             $sql .= '`' . $field . '`=\'' . $this->{$field} . '\',';
  36.           }
  37.         }
  38.         $sql = substr($sql, 0, -1) . ';';
  39.         echo 'sql: ' . $sql . "\n";
  40.       }
  41.      
  42.     }
  43.   }
  44. ?>

You simply add your functionality to your class by using the trait:

PHP:
  1. class Blogentry uses ActiveRecord {
  2.   public $fields = array(
  3.     'id' => 'int',
  4.     'title' => 'varchar',
  5.     'text' => 'text',
  6.     'created_on' => 'datetime'
  7.   );
  8. }

I think the implementation with traits is much better than with late static binding because you don't have to worry about your code semantics and (almost) no need for magic functions (if you dig deeper into AR - say hello to __callStatic).

I hope that the trait feature will soon be added to the PHP Core.

Disclaimer: These examples are just Proof-Of-Concepts there is no database driver implemented yet. Currently we are working with PHP bleeding edge to have a tight implementation of a state of the art web framework. You can check it out at google code - but the current state is far from beeing stable.

PHP Unconference 2008

May 6th, 2008

Last weekend, Dennis and I attended the PHP Unconference 2008 in Hamburg. We were very curious to see where the PHP community is heading to, keeping in mind that there is a quite loud debate going on about future enhancements. Some people want to see the PHP language getting closer to Ruby or Python, allowing more elegant code while other want to stay still on keeping it simple.

Unfortunatly, we were not able to reveal our opinion on this matter properly, as we came to late to our own session - due to damn german weekend traffic jams. However, during the in-between debates, we took position for extending the core of the PHP language so that it can compete with Ruby or Python. Our opinion emerges from our own experience: we are developing projects in all languages; PHP (large scale projects), Python (mid-size projects), and Ruby (prototyping, internal software). While we appreciate the scalability and relative straight forwardness of PHP, we miss the elegance and handiness of Ruby (and Rails) and the perfomance aspect of Python. Sure, we all have to compromise at a certain point, neverthough you must at least try to get rid of things that are bugging many many people among the PHP community. It's open source dude - everybody is (can be) responsible.

While attending the "Ask the core developer" Session by Johannes Schlüter, which was definitely a highlight of the Unconference, we understood that one of the most fundamental problems is that every released unofficial patch can cause trouble in other PHP components or modules. That's why testing on a larger scale is essential for further enhancements of PHP. Hence, we welcome the idea of the upcoming TestFests, where we expect some nice results. We will soon reveal some results of our "playing around" session with the PHP core - we like coding much more than wining around ;)