Fuck It Principle

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.

References:

So much loving and hating with PHP

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).

(+) Productivity

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.

(-) Productivity

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.

Notes:

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”.

Some of my thought about Software Architecture

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…

Design Pattern:

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.

Polymorphisms:

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.

Web Frameworks:

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.

Scalability:

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.

Software/Jargon Zealotry:

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:

Just because Javascript/Flash used to sucked, it doesn’t mean that both will stay suck.

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.

Resource:

IBM – Best Practice for Web Developers

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”

I’m leaving my job…

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 :D

Wish me luck guys.

The dot com dream…

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…

The discouragement came when real problems arose. Whether it’s the database mapping that’s overly complicated (making searching difficult), or “way-over-the-top” JavaScript UI that I couldn’t create…

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:

Web 2.0…

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″?

  1. 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″.
  2. 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.
  3. 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:

  1. Host a CMS (Content Management System).
  2. Have a multi level permissions within the CMS.
  3. Allow registered users to Create, Read, & Update the content (based on given permission).
  4. 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…

Where Am I?

You are currently browsing the pragmatic programming category at RAPD.

Follow

Get every new post delivered to your Inbox.