First, an apology is in order, I have to admit I've been on blogging hiatus for over a month, and hopefully you'd understand that my enthusiasm for blogging has not waned. My blogging hiatus is just that, a brief hiatus (and tons of events happened since then, like I'm in between jobs as of this writing, enjoyed the Westlife concert with my better half, had an opportunity to step back and see where I am and where I want to go to, Apple's Steve Jobs passed away a day after my birthday, and most importantly, got me Dr. Dobb's Essential Books on Algorithms and Data Structures CD-ROM Release 2 CD as gift for my birthday from my youngest sister), and what better way to blog actively again than to talk about my favorite IT infrastructure, the database system (could even be the most important!) and since I'm currently in between jobs, about hiring IT professionals.
But first let me relate an incident about a friend's newly bought desktop PC, built from choice components, you can consider this computer a bazooka to kill a fly off the wall. The problem was that my friend later updated the BIOS firmware and the new PC has since had mysterious behavior like shutting down for no apparent reason. In short, that BIOS firmware upgrade cost my friend wasted time bringing the rig to the shop to be fixed, good thing the PC is still within warranty and replaced. Moral of the story is: if it isn't broken, you have no reason to fix it, so don't mess with it, same goes with the database back-end of your application.
Never Mess Your DBMS
As far as systems design go, building a dynamic web applications on a tight budget seems to follow this modus operandi: get LAMP, also known as the Linux, Apache web server, MySQL and PHP development stack, and you're set. You can bet your wager on Linux (depending on the distribution), Apache web server and PHP (depending on the version for various security and performance fixes), but my gripe is on using MySQL. I may sound like regurgitating my previous article advocating PostgreSQL over MySQL, on the contrary, focusing on what MySQL is and what its current project host's business is as of this writing, sad to say but MySQL will never be at par to PostgreSQL simply because doing so will potentially erode Oracle's bottom line.
MySQL will always be a free database management system (DBMS) that should have limited features to serve as a basic system that Oracle can use to attract the developers and implementers with while leaving much to be desired so that we will always pine to upgrade to some other more powerful database management system, Oracle hopes you switch to their proprietary app stack.
Maximize Your DBMS Investment
When a computer-based solution was initially designed, the idea that we design the database back-end with the objective of moving to another DBMS when opportunity comes isn't realistic and utterly mistaken presumption: using a DBMS would require familiarity and thus training, and this is usually costly.
Moving to and training for another DBMS can and will always have economic impact. There are also differences in how each DBMS behaves or implements a certain feature (i.e. concurrency) in relation to established standards, and these differences could be perceived by the system user as inconsistent behavior of the whole application. It's best you research for and get the best DBMS you can get within your budget (wanting to get Oracle, MS SQL Server or DB2 if you can't afford them isn't smart nor practical), develop around it and stick with it. Since I prefer free and open source tools and technologies, one tool I have used and would recommend for DBMS-related design and development is Druid.
Since often the practice is that DBMS is considered a black box, why not have the functionality of the application's domain model be relegated to the DBMS itself as stored procedures or function? Testing using mock objects on domain models will then be further simplified or avoided altogether since the application view(s) and controller(s) communicate with the domain model only through specific Application Programming Interfaces (APIs), thus the input and output of each domain model API is definite and supposedly unambiguous. Speaking of ambiguity, in the IT industry, uncertainty is most obvious during the hiring process.
Tragedy of Hiring IT Professionals
As of this writing, being in between jobs may be viewed as tragic by some, but it presented an opportunity to observe the anomaly of the job hunting and hiring process.
Why can't the companies just express what results they want to produce and pool answers from people they may deem as candidate for the post? This way, the company gets chance to hire staff(s) who understand the company concern and needs. As for the hired, they know what issues they have to tackle and thus know how to best contribute to the company. In a previous employment, the employer was supposed to hire me as an MS Access developer, but when we discussed their needs, it turns out it can best be realized using another technology, specifically free and open source software.
It's supposed to be not only on whether you know a particular tool, it's seeing the bigger picture like a radar aside from the view on the microscope provided by particular platforms, methodologies, application development frameworks and systems or server management tools.
I'm thankful for the opportunity to have a free time now, to step back and have a fresh and motivating perspective towards work and life. Now I'm ready for the next challenge.
No comments:
Post a Comment