!Neutral Ground

Update: Yes I'm still here

Wed, 16 Nov 2011 01:05:00 +0800

What happened to the “Learning Nooku” series from last year? Yes it stopped. It stopped abruptly.

Why? Because I got overwhelmed by the torrent of improvements in the Nooku Framework. Yes friends, since I wrote my journey a year ago a lot of things have changed. A lot of things I wrote are now obsolete! So I will archive my posts, and maybe write another one.

Here’s a VERY brief summary of what’s new.

REST

REST is the architecture that powers Web 2.0 and beyond. Any application that is properly using Nooku will automatically be RESTful without extra work. Just use the Nooku’s controller and database package, and you’re all set. Your app is already compliant on REST specifications. Even if you don’t completely understand REST, just understand Nooku(which is really easy) and everything will be taken care of for you!

Controller Behaviors

Another powerful and fun improvement in Nooku is the Controller behavior. This is really neat concept that will make your Nooku code even more reusable. One year ago, Nooku developers are already praising Nooku for helping them reuse and organize their code. How much more now! Controller behaviors puts some weight and clutter off your main controller’s code and forces you to code beautifully by reducing tight coupling and increasing reusablity!

View and Template Improvements

Basically, nothing much have changed in how views and templates work. But some improvements are notable like the new ‘Chrome’ and ‘Module’ filters.

The Chrome filter wraps your template’s output into a Joomla module wrapper. This will make your app look more compatible with the current template that Joomla is using. This concept is already implemented by Ninjaboard. Did you notice how Ninjaboard adapts(like a Chameleon) to any Joomla template with dark or light theme? Amazing isn’t it? You can use that same technology in your Nooku Apps with just one piece of code!

The new Module filter allows you to insert a piece of output to any Module position in Joomla. This is another neat concept that gives power to developers. More information about this change can be found here: http://blog.nooku.org/2011/08/say-hello-to-the-dynamic-module-injector/.

KFactory, KIdentifier Refactoring - KService

One big change that can break your old Nooku code is the KFactory refactoring. It is now renamed to KService. The refactoring was done to complete the implementation of the Service Oriented Architecture. Before this refactor, services(which are actually objects) are accessed through an identifier using this format:

[application::]type.package.path.name

Now it’s using a more standardized format which everyone is familar with. The Uniform Resource Locator(URL) http://www.ietf.org/rfc/rfc1738.txt. The format now looks like this:

type:[//application/]package.path.name

Another change is the removal of KFactory::tmp. Use KService::get() instead. KService::get() will always instantiate a new object much like KFactory::tmp(). But if the class is intentionally a singleton(implementing the KServiceInstantiatable interface), KService::get() will return the single instantiated object.

So how does this help you? Well, for one, the object identifiers are now more familiar and is actually following a standard. Which means it’s easier to explain. And of course, this improvement has also allowed some optimizations that makes KService more efficient.

Better look inside the Nooku code to see it in action or check the wiki about this change.

There are more improvements actually

But we can’t list them all. These are just some of the significant improvements. But by the looks of it, I believe that the best time to learn Nooku is now. It has gotten more stable and a lot better than the version last year.

The new features of Nooku are so awesome! But of course it will take some learning curve. Once I feel that it reached a certain level of stability, I will continue writing about it in my blog.

are you still working with Nooku? I read your articles on starting out with Nooku, but noticed they were entered a year ago. I find myself in a VERY similar place as yourself (wanting a good PHP MVC (or HMVC) framework AND an existing CMS system combo). Nooku looked like "CakePHP meets Joomla" and that was ideal for me. Just wondering how it was going (if at all) with Nooku.

Wed, 16 Nov 2011 00:46:00 +0800

Hi! Yes I’m still working on Nooku. In fact I got employed by Johan Janssens’s company which allowed me to get a little more intimate with Nooku’s developments and the privilege to learn from the master himself.

Yes, Nooku is a great tool especially if you’re working on Web Applications inside a CMS shell like Joomla. But I’ll hardly compare it to CakePHP, Nooku is far more than that :).

Nooku is being developed in a fast pace, right now it’s in Alpha 4. There will be one alpha left, then the Beta. I think we can expect a stable by mid 2012 but that’s just a guess!

Thanks for getting in touch!

Simplest DB Access in Nooku

Wed, 15 Sep 2010 13:38:00 +0800

Learning Nooku Part 3: Accessing and Displaying Database Records

This is Part 3 of a series of posts where I document my learning process in studying Nooku. I’m a total Noob to Nooku so this might help other Nooku noobs to learn the framework.

You can read the Introduction of Learning Nooku Here.

Update: Download the component at this stage here - com_awesome-part3.zip

In Part 2, I learned 3 things.

Nooku does many things automagically. If it doesn’t see an expected class or object in your component, it will fall back to layers of objects using its Cascading Class Override System.
First layer of fall back is com_default.
Nooku is a RESTful framework, which means that “Requests and responses are built around the transfer of representations of resources”. Because of the RESTful architecture, the URL used to access a Nooku application is meaningful. So when you try to access a singular or plural resource, Nooku will deal with it accordingly.

In this post I’ll try to use some Nooku magic by accessing resources from the database.

Although I haven’t delved deeper into Nooku’s RESTful architecture, the first thing a noob will encounter is the significance of singular/plural resources. In Nooku, we access a resource by specifying it in the view variable in the request. If the view is plural, Nooku will try to return a collection of resources. If thew view is singular, Nooku will try to return a single object.

This becomes more apparent when we use Models in Nooku. In Part 2, I was trying to simply display a “dashboard”. It’s not a resource but it’s supposed to display a collection of resources. A dashboard doesn’t fit the mold of “singular” or “plural”. I simply want to display anything in the dashboard, and in this case a simple text.

But by default, Nooku will assume that I’m accessing a Database resource and it will automagically fetch data from a database table jos_awesome_dashboards. To override this default behavior, I had to create com_awesome/models/dashboards.php and then I created a class ComAwesomeModelDashboards which extends the base non-magic Model in Nooku, KModelAbstract. The magics happen in KModelDefault.

Magically Listing a Collection of Resources

Now that I understand how plural/singular resources are handled in Nooku, I’ll try to put that knowledge into use. I will now make com_awesome list resources from the database.

I’ll make a generic resource named item. If I try to access the “item” resources at this stage using index.php?option=com_awesome&view=items, I’ll get an error Table ‘database.jos_awesome_items’ doesn’t exist of the following query : SHOW FULL COLUMNS FROM. jos_awesome_items. So I created what it’s looking for, a table named jos_awesome_items.

Now that the table has been created, Nooku is looking for com_awesome/views/items/tmpl/default.php. So I also created it.

I have to populate the table jos_awesome_items with dummy content. But first I added 2 columns in the table: awesome_item_id(according to Nooku’s table field naming convention) as primary key and name as varchar. Then I populated the table with anything that came to my mind. I added Duck, Airplane, and Juice.

At this point, I’m assuming that Nooku’s magic will work. I haven’t created a Model for items yet, nor have I created a View for it. I just created a Database table and populated it with random data. I am assuming that Nooku will display the data automagically if I create a template for it. Here’s the template that I created:

com_awesome/views/items/tmpl/default.php

<ul>
<?php foreach ($items as $item): ?>
    <li><?= $item->name;?></li>
<?php endforeach ?>
</ul>

Trying to access it using index.php?option=com_awesome&view=items, bahm! The list is there, Magically!

Now I hear many people saying “amazingly awesomeful!”

But I’m afraid of Magic

As of this stage, my feelings are mixed. In one hand I’m delighted that the most basic and elementary functionalities are taken care of by Nooku. On the other hand, I dread the time when I have to do something unconventional, I’ll need to override the Magics first so I can proceed with my unique app freely.

I already have a bad feeling when I created an empty ComAwesomeModelDashboards whose only purpose is to disable magic so I can display a dashboard.

Magic Frameworks make simple things really simple, but complicated things really hard. I can only hope it’s not true in Nooku. I’ll learn as I go on.

I just have to accept that there are Tradeoffs… I can’t have everything. But I can’t help but wonder if I can easily disable all the Magic that Nooku does and simply start with the bare minimum.

Magically Displaying a Single Object

So now I’m just dealing with 2 files to display a collection of resources from the database. The dispatcher file and the template file. Everything else is automagically handled by Nooku. I guess it’s the same when displaying a single resource from the database. So now I’ll access a singular index.php?option=com_awesome&view=item.

In Part 2, I learned that accessing a singular item will make Nooku assume that you’re editing an object. In this case, Nooku is now looking for /com_awesome/views/item/tmpl/form.php. I created this file, and put this code there:

<?php echo $item->name; ?>

I accessed it by specifying an id in the URL index.php?option=com_awesome&view=item&id=1.

Great! It worked as expected. It displayed the text Duck which is the name of an entry in the database with id = 1.

Summary

In this session, I learned that Nooku is a Database centric framework. Most of the Magic I encountered in Nooku seems to revolve around Database CRUD(Create Read Update Delete). At this stage, I was able to experience how easy the “Read” part is. By simply creating database entries and accessing those entries directly from the Template, I was able to display data. I had no need to create controller, model, and view classes.

However, I also had a bad feeling about it. As a programmer, my experience has always been that CRUD is not as simple as it sounds. When dealing with real world apps, I usually customize every bit of the app. Basic CRUD goes to the trash. What I want to know is how Nooku can help me create complicated, unconventional apps.

I haven’t decided yet what to tackle next. It seems that I don’t want to delve on CRUD anymore as it is so elementary I might be wasting my time. So my next entry could be any topic, and it should be a little more advanced.

Simplest Nooku Component

Tue, 14 Sep 2010 12:33:00 +0800

Learning Nooku Part 2: Displaying a Simple Text

This is Part 2 of a series of posts where I document my learning process in studying Nooku. I’m a total Noob to Nooku so this might help other Nooku noobs to learn the framework.

You can read the Introduction of Learning Nooku Here.

Update: Download the component at this stage here - com_awesome-part2.zip

In order to understand the Nooku Framework, I want to know what it does for me so I’ll also know what’s left for me to do. The first thing I want to know are the Magics that I can use.

In documenting this learning process, I’m looking at com_harbour. It’s a sample component for Nooku. But I won’t reference code examples from com_harbour here. I’ll just use it as a jumpstart, then anything I want to do for my first simple app, I’ll find out through experimentation.

In order to fully understand how Magic works in Nooku, I need a bit of experimenting. What is the bare minimum amount of files needed to display a simple text, “Whatever”? Of course you can simply echo text from the entry point. But if we want to use the MVC, we’ll follow the convention.

So I’ll make my first Joomla Component powered by Nooku. I’ll name it com_awesome. As a start, I’ll just make it display any text like “Hello World”.

The Dispatcher

In my entry point for Joomla(the first file that Joomla executes when running the component), I’ll put the dispatcher.

administrator/components/com_awesome/awesone.php

<?php
// Check if Koowa is active
if(!defined('KOOWA')) {
    JError::raiseWarning(0, JText::_("Koowa wasn't found. Please install the Koowa plugin and enable it."));
    return;
}

// Create the controller dispatcher
echo 
KFactory::get('admin::com.awesome.dispatcher')->dispatch(KRequest::get('get.view', 'cmd', 'dashboard'));

From the code alone, I can see that KFactory is used to call a dispatcher object. Inside KFactory::get() is a key or identifier that maps to the dispatch object. I noticed that KFactory::get is commonly used in Nooku applications. Looking at the code, I think KFactory::get instantiates and returns objects according to the identifier, if the object is already instantiated, KFactory::get will return the same instance.

So in the entry point, the controller is dispatched. This is the first magic that I encountered. I am calling a dispatcher, but I don’t need to create a dispatcher file. If Nooku doesn’t find a dispatcher in your component, it will fall back to its default dispatcher. If I want to override the dispatcher, I just have to create com_awesome/dispatcher.php and extend the ComDefaultDispatcherDefault class.

<?php

class ComAwesomeDispatcher extends ComDefaultDispatcherDefault 
{

}

While finding out about this pattern, I was overwhelmed by the many things that was going on in the source code. ComDefaultDispatcherDefault extends KDispatcherDefault extends KDispatcherAbstract which extends KControllerAbstract which extends KObject and implements KObjectIdentifiable.

Whew! I initially thought that I’ll find a dispatch method somewhere along the hierarchy. But I didn’t find it. Digging deeper, I found out that I was actually calling _actionDispatch from ComDefaultDispatcherDefault. Maybe I don’t need to explain in detail what I found out but suffice it to say that the more I dig deeper, the more I find awesomeness. It is simply “genius”! I can already imagine how I can put those things into good use!

So we don’t need to create a dispatcher file unless you really really need to override Nooku’s default dispatcher.

While going through this learning process, I learned this very important concept in Nooku: For things you don’t create, Nooku has a fall back. What you’re actually writing is the code that’s unique to your application!

The Model

Note: This section is now irrelevant. The 99-toolbar branch of Nooku(which will soon be merged with the 0.7 trunk) has fixed this issue. (Edited Sept 29, 2010)

One thing I realized while experimenting on Nooku is that it is very Database-centric framework. Most of the Magic happens by automagically doing the most common tasks in accessing and displaying database data.

So by now I’ve just created one file. That is the component’s entry point. From there I called the dispatcher. By default, the dispatcher tries to access the “dashboard” view. The second magic that I encountered was when I tried to access the component without creating any other files. I encountered this error:

Table ‘database.jos_awesome_dashboards’ doesn’t exist of the following query : SHOW FULL COLUMNS FROM `jos_awesome_dashboards`

I soon realized that Nooku is trying to do its magic by falling back to a default model object for me which seems to automagically gets data from the database. But I don’t want this yet as I simply want to display text. So I had to override the default Model by creating an empty base Model.

So here’s what I did. I created /com_awesome/models/dashboards.php and created this class

<?php
class ComAwesomeModelDashboards extends KModelAbstract
{
	
}

By creating this class, Nooku doesn’t fall back to the default Model. It uses this Model which extends the most basic and core Model Class in Nooku which doesn’t have any Magic in it.

This removed the error but I encountered another error which is related to the View.

The View

If there is nothing different in what you want to do, you don’t need to create a controller and a model, and a view class. All I want to do here is to display text. I’ll proceed in creating a view template. Going back to the dispatcher I noticed that I’m passing a default view variable.

KFactory::get('admin::com.awesome.dispatcher')->dispatch(KRequest::get('get.view', 'cmd', 'dashboard'));

If no view variable is passed through $_GET, the default value dashboard will be used. From my readings about Nooku, I found out that passing the controller value through $_GET is a bad practice. So what Nooku expects is the view which makes your application “RESTful”(as Johan puts it).

So to create a view, I created /com_awesome/views directory. Then I created /com_awesome/views/dashboard directory, then I created /com_awesome/views/dashboard/tmpl directory, and finally, I mistakenly created a /com_awesome/views/dashboard/tmpl/default.php file. I said it’s a mistake, I initially thought it was the most natural thing to do, but this mistake helped me understand another fundamental concept in Nooku.

If you also commit my mistake you’ll get this error Template "com_awesome/views/dashboard/tmpl/form.php" not found. Why? Because dashboard is singular. And by default, when you access a singular view, Nooku assumes that you are trying to edit an object. So I went ahead and created a /com_awesome/views/dashboard/tmpl/form.php file. I placed a text like “This is form.php” in that file.

Now if I access my component using index.php?option=com_awesome, the text I put in /com_awesome/views/dashboard/tmpl/form.php is displayed and l also noticed that there are 3 standard action buttons on the top right corner - Save, Apply, Cancel.

This seems to be the default Nooku behavior if I don’t override the fallback classes. In this case, since I did not create controller, model and view classes, Nooku uses the default classes from com_default - the first layer of fallback. If I don’t have com_default Nooku will fallback even deeper using classes from its core.

So I don’t need to create classes, I just created 2 files and a directory hierarchy, and bahm! I am displaying something.

What is “com_default”?

com_default is Nooku’s first layer of fallback. It is located in Joomla’s site and admin component directory. It contains many “common” things found in Joomla applications so it’s the developer’s responsibility to extend it or even ignore it completely if you don’t need any of its functionality. This is where many of the Nooku magic for Joomla is located. I am yet to tap the pool of magic that can be found here, but I’ll learn as I go on.

So now I know that if I want to do something unique for my application, I’ll extend the classes found in com_default. That’s great! It’s like auto-pilot with easy manual override.

Extending or Overriding “com_default”

The first thing I want to do is to make dashboard be a dashboard. I don’t want Nooku to assume that I’m accessing an Object’s form template. So I want Nooku to display /views/dashboard/tmpl/default.php by default.

Digging the code, I found out that I should change the layout by creating a “dashboard controller”. Create com_awesome/controllers/dashboard.php and put this code:

<?php

class ComAwesomeControllerDashboard extends ComDefaultControllerDefault {

    protected function _initialize(KConfig $config) {
        $config->append(array(
            'request' => array('layout' => 'default'),
        ));

        parent::_initialize($config);
    }
}

Here I’m simply changing the layout to default which would normally be form. By doing this I can now create /com_awesome/views/dashboard/tmpl/default.php and that’s what Nooku will display.

How About the Toolbar Buttons? I just have to override the default view class by creating /com_awesome/views/dashboard/html.php and I put this code:

<?php
class ComAwesomeViewDashboardHtml extends ComDefaultViewHtml
{
    public function display()
    {
        //Reset the toolbar
        KFactory::get('admin::com.awesome.toolbar.dashboard')
            ->reset();

        return parent::display();
    }
}

So here I have just overridden the default view class and “reset” the toolbar object. Just like everything else in Nooku, since I don’t have a /com_awesome/toolbars/dashboard.php file, Nooku goes deeper. com_default doesn’t have it too, so it’s in the core, Nooku falls back deeper and used KToolbarDefault.

Summary

I have now created the simplest application in Nooku which simply displays text. This may be a very simple app, but by doing this, I understood some fundamental things which are very important in understanding Nooku:

Nooku has layers of fallbacks. It is called “Cascading Class Override System”. To make things clearer, here’s the sequence from top to bottom:
- Named Component Specific - Your most specific class based on the view e.g. ComAwesomeControllerDashboard in com_awesone/controllers/dashboard.php
- Named Component Default - Your app’s general class e.g. ComAwesomeController in /com_awesome/controller.php
- Default Component Default - General class from com_default, ComDefaultControllerDefault in /com_default/controllers/default.php
- Framework Default - Found in the Nooku core e.g. KControllerDefault
com_default is the first layer of fallback, it provides many common tasks found in Joomla. Developers would usually extend it and just change some things that are unique to their application.
The view variable is important in Nooku. Making it singular or plural will cause Nooku to treat it accordingly. In this case, a singular view dashboard makes Nooku assume that we’re accessing an object, and it looks for the form.php file by default. To change this behavior, you have to override the controller, and the view class.

Have you also noticed? The Class naming convention is consistent with the file structure. Maybe you can figure it out already just by looking at the code. You also don’t need to “require_once” the files. Nooku auto-loads the files based on the ClassName.

Next, I’ll learn more about how to display data from the Database.

How to Install Nooku

Tue, 14 Sep 2010 12:11:00 +0800

Learning Nooku Part 1: Installing Nooku

This is Part 1 of a series of posts where I document my learning process in studying Nooku. I’m a total Noob to Nooku so this might help other Nooku noobs to learn the framework.

You can read the Introduction of Learning Nooku Here.

Installing Nooku is not easy but it’s not difficult either. It’s just not a simple process. There is no official Nooku installer for Joomla. You have many options.

If you are familiar with SVN, the best way to install Nooku is to checkout the SVN Repository, and install the Nooku trunk to your Joomla installation. You have to use a script to populate your Joomla installation with the symlinked directories going to your Nooku local repository. You also have to manually insert the “Koowa” plugin in your Joomla database.

Here’s how I did it in Mac OSX.

Checkout the SVN Repository

$ cd /somewhere/in/your/computer
$ svn checkout http://svn2.assembla.com/svn/nooku-framework
$ svn checkout http://svn2.assembla.com/svn/nooku-tools

Run the Symlinker

$ sudo pear install --alldeps Console_CommandLine
$ cd nooku-tools/trunk/symlinker
$ chmod +x symlinker
$ ./symlinker ../../../nooku-framework/trunk/code/ /your/localhost/docroot/joomla

Run this SQL in your database

INSERT INTO `jos_plugins` 
	(`id`,`name`,`element`,`folder`,`access`,`ordering`,`published`,`iscore`,`client_id`)
VALUES
	(NULL, 'Koowa', 'koowa', 'system', 0, 8, 1, 0, 0);

By using this process, you are sure that you have the cutting edge version. To update Nooku, you just update your repository using svn update, and the Nooku installation in your Joomla will also be updated because they are symlinked.

If you have no idea how to use SVN, and the above steps is still very new and confusing for you, then I uploaded an Nooku installable package thanks to Stian Didriksen . You can install Nooku as a Joomla extension using this installer. But this is not advisable, because Nooku’s API improves really fast. By next month this installer would contain an outdated version of Nooku.

Don’t Forget, Nooku uses MySQLi

One little requirement that Nooku needs is MySQLi. It’s really simple, just go to Joomla’s Global Configuration, then under “Server” tab in the top right corner, you change the Database Type from “mysql” to “mysqli” if you haven’t done so.

Now let’s proceed to Part Two, my first Nooku component.

Learning Nooku - Part Zero

Tue, 14 Sep 2010 00:12:00 +0800

During the coming days I’ll be documenting how I am learning Nooku. I’m a total Noob to Nooku so this might help other Nooku noobs to learn the framework. For those who doesn’t know it, Nooku is a Rapid Application Development Framework for Joomla.

This is Part Zero of my series of posts about Learning Nooku.

This should be fun! I’m learning another PHP Framework - Nooku. I’ve had fun using Kohana 3 for a year but Kohana 3 is so easy and simple, there’s not much to learn anymore. I’ve heard many great things about Nooku, so I guess it’s time to see what the hype is all about.

Since hearing about Nooku in 2009 until now, I’ve just been reading about it. I just browse the code, check the examples, read the mailing list, see how things were done so I’d have a general idea of what to do once I actually code something.

As of the moment, Nooku lacks a solid documentation, or even a total beginner’s guide. So as my first contribution to the Nooku Community, I think it’s nice to document my learning process. I’m a total beginner to Nooku, coming from a Kohana background.

Since I am coming from Kohana, the natural approach would be to compare Nooku with what I already know. Something in the lines of “I do this and that in Kohana, now how do I do it in Nooku?”. But Johan(chief architect of Nooku) advised me to unlearn what I know, and approach Nooku from a clean slate.

I’ll take his advise. That’s gonna be the approach I’ll make. I’ll ask the most general questions and try to answer them, without comparing Nooku with what I already know.

Part Zero: Learning the Principles Behind Nooku

I’ve never written a Nooku App prior to this post. I’m writing this from a noob perspective. That means I am describing Nooku as I understand it, and I might be wrong. For sure this is also incomplete.

Nooku is a Magic Framework

A magic framework is a framework that does many things for the developer “automagically”. Many developers like this approach, but there are some, particularly me, who doesn’t like it. I don’t like “automagic”. One reason why I chose Django over Rails is because Rails does many things automagically. But Django still has many magics in it. One of the reasons why I settled on Kohana is because it doesn’t have any magic in it. Why don’t I like Magic? I don’t like Magic frameworks because they make common things really easy, and uncommon things really hard. I usually end up writing uncommon tasks, so magic frameworks rarely help me.

If I don’t like magic frameworks, why am I diving into Nooku? Because it’s a framework that doesn’t force me to use Magic. The magic is there when I need it, but if I don’t need it, I can simply discard it and still enjoy the bare minimum features that Nooku Framework offers.

I haven’t written any Nooku application yet, so I found this out when reading the Nooku source code. So maybe I’m wrong. But I’ll find out as I document my learning process.

Nooku has Consistent Conventions

Although not fully consistent, Nooku’s directory structure, class naming, object mapping, and database table/column naming are consistent enough. Knowing the conventions helps developers understand what’s going on with the code. If you see a class, you know where to find it in the file system just by looking at its name. If you want to access database objects, you’ll easily know how to access it because the object’s properties aren’t different from their database counterpart. The number one feature of a Framework should be Consistency. Nooku is grade A (and will soon to be A+) when it comes to consistency.

Nooku brings Modularization to the Highest Level

As far as I know, Nooku’s architecture allows developers to modularize their code to make it reusable, maintainable, and redistributable. Using OOP(Object Oriented Programming) makes frameworks naturally modular. If taken to the next level, we have an MVC(Model View Controller) architecture, take it again to the next level, and we have HMVC(Hierarchical MVC). Many frameworks nowadays stops at MVC. Nooku is one of the first, along with Kohana 3 to fully implement HMVC.

But Nooku doesn’t stop there. Nooku gives you many other tools to help you modularize your code. It does so by helping you implement programming design patterns such as Mixins, Chain of Command, Dependency Injection, BREAD, and many others. If you can’t see how these design patterns can help you, you must write an app. The best way to learn is to experience problems, and shoot them down with design patterns where applicable. You may have employed some of those design patterns without knowing it.

Then again, Nooku doesn’t seem stop there. Nooku was designed with modularization to the core. From its core objects to its derivative classes, even in its file structure and naming conventions, you’ll see how easy it is to modularize code!

I Imagine Nooku as an onion with many layers. It has a powerful core, as you go up higher in each level you’ll find awesome things that you can use to mix and match to use in your app. Each layer provides a certain kind of Magic!

I was overwhelmed by these things at first, but I’m guessing that once I grasp the basics, it’s gonna be a smooth sailing. I haven’t used frameworks that has this kind of modularization so it’s new to me. I don’t know if these are unique to Nooku so it’s certainly eye popping for me. But of course, I have only used Django and Kohana, and just read about other frameworks so I’ll see how it goes. Of course all frameworks are modular, what’s the use if they aren’t? But Nooku’s modularity seems to be different. I don’t know how to call it nor how to describe it in words. It’s just different from the things I’ve used.

Perhaps the best way to really understand all these things is to write an app. When you ask Nooku lovers to describe Nooku, they will use superlatives like “awesome”, “the best”, “amazing”, etc. Let’s see what they really mean. In the coming days and weeks I’m having an adventure with Nooku!

Next: Part One - Installing Nooku

Resurrecting an old blog

Mon, 30 Aug 2010 10:01:00 +0800

In the past 5 years, I tried to maintain a blog 3 times already. But everytime I move to a new server, my personal blog is usually the least of my priorities so it gets left out in Migration. Then came Tumblr. My blog has found a new home and hopefully, a permanent one. I don’t have to manage it on my own server, and I don’t have to worry about hackers. All I’ll worry about is what to write.

Well, this time I think I have new thoughts and ideas to publish.