news
Yet another topic that I do not have a strong opinion or clear perspective: politics. I must say I am mildly interested and sometimes my interest heightens and then for months I don't even read newspapers. When I was in college, I used to devour the local newspaper from first to last page - everything from politics, economics, sports and local affairs. I was in no particular hurry in the morning to get to college, I could park the breakfast on to the paper and go through every inch. But after I moved out of there, I have never managed to read a newspaper or magazine from cover to cover. I can attribute that to a lack of care about what is happening around me (unless something drastic which demands attention), bulky newspapers which are very clearly meant for a serious study rather than daily news, internet newspapers which don't have a definitive path to follow (side bar, top bar, snapshots, summaries and in between a small strip of news strewn with links - I am compelled to click on something else before finishing one story) and news channels. The old way still seems better - I can just catch the 10 o'clock news, which will give me relevant news of the day - instead of a 24-hour news channel, which stretches the bits of news beyond imagination to fill in the time. I am tired of the expert’s analysis of statistics of past occurrences of hurricanes that seem to be going up from category 2 to 3 and back to 2.
I am still in the process of discovering the best way of reading news. Latest on that is rss feed - my initiation is with bloglines. But I would at least like summaries of stories, most sites give me headings and I don't want to click too many links. Since we have reached so far, I would like my customized news page with latest and relevant news from Kerala (not about thunder strike by postal workers and flood in Trivandrum bus station), Indian politics and business, cricket, British football, general tech and world news (no, for me, world doesn't mean just US). I think such a newspaper is not far away from making. I should be able to rate stories and say what I don't want to read about from tomorrow onwards and what I would like to monitor more.
Coming back to where I started, last when I had a little bit of interest in politics was during UK election. It was less entertaining than Indian elections where they will surely make me memorize and eventually gag over the name of the candidates by shouting through loudspeakers from morning to evening and putting posters in every inch of available space. I had to make an effort to learn the candidate's names in UK for local constituency. But then even they are becoming more of presidential election with 2 and 1/2 candidates and an enviably low number of major parties. I think the most interesting thing for me was multiple talk shows with the candidates themselves with opportunity for public to probe. It must be incredibly difficult for the leaders to answer all the questions (about education fees, immigration issues, taxation, international affairs, health, environment etc - I have to give them credit for attempting to answer). If not get a satisfactory response, you can at least make out which of them is genuine, still has a trace of sincerity and bit of intelligence. I don't think except for designated spokespersons, most of the ministers back home can perform well under that microscope.
Again, back to my original thought - why do I want to fill up my unused memory cells with obscure views about world peace? Maybe it is the process of my ageing. I think I really feel and want to know the real stories, but am tired of the very standard and pristine news products coming out of news processing industries - I don't want to read "Suicide bomb explodes in hospital - 20 killed." followed by a standard description about where and when it exploded, the counts and such. I think news is getting very unemotional and too high level to comprehend what is really happening. I no longer know whether anything is really true or just a publicity stunt or fed by the PR agency or staged hysteria. I think the current way is hallucinating, creating a world that exists mostly in paper. Lock us up and give a daily sample of celebrity gossip, terrorist attack etc - we might not even notice the change. But does it really matter whether the news is nothing but truth?
luck
Yesterday was a hot sunny day - there won't be many days like this, but being incredibly lazy about making most of it, I mourn the passing of each day. In the afternoon, I called an old college friend - main topic of these calls has become gossip about old classmates - who got married, who else is on the line, tracking people around the globe. Nowadays I wait for being in the right mood to call friends. Most of the times I am really not in a mood to talk to anybody at all. I think I can muster enough energy to call someone when there is absolutely nothing else I can do - when there is not even crap on TV and I don't feel like reading. I can even be a bit talkative then.
Anyways, I took the car to go out for shopping, still talking to him on mobile and got out to the single lane road out of the apartment. It was a 35 mph road and I must have hit the customary 40. Suddenly out of nowhere, a van pulled into my path from left. Within a fleeting second, I hit hard on the brakes, avoided the van narrowly, turned hard to the right to the sidewalk, before hitting it, took it back on to the road. I was surprised that I got out of that situation without a scratch. I continued talking to my friend, he wouldn’t have noticed any difference but if he listened closely, I think I babbled a bit for couple of minutes. It was a genuine “thank god” situation. Much afterwards I was happy with myself about my presence of mind and good reflex.
Later I was wondering how that pleasant afternoon would have gone upside down if I couldn't react fast enough or the van was bit faster or I hit a post or something. That feeling is the more dreadful than actually seeing the van looming in front of me. I guess all misfortunes like that hits pretty fast and we will be amazed how fast it will all be over.
Yesterday was a hot sunny day - there won't be many days like this, but being incredibly lazy about making most of it, I mourn the passing of each day. In the afternoon, I called an old college friend - main topic of these calls has become gossip about old classmates - who got married, who else is on the line, tracking people around the globe. Nowadays I wait for being in the right mood to call friends. Most of the times I am really not in a mood to talk to anybody at all. I think I can muster enough energy to call someone when there is absolutely nothing else I can do - when there is not even crap on TV and I don't feel like reading. I can even be a bit talkative then.
Anyways, I took the car to go out for shopping, still talking to him on mobile and got out to the single lane road out of the apartment. It was a 35 mph road and I must have hit the customary 40. Suddenly out of nowhere, a van pulled into my path from left. Within a fleeting second, I hit hard on the brakes, avoided the van narrowly, turned hard to the right to the sidewalk, before hitting it, took it back on to the road. I was surprised that I got out of that situation without a scratch. I continued talking to my friend, he wouldn’t have noticed any difference but if he listened closely, I think I babbled a bit for couple of minutes. It was a genuine “thank god” situation. Much afterwards I was happy with myself about my presence of mind and good reflex.
Later I was wondering how that pleasant afternoon would have gone upside down if I couldn't react fast enough or the van was bit faster or I hit a post or something. That feeling is the more dreadful than actually seeing the van looming in front of me. I guess all misfortunes like that hits pretty fast and we will be amazed how fast it will all be over.
Software Deployment
I read a bit on Environment Tests and Deployment tools and it got me thinking. In my mind if there is a picture of deployment tool, it is InstallShield. If I need to install an application in my PC, I would ideally like to get a package which tells me exactly which exe to double click to start installation (No, I don’t want to do 10 things before starting my installation), essential information I need to know (I don’t want to choose a thousand attributes which can be probably defaulted) and a neat and complete way to uninstall the application (it should remove every bit of itself – I don’t want to pollute my PC with unnecessary stuff). Now, the application I am developing can be deployed like this? Probably no. I assume my job ends when I have a perfectly working application satisfying all user requirements and more. Deployment should be easy and it is left to system administrators.
Deployment or Implementation would seem like an insignificant task for most developers. We burn so much energy into designing an application, build, test, fix and make it ready for the user to test it or to implement it in production – a minor problem in the implementation can create bad vibes for the product at the outset. In my experience, most often the initial implementation problems were minor in nature (as far as I am concerned) – it usually takes less time to fix and more time to explain. It is very frustrating for the developer than anybody else when somebody totally unaware of application starts screaming that it is not working! At least for the peace of mind, it is important to have the steps for installation of the product and the pre-requisite and post implementation tasks documented and as much as possible automated to reduce the risk of manual error.
In the systems which I have worked on, as soon as it goes for production implementation, system administrators take over the implementation tasks. It is like you go through all the pains of developing your baby and as soon as it is the delivered someone who may not even care as much adopts it. When it starts crying, they become angry and frustrated and you know exactly what it needs and you can only explain what to do. Suddenly you have limited access and you are required to guess what is wrong with it. A compilation sequence has gone wrong and a package did not get compiled or after implementation couple of packages became invalid and needs recompilation – just this much could make it unusable. That is probably one more reason for me to consider this step as important.
So far, in my experience, following were tried out-
1. Environment Documents: - Document every single bit (configuration file changes, directory setups) and keeping the focus that a third person is going to configure the system.
2. Installation Documents (Readmes etc):- Pre-requisites:- Make sure that everything which is needed to even start code installation is already setup in the environment; sequence of installation of various types of code. Post installation setups.
3. Automated Installation Scripts: - As much as possible automate. It will simply reduce the chance of manual error and you don’t have to answer any questions.
At this point, I did a bit of research and following are some points, which I may be doing, but not put into a structured thought process.
Other systems should still work after your implementation. We could be so much concentrated on getting our software installed on to the target machine that we may forget it already has something which may get affected by our installation. Make sure such impact is tested earlier.
Generating logs of installation: - Success as well as failure of installation should be logged and log should be verified before starting to use the system.
Pre-cursor steps: - Check whether instance is even ready to take application in. It could be multiple steps ranging from verifying application server setups, presence of database objects to checking whether required directories are present with required permissions.
Installable in multiple host instances: - Often we design the installation scripts knowing the target system specifically. If there is a chance of the scripts being used for multiple stages (probably user testing, acceptance, production type of scenario), keep the scripts and configuration documents generic.
Versioning could play a very important part in a system where continuous software upgrades happen to the system and the code base progresses through multiple stages before reaching production.
There are two distinct dependencies: - Run-time and Install-time. Just because of the files are installed successfully may not mean that application will work. It would require run-time configuration steps to be completed. It is possible to write a script to verify whether all nuts and bolts required for the application to run are already put in place. Another handicap for developers is, once application is live, you cannot run it through a set of test data and make sure that all its functionalities are proper.
Deployment involving change in system configuration could take backup of the existing configuration files and then perform the new steps.
Packaging the builds: - To refer to what version of the build is currently deployed, it is important to wrap the different set of sources into one (usually compressed format to transfer safely and completely) and refer using a naming convention. There could be initial installations, upgrade releases and hot fixes – depending upon the complexity of environment it may be useful to name the packages used in each case appropriately.
If the development and deployment teams are well separated, then complete transition becomes key to successful implementation. It is too easy for something to go wrong if the development team’s assumptions about what they are building is not documented and known to deployment team.
File-conflict detection: - Bit more advanced. This could make sure the existence of a lower version of the file when a new build goes into the system.
De-install scripts: - what will happen if installation breaks down in the middle? System can’t remain down until you fix the installation? If there is a chance of incomplete installation harming the host system and existing applications in any way, plan for it by keeping any de-install script or steps ready.
This whole process should be well integrated with the build process itself. If you wait till the last of the features are tested, close your books and hang up your boots and then remember to make up some installation scripts, first of all, it will be a grunt work and second, you probably don’t have any way or patience to test your deployment scripts.
Deployment plan (level of automation, mode of deployment, usage of tools) should be made well ahead. Typically, the race will be to meet the deadline for the development of the application, but on the designated day if you give hundred files to system administrators, it would probably take another week to get it implemented and effectively there will be project delay.
Deployment process could have following steps:-
Validates prerequisite dependencies
Checks for file conflicts
Executes and pre-installs scripts
Installs the files
Records the installed files in a database
Executes post-install scripts
The level of automation or planning for deployment will depend upon the scope of the project, frequency of upgrades, complexity of environment etc. It could range from simple readme for installation to full-scale deployment tool to be used.
There are variety of deployment tools available which I haven’t had an opportunity to use and have a prejudice that it will probably not meet 100% of my requirements and I may have to then find ways around it which will in turn reduce the effectiveness. But then again, it is just a prejudice.
References:-
1. Software Deployment and Configuration
2. Towards automated software component configuration and deployment
3. The Software Deployment Mystery – Solved
4. Agile Deployment: The View from the Inside
Deployment or Implementation would seem like an insignificant task for most developers. We burn so much energy into designing an application, build, test, fix and make it ready for the user to test it or to implement it in production – a minor problem in the implementation can create bad vibes for the product at the outset. In my experience, most often the initial implementation problems were minor in nature (as far as I am concerned) – it usually takes less time to fix and more time to explain. It is very frustrating for the developer than anybody else when somebody totally unaware of application starts screaming that it is not working! At least for the peace of mind, it is important to have the steps for installation of the product and the pre-requisite and post implementation tasks documented and as much as possible automated to reduce the risk of manual error.
In the systems which I have worked on, as soon as it goes for production implementation, system administrators take over the implementation tasks. It is like you go through all the pains of developing your baby and as soon as it is the delivered someone who may not even care as much adopts it. When it starts crying, they become angry and frustrated and you know exactly what it needs and you can only explain what to do. Suddenly you have limited access and you are required to guess what is wrong with it. A compilation sequence has gone wrong and a package did not get compiled or after implementation couple of packages became invalid and needs recompilation – just this much could make it unusable. That is probably one more reason for me to consider this step as important.
So far, in my experience, following were tried out-
1. Environment Documents: - Document every single bit (configuration file changes, directory setups) and keeping the focus that a third person is going to configure the system.
2. Installation Documents (Readmes etc):- Pre-requisites:- Make sure that everything which is needed to even start code installation is already setup in the environment; sequence of installation of various types of code. Post installation setups.
3. Automated Installation Scripts: - As much as possible automate. It will simply reduce the chance of manual error and you don’t have to answer any questions.
At this point, I did a bit of research and following are some points, which I may be doing, but not put into a structured thought process.
Other systems should still work after your implementation. We could be so much concentrated on getting our software installed on to the target machine that we may forget it already has something which may get affected by our installation. Make sure such impact is tested earlier.
Generating logs of installation: - Success as well as failure of installation should be logged and log should be verified before starting to use the system.
Pre-cursor steps: - Check whether instance is even ready to take application in. It could be multiple steps ranging from verifying application server setups, presence of database objects to checking whether required directories are present with required permissions.
Installable in multiple host instances: - Often we design the installation scripts knowing the target system specifically. If there is a chance of the scripts being used for multiple stages (probably user testing, acceptance, production type of scenario), keep the scripts and configuration documents generic.
Versioning could play a very important part in a system where continuous software upgrades happen to the system and the code base progresses through multiple stages before reaching production.
There are two distinct dependencies: - Run-time and Install-time. Just because of the files are installed successfully may not mean that application will work. It would require run-time configuration steps to be completed. It is possible to write a script to verify whether all nuts and bolts required for the application to run are already put in place. Another handicap for developers is, once application is live, you cannot run it through a set of test data and make sure that all its functionalities are proper.
Deployment involving change in system configuration could take backup of the existing configuration files and then perform the new steps.
Packaging the builds: - To refer to what version of the build is currently deployed, it is important to wrap the different set of sources into one (usually compressed format to transfer safely and completely) and refer using a naming convention. There could be initial installations, upgrade releases and hot fixes – depending upon the complexity of environment it may be useful to name the packages used in each case appropriately.
If the development and deployment teams are well separated, then complete transition becomes key to successful implementation. It is too easy for something to go wrong if the development team’s assumptions about what they are building is not documented and known to deployment team.
File-conflict detection: - Bit more advanced. This could make sure the existence of a lower version of the file when a new build goes into the system.
De-install scripts: - what will happen if installation breaks down in the middle? System can’t remain down until you fix the installation? If there is a chance of incomplete installation harming the host system and existing applications in any way, plan for it by keeping any de-install script or steps ready.
This whole process should be well integrated with the build process itself. If you wait till the last of the features are tested, close your books and hang up your boots and then remember to make up some installation scripts, first of all, it will be a grunt work and second, you probably don’t have any way or patience to test your deployment scripts.
Deployment plan (level of automation, mode of deployment, usage of tools) should be made well ahead. Typically, the race will be to meet the deadline for the development of the application, but on the designated day if you give hundred files to system administrators, it would probably take another week to get it implemented and effectively there will be project delay.
Deployment process could have following steps:-
Validates prerequisite dependencies
Checks for file conflicts
Executes and pre-installs scripts
Installs the files
Records the installed files in a database
Executes post-install scripts
The level of automation or planning for deployment will depend upon the scope of the project, frequency of upgrades, complexity of environment etc. It could range from simple readme for installation to full-scale deployment tool to be used.
There are variety of deployment tools available which I haven’t had an opportunity to use and have a prejudice that it will probably not meet 100% of my requirements and I may have to then find ways around it which will in turn reduce the effectiveness. But then again, it is just a prejudice.
References:-
1. Software Deployment and Configuration
2. Towards automated software component configuration and deployment
3. The Software Deployment Mystery – Solved
4. Agile Deployment: The View from the Inside
Subscribe to:
Posts (Atom)