|
[ Previous entry: Foxpro and CSharp ] [ Next entry: Meet IKIA ] 02/23/2004: IMCS.CPanel.DataTransfer Module 02:08AM. Unholy hour for some... but for me this is the holiest of holy hours. Every thing's calm and at peace and I can code the way I want. Of course there are those times (especially when the sun is up) when I would prefer coding when U2, Paul Oakenfold, Enigma, NIN or even the soulful music of ColdPlay pounds in my ears... but when the sun decides to dream, I prefer silence. Ah... enough of these things. I did promise myself to concentrate on work blogs once more. To discuss more programming/freelancing/system-analysis-related issues and insights would be the priority. The info-links you used to see will still be there, probably underneath each 'work blog'. So what have I been working on for the past few hours? IMCS.CPanel.DataTransferModule What in wakahalarovha's name is that? IMCS stands for Integrated Media Center System and CPanel for Control Panel. Like most control panels you see in this world, this module aims to give the user the 'lowest level access' to some core parts of the program. Most settings and configuration are in there. One of my measurements on how 'good' a program/system is, lies on how it can stand alone independent of the programmer who created it. If it can run for 7 years or more without my intervention, the hacker-part of this soul would be lust-ified. That is why the CPanel is there. Of course certain 'outside factors' like operating system variables, upgrades, environment, meteorites, non-thinking management and millions of other factors, pose a great challenge to that 'independence'. Include some marketing related factors too. But, that would be another blog for now. It has been my practice too, to make the database systems I develop compatible with a certain client's other existing database applications. And since the Registrar and Cashiering (which involves different student information-related modules) are already handled in four of my clients by another software development company years before me, I made the Transfer Module as a means to export their databases to my database applications. Of course I could make use of their database directly inside their own folders, but I prefer using my own re-structured database for a number of reasons. One's to be safe. If something happens on their part of the application, the database applications I am maintaining would not be affected. Same holds true the other way around. If corruption or any variation of those things happen, their system would not suffer. And trust me when I say I don't want a fellow Foxpro programmer to suffer... especially in my own hands. Second reason is I am very particular with how I name the fields, the name formats and such. If you maintain several programs, it would be good for you if you're using your own easy-to-remember conventions which would be hassle-free for you to recall once you switch on your development process to and fro from within your tasks pool. Third reason involves the way I normalize fields and records. Fields such as Relative01, Relative02, Relative03 and so on is a big no no for me. Well, at least most of the time. This would be a different story though if it is a RelativeGivingOutiPodsandG5sToDevelopers. If this is the case... the more the merrier applies instead. But following a database system that is not yours is not that easy. Even if both systems are developed in Visual Foxpro and you're only scratching the database parts. For one, the other database programmer can change the structure of the database at any point, and you, like me, find yourself re-coding some parts of your program, which in my case, the Data Transfer module. These occur too especially if the other software development company has more than one programmer who seems to juggle with their field naming convention. CLIENT_01 uses MTELNO and FTELNO for their parent's phone numbers. CLIENT_02 on the other hand uses MBTELNO and FBTELNO where I suppose 'B' stands for Business. Client_01 don't have equivalent names for those fields. And in this digital world, one bit makes a BIG difference. Last June, I also found myself in a position where another database structure was change and I cannot even edit it until I open the database exclusively. A feature which I should be adding on the Database Utility Module (equivalent to Clipper's DBU) I made. A utility which I will discuss further in another blog... in another time. ··· Good luck, Arctic Team... may you find what you've been looking for. Same shout outs to Cassini and the Mercury Messenger as well (472 million dollars for 7.9 billion kilometer journey eh?). Aloe vera may treat battle wounds. Nah... I prefer peace, unity and discussion. Deal with things the way 'good' programmers handle problems. War was never a solution... and never will it be. How come we never learn from the past? Make way for Doom's Day instead. Mark Anthony Panizales is now bloggin'... and Ceazar Ryan Sealana too. If you could remember they were part of the first call-to-blog post of mine. I'll be posting a second batch of roll calls within the week. Looks like SCO gets it. I don't get it. Nevermind. Happy birthday, Neil Armstrong. Disclaimers are for castrated EARTHLINGS. Powered: GREYMatter | GM-RSS
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
