Published on August 23, 2006
in How To.
You won’t regret installing CCNet…
You might wish you had never heard of the f@#)#()@#ing thing a little
whilst you are trying to get the m@#)#()@#ing thing to work.
But *after* that you won’t regret it.
(c) Software PM
There are several things that can speed up the development process via the automation. Basically here comes the principle “if the machine can do it, then let her do it”. Machine time is much cheaper than developer’s, after all.
Build delivery
If CCNet and NAnt can do it, then let them do it instead of assigning some person to do that. And then you can do releases as often as you need them.
Database management
If database deployment for testing/release purposes can be done automatically then it should be done this way.
Integration testing
If CCNet, NAnt and NUnit can perform some testing and email you report when some code commit breaks the system, let them do it. Continuously.
It would be a nice idea to run those integration tests on a “clean” db first and then do another run on a database filled with some sample data.
Proper tools
If you have to work with C# then get yourself a Resharper. It just boosts your productivity up. Instantly. Period.
Published on August 3, 2006
in Articles.
The greatest programming project of all took six days;
on the seventh day the programmer rested.
We’ve been trying to debug the !@#$%&* thing ever since.
Moral: design before you implement.
(c) Usenet
Microsoft Composite Application Block is a really nice guidance asset to the world of creating feature rich smart client applications (those are words from the MS))). This is really a nice set of files and documentation that was created to provide developers with a guidance framework that utilizes some common real-world practices of creating GUI applications with complex and yet modular structure. This introduces separation of different application layers, ability to develop, implement, test, distribute and maintain application modules in a separate and yet unified and reusable manner. Sounds great to me. IMHO, there are some problems with the MS CAB:
- It has quite a learning curve (all this code injection, MVC-MVP pattern implementations, WorkItems etc are way to much to get over within a day)))) However the time spent on getting yourself familiar with this AB is a wise investment.
- MS CAB is a solution that tries to be universal. As we all know Jacks-of-all-trades never perform that well in specific application areas. A great try, however.
- Using strings to reference different items feels quite weird. We’re in the modern world of IntelliSense, compile-time checking and LINQ, after all )))
- Item number 10 in the License agreement of the MS CAB states “That you may run the Software or modifications only on the Windows platform“
Now here’s why this last item in the list bothers me. Mono seems to be the natural target for the application of MS CAB. It is even possible to get over that “you have to use Gtk# instead not-that-portable Windows.Forms” disadvantage with the Mono+CAB combination. However, Microsoft does not want to do that (either intentionally or unintentionally). So, the only way to reuse those guidance assets within Mono projects to rewrite the code (we are not talking about running mono-compiled application on windows only, are we?))). We’ll have to “port” ObjectBuilder and CompositeUI adapting those for the specific (and yet generic enough to be profitable) application areas. CompositeUI.WinForms, on the other side, has to be rewritten almost completely using the Gtk# and some type of “common building blocks” approach). That’s enough for today’s studies. I’ll get back to that topic of Mono+CAB later.
Latest Comments