I have moved the blog to Posterous as you can notice. All articles have been migrated but I only checked and reformated the ones from the two first pages. Expect to encounter poorly formated posts or broken links if you go too deep in the archives. You can email me if such things happen.
Unfortunately I couldn't migrate the comments as they are managed by Disqus, which is not compatible with Posterous for the moment (I hope it will be soon!). If you subscribed by RSS, do not forget to change the url (unless you're using the feedburner feed).
The reason for this move is that I don't have a lot of time on my hand anymore. I'm working a lot on the products for Novaden and I didn't want to bother with managing my custom server and servers from the company. Posterous is a great blogging platform even if I miss some little things (like Disqus and Google Reader shared items in the sidebar).
As I'm losing my personal server (one month left), I'm discontinuing ronchon.fr, an old project which has never succeeded.
I'm also going to move some of my open source projects (Atomik, Bushu and Spatial Desktop) to my company. They now will be developed and sponsored by Novaden (but no worries about the licence, they will always be open source). Thus, hosting of this project will now be provided by Novaden. I've never talked about Bushu but I will soon do a proper presentation.
Also, I'm going to migrate all code repositories to github. I think github is becoming the leader for open source code repositories and social coding. It provides great features and has really simplify forking and working and any projects.
I don't know what is going to happend to Harmony yet. It will be migrated to github for sure but I don't know if I'll get back to work on it yet.
This changes should occur before the end of the month.
I've been working for some time on a great project (which explains the total lack of updates of this blog). I'm really pleased to announce that I have created my company called Novaden, based in France.
Novaden provides consulting services on web development, cloud computing and linux integration. I will also reveal some time soon two online services for businesses that I've been working on for some time and that I hope will prove very innovative.
The company will be present at the Cloud Computing conference in Paris La Defense the 5th and 6th May. You can learn more at http://www.datacenter-cloud.com/. Some of my Open Source projects, like Atomik, will become sponsored by Novaden.

I recently had to write a little script to check the integrity of references inside a database. Notice: This was done as part of my work at Tribal Nova. Thanks for letting me share!
The script (command line only) is very simple and aims to check integrity of references (foreign keys or soft references). It's for MySQL only and requires PHP5 with PDO. Foreign keys are automatically discovered and you can specify additional references in a mapping.xml file.
A report will be displayed. Upon this, you can choose to execute an action to resolve issues. You can
To run it simply call it from the command line with connection info: php integrity.php --database=my_db --username=root --password=root. You can get some help using php integrity.php --help.
You can download it by clicking here.
Update: Things have completely change since then. While annotations will be used, their syntax and the way to define models have changed.
It's been quite a long time since I blogged anything. I merely touch at a computer for the past two weeks but I hope to resume the work on Atomik as soon as possible for the 2.2 release.
Meanwhile, I want to present you the new Model plugin that will come with this version. A quick reminder to begin. Putting it simply, models are a way to map database tables to classes. This allow to manipulate data from the database as objects in our application. An ORM (Object Relational Mapper) is the library/tool that allows you to do such a thing. The Model plugin brings the Atomik_Model library which is an ORM.
I tried to create an ORM which is not full of big enterprisy features (there are already some very good ones) but one that is more suited to the everyday developer. Models are defined as classes and annotations are used to configure it. By annotations I mean using PHP's doc comment and @ keywords (like php documentor documentation).
A big feature of Atomik_Model is that the data do not have to come from the database. Each model is bound to one adapter where it will fetch its data. This can be an xml file or a web service for example. Relations between models (like foreign keys in an RDBMS) are also supported. Finally, you can also generate forms for each model (this uses Atomik_Form / Form plugin).
So, how to define a model ? Assuming that our default adapter (the data source) is the database:
1 class User extends Atomik_Model 2 { 3 public $username; 4 }
This will be mapped to the User table. The primary key is automatically generated (and named id, this can be changed). You can change the table name using the @table annotation:
1 /** 2 * @table users 3 */ 4 class User extends Atomik_Model 5 { /* ... */ }
The Model plugin creates some console commands to automatically generate tables associated to the models (the Console plugin is needed). You won't have to write a line of sql!
1 php indexp.php db-createNow let's create another model named Article and add a relation between the two (a user has many articles).
1 /** 2 * @has many Article as articles 3 */ 4 class User extends Atomik_Model 5 { 6 public $name; 7 } 8 /** 9 * @has parent User as author 10 */ 11 class Article extends Atomik_Model 12 { 13 public $title; 14 public $text; 15 }
As you can see, the @has annotation is used. It follows this schema: @has [relation type] [model name] as [property]. The relation type can be one, many or parent. The property will be the object property used to access the associated model.
Now let's query these models! There are three static methods of Atomik_Model to do so: find(), findOne() and findAll(). All takes as first argument the model name. find() takes as second a model id. findOne() and findAll() works the same way except that findOne() returns the first record only. They take as parameter an array of fields/value for conditions.
1 $users = Atomik_Model::findAll('User'); 2 echo '<ul>'; 3 foreach ($users as $user) { 4 echo '<li>' . $user->name . '<ul>'; 5 foreach ($user->articles as $article) { 6 echo '<li>' . $article->title . '</li>'; 7 } 8 echo '</ul></li>'; 9 } 10 echo '</ul>';
As you can see, we're getting the user's articles by simply using its articles property. This was a quick look at what's coming up. There's much more to discover in Atomik_Model as well as in the new Atomik Library. I hope you'll like it!
I said that I released it before the end of March. I'm one day late but it's here: the first milestone for Atomik 2.2! This new version has great new features which will make Atomik really simple to use. The core is mostly finished and I'm now working on plugins. I can't give a release date yet as there's still lot of work.
So what's new in this release?
And the cool think is that it's already fully documented!
Be aware that there is a big compatibility break with the configuration. New configuration keys are listed in Appendix A of the documentation.
But the things I'm the most excited about in this new release are the new plugins. Using the new pluggable applications feature, I created the Backend plugin which adds, as its name implies, a backend to your website. Plugins can then create administration interfaces in this backend. For example, the Db plugin will now come with a database management interface! It will become very easy to create simply administrable website.
Another plugin that I'm hardly working one is the Db one. From version 2.2 it will include models support. I tried to create a very simple (yet powerful) way to define your models. The great thing is that their data source won't have to be a database. I'll talk more about that later. From Atomik 2.2, there will also be a sub-project called Atomik Lib. When I create a plugin, I always try to create the associated libraries as reusable as possible. These will now be available as independent packages or all together, like the Zend Framework.
Note that there is no documentation for new plugins as well as for Atomik Lib yet. These new plugins are also in heavy development so don't expect much of them for now. You can still download them to have a look.
Download Atomik 2.2 M1
Documentation (see bottom of the page)
At work, I'm currently working with Wordpress and I was amazed at how most plugins are really bad written! PHP developers should really start to make an effort about that and this is even more true for popular projects like Wordpress. At least, the core or the Akismet plugin, which comes already installed, should give an example. But no! Have you ever had a look at this plugin source code? I nearly puked! Come on guys, not even comments ? Don't be surprised why enterprise are a bit reluctant to use PHP.
Most plugins don't use classes, don't comment their code, HTML is in the middle of PHP code...all anti pattern or bad practices can be found in these. While Wordpress does not force you and does not provide means to facilitate clean programming, it is still not a reason to not use it. It is fairly simple to separate HTML from php files and use a class for the plugin. Here how I did it (and I'm sure there's even a better way but at least this one is cleaner than most plugin).
In your plugin file, starts by creating a class. I use a start() method which will register all hooks and one method for each of them.
1 /** 2 * explain what my plugin does 3 */ 4 class MyWordpressPlugin 5 { 6 /** 7 * Initialize the plugin and register hooks 8 */ 9 public static function start() 10 { 11 add_action('hook', 'MyWordpressPlugin::onHook'); 12 } 13 14 /** 15 * Callback for the action "hook" 16 */ 17 public static function onHook() 18 { 19 // do stuff 20 } 21 } 22 23 // starts the plugin 24 MyWordpressPlugin::start();
That's it! Far more cleaner than putting everything in the global scope.
All my HTML content is saved as php files with the phtml extension in an html subfolder. Then for each of them, I create a renderSomething() method which simply includes the phtml file.This method can, before the include, do some logic, like retreiving some data. There should be only presentation logic inside the phtml file.
I also create a separate file with a new class when it comes to create some administration pages. My plugin needed an option page so I create a class called MyWordpressPluginAdmin which registers hooks and do all the suff associated with displaying my option page. Then I include this file in the plugin file and call MyWordpressPluginAdmin::start() from the MyWordpressPlugin::start() method. Here is how it looks like:
1 /** 2 * Register the option page 3 */ 4 class MyWordpressPluginAdmin 5 { 6 /** 7 * Register hooks 8 */ 9 public static function start() 10 { 11 add_action('admin_menu', 'MyWordpressPluginAdmin::onAdminMenu'); 12 } 13 14 /** 15 * Register the option page 16 */ 17 public static function onAdminMenu() 18 { 19 add_options_page('My plugin', 'My plugin', 8, __FILE__, 'MyWordpressPluginAdmin::renderOptionPage'); 20 } 21 22 /** 23 * Render the option page 24 */ 25 public static function renderOptionPage() 26 { 27 include dirname(__FILE__) . '/html/option_page.phtml'; 28 } 29 }
I think, and correct me if I'm wrong, that this way of doing things is better. The code is commented, easily maintenable, designer could work on their own files... Do you think this is a good solution? the comments are yours!
PS: sorry for the harsh beginning but I was quite angry and disappointed when I saw all that.