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.
January 7, 2008 § 1 Comment
As a developer that’s been coding PHP for so long and as a neophyte Pythonista, I have finally arrived at this crossroad.
Why PHP has to be this über-sharp-double-edge sword? See what I mean below.
(+) Low Learning Curve
PHP is easy. Darn easy language. Many, like this one, said that PHP allows non-programmer doing programming. That argument, I think, is the strongest point of PHP. The easiness contributes to hobbyist productivity, open source growth, thriving dot com startups, and students.
(-) Low Learning Curve
The same ease of learning curve, also contributes to another PHP limitation. It is difficult to teach discipline programming in PHP. What is the need of modern design pattern if having everything in 1 php file works well? In my mind, that’s similar to: why bother folding my clean clothes if I can throw all of them on the floor. I could probably find my clothes faster if everything is on the floor (floor == hash map).
Because PHP is easy to pick up, it clearly delivers, “something”. Whether it is a non-enterprise spaghetti or well baked web framework with fabulous arrangement, PHP accounts for productivity to its developers. Increasing productivity is obviously one good solid point of PHP.
But the same productivity can also be undone by PHP itself. Either because of the syntax, security, or many other things. These caused the very same developers to go back, unravel the mess that’s either self-inflicted or, unfortunately, imposed by others (e.g. middleware “enterprise” companies). The easy way to dodge this bullet is to passed on the mess to the succeeding developers, but that’s… lame.
(+) The Speed of Prototyping
As the productivity increased, the speed of prototyping will naturally increased as well. This is most definitely a good thing. Until…
(-) The Speed of Prototyping
The prototype gives developers the illusion that it is “good enough” for live deployment. Is it? A lot of prototypes I’ve seen weren’t born with unit-test that actually represent real-life use case (Really… writing unit-tests is not that time consuming). On top of that many were born prematurely. Most of the time, the answer is not.
There will be more bullet points, as soon as I could think of.
What I’m Trying to Say
The more I use & read Python, the more I’m exposed to this perspective. To some readers, hold on your horses, I’m not trying to brew a flamebait here.
This is not PHP bashing and Python is kicking-PHP butt type of posting. I still love PHP, I still use it a lot, & I’m still CakePHP fanboi.
What I am trying to say is that, being Pythonic can apply to any languages. While writing PHP application, programmers can still apply good design.
Being Pythonic doesn’t mean using Python, it means not repeating yourself in coding, keeping everything simple, clear separation between logic and presentation, overall simply good design pattern.
1. Even before I know Python, the similarities between my coding principles and Zen of Python is striking. Although I’m not 100% agreeing with “There should be one– and preferably only one –obvious way to do it”.
September 4, 2007 § Leave a Comment
Upon various drinking occasions with fellow developers, there are a couple of wisdom worth sharing about software architecture. Enjoy…
Don’t do some of them because James Gosling said so. Don’t do some of them because the book said so. And more importantly, don’t do it because your blue suit client demand you to do so.
Use design pattern technique based on necessities and careful consideration about the feature’s purpose.
Don’t just use design pattern that you only know. Depending on the requirements, sometimes you just have to learn new design patterns. Better start learning now rather than never.
Be very careful with it. Don’t over do it. Nobody wants to see 10M lines of stack trace.
Remember that the purpose of polymorphisms is to re-use parent object’s properties as much as possible. Extending excessively cause object’s behavior to keep changing throughout software’s life cycle.
Which one is really good for you? Is the company you are working for a JAVA shop? Is the application that you build need Perl? The answer of this question depends on what skills you already have. Unless, if you make an application for the sake of learning something new.
CakePHP is awesome by the way, but that’s me being a zealot.
If you think a framework sucks, is it because the framework really suck? or is it because you don’t want to learn it? or it’s because the learning curve was huge? It is best to stay objective when reviewing or using a framework, you might miss some awesome features.
Ain’t nobody cares about your choice of framework, as long as it get the job done.
Scale what? How to scale it? It is very important to be able to identify which part of the application that needs to scale well.
Between friends, the zealotry is fun (i.e. OS X rulez, Windoze sux) but in professional setting, this is bad. Not because it would make you look “unprofessional”, but because it will clouds your judgment.
Not everything needs to be Service Oriented Architecture & definitely not everything needs to be AJAX.
Ruby on Rails may be cool, it is actually so totally cool, but the performance may varied (depending on the Gems and many other things).
Sometimes reading Slashdot too much makes you think that all of your choices sucks big time. For example, client-side development requires AJAX, or Flash, or Java Applet, or Browser plugin. All 4 of them suck big time in different categories. Maybe it’s best to just pick 1 and read more API.
I think Java sucks, and becoming suckier in every upcoming version but it is de facto standard for blue suit jobs. If I’m starving, I will code in Java.
Debunking Old Myth:
It is true that IE 7 is still suck, but try opening IE 6… you will realized that the world had become a better place. In addition, Firefox was and is still awesome but the memory usage is still brutal.
Scriptaculous was great, but there are others which is flat-out better now, i.e. Mootools or Mochikit. Why I said that Scriptaculous was great? Browser memory is precious and Scriptaculous is not really efficient, new Effect is always creating a new object as opposed to recycling existing Effect object.
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 16, 2007 § Leave a Comment
& I cannot possibly express how excited I am.
Starting on Monday, I will be working for game company in Oregon.
I have yet to know what am I going to do in the new company,
but I can tell you for sure: IT IS NOT JAVA
Wish me luck guys.
May 25, 2007 § 1 Comment
is hella difficult to pursue.
When dreaming the web 2.0 dream, I cannot help but to felt discouraged. A lot…
But such is life, ain’t nothin’ is easy. If success is easy, then everyone is successful already. Pursuing such humongous dream, of course I do the usual routes:
- Bank in skills like mad because cool stuff are made by utilizing various skills.
- Learn and apply time management. Even at home, or at work, or at plain old day-job, or while working at that cool open source framework. There’s only 24 hours a day. I cannot possibly lose too many minutes a day dreaming.
- Being Frugal. Because Frugal is the new Cool in Web 2.0
But those are seemingly not enough. It’s really though to COMPLETE a dream.
Therefore, when I’m at my low points. I like reading stories about how other entrepreneurs do things. I never read self-help books, but experiences told by real entrepreneurs are believable and more importantly, REAL.
Below are compilations of good reads that I’ve read. Stay tuned because I will have more:
- http://www.littlehart.net/atthekeyboard/2007/01/02/just-build-it-damnit/ (funny, and straight to the point. Why is it on the top of the list? CakePHP, nuff said…)
- http://mingle2.com/blog/view/how-i-built-mingle2 (I gave comments on this one earlier)
- http://makeitbigingames.com/blog/?p=29 (This is more like for game developers. But if it works for games, it should work for web 2.0 as well)
- http://www.techcrunch.com/2006/01/09/dont-blow-your-beta/ (Interesting advice about Beta version)
- http://bnoopy.typepad.com/ (This guy created Excite.com and JotSpot. Beware: Most of these are old posts, but still fun nonetheless)
- http://www.paulgraham.com (Ahh… Paul Graham, the LISP guy. Entrepreneurship is nothing without his essays)
- Signal vs Noise (37Signals, the RoR champion. It’s always worthed to read their essays)
May 13, 2007 § Leave a Comment
is probably the most commented buzz-word in tech industry nowadays, especially by critics.
Within online community, we hear so much about “Web 2.0″. Their cool rags-to-riches stories. Their shiny, slick looking applications. As well as their spectacular failures.
Why people scoff “Web 2.0″?
- The fact that it is a widely used marketing buzz-word soured web 2.0 to the point of no return. Rounded corner and gradients are pretty much what people have in mind about “Web 2.0″.
- The fact that many of the founders have no business plan also worsen the image of “Web 2.0″, remember that dot-com bust happened not too long ago.
- In addition to no. 2, Google, Yahoo, MSFT, or even News Corp. bought all these new start-ups with ridiculous prices, creating disgusting odors of “Let’s get rich quick by making funky app! Who knows we’ll get bought by [xyz]“.
It saddens me to hear bad comments about “Web 2.0″. I like “Web 2.0″. I like it because of its simple formula:
- Host a CMS (Content Management System).
- Have a multi level permissions within the CMS.
- Allow registered users to Create, Read, & Update the content (based on given permission).
- Finally, Let the CMS to do 1 particular thing. Nothing more and nothing less (e.g. photo album, wiki, messaging, or personal profile).
The final point is what makes me attracted to “Web 2.0″. Simplicity. The application only offer features to specific targeted audiences. If there’s at least 1 good image about “Web 2.0″, it must be “non-bloatware”. The simplicity allows “Web 2.0″ to be cheaply produced. And that’s a good thing.
“Web 2.0″ is also fun to code because the application empowers internet users to produce, manage, & distribute digital products. Products such as articles, audio, or visual presentations (or hell, even online bookmarks).
The internet is not so foreign in the eyes of commoners anymore. Web portals and other overly complex applications are things in the past. Internet users don’t need to be guided anymore. What users really want is to get their task done as quickly as possible (online) with minimal interference.
When done right, “Web 2.0″ makes internet usage simpler and friendlier. Consumers associate themselves with “Web 2.0″ brand easier because of the targeted nature of its features. Also, because of the same reason, targeted advertisement can easily be done.
I love the core idea of “Web 2.0″. I love applications that make people’s life easier. On top of that, I enjoy reading the “american-dream-look-alike” start-up dreams.
If only more start-ups think about profitability…
If only more start-ups drop the idea of selling-out and get rich quick…
If only more start-ups care about their existence along with their users’ data…
I can only dream…
April 30, 2007 § Leave a Comment
April 30, 2007 § Leave a Comment
Here is the excerpt of the Zen of Python:
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
This might come across as a joke first time, but I found it more and more relevant to agile programming (& my coding style). And, totally applicable to different programming languages.
Now, let’s talk about simplicity and readability:
For example, in the JAVA world I keep finding myself swimming around Interface classes which only be used once. Or to be exact, this type of relationship: Interface -> Yet another Interface -> Yet one more Interface -> Abstract Class -> Concrete Class.
Obviously that drives me mad. This type of codes is clearly complex, whether such abstraction is intended or not that’s different story. But, in short, overly complex and disturb readability. Especially in debug mode. Imagine gazillion lines of stack dump, yeah…. you know what I’m talking about.
Another example, which one you prefer?
- Having polymorphisms of Entity Beans, each of the methods in them doing things slightly different…
- Or have a general ORM class, capable of handling all of those methods? (Of course in such case, you need to define the methods more carefully)
Obviously, 50% of earth’s developers prefer no. 1 and the rest prefer no.2. Either way would work, but
no.1. would have a lot more verbose stack dump. Depending on what kind of developers you are, too much verbosity might hurt your eyes.
no.2, if implemented wrongly, might hurt your eyes as well. But once implemented correctly, you always know that table_object.insert() always perform the same way regardless what kind of table_object you are talking about.
For people who have passion in building a product, getting it done as simple as possible is definitely the better approach. Thus, the Zen of Python would apply beautifully.
For people who work for big corporations, with zillions of legacy code and funky scalability… The Zen of Python might fail to guide you miserably.
In short, read the Zen… think about it… sleep over it… and try to apply it given your context. Who knows, you might have an enlightenment.