June 28, 2008 § Leave a comment
Kamaelia is not yet another Rails-esque framework, thus making it more interesting.
Kamaelia is open source framework for building concurrent system. It was conceived inside BBC.co.uk r & D lab. It is written in Python, making it double interesting.
It draws its inspiration from UNIX pipeline. UNIX pipe allows chaining processes so that the output of current process goes directly to the input of the next process. The ‘pipeline’ module is called Axon.
From its documentation, Kamaelia is more like collection of components. The components comprises a lot of thing; TCP server/client, GUI builder, Audio codec, IRC client, etc…
This framework is most definitely different.
- BBC open source
- Kamaelia – Introduction
- Kamaelia – Getting started on “Axon” concept
- Kamaelia – components
- Wikipedia – UNIX pipeline
June 11, 2008 § Leave a comment
In software development, being able to say fuck it, and not implementing the not-so-important features is a good thing.
By saying Fuck It(TM):
- There’s less code to debug.
- There’s less features to unit test and functional test.
- Security schema protects less things.
- There’s less complication (in an already complex application). See: Feature Creep
- Deadline does not get pushed further and further.
- It prevents a decently good idea becoming stupid, by having too much features.
As a reminder, I must never ever attempt to add too much Cruft.
Fuck It is more or less similar to YAGNI, as 1 reader pointed out.
Hope this post can be a helpful reminder for readers as well.
May 29, 2008 § Leave a comment
On March 1st, 2008, AOL stop all supports as well as security updates.
AOL recommends Firefox or Flock as migration options.
Netscape has officially passed away.
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)
[you block of PHP code]
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”
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.