The Bolla Blog

A Better Continuous Integration + Version Control System?

Jim Bolla — Fri, 04 Apr 2008 01:39:00 GMT

Imagine this workflow...

You open your project in your IDE.
The IDE automatically updates your working copy with any new changes on the server.
You begin your work, using TDD or "test after".
You run your tests and they pass.
The locally passing tests trigger the process of your changes being sent to the CI server.
The CI server does a full build + test run.
If the full build/test completes, your changes are automatically committed to the VC server. The commit message is the concatenation of the new test names.
Your teammate's IDE polls the VC server for changes once per minute, and automatically updates his working copy when new changes are available.
His IDE is smart enough to merge changes in a way that does not disrupt his typing. Projects are updated "silently" and merges are performed successfully even with files that are open with unsaved changes.
This process is repeated thoughout the day between all team members.

The concept here, is that passing tests trigger integration. The benefits are less excise of having to do updates and commits, as well as a better sense of "trust" in the latest version because it is always compiling and passing tests. The test-driven commit encourages effective test writing.

This obviously puts the burden on the codebase to be testable. Some parts of the application, UI for example, are notoriously difficult to test. This "Continuously Integrating Version Control System" (CIVCS) would need ways to manually trigger commits as well. Plus for updating non-functional parts of the application, such as your spinning company logo graphic.

Also we need an IDE that can load changes to a project file without interrupting the user. VS 2005 is horrible at this. One way to cheat this would be for the CIVCS IDE plugin to simulate the changes being made manually though the UI.

There are a few places where our currently tools aren't quite ready to make this a reality, but I don't think we're that far either. I image it would be rather easy to add a feature to Resharper's test runner to trigger a process if all the tests pass. TeamCity already has a feature to do a "pre-tested commit." Determining new tests should be as easy as comparing all the test names to the previous build's list of tests. Polling for changes... trivial. Merging changes without interrupting the user... ok we need to work on this one. The "only tested code" concept could be handled with a branch that gets sync'd with the main branch. Most of the puzzle pieces are there. We just need someone (*cough* Jetbrains *cough*) to put them all together. Thoughts?

Analyzing NHibernate.dll with NDepend

Jim Bolla — Sat, 01 Dec 2007 22:00:00 GMT

I'd like give a big thanks to Patrick Smacchia for offering me a free license for NDepend, a code analysis tool. I've spent the past couple days experimenting, watching tutorial videos, reading his articles, and running the tool against my work project and also NHibernate, for which I am an occasional contributor. My opinion of NDepend is very high. As a metrics-junkie, this tool is my Columbian drug lord. I won't bother rehashing all the information already provided on the product website, but, as an example, you can do stuff like this...

WARN IF Count > 0 IN SELECT METHODS WHERE IsUsing "System.Web" AND IsUsing "System.Data.SqlClient"

And you will get a result set of any methods in your project that are doing web stuff and SQL stuff in the same method! COOL! Now you know which n00b programmers you need to go ~~slap~~ mentor. In other words, you can define NDepend CQL queries to find methods that violate the Separation of Concerns principle. Another feature of NDepend that is very fascinating is the dependency matrix and how it visualizes dependency levelization. (Go read that article, it's ok, I'll wait...) I was very interested to see how well NHibernate levelizes its inner-namespace dependencies. Here's the results...

That big red box that nearly encompasses the entire grid indicates that all of those namespaces have a cyclical dependency. That kinda sucks. The black squares that are peppered about the grid indicate a cyclical dependency between that row and column. Looking closer, there are four namespaces in particular that heavily used (as indicated by a high density of blue and black squares):

NHibernate (row 51)
NHibernate.Engine (row 16)
NHibernate.Type (row 37)
NHibernate.Util (row 33).

If properly leveled, these namespaces should drop to the bottom of the grid. In order to achieve namespace levelization, refactoring effort would focus on the details of the black boxes on these rows. There are several difficulties in doing this:

NHibernate is a public API. Making API changes to break dependencies will annoy current users when they upgrade to a new version with a changed API. This would have to be mitigated by making some changes transitional by leaving the offending members and marking them with the [Obsolete] attribute.
NHibernate has tried to maintain a similar API to the Java version in order to be able to reuse documentation and make porting of features easier. Much of this problem is "sins of the father."
Many of these refactorings are likely to be broad in scope. This will require extra coordination amongst the team to make sure refactoring doesn't conflict with feature development. There is also the chance of introducing bugs. Making sure the relevant code is being tested effectively would be important.
The open-source nature of the application means there isn't necessarily a central architect to enforce these constraints. But we could beef up the build script to run NDepend with a defined set of queries to inform the developer if he is deviating from the intended design.

What is the next step? I'm not sure. It's likely that many of the cyclical dependencies may be easy to bust up with minimal effort. Is that effort even worth it if no work is being done in that part of the code? The areas of code that are modified most are probably the ones with the most coupling. I'm having a fantasy where some master tool could combine the data from NDepend (which files hurt the most) with the Subversion commit log (what files are changed most), the JIRA issue tracking data (what files need changed the most), and dotTrace profiling data of any defined NUnit tests (what files get used most) into some uber-report.

C# 4.0 Feature Request: "??=" the Lazy load operator...

Jim Bolla — Fri, 26 Oct 2007 23:06:00 GMT

A cool C# 2.0 feature is the "??" coalesce operator, which lets you do this:

public ISomeService Service
{
    get { return service = service ?? LazyLoadSomeService(); }
}

For the noobs, this code is equivalent to this:

public ISomeService Service
{
    get { return service = service == null ? LazyLoadSomeService() : service; }
}

Which is the same as:

public ISomeService Service
{
    get
    {
        if (service == null)
            return service = LazyLoadSomeService();
        else
            return service;
    }
}

Now it would be great if we could trim this up just a little bit more...

public ISomeService Service
{
    get { return service ??= LazyLoadSomeService(); }
}

This is similar to +=, *=, and family. This seems like the logical progression to me. I guess this would be called "coalescing assignment operator" or something like that. And we could take this one step even further... C# 3.0 has Automatic properties that alleviates the need for an explicitly declared backing field. What happens when my suggested "coalescing assignment operator" and automatic properties do the nasty...

public ISomeService Service
{
    get?? { LazyLoadSomeService(); }
}

The syntax is debatable but I think the concept is nice and useful.

Finding A New Job, Week 2 - Observations From The Interview

Jim Bolla — Sun, 16 Sep 2007 02:20:00 GMT

What a week! It started with the lousy first in-person interview on Tuesday, and then several phone interviews, and concluded with another in-person (Friday) morning. From these interviews, and also from interviewing candidates for my current employer, I've made a few observations worth sharing:

Figure out what your deal-breakers are. Address those a soon as possible with each employer, preferably during the phone interview or before it. Always do a phone-interview first. This will save you from having to take time off work, putting on your suit and tie, and traveling. Before you start scheduling interviews, spend some time reflecting on what's most important to you. Make a list of everything that might affect your decision whether or not to work there. Be thorough with your list but then really focus on the ones that matter most. No place is going to be perfect but you gotta get the big stuff right.
It's possible to be overqualified for a job. By the end of the first interview I had, it was obvious I was years beyond those clowns. They had neither the technology nor the process in place to keep a developer like me happy. The wrong tools, no unit testing, no automated build, no continuous improvement. "Once we hire 15 more people we'll have some time to implement those things." The Mythical Man-Month much? Make sure during the phone interview that you weed these places out.
Watch out for arrogance. This can happen on either side of the table (or phone line). I interviewed with company that sounded like they had a very mature process and was doing cutting-edge stuff... SOA/WCF. The attending staff seemed pretty smart and "with it." The phone-interview went well but afterwards I started analyzing the conversation and realized a few things that bothered me. One thing in particular, when asked what I felt was one greatest strengths, I went with something like "I think I work very well in a leader/mentor role and enjoy teaching other team members about various technologies and practices." The lead interviewer's response was "Well our team is mostly senior developers and we don't need mentoring." Perhaps we misunderstood each other, but that came across to me as very arrogant. I also like to think I'm a pretty good developer, but I know there is always more to learn and ways to improve. I proudly subscribe to Jeff's "Sucking Less Every Year" mentality. I want to work with people that feel the same way.
Sell your strengths. (But don't be cocky.) From the resume to the interview, the point is to make yourself desirable. Tailor your sales-pitch to each employer. (Check out their website ahead of time to get an idea for what they do.) If the employer does a lot of data-centric applications, talk about your database experience... normalization, optimization, O/R mapping, whatever. If you find out during the interview that the employer has not yet embraced automated testing, tell them about how and why you write automated tests. That one in particular has been a hot topic in every interview I have done. I always discuss the mechanics (nunit... cruise control...), the realized benefits (verify requirements, performance, bug fixes), the impact on design (dependency inversion... single responsibility principle...), and even the pains (refactoring for testability... mock objects...). After the interview, the employer is going to review all of the applicants to decide who they want. I want to stack the deck in my favor by focusing in on a few key items that I think will make me stand out from the crowd.
It's OK to talk about mistakes and weaknesses. (But don't overdo it.) We've all made mistakes before and employers know that. What's important is to show that you understood why/how you screwed up and that you learned something from it. Some interviewers will throw in questions design with this purpose. "How do you handle times when you go over budget/estimate?" is a good example. This is a good opportunity to show some personality. Turn it into a war story: "Oh man this one time I had this project..." When asked about a technology/practice that you're unfamiliar with, go with something like "I've never heard of Technology Z. What is that? ... How do you use that here at Company X? ... That sounds pretty cool. Can you recommend a good book or website I could check out to learn more about that?" Just like that you spun the fact that your clueless about that tech into a chance to show you're interested in what the company is doing and that you are enthusiastic to learn new things.
People skills are as important as technical skills. Chief amongst these are good communication skills. Be a good listener and a good speaker. When an employer asks a question, be sure to answer it. Try not to off on too many unrelated tangents. Personality is also important. No one wants to work with an a-hole or a robot. Show some humility and a sense of humor. Hygiene is important too. Would you want to pair program for eight hours with a mouth-breather who hasn't quite mastered deodorant and toilet paper? Neither did I. Show that you are a good team player.
Be professional. Unless explicitly told otherwise, wear a nice suit. Show up about 15 minutes early. Watch the profanity. Depending on your rapport with the interviewer, you may be able to toss in a damn or hell, but definitely avoid f-bombs and genitalia references. I once interviewed a guy that threw in a "Cleveland Steamer" reference during a follow-up interview. Lucky for him I found it freakin' hilarious in context, but I would not recommend you try that one yourself. Present yourself as someone who could be trusted to meet with clients or upper management.

That's what I've got so far. Stay tuned for more.

Conflict

Jim Bolla — Thu, 13 Sep 2007 03:04:00 GMT

Earlier this week, a coworker was doing a Subversion merge conflict resolution because he and another dev modified the same file. That got me thinking how freakin' sweet it would be if Subversion knew about potential conflicts in my working copy sooner than commit time. My idea was to have a running process on each dev machine that talked home to the server on an interval (maybe 1 minute) to tell it which files I've modified and find out what files other developers have modified but not committed. Well apparently Dennis Byrne had the same idea a few months ago and created Conflict:

Conflict notifies a software developer of potential conflicts between his/her work and that of other developers, before the commit.

Conflict is an open source project composed of two parts: Conflict clients and a Conflict server. A Conflict client is a transparent process running on the workstation of each developer. It stays in the background, reporting local file system changes to the Conflict server. When the Conflict server detects a conflict between two or more developers, each developer is notified. The Conflict project improves feedback and communication while encouraging developers to check in code frequently.

I'm finding this at 11:15 and I'm supposed to be going to bed but instead I will be tossing and turning thinking about playing with this shiny new toy tomorrow. Found via blogs.thoughtworks.com, which I found via Jeremy Miller's blogroll while reading about StructureMap. Now I have two new tools to learn how to use this week.

Finding A New Job, Week 2 - How to Waste Five Hours of My Time

Jim Bolla — Tue, 11 Sep 2007 22:59:00 GMT

Today I had my first on-site interview, set up via an IT staffing agency. The position was described to me as a contract position in Cleveland Ohio with a company looking for .NET developers with strong database skills. I checked out the company's website which looked nice enough and agreed to the interview. This morning, I made the almost-two-hour drive to meet with my interviewers "Van ***" and "Slick" (as I will call them), which was to be my first (and last) direct contact with this employer. Van *** was the head project manager and in charge of the current development team of approximately roughly twenty. Slick was one of the lead developers who would conduct much of the technical screening portion of the interview. After ten minutes of small talk... what the company does... why I am jobseeking... bleh bleh bleh... we started the technical screening.

Not surprisingly, the 45 minute technical screening consisted of roughly half database questions and half .NET questions. The database questions were pretty easy stuff... What's the difference between an inner join versus left join. Write a query (on paper) that joins two tables. What's the difference between primary keys, foreign keys, and indexes. Clustered vs non-clustered indexes? Advantages of stored procedures? Explain Cartesian product. Those are the few I remember. I thought most of the database questions were fairly good questions to ask. Slick's last question to me during the database part was "When can you start?" I was also feeling good about the way things were going at this point.

The .NET questions were of the same caliber... What is the advantage of the ViewState? What's the difference between app.config, web.config, and machine.config? (Doesn't this question kinda answer itself?) Have you used web services, windows services? C'mon guys, try harder than that.

We also went over several of the technologies on my resume that they were not familiar with... Subversion (never heard of it? bad sign #1), NHibernate in particular. I explained how Subversion's update/merge/commit paradigm differed from SourceSafe's check-in/check-out paradigm. I explain the basic concept of O/R mapping. We also talked about unit tests and automated builds and their current lack of said items. Ok that's bad but here's a great opportunity for me to come in and put boots to ass. Those are things they are looking into but haven't had time due to having too much work to do. They are currently looking to expand from 20 to 35 to handle the current workload. Once they have the people on board to support the workload, they will begin to add some more process improvement procedures such as automatic builds and unit tests.

The next big red flag was when Van *** explained that the company didn't allow the use of open source tools because they want to have a company to hold accountable (read: sue) when things go wrong. Wow. Let's see... Subversion, TortoiseSVN, VisualSVN (not OSS but dependent on it), KDiff3, NHibernate, NUnit, NAnt, RhinoMocks, CruiseControl.NET... all gone from my toolbox? And those are just the ones I know I use every day! There's another question to add to my list. I guess if you gave me Team Foundation Server and upped my salary another 30K I might take the job. Then the deal breaker...

Van *** says "...blah blah blah the main VB6 application..."

I ask "So is the project a migration of the VB6 application to .NET?"

Van *** replies "No we do not have time to do that with our current workload. You would be doing maintenance development on the application."

I respond with "I was under the impression that this was a .NET job. I guess the VB6 thing would be kind of a deal breaker for me, because I feel that is actually a step backwards for my career. But if you're in need of fifteen more developers, it sounds like you could specialize with some .NET developers and some VB devel..."

"No that is a deal breaker for us too. We need someone who is willing to do whatever it takes to get the job done. Thanks for your time." says Van *** as he stands up, opens his office door, and points with an outstretched hand.

I start "Are you sure? I think..."

Van *** injects "Thank you for your time."

As I stand up and am escorted out the front door, I bewilderedly say "Ok. Uh well thank you for your time. I'm sorry things didn't work out. Good luck."

I got in my car and began my 100 mile trek in the opposite direction, thinking "What the f*** just happened?" After taking a half day off from work, putting 200 miles on my car, and going through their interview process, I expected a little more professional courtesy at the end of the interview, even if I'm not the right man for the job. He could have entertained me for a few minutes with some shop talk before wrapping up in a friendly manner. (That's what I've always done when interviewing candidates that I wasn't gonna hire.) Instead he burned the bridge beyond repair. Not only will I never work there, but I will tell any of my peers who might happen to be looking in the Cleveland area to avoid this place.

The irony of the situation is that what they actually need is a full time developer who's job is process improvement and mentoring of their current staff. They need to commit a number of hours per week to augmenting their process with some automated builds, unit tests, some proper object orientation of the code base, and so on. In given time, maybe six months to a year, those twenty would be doing the work of thirty five or more. They are too busy working hard to start working smart. These are all things a person like myself could bring to the company, but if they treat other interviewees with the same disrespect with which I was treated today, then they will have a hard time finding such a person.

Update: PS: The profanity filter is blocking my nickname for him, which was a reference to his facial hair. Which is also a derogatory term for a lady who has relations with other ladies. Hah!

Finding A New Job, Week 2 - Preparing for the Interview... What to ask employers

Jim Bolla — Tue, 11 Sep 2007 00:54:00 GMT

I've begun compiling a list of questions and discussion points for potential employers. Many of these are lifted verbatim from Joel Spolsky, Derik Whittaker, and Eric Wise. *YOINK* If anyone has more, please leave a comment and I will continue the harvest. I will also continue to update this post as I think of more of my own. Onto the list...

Openers

What does your organization do? How do you utilize IT to accomplish that more effectively?
What is your role at the organization?
How many full-time employees and contractors do you employ? In IT?
What are the company's future plans for utilizing IT?

The Position

What are the job duties of the position for which you are considering?
Tell me about the average workday of a developer of my level.
What is the nature of the project(s)?
How often do you extend contracts or offer full-time placement to contractors?
How many bosses will the employee have? Direct reports? Teammates?
Does this position have the authority to enhance/improve the development process or team behavior?
What opportunity for advancement is available at your company?
What is the typical process a candidate goes through before he is hired and sitting at his desk working? How long does that usually take?
Does your company have policies regarding employee blogging or contributing to open source projects?
What is the appropriate dress code?

Project Management

Does your development staff follow an agile/iterative methodology? (XP, Scrum)
How do you define project requirements?
How do you determine whether a project was successful?
How do you test your software? (Unit, integration, QA, usability, acceptance)
How do you deploy your software?
How do you manage bugs and change requests?
What form of stake holder involvement is there in the development cycle?

Development Environment

What types of tools do you provide your developers? Hardware/software/furniture? Resharper?
Do you have a VPN? What is your work from home policy?
Are employees allowed to provide their own hardware/software?
To what extent does the development team use version control? Branching?
Does the development team utilize an automated/continuous build process?
Does your version control repository contain everything needed to build the project? [Added 9/12]
Do programmers have quiet working conditions?
What proportion of development is done in a team environment? Pair-programming? Code-review?
Do you have a knowledge center for the team such as a team portal, wiki, etc?
Do you have documented coding standards? Are they followed?
Does the development team have established mentoring/training practices?
Can I see the (physical) development environment and/or meet some of the team? (Some employers may not allow this, but it's worth a shot. This would go a long way in my book. Their answer might also depend on their opinion of you.)
Does you company have a policy on the use of open source tools? [Added 9/11]

Compensation

How many hours per week do your developers realistically work?
Do you compensate for overtime?
What type of benefits are offered to full-time employees? Do you have any education benefits?
Do you have a documented process for rewarding extraordinary work?

Closers

What's the best thing about working here? The worst?

Obviously one shouldn't just enumerate the list and recite verbatim, but this is meant as a guide to refer back to at natural conversation endpoints. Some of these may not be relevant to the position for which you are interviewing. Also, many companies will answer some of these questions on their website. Do your homework and look at their website ahead of time. At my current job, I've interviewed many people who didn't even go to our website before the interview.

Something for the ladies employers: If you answer many of these questions on your website, motivated developers such as myself would be much much much more likely to want to work for you.

Finding A New Job, Week 1 -- Recruiters and the demand for .NET

Jim Bolla — Sat, 08 Sep 2007 18:15:00 GMT

After eight years at the same (and my only ever) employer, I have decided it is time to move on to bigger and hopefully better things; not only professionally, but also personally. Yesterday my boss and I discussed my intentions to move out of the Erie area by the end of September. I have begun to cast my net (pun!) into the nearby Cleveland and Pittsburgh job markets, via dice.com and monster.com. So far during my first real experience as a job seeker, I have made some observations that maybe useful to others...

The Demand for .NET

Demand is high for .NET workers. There are pages of current openings posted on dice.com in these two cities. Since posting my resume a week ago, the number of calls and emails has been overwhelming, almost to the point that getting a second phone line would be worthwhile. (I have one cell and no home phone.) Sorting between new callers and known contacts is quickly becoming a chore. I have had to put my phone on silent/vibrate and screen the calls via caller ID. Email inbox filtering rules are also now a necessity. My advice to other job seekers is to set up separate email accounts and phone numbers to use as your posted contact information, and then once you get serious with a potential employer, give them your real contact details.

Demand is especially high for those with greater than five years experience with it. We are five and a half years since the platform officially launched in early 2002. This means early adopters are the target demographic. No joke, I've seen at least one posting that explicitly stated 5-7 years of .NET experience required. Seven years? I guess if you worked at Microsoft on the CLR/BCL teams you could claim this. I wonder what proportion of these companies are truly that progressive in their adoption of new technology versus ignorantly inflating the requirement beyond the point of reality. I am anxious to find out if these companies, so anxious to scoop up early adopters, continually support the adoption of new technology. Mr. Employer, will you continue to buy us the latest versions of Visual Studio and Resharper and invest the time and money in upgrading projects to new platform versions? I expect this to be and give and take relationship.

IT Staffing Agencies

Many posted jobs are handled through a third party IT staffing agency, affectionately referred to as head-hunters. These jobs are usually contact or contract-to-hire. This means you make an hourly rate instead of a salary. Many of the agencies offer benefits such as insurance to their contractors. At the end of the contract, the client will either extend the contract, offer a full time position to the developer, or tell you to not let the door hit you on the ass on your way out.

My experience with the recruiters themselves so far has been mixed...

On the low end, there is what amounts to spam. I have gotten several emails that were not even addressed to me, but someone else, and I was a BCC on the email. My resume and email address were harvested, keywords were found, and fed through someone's mass mailing. No human being actually read my resume.
The second worst are those that have perhaps a slightly better spamming engine that at least appears to personalize the email. On both Dice and Monster, I explicit stated that I am only willing to relocate to Cleveland and Pittsburgh, yet I am still getting solicitations for Nebraska, Texas, Connecticut, and Georgia. Either they're spamming me or they are incapable of reading or doing basic geography. Also important is getting my first name right.
Next up are those that send a personalized messages that are too informal. Lack of capitalization, abbreviations such as "plz" and "ur", and so forth. This is unprofessional and makes a bad first impression.
I have received several phone solicitations from individuals with a foreign accent so thick that I could not understand their name, the name of their company, or other key details.
One recruiter hung up on me when I told him I was already in contact with the client he was representing. This was after spending fifteen minutes of asking me questions about my background. I will never accept solicitation from his company again.
In the "not bad" category are plenty of recruiters that are doing a decent job with whom I have had email/phone discussion. While not bad, they also are nothing special.
Finally I get to the good news. There are some recruiters that really kick ass at their job. They have great people skills, get back to you in a timely fashion, are show a real motivation to set up interviews quickly. They go above and beyond. I am moving forward with several of them to the interview phase of the job hunt. I actually feel bad that at some point I will have to tell all but one of them that I can't take the position they are setting up for me.
One lady in particular has been extraordinary. She has given me guidance on how to edit/format my resume to make it more appealing, helped with determining appropriate salary requirements and so forth. If the quality of service she has provided so far continues throughout the process, then I will write a future blog post giving her and her company a glowing recommendation.

On a Personal Note

While I'm exciting to be moving on to this next chapter of my professional career, I'm also a bit anxious. For my own experiences with some clients, tales from coworkers, and from years of reading ~~The Daily WTF~~ Worse Than Failure, I'm worried about ending up some place that has a development process that would give Rube Goldberg nightmares. I'm trying to come up with questions to ask potential employers to weed these places out. Unless of course they are looking for somebody to come in and whip them into shape... deploy Subversion/CC.NET and teach the team dependency injection, design patterns, automated testing and all of those awesome things that give my brain a chubby. I'm also worried about changing from big-fish-in-a-small-pond into little-fish-in-a-big-pond. Right now I've got my own office with a couch, a 3GHz machine with 4GB of RAM and a 30" monitor, and I can (diplomatically) tell clients and coworkers that they are being idiots because they love me. Next month I'm gonna be "the new guy" and will be giving up many of the comforts I currently have.

The next step for me is the in-person interviews. I'm not used to being on this side of the interview. Right now I'm trying to mentally prepare myself... what are the key topics to discuss? I should make a list. During the next couple of weeks I will write about my experiences. Stay tuned...

An ASP.NET site to add DVDs to your Netflix queue via your camera phone

Jim Bolla — Thu, 05 Oct 2006 22:24:00 GMT

Have you heard of this site? You use your camera phone to get product information, comptetive pricing, Netflix integration, etc by simply taking a picture of the UPC barcode on any product!

You send the image to the site's servers via SMS or email (depending on your phone's capabilities) and it does image processing to translate the barcode into a number, which is then looked up in some combination of databases such as barcodepedia. Once the product is identified, it's name can be used against a variety of web sites, such as Netflix, Amazon, Google, Froogle, Wikipedia, just to name a few. Online pricing details, product reviews, and summaries are sent back to your phone. All your searches are saved with your registered profile so you can review them later to allow you to further act on it, such as Rent from Netflix or Purchase at Amazon.

Based on your activity, the site learns your preferences and begins to make reccomendations similar to Amazon, contextual advertising via Google Adwords, and more. Usage data is also aggregated for use my retailers and marketing to track "What's Hot." The service is being postured for partnership with the likes of Verizon or Motorola for seemless integration with the handsets and services. So why haven't you heard of it (and why is the link broken)? Because it only exists in my head. :-( Anyone want to give me a big pile of cash to build this beast?

PS: This is just one of many crazy ideas I've got floating around upstairs. Expect to see them occasionally sprinkled amongst my more technical posts.

Model View Presenter mutated: Observable View

Jim Bolla — Tue, 03 Oct 2006 22:25:00 GMT

Transgression

One of my crusades of the past year has been to break myself and my team of the habit of embedding domain logic into the code-behinds of our ASP.NET pages. For me, this is a habit that has carried over from the ASP 3.0 days of old. More recently, we have a nice domain layer that is persisted to the database using NHibernate. Classes are created that encapsulate specific functionality, whether through design or refactoring. We have even adopted Dependency Inversion through use of interfaces, which has allowed for unit testing of these classes. But many of our pages still contain too much logic about the process of how to perform a given task. This means a significant portion of code was not being tested.

Repentance

The first source to shed some light about how to extract this remaining logic from the pages was Martin Fowler's Patterns of Enterprise Application Architecture in which he covers the Model View Controller pattern. Much googling lead to my discovery of Model View Presenter. The most enlightening source on this was Jean Paul Boodhoo's Model View Presenter video on dnrTV. We began experimenting with MVP in our designs shortly afterwards.

Transcendence

Finally, extraction and unit-testability of the logic that once existed in our code-behind. But there was still something I didn't like about our implementation of MVP. The code-behind was still responsible for calling the correct method on the presenter whenever a control's event was raised. I felt like we were 90% there. Through experimentation, I eventually came up with what I call the "Observable View" pattern:

The interface:

interface IManageCustomerView
  {
        string Name { get; set; }
        // etc...
  
        void DisplayValidationErrorMessage(string errorMessage);
        void DisplaySavedSuccessullyMessage();
        // etc...
  
        // The interesting part...
        event EventHandler Initialize;
        event EventHandler SaveCustomer;
        event EventHandler DeleteCustomer;
  }

The code behind:

class ManageCustomer : Page, IManageCustomerView
  {
       protected override void OnInit(EventArgs e)
       {
           new ManageCustomerViewObserver().Observe(this);
  
           if (Initialize != null)
               Initialize(this, EventArgs.Empty);
       }
  
       protected void OnSaveButtonClick(object sender, EventArgs e)
       {
           if (SaveCustomer != null)
               SaveCustomer(this, EventArgs.Empty);
       }
  
       // etc.
  }

The observer:

class ManageCustomerViewObserver
  {
       public void Observe(IManageCustomerView view)
       {
           view.Initialize += delegate
           {
               new ManageCustomerViewInitializationProcess(view).Execute();
           };
  
           // repeat for each event
       }
  
  }

(Note: The code above probably has typos... wanna fight about it?)

The key element is the use of events. This allows the view implementation to forget about observer after calling the Observe() method. The reference that keeps it from falling out of scope is the observer's subscription to the view's events. The .NET framework's event mechanism hides makes this slightly less than obvious. The events' presence in the interface also assist the implementation in hooking to the presenter observer correctly. The observer simply delegates the logic to a process class (one per event) which is an implementation of the Command pattern. The observer class only contains the Observe() method, which is simply glue code that doesn't warrant unit testing. Each process class can be tested independently or as a group. All in all, I'm pretty satisfied with this design. It does lead to a lot more class files in the project, but unit testing, the Single Responsibility Principle's biggest cheerleader demands most of this anyways.

Who is Jim Bolla?

Jim Bolla — Sat, 30 Sep 2006 15:47:00 GMT

Oh no. Another introductory post.

*ducking* OK I know. I'm sorry. Please stop throwing rotten fruit and garbage at me. I'll try to make this as quick as possible...

The Man

I develop custom business software for a small consultant in Erie, Pennsylvania as lead of small dev team, creating solutions on the Microsoft .NET platform (ASP.NET + C# + MS SQL). November 1^st will mark the seven year anniversary of my professional career. Before that, I was just another computer nerd lurking in his darkened room, making BASIC programs on his TRS-80, Apple IIc, Compaq Persario 66 MHz 486 with 4 MB of RAM... Turbo Pascal, C++, Java and finally a one year stint in college with Eiffel. My career has involved ASP (VBScript), HTML, Javascript, database design, T-SQL, IIS administration, MS SiteServer (*shudder*), VB6, XML... I dabbled with ASP+ (before MS renamed it to ASP.NET) and began developing production code with it almost as soon as VS.NET 2002 was gold. I have a ".NET guy" ever since.

The past two years have seen a renewed growth in learning and process improvement for me. I've been learning about and implementing many technologies and methodologies in the name of Quality... source control (Subversion), O/R mapping (NHibernate), refactoring (Resharper), continuous integration (CruiseControl.NET), code analysis (FxCop, SourceMonitor), OOP (design patterns, dependency inversion, SRP), unit testing (NUnit)... I'm still trying to come to terms with TDD, but I will keep at it until I "catch the bug." I'm sure there is plenty more I am forgetting to mention. About a year ago I took on the duties of project manager, which has added even more to my plate... customer management (requirements analysis, estimation, controlling scope creep) and helping my team stay productive (design meetings, code review, agile practices).

The Blog

The previous paragraph was intentionally buzz-word heavy. This is my reminder to myself as to why I'm blogging; these are the topics on which I might have something (useful? insightful? interesting?) to say. My goal for this blog is to post one or two quality posts per week on topics such as those above, being between one half and two pages of well formed English prose containing coherent (original?) thoughts. I also intend to comment more often on posts by fellow bloggers. I'm looking forward to doing my small part towards the enlightenment of the .NET community.

OK, that is all. You can resume the garbage tossing.