I am working on automated builds for our projects. I am quite excited about it, since it feels like taking back the power over the creation of the code. Not only that, the ‘auto-magic’ dissolves ones you do it manually and things become simple. You run the script, the script is failing, you need to fix the issue and you want the issue to be simple in order to A) locate it quickly B) fix in the least effort applied.
Combining client-side with server-side, coping with multi-browser support, handling imperfect world of CSS , implementing the code the best way you can relaying on patterns and principles with legacy code kicking around, keeping up with the pace of changing, facing clients that are not ready to pay for the quality, dealing with team mates that are still loyal to procedural code order and married to databases, yet not over-designing is more than just agile. My definition of this is going on the edge with agility in mind. Or just Edgility.
Just finished reading Agile Principles, Patterns, and Practices in C# from Robert and Micah Fowler Martin. A definitely recommended book. Some stuff is not taking advantage of the .NET (not using generics where could do that, Visitor pattern for example.
Next book - Domain-Driven Design: Tackling Complexity in the Heart of Software. What else would you recommend that would fall into this category?
I was following the development on Script# CCC was developing. Sounded like an interesting idea of getting closer .NET and client-side JavaScript. Today found a link to MS experimental project called Volta (hmm, I wonder what will happen if you dare to touch it, same that happens to many experimental projects - a moment of joy and a big shocker at the end? :)
In my previous blog I was looking how to enable MbUnit with MSBuild from visual studio. As nice as it is, I was missing the flexibility and options of going beyond unit testing only.
After attending “Nothing But .NET” training session help by JP Boodhoo in Calgary, I was more aware about option of using NAnt and CruiseControl.NET in the future for potential Continuous Integration.
So why NAnt? Several reasons:
While reading materials about how to improve my OO code / design, I run into “Tell, Don’t Ask” principle. Interestingly, I also have read this article and realized that I am still thinking as a procedural developer. But then I got confused by the idea - you can test the interactions, but how do you test the state if you trying to eliminate any trace of state from the object? Does that mean that state base testing causes to violate TDA principle?
One of the web applications requirements is to provide a rich user experience. Client side validation and formatting is a part of this UX. The subject I want to address today is how to achieve a good level of UX on formatting with respect to one of the OO principles, DRY principle.
The case is simple, user can edit multiple date inputs, that are reformatted right away. The screen would look like this:
The training session I took with JP Boodhoo “Nothin But .NET” was awesome. Was quiet surprised that a variation of this course, “Nothin But .NET Fundamentals” is not sold out yet. If you are anywhere near to College Station TX, and want to know what high-end fundamentals are - register to this training session.
JP is a great guy and an awesome trainer. If you looking for challenge - you will get it. Fundamental will never be the same after you go through the session.
This post is not going to be technical at all - pure theory of how to generate a change in minds of those who cannot accept what agility and test driven development are proposing.
One of the biggest questions is “why”. Why would someone bother to code to interfaces, if could deliver a working application without it. Why to have the hassle of creating test first, interface and then concrete implementation, going through enormous amount of code changes, if you can code the class, and in ‘worse’ case extract an interface ‘just-in-case’? Why to give a method a fluent name and worry about simplicity, if you can ‘dig the code to see what it’s doing’? Why to bother test in isolation, if you can do the integration test. Hell, why even to bother doing integration, let the user do the testing…
User Controls are handy when working in web forms, but what a mess they can generate. I was asked what to do when UCs are used and some dependencies need to be injected during the construction - but UCs are a bit tricky in regards to construction. So the possibilities are:
Use new operator and instantiate a user control (Web Application Project) - no good as the visual elements residing on the designer surface (.ascx) then not loaded.
