Archives
-
Are Procedural Languages Justified?
Several months ago I got into a debate on GotDotNet about the place of procedural languages in our programming world. During the course of the discussion my line of thinking evolved on the subject. At first I felt, why bother with a procedural language, when an OO language such as c# can be used? However since this discussion, I firmly believe that procedural languages have their place in our world. For example,
-
More on Forcing a Postback using ASP.Net and JavaScript
I have received quite a bit of feedback from this post Forcing a Postback using ASP.Net and JavaScript as well as a quite a few emails that go into some detail about how you modified it to fit your needs. The comments people have posted have also helped others....
-
I need to vent=="SqlServer Enterprise Manager" + "Invalid Cursor State"
***Danger Will Robinson...Blood Pressure Rising***
-
The 11th Fallacy
Ted Neward has an interesting rant what he calls the 11th fallacy. Specifically, centralizing all business rules is a fallacy...his 11th fallacy (http://www.neward.net/ted/weblog/index.jsp). His argument contends that that applications do perform some Business Rule Validations on the client and some on the Server and because you do this it's a fallacy to think you can centralize all business rules. Fallacy defined by Merriam-Webster is as follows
-
Reflection Is It Worth The Cost?
Back in March I wrote an article for www.TheServerSide.net about using validators in the middle tier. The article Validators In The Middle-Tier enables you to use declarative programming techniques such as (Download the Validation Framework Here)
-
Arrogance + Ignorance = A Recipe For Failure
The other day I was reading through a bunch of different blogs and one blogger had a quote about Arrogance + Ignorance being a deadly combination. I tried later to go back and find where I read it in order to give proper credit but I could not find it.
-
Data Access Layer and Tier Purity
Ralfs Sudelbucher has an interesting post about using a DataAccess Layer.
-
More on Attribute Oriented Programming
A couple of my posts (here and here) on AOP have sparked a little bit of a discussion that I would like to clarify. I had a minor rant about AOP being more then Attributes + Interception (as have others) and that people in our industry who present on the subject or write about it should do so in the context of the greater body of work presented by Gregor Kiczales and team because I believe that it is causing people to think of Aspects as a superset of Attributes which just isn't the case (i have heard this from a number of people). First of all, whether or not you prefer a static model or a dynamic model. Or if your implementation is Attributes + Interception without a pointcut composition model...i have no issue with that. My point was to help evolve how we think of AOP. Not the implementation model.
-
Serializing Collections.
When designing or using strongly-typed collection classes that are to be serialized over the wire with webservices and the xml serialization process, you should keep in mind that:
-
Measure Twice, Optimize Once; Wash, Rinse, Repeat.
The title to the post was taken from an entry Larry Osterman http://blogs.msdn.com/LarryOsterman/archive/2004/05/03/125198.aspx. In this blog, Larry correctly points out that we should truly understand where and if we have a performance issue and if so...exactly where is the performance slow-down occurring. It's true. When I first started off in the software business, one of my first technical mentors taught me to constantly test for performance as I develop and that I should make sure I understand where any performance slow-down is before fixing it. True or false, have you ever fixed a performance problem only to find out the problem was actually somewhere else? If you haven't, you probably aren't being honest with yourself. It's a learning experience that every cowboy programmer goes though.