Archive for October, 2009

A Stitch in Time

Friday, October 30th, 2009

There is an old saying “A stitch in time saves nine.” What it means is that if there is an issue, if you address it early, it’ll take overall less effort than addressing it down the road. This is saying applies not only to stitch, but to programming as well. Employers should be wary of creating an environment where employees are concerned about asking questions. A hostile work environment might cause the worker to avoid any questions that can clarify the task at hand. That can ultimately lead the entire project off course.

That being said, while it’s great to fully trust your employees to do the task you’ve assigned, communication is extremely essential in an organization. If you didn’t communicate your desires clearly, or if your employee didn’t fully understand what you’re saying, that can also lead the project off course. Which is why you should check in with your employee every now and then to see if he has any questions or to get an idea of where the project is at and where it’s going.

If you have the choice to either spend 5 minutes to fix it now or spend 3-4 months fixing it later. Spend the 5 minutes now.

View Point on Frameworks

Saturday, October 17th, 2009

The way humans get computers to do what they want is through “programming” and we program in a “programming language”. In a way, it’s how humans communicate with a computer. When I program, it’s more like talking to a computer than anything else. Talking is what keeps me clothed, fed, and sheltered.

In English, you say whatever you want in any way you want. You can even redefine what words mean. In a programming language you have a similar freedom.

A framework, on the other-hand is a self-imposed method of doing things. In order to do anything within the framework, you must follow these constraints; otherwise, it can’t be done.

Why would anyone voluntarily limit their own freedoms? The answer is collaboration and consistency.

The downside of a framework is the need to remember what these constraints are. The upside of a framework is that through such constraints, you know exactly where a file should be located, how things should be called, where things should be placed and etc. A person who jumps onto the project who is familiar with the same constraints would also instantly know where everything is place, how to place everything, and etc.

When using frameworks, developers should be careful that we don’t over customize the framework. Over customization will cause new developers who know the framework to be unable to find all the things they would need to.

I love frameworks for mid-scale to large scale applications, but I find them unnecessary for simple scripts.

Handling File Storage

Thursday, October 8th, 2009

When you’re writing a massive application, if given a choice to use a file manager to manage files or to allow the application to manage the files on its own, it’s much preferable that allow the application to handle the file placement logic. This way, the application’s database can be put in charge of maintaining the file locations ensuring that there are no conflicts and that there is a centralized location to find everything. When an application is maintaining the files, there isn’t even a need for a descriptive name to a file, since all relevance will be maintained by the database. Since you’re only interacting with the files through the application, the application can ensure that the file exists, the file won’t be overwritten, and upon deletion, there are no dependencies on this file.

In the case of major applications, where it’s possible for many components to have access to the same files, I recommend that all these interactions be performed through a centralized file management core. This way, if we were to change the file management logic, it can be easily performed at a single location.

Data Inside a Database

Tuesday, October 6th, 2009

Data inside a database should always be post-processed and ready-to-use-as-is. If you can rely on the data provided by the database to be usable as is, then you’ll save yourself a lot of string processing work. Think about it this way, if you have a string, let say “orange” and it’s stored in the database, and you had another string called “apple”, along with other fruit based strings stored in the database. When you do a search for these fruits, you can specify a where condition and then the fruit the name. Even with for usage, you can use the fruit name as is. Whereas if these strings had all these weird characters in it, “orange\’s” and “@pples”, then the where statement will no longer be as effective. Not only that, during run-time, you’ll have to have code to handle these weird characters appropriately. So if you’re ever inserting data into the database save yourself some problems in the future by ensuring that the strings are properly processed.