2016-07-09

Hello, World!

I assist a cloud project, storing company public data in a cloud app. Some of this public data should be imported into the company Intranet for convenient access of the company's employees. We will call a webservice requesting updates and then import them into the intranet. Since the cloud app provider has not yet created this web service I asked them to provide us with a web service responding with the classical ‘Hello, World!” phrase. With this webservice I could write a PoC, this was necessary since we and especially I had not done such a program before. I started by writing a Powershell script, but I could not find any good documentation how to access our intranet (I didn’t try that hard to be honest). I got the impression my Powershell script had to be executed on the intranet server, which I do not have access to. I switched to C# and .Net and wrote my first C# program (I got much help from a consultant).
Setting up the dummy ‘Hello, World!’ was a real smart move since it is rather complex to find your way through proxies and firewalls calling the right service provider with right parameters, receiving and interpreting the result updating the intranet, logging the event, do error checking and sending notifications if something goes wrong. Now when I had this complex dummy program up and running, the project leader suggest I should put this program into production. This was really clever, the intranet was hosted by another external service provider and we have not set up a similar program before. By moving the dummy program into production we would learn this process as well and when we have the final program ready we only have to substitute the program, this should be a quick operation.
So I sent my program to our internal development guys and asked them to help us move the program into production, After a quick quality review they handed over my program to the intra net service provider. Their response in italic:


First and foremost, what is provided is an executable and not a script so we cannot continue with the provided info/executable. - I was a bit surprised since I had supplied the source code and I’m happy to share the entire .net project.


There is no guarantee that what is provided/described in the post below is actually inserted into the executable. Moreover, it is a bad idea to stab "parameters" such as email addresses, mail servers and URLs in compiled code. Normally a programmer puts these in resource or configuration files so that it should not be recompiled whenever you need to adjust the parameters. - I was surprised they questioned the supplied executable was the right one, but since I supplied the source code they should be able to compile themselves. This was a first version of a dummy program with all hard coded. The current version I use the configuration manager e.g.
string info = ConfigurationManager.AppSettings["webRequest"];


Secondary we prefer this would be a PowerShell Script . It is easy to convert such into a PowerShell script because the syntax of C # and PowerShell are similar. But as the "developer" indicates "I have no knowledge of C # .NET or Visual Studio" ....Nevertheless we can provide help to convert from C # into PowerShell. If needed please inform me so I can request a quote to provide this kind of support. - I could not see any point in converting my C# to PowerShell script. (If you are afraid of .Net upward compatibility issues, I’m pretty certain that is nothing against PowerShell version hell.)


Furthermore, you will need to approve this request for the three different environments since the script for the three environments will be different. This because the parameters for each environment are different  (cfr. URLs) and you such cannot follow the DTAP model and so therefore you might face different behavior in production that has not been tested in ITE and staging. - ?

After replying the best I could to the the service provider's letter, I received a response that made me think it was a bad idea to put my program into production. E.g. the service provider thought it was a bad idea to test the program in the test environment, which I found a bit ‘odd’, I usually test programs in test environments. Anyway I skip this idea, I’m pretty good at conceiving ideas so I’m confident I come up with one to everybody's liking. I’m fond of PowerShell and now also .Net, in the end I might convert my C# to PowerShell even though it is awkward, normally you start with a quick script prototype and convert it to an executable for production. Our service provider seem to favour the other way around. And they indicate test,staging and production environment are so different you need to modify your program when moving between these environments, I question the value of testing at all.

No comments:

Post a Comment