Web 2.0 Entrepreneur

Develop like an architect, not like a cowboy

• Posted by Tengku Zahasman on May 16th, 2007 filed in Web Programming, Web App Development


• 4 Comments »
• (1,761 Views)

Few years back when I was still in University, one of my lecturer who taught us Software Engineering said, “Don’t be a programmer, be a developer.” I was a bit confused back then. In my head I asked, “What’s the difference? Don’t developers also write codes?”. I’m pretty sure the other students in the lecture hall were as confused as I was at that time. But now I know for sure that programmers and developers are from different planets.

In software development, there is a term called “Cowboy coding” which implies the method of writing softwares where the programmer start coding the application without doing any sort of proper “planning”. They just picture in their head how the application will look like in the end and start coding straight away…. do whatever they think is right. They hate planning. They think planning is boring and a waste of time. The idea of writing codes straight out from the head may sound cool, but in reality, applications that are written by cowboy coders are typically sluggish, full of bugs and very troublesome to maintain. I know this because I used to be one of them (in certain cases I still am, but well that’s a different story ).

An experienced developer will plan his project out before he even writes a single line of code. Knowing the basics of UML (Unified Modelling Language) is an advantage. Now you don’t have to plan out too detail until you had to prove the cowboy-coder’s point - wasting time. No. The best thing is to balance your planning phase so that you have a firm base to start writing the code. For me, I like to use UMLPad to plan for my project. It is a very lightweight program, free, easy to use, very straight forward, and eliminates the complexities of other more sophisticated UML tools like Rational Rose or maybe, ArgoUML. Since PHP is not really a pure Object-Oriented programming language, all you need before you start writing an application are:

1. a simple Class diagram - to define your classes/objects and the relationships between them,
2. an activity diagram - to define your application’s flow, and
3. a state diagram - to define your application’s behavior.

UMLPad provides exactly that. Alternatively, planning the traditional way (ie: sketching on papers or white boards) is also very recommended because many finds it to be more comfortable and allows us to think out of the box. What about the rest of the diagrams in UML? No need to worry about them for now. Is UML hard? Trust me, UML is just common sense. Do you need to plan in detail about everything? If you can do that very quickly, go ahead, but you probably don’t need to. Remember, we don’t want to waste too much time on planning, but we also understand that no planning is planning to fail. So if you respect yourself as a person, be a developer who plans, not just a programmer who cares about nothing but codes.

Should you build localized or international web apps?

• Posted by Tengku Zahasman on May 10th, 2007 filed in Web App Development, Advertising, Thoughts


• 8 Comments »
• (1,153 Views)

Local web applications

Local web apps means the applications are focused and meant to be used by only some people in certain countries or communities, not meant to be used by the general Internet users everywhere. For example, if I am to build a localized web application, it may be something that only Malaysian users would be interested in using. Such app could be a Malay-based search engine that searches for only websites in the Malay language. Or it could be something like a video sharing portal - like YouTube - but only focused on Malaysian-made videos.

The good thing about localized web application is that it can get famous pretty quickly. People like something if it is close to themselves. You don’t need to put massive advertising to promote your web apps because word-of-mouth advertising will efficiently do the trick for you. Malaysian-specific web apps like Tumpang, Advertlets and Nuffnang proved this is true.

International web applications

International web apps on the other hand, can be used by anyone regardless of who they are or where they live. MySpace is a good example. Everyone can use it and it doesn’t specifically mention if it should only be used by, say, the American people. In fact, many big Web2.0 companies targets the wider audience - everyone. But unless you have a pretty damn brilliant idea, promoting an international web app can be quite tough as you need to reach for more people.

So which one is better?

Localized app give you fame very easily. But the fame you get is focused only to some geographically centralized users. If your international web app becomes successful, your credits will be recognized internationally. Localized app can pocket you money a lot faster, but international app is where the big bucks are made. If localized web apps can give you 10k a month, international apps could possibly give you a 100 times more, but that may take patience and longer bootstrapping. Making your international app a success takes more effort, and usually means needing more capital to do the marketing. Localized web app is way cheaper.

My point is, both local and international web apps have their own strengths and weaknesses. If you’re still new, maybe it is wise to start with a localized web app. Apart from giving you the good portfolio you need, it’ll also give you the experience of running a web2.0 application in a smaller scale. This can prepare yourself for your next international web app idea. Not only that, because localized web app needs less money and gives you cash faster, it will be the one to support your international web app developement that needs more money, more dedication, and more time to give you the wealth that you and your team are waiting for.

Craft and optimize your friendly-URLs

• Posted by Tengku Zahasman on May 8th, 2007 filed in Web App Development, SEO


• 1 Comment »
• (1,387 Views)

Using friendly-URLs in your web application is essential when it comes to SEO (Search engine optimization). Friendly URLs (or some might refer to it as “Clean URLs” or “Pretty URLs”) help search engines’ crawlers to read your URLs and understand better what the page is mainly about. It acts as an additional option to look for keywords apart from looking in the page’s content itself.

There are a few strategies of how people make their friendly URLs to look like. Consider the three examples below:

1. Using IDs without descriptive keywords
http://www.domain.com/items/23 <– that’s the ID of the item in the database

2. Using descriptive keywords without IDs
http://www.domain.com/items/the-name-of-the-item <– (eg: a blog post’s title)

3. Using both IDs and descriptive keywords
http://www.domain.com/items/23/this-is-the-name-of-the-item.html

Explanation

#1 doesn’t explain much…. so while it is cleaner to the eyes, it’s not really friendly to the search engines’ crawlers. You lose a lot of points by not utilizing keywords in your URL to describe your page item. However, this technique is not all useless because for links that doesn’t need descriptive URLs (eg: when doing paginations), this technique can be pretty handy.

#2 is what most people like to use for linking items. The idea is to make the URL “very friendly” so that every part of the URL is descriptive and contains only keywords. No numbers. No IDs. However, this is gonna bring some problem because by using this technique, the application will search for the item in the database based on its name, not the ID. It takes out the slug “the-name-of-the-item” from the URL, chop it, slice it, and then use the string to search for the exact name of the item in the database. What if in the future you decided to change the item’s name? At that point of time, the application won’t be able to look for the item anymore using the old URL. And this is not good. Because if your URL has already been indexed by a search engine, or if someone has linked to that item from his website, users who click on the link will reach an “Object not found”, unless they use the new URL.

#3 is my favorite technique when creating friendly URLs and one that I recommend the most. Always include the ID. And always use the ID to look for the item in the database. The keywords at the end just describes the link. It doesn’t need to do anything else. This way, not only you save time (because you don’t have to write codes to slice the URL and look for the item based on the name), you also ensure that the item will be reachable no matter how many times you change its name. Afterall, that’s the main reason why people create IDs in the first place.