Scott Hanselman has a post on the three things he learned about software after college and has asked for others to chip in. Here are my thoughts...
College:
1. Boolean logic can help prove a statement.
2. Comments should be added to code for clarity.
3. Projects should be completed on your own.
Out of College:
1. A test, or set of tests, is much clearer at proving that code is correct.
2. Good code needs well-named, decoupled, highly cohesive parts, NOT comments.
3. Asking for help does not mean that you are weak, it means you have the strength to admit that you cannot accomplish something on your own.
Disclaimer: I have not actually completed college (YET) but have taken many college courses.
Friday, June 29, 2007
Saturday, June 02, 2007
Background Compilation and TDD
Jeff Atwood has been blogging about the lack of background compilation in C# within Visual Studio (here and here); a feature that is built into the VB.NET editor of Visual Studio. I'll have to agree, for the most part, that background compilation can be useful at preventing common mistakes, especially in an environment where case sensitivity is important. And one of his readers pointed out that ReSharper includes background compilation for those of us who are lucky enough to have this tool. But background compilation, and even intellisense in general, annoy me during TDD sessions.
It is often the case, when writing code test first, that a class you are using does not exist yet and the method you are testing does not either. In each of these scenarios, background compilation becomes a little distracting as I immediately switch gears to eliminate the squiggles and the types that are now colored red. I find myself being pulled away from the task at hand: thinking about my design. This is certainly a personal issue and has me thinking that I should look into creating (and I don't even know if this is possible) shortcuts for disabling and enabling intellisense and background compilation. This may even solve the issue for those of us that think background compilation is annoying because "I haven't finished typing yet."
It is often the case, when writing code test first, that a class you are using does not exist yet and the method you are testing does not either. In each of these scenarios, background compilation becomes a little distracting as I immediately switch gears to eliminate the squiggles and the types that are now colored red. I find myself being pulled away from the task at hand: thinking about my design. This is certainly a personal issue and has me thinking that I should look into creating (and I don't even know if this is possible) shortcuts for disabling and enabling intellisense and background compilation. This may even solve the issue for those of us that think background compilation is annoying because "I haven't finished typing yet."
Sunday, April 15, 2007
NoVa Code Camp
A special thanks to the organizers and sponsors of the Northern Virginia (NoVa) Code Camp this weekend. It was my very first code camp and I enjoyed it thoroughly. Kudos go out to the speakers of the sessions that I attended - Bryce Covert, Blair Hall, Jonathan Cogley, and Paolo del Mundo (with assistance from Jay Flowers).
Monday, April 09, 2007
Prototype, JSON, and DHTML
I am playing around with the Prototype JavaScript library and script.aculo.us in an ASP.NET application, as I have heard great things about these two libraries. I know, I should be using AJAX.NET, but I am not sure that it is mature enough to accomplish exactly what I need. So I downloaded script.aculo.us's (man that's hard to type) scripts and added them to my solution - simple enough.
In an effort to see if I have a grasp of the JSON syntax, I included the Protoype.js file in the header of a simple HTML page and created a simple object. You'll note the use of "simple" in my description of the web page and the class that created. So I fired up trusty, ole IE to execute the page and nothing happened. Man was I irritated. How could I mess that up?
So I went to the Prototype website to ensure that I had the class creation syntax correct. Okay, I was missing a semi-colon at the end of my prototype definition (not the library - this can't possibly be confusing?), but I know you don't need that semi-colon as they are not required by JavaScript. I added it anway.
Now I Execute the page again. Nothing! Not even one of those helpful error dialogs that IE provides when there is a scripting problem. This story continues for about 6 hours of my Friday while I attempt to find the problem. Long story short, and a weekend's worth of rest I fixed the issue in 30 minutes of playing around this morning.
The problem: my "script" tags were self-terminating in the "head" of my XHTML (I forgot to mention that earlier). As far as I know, a self-terminating tag is legal XHTML, but apparently not where "script" tags are concerned. I could spend hours sifting through the XHTML schema, or searching online, but I am just going to document this here. "<script />" is not the same as "<script></script>. The latter works for script includes, the former breaks the HTML document in both IE and Firefox (FF). Now I am well on my way to JSON and AJAXian goodness.
Except that my boss just told me to stop spending so much time on research and "just get things done". Which is a whole other post.
In an effort to see if I have a grasp of the JSON syntax, I included the Protoype.js file in the header of a simple HTML page and created a simple object. You'll note the use of "simple" in my description of the web page and the class that created. So I fired up trusty, ole IE to execute the page and nothing happened. Man was I irritated. How could I mess that up?
So I went to the Prototype website to ensure that I had the class creation syntax correct. Okay, I was missing a semi-colon at the end of my prototype definition (not the library - this can't possibly be confusing?), but I know you don't need that semi-colon as they are not required by JavaScript. I added it anway.
Now I Execute the page again. Nothing! Not even one of those helpful error dialogs that IE provides when there is a scripting problem. This story continues for about 6 hours of my Friday while I attempt to find the problem. Long story short, and a weekend's worth of rest I fixed the issue in 30 minutes of playing around this morning.
The problem: my "script" tags were self-terminating in the "head" of my XHTML (I forgot to mention that earlier). As far as I know, a self-terminating tag is legal XHTML, but apparently not where "script" tags are concerned. I could spend hours sifting through the XHTML schema, or searching online, but I am just going to document this here. "<script />" is not the same as "<script></script>. The latter works for script includes, the former breaks the HTML document in both IE and Firefox (FF). Now I am well on my way to JSON and AJAXian goodness.
Except that my boss just told me to stop spending so much time on research and "just get things done". Which is a whole other post.
Monday, August 28, 2006
More on Test Driven Development and Agile Ideologies
My current employer is a supporter of "big design up front" (BDUF). If you have been developing for a while you know this method, usually associated with waterfall development, to be a bunch of people sitting in a room thinking things up until it seems like a great idea. Well not exactly, but you get the point. A requirements document has been gathered - imagine a single document containing, supposedly, anything and everything that a client wants (HAH) - and developers and architects (who can even make the distinction any more) come up with the ENTIRE structure of the application. Let me repeat that, the ENTIRE structure of the application.
Now, how many times have you developed software for a company? Go on, raise those hands - ok, so I can't see them, but I know they are out there. Now, those of you that have ever worked with a client that HAS NEVER changed the requirements document after sign off can put their hands down. Not many hands should drop - hopefully. Requirements are just as dynamic as a business and should be treated as such. Okay, so what does any of this have to do with TDD?
One of the beauties of TDD is the flexibility (read creativity) it allows a developer to have while building an application. As my previous post mentions (the one back in Sept. of last year), starting with implementation can be a big eye opener when it comes to design. You see your application take shape and you can either continue along or change it as you go. And, because you are building tests first, when requirements change, there is no need to worry. The tests should catch any breaking modifications.
However, the true power of TDD seems to take shape when it is coupled with Agile methodologies. The Agile community focuses on developing working software through extensive customer collaboration from all members of the development team (agilealliance.com). What?
From what I can gather, Agile development is about small iterative cycles that end in a product being released to the customer. This means that components of the end product can be delivered well before the end product is complete, giving the customer a chance to see pieces of the application. What a powerful concept! The client has an opportunity to make changes as early and as often as they like. And because they are getting to see things early on, positive and negative feedback can be given before pieces become embedded into the application increasing modification costs - although if you are using TDD as it is intended, this coupling should not be a problem.
Now, how many times have you developed software for a company? Go on, raise those hands - ok, so I can't see them, but I know they are out there. Now, those of you that have ever worked with a client that HAS NEVER changed the requirements document after sign off can put their hands down. Not many hands should drop - hopefully. Requirements are just as dynamic as a business and should be treated as such. Okay, so what does any of this have to do with TDD?
One of the beauties of TDD is the flexibility (read creativity) it allows a developer to have while building an application. As my previous post mentions (the one back in Sept. of last year), starting with implementation can be a big eye opener when it comes to design. You see your application take shape and you can either continue along or change it as you go. And, because you are building tests first, when requirements change, there is no need to worry. The tests should catch any breaking modifications.
However, the true power of TDD seems to take shape when it is coupled with Agile methodologies. The Agile community focuses on developing working software through extensive customer collaboration from all members of the development team (agilealliance.com). What?
From what I can gather, Agile development is about small iterative cycles that end in a product being released to the customer. This means that components of the end product can be delivered well before the end product is complete, giving the customer a chance to see pieces of the application. What a powerful concept! The client has an opportunity to make changes as early and as often as they like. And because they are getting to see things early on, positive and negative feedback can be given before pieces become embedded into the application increasing modification costs - although if you are using TDD as it is intended, this coupling should not be a problem.
Thursday, June 01, 2006
Dog Training: Positive Reinforcement vs. Negative Reinforcement
And so the saga continues...
Oh wait, there was never a saga introduced, so here it is...
We have two dogs, Bandit and Rascal - simple enough. We adopted Bandit first, and being our first dog, we wanted him trained. As a techie, the obvious resource choice is the web. I wanted to enroll him in a school ASAP, so after a quick directory search on dog trainers, I found one locally. My wife and I showed up for orientation and we were amazed at the behavior of the trainers' animals. There were approx. 50 or so people there for orientation and they had 3 dogs lying on mats chewing on bones or sleeping. Okay, so what, they were on mats, they could leave if they wanted to...not so!
The dogs got up a couple of times, but it was like watching a pantomime trapped in his invisible glass box. The dogs didn't go past the edge of their mats. Who can train their dog to do that? We were amazed and we signed Bandit up right away.
The first day of class was a little disconcerting as we were taught the true nature of the training - the leash correction. It started with being a simple leash jerk and progressed more aggressively for subsequent disobedience. Our initial thought was to give it time, perhaps the jerking would subside once the dog became used to the commands...
Oh wait, there was never a saga introduced, so here it is...
We have two dogs, Bandit and Rascal - simple enough. We adopted Bandit first, and being our first dog, we wanted him trained. As a techie, the obvious resource choice is the web. I wanted to enroll him in a school ASAP, so after a quick directory search on dog trainers, I found one locally. My wife and I showed up for orientation and we were amazed at the behavior of the trainers' animals. There were approx. 50 or so people there for orientation and they had 3 dogs lying on mats chewing on bones or sleeping. Okay, so what, they were on mats, they could leave if they wanted to...not so!
The dogs got up a couple of times, but it was like watching a pantomime trapped in his invisible glass box. The dogs didn't go past the edge of their mats. Who can train their dog to do that? We were amazed and we signed Bandit up right away.
The first day of class was a little disconcerting as we were taught the true nature of the training - the leash correction. It started with being a simple leash jerk and progressed more aggressively for subsequent disobedience. Our initial thought was to give it time, perhaps the jerking would subside once the dog became used to the commands...
Wednesday, March 29, 2006
Blogging Not So Easy
Blogging isn't the easiest thing when you get busy, actually, it's not easy when you have free time!! I haven't been here in ages, not that anyone's listening. So I have decided to blog on technical topics and dogs!
Yeah, that's weird right? But my wife and I have two wonderful, adopted dogs and they are so interesting. I never realized how dynamic and social dogs are! I have started reading books on dog behavior and dog training, and learning tons. Check back soon for more.
Yeah, that's weird right? But my wife and I have two wonderful, adopted dogs and they are so interesting. I never realized how dynamic and social dogs are! I have started reading books on dog behavior and dog training, and learning tons. Check back soon for more.
Subscribe to:
Posts (Atom)