Having just been to a conference, I saw a lot of different presentations, and saw a few things that [a] I hope I don't do when I'm presenting, and [b] definitely didn't help the speaker's cause. The biggest one was the number of speakers who kept turning back to look at there slides on the big screen. Not just a little peek to make sure they were in the right spot and get their bearings. I mean a full on reading of the slide with their back to us. Well, not reading - I don't think anybody pulled that old stunt. But looking at their talking points and keeping their back to us for the most part. Definitely not a very positive experience - at least some of them had content that made it possible to overlook this, but...

The other problem, one guy (won't mention any names) had his slides on a timer, so he could walk around. The problem was, his time interval was set too short, and he constantly had to go to his computer an re-adjust. If you want to walk around (and I think that's a great thing - I need to figure out how to do it), get one of those wireless remote things to control your slides.

On the positive side, several of the speakers were very obviously letting their true selves show, and it made the presentation much better. I don't know how they were able to be so relaxed, other than experience, which I'm sure was the case, but they were joking around, even poking fun at themselves, and just generally very engaging. I know its a hard skill to acquire - I am certain I'm not there yet, but its worth the practice, because these guys came across as real pros.

So, in the end, Dr. Dobb's Architecture & Design World was a worthwhile way to spend 4 days. Well, 3 and a half, anyway - we left after lunch on Thursday, because our flight was extremely late and we wouldn't have gotten home until long after midnight (Jim longer - he lives much further from the airport) and we found that there were seats on the 3 o'clock flight. The talks for the final session looked bad - we couldn't find anything that interested us, and the next to last session had one talk that we thought might have been decent, but given the recent sales pitch we had just experienced, we thought that a talk about scaling out databases by a guy who works for Sybase had too high of a risk of being another sales pitch. I'm not saying it was - we didn't have any slides to refer to - they were not published (that could be a warning sign right there) - so it could have been an awesome session - its just that given the information we had, we had to make a judgment call, and elected to ditch.

All in all, both Jim and I felt we had learned a lot, had generated a lot of good ideas we want to try out, and had a very positive experience. I'm hoping to maybe attend again next year.

If you walk into a conference session, and every seat has a vendor's flyer on the desk, do yourself a favor - just walk out. Frank Cohen from PushToTest never really talked about testing services in any practical way. Then again, he also didn't do a very good job of demostrating or selling his product, either. It was very much the worst of both worlds, and I actually turned on the WiFi antenna (which I had resisted a few times in some other talks) and checked my email, as well as did a little GoogleTalking with the people back at home. The worst part was, because the room was fairly full when we walked in, we sat in the front row. I felt a little bit bad - Frank seemed like a really nice guy, and in fairness, the tool he was pushing was open source. But he really didn't have much useful to tell me.

The moment we were all waiting for - Scott Ambler. Ok, that's an exaggeration. I've read his articles, listened to webcasts, read some of his books. I really was looking forward to seeing him in person.

His talk was entitled Agile Model Driven Development, but he covered a lot more along the way to that topic. His view of Agile is very pragmatic. He took a few swipes at the dogmatics, which was good, because I could see where he was coming from, and I often find myself on the highway to hell, um, I mean, the religious aspects of Agile. His exaggerated lack of respect for the general tone on some agile mailing lists definitely helped remind me of what it is we are trying to achieve. I think the reason why I wasn't offended was because he pretty much attacked all of the sacred cows in our industry - it was very South Park in that way... :)

I took a boatload of notes, so I'll summarize the highlights:

There was much more, but I think I am heading past attributing and into stealing his content, so I'll just leave it there. If you ever have the opportunity to see him speak, DO NOT miss it. I think when you look at those currently practicing the art of software development, he's one of the 3 most relevant people (at least to me) right now. [The others would be Joel Spolsky, who might be falling a little and Steve McConnell, who is always that much needed voice of reason]

The final Udi presentation of the conference.

Key takeaway - pubsub is generally the best way to build your services - think of everything as long-running. Instead of having your billing service ask your customer service for their current address every time it needs it, have the billing service cache customer data, and subscribe to the customer service to receive updates. The important thing to note here - this is NOT replication. In replication, there is no authoritative source of data - all sources are authoritative. In this scheme, the customer service is the system of record for customer data, and is responsible for it. If the billing service were to encounter a discrepency in customer data, it would ask the customer service for the current data, and use that. There is never a conflcit - the customer service is always right (sorry, that's almost a pun).

As you design your system, think about how it worked before it was automated. An order was faxed in, and handled by various people. Eventually, good would be shipped and a bill sent to the customer. Each of these steps in the workflow are just a process in the business, just now they are automated to improve efficiency (hopefully). Services are not APIs in the RPC style of thinking - they are different parts of the business, and have their own responsibilites. They don't care about what happened before in the workflow (beyond what concerns them) and they don't care what happens after them. When they finish their work, they post events to whomever is subscribed, and let the next processes figure out what to do.

Once again, we went to a presentation by - Intentions & Interfaces - Making Patterns Concrete. We would also attend his other presentation, which was immediately after this one, which of course must make us Udi's groupies... :)

Udi is a very dynamic speaker. He gives the impression that he really knows what he's talking about, and not only that, he has done it. For this presentation, I was so caught up in what he was talking about, and how it would solve problems I have to solve RIGHT NOW, I didn't take especially good notes. So, I'd recommend checking out the link to his slides above for the details, but basically, the premise was to build interfaces for all of the different cases where you would need an object, instead of having a large class with a lot of different methods. If you have a customer object, and sometimes you want all of the orders for that customer (but most of the time you don't), you have two methods (or as someone in the room suggested - one method with a boolean - I've done that as well). Obviously, over time, when you take into account all of the scenarios, you can end up with a lot of methods and a very large class.

The bigger problem, of course, is that these methods are only loosely related (they pertain to the same object, but they don't have the same purpose - a clear violation of the single concern principle. By creating interfaces, and then creating classes for those interfaces, you can pull that functionality out into different classes, and seperate the concerns. It also reduces your coupling - the customer class doesn't have to know about the orderdetails class in order to work with its child orders.

Its definitely a lot of common sense stuff in a way, but I probably never would have thought of it that way. I need to throw together my own reference application to fully assimilate what he talked about - I don't think I'm doing it justice in this post. It was good stuff - got me thinking, anyway...

Randy Miller gave a ridiculously short (under 45 minutes) presentation on Composite Architecture. I went in thinking he would be talking about how one hooks up different technologies into one system, which is a problem we face at McKesson Automation - our product lines are based on various technologies, and our customers like them to work together.

I completely forgot my brainwashing back in my Microsoft Merit Badge days - Composite Applications used to Microsoft-speak for cobbling together an application from various Office applications and enough VB and VBA to make them stick. Randy works for Microsoft. So, it should come as no surprise that Composite Architecture is the updated version of that vision, where instead of hooking together Office products, we're hooking together server products such as SharePoint, BizTalk, Excel Server, etc. Certainly a good solution in a lot of cases, but he didn't really dive into the details very much, or at all for that matter.

The only useful thing he mentioned was adding a "Productivity Tier" between your business logic and presentation logic, to allow for non-human systems to interface with your application easily. Definitely a good idea, if you have the need to take order via a web service, or reservations via a message queue, etc. The Productivity Tier essentially reformats your data into a form that your business tier can use, and that external applications can make use of going the other direction. Of course, its kind of a logical, common sense thing to do, but it is good to mention, I suppose. I just would have rather gone to a different presentation (Rob Daigneau had a presentation, Messaging-Oriented Design Patterns for SOAP Services, that might have been better at the same time).

The first talk I attended on Wednesday was Chris Armstrong's presentation on Agile Enterprise Architecture. I'm going to have to be honest - he started with a 10 minute rehashing of the Agile Manifesto, in his own thinking, and for me it went down hill from there. He is one of those delusional folks that thinks RUP can be Agile (anything with distinct phases for the different activities (requirements/design/coding/testing) is NOT agile). I just couldn't get over the fundamental difference there, and his constant reference to such BIG PROCESS things like TOGAF and IEEE processes didn't help. For an old-school architect, what he was saying was indeed agile, but it wasn't the kind of agile I was expecting. My friend and coworker Jim Patula (no blog) found him to be a half-way decent, so it could just be me.

There were two useful points he made, that I agree with completely - Agile is about minimizing rework (probably more than just that - what about other wastes, but a good thing to keep in mind all the same), and "At the end of the day, Microsoft Project doesn't work".

Rob Daigneau's presentation on Introducing Domain Services was a pretty decently balanced between "astronaut-y" architecture and practical advice. He was a fairly engaging speaker. Probably the biggest takeaway I got from his talk was: "If you want to do anything useful in software, coupling must exist". He spent a good deal of time discussing this paradox - we want to have loosly coupled everything, but at the end of the day, if our code is going to do anything, it has to be coupled to other code in some way. So, in the end, its a matter of determining what type of coupling is best for a given scenario - different systems will have different needs.

He described the types of coupling as:

Larry Constantine talked about Interaction Design for Non-Designers. It was a very 101 level presentation, and there were a lot of, well, yeah, of course moments, but overall, I felt it was worthwhile.

Some of the highlights:

Pramod Sadalage presented on Agile Database Development. I'm slightly familiar with his work, as I have read Scott Ambler's Agile DBA book, on which I believe Pramod contributed. At the very least, the two have also written Database Refactoring together, so I pretty much knew about the topic. I have been taking notes in OneNote all through the conference, and I created a page on which I'm listing things I need to do when I get back to the office (things to research more, or things to talk to someone about - mostly things we should consider re-evaluating). My list of things to re-evaluate grew greatly during this talk. There are lots of little things we could do better database-wise, with regards to our adoption of Scrum.

Our DBA's have a database build script, but its hardly automated, and it depends upon some crazy Access application to run it (yes, you read that right - an Access application to build a SQL Server database). The database team also uses a crazy versioning scheme in SoresSafe. But more importantly, we don't really include them like we should, and talk to them about what we are trying to achieve, and it causes conflict.

The coolest thing Pramod demonstrated was dbdeploy. It doesn't really do anything all that crazy, and yet what it does is pure genius. It will run a series of scripts to bring your database up to date, and also allow you to roll back to an older version. You have to write the scripts, but it manages the process for you, and makes it real easy to get an up to date database for you development or QA environment, or even production (although if your DBAs are squeamish, it will generate the script necessary to go from one version to another). Its nothing complicated, and yet incredibly elegant.

First presentation today was about code metrics. Sure, he threw the word agile in the title, and it had some relevance, but at the end of the day, the talk was about metrics. The presenter was Neal Ford, and he was pretty good. I had mixed expectations coming into this talk - I wasn't sure if it was going to be a lot of crazy math and theories. It turned out to be a really good look at some meaningful metrics, and more evidence against KLOC.

Some interesting points:

Some useful metrics:

My "grand-boss" has been on a hunt for metrics, and KLOC and Feature Points have come up a lot. I'm hoping maybe with this newfound knowledge, I can help steer him away from those outdated metrics... Wish me luck!

The final presentation of the day yesterday was a Birds of a Feather group discussion about what was important to make an agile project succeed. It was lead by Chris Sims, who did an excellent job facilitating. I don't know that I necessarily learned anything, about agile, but I did learn another way to give a retrospective, which in many ways was what Chris led. Going around the room and giving everyone a turn to mention something (after having them write up a list) seems like it would be very empowering to those who often don't speak up - I'm definitely going to give it a try the next time I facilitate a retrospective.

If you're keeping track of fads, Scrum and 2 week iterations are the most popular way for people to do agile, at least according to the show of hands...

I attended Mike Rosen's (doesn't appear to have a blog, and the domain for the email address he gave doesn't appear to have a web site, but you can try searching for him by name and his company, Wilton Consulting Group, which will give you a ton of hits on presentations he's given) talk on Designing Service-Oriented Applications. It didn't quite meet my expectations. It was very high level, architecture-astronaut-y. Mike admitted many times to being a UML guy, and I got the distinct impression he hasn't written any code in years. Guys like him are the reason why I resist the title architect. If you don't have that same bias, it probably would have been a pretty good presentation. Mike's presentation skills are decent, and he does have a lot of experience. I was just hoping for something a little more practical.

The first presentation I attended was an excellent presentation about building distributed systems given by Udi Dahan. He talked a little about his open source enterprise service bus (ESB) nServiceBus. He had a boatload of material, and ran through it all - it was a little bit too much for the time, and yet he managed to do a good job of not crushing us with it all.

Some of the more interesting notes I took:

If you have the opportunity to see Udi speak, I highly recommend it. I'm hoping to get a chance to play around with nServiceBus - maybe I'll have somethign to write about that in the coming weeks.

This week, I'm in downtown Chicago, attending Dr. Dobb's Architecture & Design World. So far, its been well worth it, although as a suburbanite who has never really had to deal with city life, I am somewhat shocked by how damn expensive a 10 minute cab ride is... :)

I'll try and give a brief recap of each session I attend over the next series of posts.

I'm sure everyone knows this already, but I figured since I have no worthwhile recourse with Dell, I'd complain about it on my weblog, and at least make me feel better that I might have disuaded one person from buying a Dell printer...

Anyway, Dell printers (specifically, the AIO 962 in my case) have timebombed ink cartridges. I have heard rumors that other companies do this to, I don't know specifics, but check carefully - its not hard to find out via an internet search. What this means is, if you don't print terribly often, and you have a spare ink cartridge hanging around, the cartridge might expire before you put it into the printer. It will probably still print just fine, but Dell has planted a chip in there to say it won't, and you can't really do anything to convince your printer otherwise.

This seems about right.

My friend Rich just posted on his blog about 4 openings. At my company (McKesson Automation), we have a bunch of openings that we are having a hell of a time trying to fill. I wouldn't say its the Roaring 90's again, but it seems to be a pretty good time to be a developer in Pittsburgh.

If you work with Microsoft technology, as a developer, QA, or sysadmin, contact me if you want to know more...

One of my fellow developers is making the transition from VB6/ASP/COM+, and moving into the .Net world (he's be chained to a product that hadn't been scheduled for upgrade, but now it finally is). He's been asking some good questions. Here's one I'd like to share…

Question:

Are there any string truncation methods in C# that remove a number of characters or substring from the end of a string?  I've been playing with TrimEnd and it seems to ignore anything I try.  My purpose is that I have built a string dynamically (SQL statement) in a loop and I need to remove the last "UNION ALL" keyword I add.

Answer:

The biggest problem is that the string functions in .Net to do not replace the string you are working on – instead they return the resulting string. This is behavior is more flexible, but entirely different from the way things used to work in VB6, thus leading to confusion. Here is a snippet that will do what you are looking for:

string crap =

"SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL";

crap = crap.Remove(crap.LastIndexOf("UNION ALL"));

Another thing, though, if you are building a really big string, you might want to consider using the StringBuilder class. The way I'd get around the extra UNION ALL is to not write it in the first place – create a bool, check to see if it's true in your loop, and if it is, write the UNION ALL before the rest of the stuff you were going to write in the loop. Then, if it isn't true, set it true, so that the next time through you'll get the proper UNION ALL written:

string[] selects = {"select 1", "select 2", "select 3"};

StringBuilder builder = new StringBuilder();

for(int i=0; i<selects.Length; i++)

{

if (builder.Length > 0)

{

builder.Append(" UNION ALL ");

}

builder.Append(selects[i]);

}

Console.WriteLine(builder);

Actually, I cheated on the bool – I just used the fact that the StringBuilder would be empty. But it's basically the same thing…

Sure, the documentation leads you to believe you can use them. The mapping files even support it. But once you try and add a new item to a collection of objects that has a composite key, it breaks down. It doesn't give you an error - it politely lets you think the collection saved. But go check the database - the records aren't there.

I took a quick look in the code (not enough to say with any certainty I can even spell NHibernate correctly, mind you), and I can't see any way for NHibernate to know that the objects in the collection aren't saved. I did read in the help file that you can use an Interceptor to figure it out, but that seems to be a lot of pain for little gain. So, while reading in the collection works, and I assume updates would, inserting just ain't happening. Fortunately, I was able to convince our DBA to change the tables, but not until I lost most of the day trying to figure out how to make it work.

If anybody knows a solution, I'd love to hear it. Otherwise, let me stand as a warning to you. Hopefully the time you save will be your own.

My friend Rich Dudley asked via a comment on my last post for some advice on database version control...

Well, I don't really have any good advice for database source control - our former head DBA swears by VSS, and the remaining ones haven't had time to come up for air an re-evaluate. (What does that tell you about our former DBA?)

However, after thinking about it a little, here's what I'd probably try: Have each table in its own script, create a build that executes each one in sequence, and keep them versioned that way, and you can do the same for views and stored procedures (hopefully you have no triggers :)). You probably need to define a convention as to which side you'd keep the foreign keys, to avoid conflicts. I'd recommend on the "parent" table - that way you can easily find out what tables depend upon it.

As far as that build part goes, if you don't have one already, I know there are NAnt tasks you could use, and there is probably an MSBuild task or two (if not, its really easy to create one). The pain part is keeping track of the dependencies. Seems like a task that is screaming for a quick and dirty tool. :)

Anyone else have any advice to add, or see any obvious holes in my suggestions?

I have spent my whole career wearing multiple hats, probably mostly because of ADD or something. I do tend to get bored if I'm not doing a wide variety of things, no matter what the reason. I've been lead developer, technical support, network engineer, database administrator, product manager, business analyst, build manager, installation developer, and probably other roles. I'm not saying this for the ego stroking, but to point out that there are real world examples of generalizing specialists, and I firmly agree that it is a good thing.

Lately I've been doing a lot of installation, build, and source control work. It fits in well with my other role of leading/mentoring, because it can be interrupted fairly easily (unlike, say, trying to figure out the subleties of fixing some problems with getting NHibernate and our crappy legacy data model to play together nicely, which is the work I probably should be doing - fortunately, there are some very talented people on the team dealing with that problem (although I do get sucked in to that, too) so I can focus on helping everyone else). Since I've been reading and exploring agile development, I've come across a lot of very good resources, which I either have shared or plan to share via this blog. We've finally hit the point where the rubber hits the road - our team has embarked on using Scrum (not very well at the moment - I thought you could just implement it little by little, and while its helping keep things on track than the chaos we used to have, it isn't giving us the full benefit it could - we're working now to correct that...). Anyway, enough mental masturbation context setting...

One really awesome resource for Scrum, beyond the usual suspects, is Henrik Kniberg. His latest article on agile version control is exceptional. I had been contemplating branching for every story, and merging the story branch back into the trunk, in order to keep the trunk releasable. It aligns with one version control practice I have read about of a branch per feature, but a story is finer grained than that definition of feature, so trying to maintain that would have been a nightmare. Henrik's method is to have a branch for each Scrum team, and then merging finished stories into the trunk, which seems like MUCH less trouble. The one complication is trying to figure out what files should be merged into the trunk. I think we can accomplish this by using StarTeam Change Requests to manage what check-ins belong to each story, and migrating change requests up to the trunk.

One other thing that will make this us do is ensure that stories are independent, and our code is properly broken into classes with a single responsibility each. Otherwise, this will still be hard to manage. But that "pain" will decrease over time, as we get better at writing GOOD user stories and GOOD object-oriented code.