Joost: A start-up i’m actually looking forward to…

July 31, 2007 § 1 Comment

besides tesla motors of course.

What is Joost:

from Wikipedia – “Joost (IPA pronunciation: [dʒuːst][1] ‘juiced’) is a system for distributing TV shows and other forms of video over the Web using peer-to-peer TV technology, created by Niklas Zennström and Janus Friis (founders of Skype and Kazaa)“.

They are not another YouTube. It’s a cool way of distributing hi-quality videos online without old-media up-on-your-butt. In a way they are the new distributor, but hey, if Joost is executing it well… Why not?

Video Demo:

YouTube: Ubuntu Feisty with Mac OS X skin

July 31, 2007 § 2 Comments

CakePHP: Mambo is using Cake!!!!

July 30, 2007 § Leave a comment

for Real!!!

What is Mambo:

Mambo is pretty well known, 6 years old, open-source CMS, of course using PHP with typical LAMP setup.

When will they use CakePHP: Mambo Version 5.

This is yet another nod to CakePHP as the most awesome web framework on planet (extreme hyperbole pun here).

Reference:

CakePHP: book for newbies…

July 30, 2007 § 1 Comment

is almost here.

David Golding is the author, and here is his announcement about it.

Update: December 29th, 2007

Couple of the chapters are available here.

There’s also discussion forum about the book.

If you cannot wait to get started on CakePHP, see Resources below:

CakePHP: getting list of all of your controllers

July 30, 2007 § Leave a comment

This tips is written by Felix Geisendörfer aka the_undefined. He is waaaaay involved with CakePHP community.

His blog is recommended for readers who enjoy baking with CakePHP.

Zend Framework… Performance & Caching (part 2.1)

July 30, 2007 § 2 Comments

In my previous post (here), I promised you about performance of Zend Framework.

Unfortunately, I cannot give you the result yet. Because it is still work in progress.

So here is the low-down:

First of all, I’m researching (learning) about Zend_Cache, which consist front_end and back_end. Don’t worry about the mumbo jumbo just yet. The front_end is nothing more than helper functions that can help you optimized specific parts of your application code. The back_end utilize different types of medium Zend Framework use (as of version 1.0, there are 5 different choices of storage: filesystem, APC, SQLite, memcache, or ZendPlatform). ZendPlatform is not free.

The plan is to implement caching and run stress/load testing on both before and after-cache. Then I can publish the result here.

Currently, the front_end confuses me on how to utilize it… It promotes sloppy code. Or is it me not finding the good tutorial online?

Here is an example from Zend_Cache_Frontend_Output (<– it’s 1 of 4 front_end Cache objects):

(assuming $cache object has been initialized using the factory pattern)

if(!$cache->start(‘tag_for_block_of_PHP_code_below’))

{

[you block of PHP code]

$cache->end();

}

How in the world does this promote elegance? I supposed it should be fine if I enforce its usage strictly on View pages. But still…

Another thought would be to cache all public functions inside model classes using Zend_Cache_Frontend_Function. It’s the cleanest, most seperated (because hidden inside model classes), & has the highest impact (because of caching database calls made by the functions).

(Brain starts steaming up…)

So now y’all know why I’m so late in giving the performance report. Stay tuned for more tips on how make your Zend application… “enterprise-level”

Zend_View…

July 24, 2007 § 3 Comments

Seems kind of weak to me.

Disclaimer: I’ve been developing a web application using Zend Framework for quite a while now (couple of months).

Couple of points why it is weak:

Using Zend_View is quite a labor. I have to setScriptPath() manually for various .phtml that’s located not in the standard location. Of course readers might wonder, why would I want to place .phtml files in NON-default places? Please see the next point below.

In RoR and CakePHP, inserting a block of view inside another view page is a breeze. Zend_View doesn’t have render_partial() or anything remotely close to that. In order to make my extended View object have renderPartial(…), I need to call setScriptPath() to include the inner view element.

Another “I cannot believe they didn’t have it” moment, Zend_View has no capability of setting global layout. Again, I have to implement such function in my extended View object.

Granted, extending Zend_View object is pretty simple job. Thus, it is not something to get mad about. But it would be nice to have out-of-th-box experience like Ruby on Rails.

Overall, Zend_View is definitely lagging behind its competitors.

Where Am I?

You are currently viewing the archives for July, 2007 at RAPD.