Bits and bobs

I recently stumbled on Knockout. js http://channel9.msdn.com/Events/MIX/MIX11/FRM08 , watch the video, its gives a very good demo of how to use it and why. It seems to integrate well with MVC and jQuery . I have always felt the Javascript component of an application is always the messiest. Knockout. js tries to fix this by using MVVM patter in javascript to consolidate binding to the UI. I think this has a potential to be a great addition to any developers tool belt. Here are some links to PM pattern and MVVM and its usage. http://msdn.microsoft.com/en-us/magazine/dd419663.aspx http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx http://martinfowler.com/eaaDev/PresentationModel.html

I recently started working on a SOA project, and thought it would be a good idea to brush up on my WCF understanding. and I came across this article WCF Service Binding explained . I never really understood how to use the different bindings available, and I always tended to choose basicHttpBinding or wsHttpBinding as they most closely resembled what I used to know as web services. however, Thumb rules in choosing endpoint' binding If you require your service to be consumed by clients compatible with SOAP 1.1, use basicHttpBinding for interoperability If you require your service to be consumed within the corporate network, use netTCPBinding for performance If you require your service to be consumed over the internet and the client is a WCF compatible, use wsHttpBinding to reap full benefits of WS * specifications If you require your service to be accessible only in the same machine, use netNamedPipeBinding If you require your service to be queue messages, use netMsmqBindin...

In my previous post I talked about the database, and some of the hardships we encountered during this project. Now I would like to go through the application layer and describe some of the critical areas which hurt us druring and after the development. Web UI Architecture I think there is a beautie in simplisity which is offten mistaken for lack of experience of expertise. I think this was the key driver for much of the core designs used in this application. Our initial requirement document stated, the site must be built using web parts, and it described in great detail how each of the web parts interact with each other. However, no thought was given to how this would be used by the end users, how was this going to solve the business problem, how was it going to be utilised to benefit the end user? Only once most of the application was built was a thought given to the end users, and how this architecture would work. It became clear the solution was Technology driven rather then busines...

I recently finished up on a project which has seen some troubled times. I think it is very important to stop and think about what did work, and what didn't work after a project is finished (or near finished), and get some pen to paper so that the memories do not fade (along with key learning's ). Starting right from core of the application, the database. Right from the onset, the client was driving the database design. We put up a few questions and concerns, but as the client was very insistent that we use this design as it was the same design used for another similar project, our hands were tied. In retrospect, this was a critical mistake, we really should have done some analysis on the types of issues we could have and explained to the client what our concerns were on a factual basis. I have never seen this before, but if the database is over normalised it can get quite complicated, and bit you very hard when you start look at performance. Logical Model Vs Physical Model...