From now on, all .NET related posts can be found on my new devlicio.us blog, which can be found here.
Head over and read the main feed - there are some great articles up already.
Filtering RSS feeds
The other day I had the idea that being able to filter high-volume RSS feeds would be very useful. I started developing a solution, but tonight I realised I hadn't checked if anyone else had the same idea. Googled and, yes, many others had. Most of them provided simple keyword filters (inclusive) which is, frankly, crap when you put that function in context. Take, for example, MSDN Blogs which generates at least 100 posts per day (less on the weekend). This is the conglomerated feed of all MS tech blogs. To apply a keyword filter to this is useless, since the whole reason I read it is to keep up to date with the Microsoft world. Filtering by such a precise method will cause many interesting topics to go unseen. Same with something like slashdot. In other words, keyword filtering won't cut it with blog browsing.
Filters like date range, author, and tag work well these types of feeds because they are broad. And that's why I chose Feed Rinse because they provide the above, a nice interface, and tiered membership so if you're really serious about feed filtering you can pay for the privilege. Shame I didn't think of it first but at least I now have decent filtered feeds available and I barely had to lift a finger!
Filters like date range, author, and tag work well these types of feeds because they are broad. And that's why I chose Feed Rinse because they provide the above, a nice interface, and tiered membership so if you're really serious about feed filtering you can pay for the privilege. Shame I didn't think of it first but at least I now have decent filtered feeds available and I barely had to lift a finger!
.NET 2.0 get properties vs method calls
When an object is required to provide some simple true/false information about itself one may use a method or a property to return a boolean value.
The question is which is preferable to use? Or does it even matter. I'm sure there are solid design reasons for going either way.
e.g. bool-returning method - IsBlah() - Vs a [possibly readonly] property - IsBlah.
Each will provide its return value depending on the internal state of the object. The syntax will differ, as well as the accessibility (properties can have mutators). What else is different?
One major difference is that in C# a property with both get and set accessors can be inadvertently assigned to via a small typo:
if (obj.State = serverState)...
when you mean,
if (obj.State == serverState)
Obviously this can be avoided by only providing a get accessor, however this can't always be done because some properties need mutators too. Another fix would be to enforce a coding style where the comparison value always appears on the LHS of the comparison - not stable though, as it depends on the developer.
Bill Wagner at SRT Solutions suggests that there are no hard-and-fast rules, but that some simple guidelines may be followed in order to make the decision. This checklist can be found here. Some good points he makes in favour of properties is that they can be serialised, which is definitely becoming more and more important as web services gain popularity. In the context of .NET this also affects objects sent over a Remoting boundary.
Personaly, I prefer to use properties whenever possible as they fit well with the concept that they are exposing an attribute of the object. I definitely agree with Bill in that they should be simple, settable in any order, and should not call outside the object to determine their value. I think it is wise to use private methods to calculate properties based on external data, and then cache that result for when it is required via the property. This can be done when the object is created.
As always, it depends on the particular requirements for the object. If the attribute in question can be safely calculated from internal state at any time in the object's lifetime, then a property is the way to go. If the attribute can only be calculated after the constructor has finished, or if the attribute depends on external data, a calculation method and caching solution, or a re-design/refactoring would be preferable.
The question is which is preferable to use? Or does it even matter. I'm sure there are solid design reasons for going either way.
e.g. bool-returning method - IsBlah() - Vs a [possibly readonly] property - IsBlah.
Each will provide its return value depending on the internal state of the object. The syntax will differ, as well as the accessibility (properties can have mutators). What else is different?
One major difference is that in C# a property with both get and set accessors can be inadvertently assigned to via a small typo:
if (obj.State = serverState)...
when you mean,
if (obj.State == serverState)
Obviously this can be avoided by only providing a get accessor, however this can't always be done because some properties need mutators too. Another fix would be to enforce a coding style where the comparison value always appears on the LHS of the comparison - not stable though, as it depends on the developer.
Bill Wagner at SRT Solutions suggests that there are no hard-and-fast rules, but that some simple guidelines may be followed in order to make the decision. This checklist can be found here. Some good points he makes in favour of properties is that they can be serialised, which is definitely becoming more and more important as web services gain popularity. In the context of .NET this also affects objects sent over a Remoting boundary.
Personaly, I prefer to use properties whenever possible as they fit well with the concept that they are exposing an attribute of the object. I definitely agree with Bill in that they should be simple, settable in any order, and should not call outside the object to determine their value. I think it is wise to use private methods to calculate properties based on external data, and then cache that result for when it is required via the property. This can be done when the object is created.
As always, it depends on the particular requirements for the object. If the attribute in question can be safely calculated from internal state at any time in the object's lifetime, then a property is the way to go. If the attribute can only be calculated after the constructor has finished, or if the attribute depends on external data, a calculation method and caching solution, or a re-design/refactoring would be preferable.
References
Properties vs. Methods @ SRT SolutionsWhat can a software developer expect?
It seems like the really valuable skills to work on right now are related to the new-wave design stuff - like Martin Fowler, refactoring, agile, domain-drive development, and so on. There is a difference between a computer nerd, or hacker, and a software developer - namely that the former enjoys the art of conquering the computer, language, sdk, toolkit, etc; while the latter treats these things as a means to delivering software that is useful to people [usually in business].
Thus, I am currently of the mind that while you have to specialise in a language to get a job, the way to ensure that one's career trajectory continues in a positive direction is to get very good at analysis and design. That is, translating real world entities and processes into clean, precise, scalable, and maintainable models. Most people have a preferred language, but as long as the language one must work with allows things like inheritance, encapsulation, and events, it is really only an afterthought. Ok, well also the language has to perform, be affordable (meaning its platform has to be), and be maintainable by future staff.
It seems futile and really a hacker's exercise to try to know every little nuance of a language. Personally I'll always have this fascination with obscure detail to some degree, but work-wise one has to preserve and increase one's value so it pays to look at what are the essential skills. I don't even think UML is that important. I honestly believe the key to making software engineering as effective as older forms, is improved and streamlined process. I think the communicative and documentative aspects become less important when the development process itself engenders constant progress.
I'm really just getting started but I predict these keywords are the ones to care about: agile, reusable, pragmatic, refactor, pattern, service
Books to pave the way on this journey:
The Pragmatic Programmer
Patterns of Enterprise Application Architecture
Analysis Patterns
Lean Software Development
http://www.martinfowler.com/articles/newMethodology.html
...and that's just to start with!
Thus, I am currently of the mind that while you have to specialise in a language to get a job, the way to ensure that one's career trajectory continues in a positive direction is to get very good at analysis and design. That is, translating real world entities and processes into clean, precise, scalable, and maintainable models. Most people have a preferred language, but as long as the language one must work with allows things like inheritance, encapsulation, and events, it is really only an afterthought. Ok, well also the language has to perform, be affordable (meaning its platform has to be), and be maintainable by future staff.
It seems futile and really a hacker's exercise to try to know every little nuance of a language. Personally I'll always have this fascination with obscure detail to some degree, but work-wise one has to preserve and increase one's value so it pays to look at what are the essential skills. I don't even think UML is that important. I honestly believe the key to making software engineering as effective as older forms, is improved and streamlined process. I think the communicative and documentative aspects become less important when the development process itself engenders constant progress.
I'm really just getting started but I predict these keywords are the ones to care about: agile, reusable, pragmatic, refactor, pattern, service
Books to pave the way on this journey:
The Pragmatic Programmer
Patterns of Enterprise Application Architecture
Analysis Patterns
Lean Software Development
http://www.martinfowler.com/articles/newMethodology.html
...and that's just to start with!
C# static readonly vs constant variables
I wondered about the differences between these the other day and here's what I found.
I am comparing constants to static readonly class fields because they are used in the same way.
At a high level, constants are obviously dealt with at compile-time, while static readonly fields are set at the time they are evaluated at run-time. The fact that constant values are subsituted by the compiler means that any library/assembly which references the constant value will need to be recompiled if the constant value changes. Libraries referencing a static readonly field will reference the field and not the value, thus they will pick up any change in the field without the need for recompilation. So constants 0 - static readonly 1 in the area of maintainability.
Static readonly fields are able to hold reference types whereas constants will only support value types plus the special .NET ones string and null.
Finally, readonly fields can be set wherever and however the developer chooses meaning they can be lazy-loaded, and they can contain calculated values. A use for this that I found was when I was developing a system which could potentially use multiple databases. I needed the maximum permissible date from Oracle and Sql Server. Based on application configuration I was able to calculate this at runtime and still store the value in a static readonly field in the static Constants class along with regular constant values.
So, it appears that constants should be used when it is very unlikely that the value will ever change, or if no external apps/libs will be using the constant. Static readonly fields should be used when run-time calculation is required, or if it external consumers are a factor.
I am comparing constants to static readonly class fields because they are used in the same way.
At a high level, constants are obviously dealt with at compile-time, while static readonly fields are set at the time they are evaluated at run-time. The fact that constant values are subsituted by the compiler means that any library/assembly which references the constant value will need to be recompiled if the constant value changes. Libraries referencing a static readonly field will reference the field and not the value, thus they will pick up any change in the field without the need for recompilation. So constants 0 - static readonly 1 in the area of maintainability.
Static readonly fields are able to hold reference types whereas constants will only support value types plus the special .NET ones string and null.
Finally, readonly fields can be set wherever and however the developer chooses meaning they can be lazy-loaded, and they can contain calculated values. A use for this that I found was when I was developing a system which could potentially use multiple databases. I needed the maximum permissible date from Oracle and Sql Server. Based on application configuration I was able to calculate this at runtime and still store the value in a static readonly field in the static Constants class along with regular constant values.
So, it appears that constants should be used when it is very unlikely that the value will ever change, or if no external apps/libs will be using the constant. Static readonly fields should be used when run-time calculation is required, or if it external consumers are a factor.
References
Static readonly versus constants
Subscribe to:
Posts (Atom)