Living in a Box

I have been in this business for a long time and one thing that is certain is the amount of change we go through. Each day one of our partners, or technology providers will introduce a new way of doing x,y and z and for the most part of the process I have gone along with the ride. Microsoft has been very guilty of shifting gears on technologies and many times even cornerstone technologies such as Data Access.

I have been to many conferences where I could hear the grumblings of developers crying about another thing they would have to learn, or how they just built something on a stack that has been made obsolete

Just recently we hear of the ‘death’ of Silverlight, a RIA technology and one that I quite like. We are also hearing the day to day tribal chants on how HTML5 is going to take over the world. Honestly I cannot personally see how HTML5 is going to have the massive impact and I still can see how the browser manufactures can fragment their implementations to that they are still somewhat incompatible.

But this post was not supposed to be a rant on the frequency of change, or that change happens but the joys of embracing the change. Most of my day now is spent on our consulting services and I do not get as much practical time just playing with technologies. I do read a lot so I know what is going on, and fortunately I am still quite skilled (if I say so myself) at getting in quickly and being to apply new technologies with little resistance.

I decided to get back into the play time with technologies that aligned themselves to what we do here at BITtelligent, so I have jumped into MVC3 with Razor, Code First Entity Framework, and more and more Silverlight. I have to say I have been excited with the outcome of late, especially with the productivity curve.

I really got excited with EF for several reasons

1. It was really quick to get up and running and coding the repository objects using Linq was a win over my old world SQL methods

2. It fits will with some basic integration needs in the SalesLogix space.

With SLX there are several people that have worked on Linq providers that can work against SData or the Database directly but for quick and running requirements that you do not want to carry the platform tax for EF Code First seems like the ticket.

So being said I am not a fan of the box, no sir I do not like it and I will be trying to keep out of one from now on and spending more time with learning, trying and applying the new stuff.

Don’t make your Web.Config stinky

I have this ongoing quest to figure out the best practices for creating customizations for SalesLogix web client that will not cause downstream pain come the time a new update comes from Sage. At times there are places that you just cannot avoid to get your fingers into but more and more I believe we should avoid altering the web.config file.

I know its quite easy to add extra app settings, or configuration settings there however doing so means the files has to be included in the check list when doing an upgrade.

From a standpoint of reducing the cost of future upgrades I am proposing that any of your component based configurations should use a separate file. Use the same naming convention as ending your settings with *.config to ensure the outside world cannot view it but store it inside of the app_data folder instead of root. I am also thinking that the configuration file should have a naming prefix such as <companyname>_<area>_settings.config this way new items can be provided/shared between business partners without worry of naming collisions.

I know that this deviates from the ease of use of the included .net configuration libraries but in the long run it makes the application more maintainable.

agree?