- Recent
- Popular
- Tags (0)
- Subscribers (1)
- VS.Net template for Test Driven DevelopmentApril 12 2007
-
I've found this template to be very useful for codegen TDD classes for me.
http://blogs.ipona.com/dan/archive/2007/01/02/SimpleTDDVisualStudioTemplates.aspx - Jay Fields Thoughts: Ruby Form Template Method Using ExtendSeptember 20 2006
-
Jay Fields Thoughts: Ruby Form Template Method Using Extend
One of Ruby's feature is the introduction of 'mixin' as demonstrated by Jay's article.
I have a mix feeling about using this feature (no pun intended). To me mixin sounds too close to global function as popularized by language such as C++.
In C++ you can use this "global" function in your class with the right syntax and inclusion. Obviously one would argue what's so bad about that. In the beginning if you have small codebase maybe the drawback is not as obvious, but maintaining this type of code years from now could be hassle in my opinion.
I guess what I'm trying to say things could go out of hand quickly by incorporating this practice. - Suzanne Cook's .NET CLR Notes : New Assembly, Old .NET (and Vice-Versa)August 15 2006
-
Suzanne Cook's .NET CLR Notes : New Assembly, Old .NET (and Vice-Versa)
To load the assembly compiled using the previous version of .Net framework such as 1.1, or lower, from a .Net 2.0, you don't have to do any extra effort.
However, things are not the same the other way around, to be able to load a .Net 2.0 assembly from a previous version of .Net you have to add this into your App.config
<startup>
<supportedRuntime version="v2.0.50727" />
<supportedRuntime version="v2.0.50215" />
<supportedRuntime version="v2.0.40607" />
<supportedRuntime version="v1.1.4322" />
<supportedRuntime version="v1.0.3705" />
<requiredRuntime version="v1.0.3705" />
</startup>
This will allows such case, assuming you have the required version of .Net and the supported runtime version of .net 2.0 - Data SegregationJuly 28 2006
-
Enterprise applications usually use some type of framework to support their underlying applications. Framework can vary from a simple reusable components such as a Math library to a more complex solution such as a mechanims to handle Messaging, Security, etc. Some of the more complex framework requires access to external data storages such as database or a queue, etc.
There are two options on how applications code deploy with this framework's external resouces. One solution is to share the framework's resources amongts all applications, thus data specific to those applications will be stored in the same storages/tables.
The other solution is to store data specific to the application into its own database domain, thus creating a physical boundaries between different applications.
There are pros and cons of both approaches which I will discuss as follows;
The benefits of using the same physical storage for all data are:
- Easy to implement
- Development/Support teams will only have to look at one place to find the data.
- Easy to maintain from the sense where update to data schema will only need to be applied in limited places.
The disadvantages of such solution are:
- Data from different applications are tighly located in the same place.
- No way to protect the integrity of the data of other applications, since different team could potentially affect other team/application data.
- Depends on - #region ... #endregionJuly 7 2006
-
#region my rant
Microsoft introduces a keyword #region ... #endregion that supposedly can be used to organize "like" codes into itsown region.
However, lately I have been encountering that it's also used as a somewhat of an excuse to have big classes. Somehow the use of #region makes it a little tolerable to have big classes.
I don't know if this is what Microsoft intends or not, but it's clearly not an appropriate solution to say the least.
The problem with big classes not only because it's not pretty to our eyesight, but there are some other basic problems with them:
1. Big classes are usually hard to test.
2. Big classes are usually error prone, because regardless of how we divide it up in regions, we still have to understand details of the class, and most humans usually comprehend things as smaller chunks better than one large chunk.
3. The use of region itself should have triggered the fact that the class might have low cohesiveness, thus they could be broken up to smaller classes.
The problems with region are:
1. It's another thing that we have to maintain to make sure things in the region are all "related", I have seen many times, that region starts out well but become "stink" over time.
2. Who's deciding what region to create, which code should go to which region, etc. This is left to each developer interpretation, should we have code review for the region ;-)
#endregion my r