Starbucks-fueled Developer

Thursday, July 27, 2006

Firefox Supports XSL?

So I wanted to view the RSS feed that I have set for Visual Studio to load on start up, and when I browsed to the URL, I got a nicely formatted presentation of the RSS feed. "Wha??", I exclaimed. A peak at the source for the RSS feed revealed that Microsoft was including an XSL to "pretty" the RSS (you know, so if you browsed to it in IE, you'd get a real view since IE supports XML/XSL).


(or maybe, I'm just really behind things...)

Wednesday, July 05, 2006

Hurry Up!!...Wait...

I was reading a post by Michael today and thought I'd express my thoughts given its relevance to my job - at least as of today. Tomorrow may be something completely different...

Personally, I hate the "Fast Today" mentality...The "RAD" mentality..."Mort" should you dare go there these days. I've been there, done that. Yeah, sometimes it's fun and exhilarating. But when the dust settles and you clear the air, what do you have in the end? Mud. At least, here in Central PA, that's what we have (it's ironic, now thinking about it, how the recent weather has coincided with how I, personally, feel my professional work has been going).

I'm not out to bash products, companies, or teams; they have worked hard, long hours and have significant sweat equity in their work, so this is as far as I am going down that road: sadly, I cannot say that I have enjoyed the new tools that are "features" in Visual Studio 2005. I don't know if it's because of mixing it with the Web Application Project add-in or what, but things like (shudder) the TableAdapter and DataSet designers just don't seem to like to work with web.configs and the personal web developer server in VS05 (which, I must say, I love the fact that I do not have to run as an Admin to develop a web application. Big win there!!! YAY!!!). At least not reliably and consistently anyway...</rant>

My manager says that the work I was doing for the past month was just "filler" stuff; "we've just gotta get this done and behind us so we can focus on the more important projects". You know, I don't have a bit of a problem with that mindset. In fact, it's wonderful to have a prioritized list of projects grouped and arranged by importance, visibility, customer influence, etc. Some tools/apps may just be needed to get you by or up to a certain point, allowing customers to rejoice in their new toys and IT groups/teams to focus on the other "important" stuff.

But I completely have discontent when the "just get it done" initiative vetoes the "done, safely, soundly, and 'right'" approach. What do I mean by that? A "RAD" application can't be done right? Sadly, I have to say no. When I cannot reliably know where my connection string is coming from, RAD doesn't win. When I spend half-a-day (and then some) trying to determine why my ObjectDataSource isn't updating the database when it's all "wired-up correctly", RAD doesn't win. Granted, there is a learning curve here; I am a very strong ASP.Net 1.1 and I haven't had as much opportunity to familiarize myself with all the new 2.0 stuff. But the end result is that I still feel more comfortable writing my own code that's backed by unit tests and has thought behind it as opposed to just flinging widgets here and there with little to no care.

I will be the first to admit that I am no Agile/TDD guru. But I started one project two days after I began my new position and felt pretty comfortable with all the TDD and thought that I had placed in the code that I wrote. Now, I will readily and openly admit that a major fault of mine currently is that I become too preoccupied in the architecture of an application. A simple app only needs a simple architecture - no argument. I need to learn to slice vertically instead of horizontally....Given this, three or so weeks into it, my code was scrapped to be replaced by flinging widgets and thoughtless antics. My intent here is not to be harsh on anyone or anything; but my point is that I firmly believe that the project was/is still a success because, while the development style changed, all the analysis had already been done. Potholes? Found. Recon? Gathered. From a "thought" perspective, the application had obtained 1 of 3 "done"s. The final two were achieved via demonstrations.

Thought preceded the antics. And, personally, the thought was much more fun and much more rewarding. And, given this retrospective, I can confidently say that I learned more from my stumbles in over-architecting than I did from flinging widgets.

What's in the Name?

When you get down to it, nothing really. The original one got boring and I hated explaining what I meant and all that jazz.

So the new one better reflects who I am and what I'm about. I am a consumer of over-priced coffee. And I do so all too frequently. Their numbers in my area are inversely related to my bank account balance. I've never been to Seattle so if there's something better, maybe I'll discover it but I don't intend on travelling cross-country for brown bubbly beans brewing beverages.

I am attempting to learn, as the posts within attempt to convey, the Agile methods and practices; however, my professional environment isn't condusive to doing such, so much of it is after-hours and well out of the true context of what (I believe) Agile attempts to achieve.

Also, I am a product of my parents - and as far as this blog is concenred, particularly my father. He introduced me to the technologies of Microsoft and, while I've had academic exposure to the other side, I prefer the .Net environment.

I hope that whatever makes its way onto these pages are found useful by someone, aside from myself as just reminders of days of future past. The reason I am a professional software developer is because I derive joy in developing solutions for people that result in making their lives easier. I hope that this blog is just another opportunity for doing just that.


Monday, July 03, 2006

"Does your incompetence know no bounds?"

On the subject of TDD, no, no it doesn't...Level II, I am. (found while reading Object Mentor Blogs)

Control Yourself!!

I fired up my work laptop this morning at home and, upon opening a project in VS2k5, I was greeted with the following options as I was not connected to the corp. network...I thought to my self, "you know, option 1 doesn't sound all that bad actually...":

Sunday, July 02, 2006

The Next [Family] Feud

(reader beware: this post comes from the author's recent findings on numerous posts on Agile Methods, TDD, design, and other buzzwords that he pays attention to. Incoherient ramblings may be present. Parental discretion strongly advised...)

Earlier this week, I had a mild epiphany while reading Jeremy's post on the NSpec project which led to catch-/brush-up on reading the enlightening wisdom of M. Fowler. Specifically, the update Fowler made to his post on Specification By Example and bantering of "Uncle" Bob Martin and others in the Agile community have led me to believe that, aside from the seemingly constant, recurring debates on SProc's VS. "ad hoc/parameterized" SQL, VB.NET vs. C# vs. Java (and surely to appear shortly) vs. Ruby, Agile methods and their practices are going to fuel the feuds of the future. And I really think it has less to do about the practices and methods, but rather language; that is, the vernacular of the UBIQUITOUS LANGUAGE or Domain-Specific Language (or whatever you wish to name it) that most emerge from our projects as professional developers.

OK, so after reading that, I, too, shook my head and said "a wha?!?"...

NSpec: even by looking at the very early and contrived examples on the project home page, you can see that there is most certainly a language to the object model that composes the NSpec utility (snipped from the project's home page):

namespace Example



public class Example



public void BooleanSpecificationExample()


// ...Some set up code...

Specify.That( someObj.SomeMethod() ).ShouldBeFalse();

// Or...

Specify.That( someObj.SomeOtherMethod() ).ShouldBeTrue();


OK...while someObj and Some[Other]Method my not be very informative, the Specify class and its methods clearly indicate the intentions of the developer programmer more so than an Assert.IsFalse() would and has greater meaning especially when you consider using NSpec for testing that your implementation for, say, an inventory system, is correct. Rhino Mocks has a language around creating, preparing, and verifying mock objects in unit tests as well, which I find makes my code much more understandable - thus, increasing maintainability. However, becoming comfortable with the language of these systems does, unfortunately, seem to take a non-trivial amount of time, IMO...

So how does all this language mumbo-jumbo related to the discussions of "Uncle Bob" Martin and M. Fowler? I believe that the language that the Agile fathers use to communicate the ideas and principles of the discipline are to simple. In fact, "Uncle Bob" said this himself - given the time they have, Bowling, Stacks, and Lists are as complicated they can get for an hour or so. It isn't clear or easy for to formulate a [meaningful] language around a bowling score keeper or a stack implementation. Who decided that Push() and Pop() were better names than Add() and Remove() anyway? But I digress...

I think that people who have a mind-set similar to Cedric's would greatly benefit from more concrete examples that show how when (as an example) an order is placed on, the inventory is updated, customer order history reflects the new order, and the shipping carrier is notified that an item needs to be picked up, or similar example. More importantly, to show how tests can be the specification for the software, show how the language of the system evolves, expressing the ideas, goals, and intentions of what the application does rather than just a series of "IF...THEN...ELSE...OpenReader()...CloseConnection()" statements that when any code monkey sits down at the keyboard doesn't know any more about the application than the person(s) who originally wrote the feature.

To me, I think this may need to become more of the language of the Agile mentors and "prophets" than "just wire-up your xUnit framework and 'RED-GREEN-REFACTOR' your way to the application of your customer's dreams!" to illustrate the development principles that make one an Agile developer...