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 just took a 2-day Certified Scrum Master class from Innovel taught by Mark Pushinsky. I guess that makes me a certified Scrum Master, although I have to say it was the least rigorous certification I've obtained to date - all you had to do was attend class and participate.

We have been dabbling in Scrum for my current project, through my decision to utilize a Scrum-like approach, and with my boss's support (he has been pushing for iterative development since before I got there, so he's happy to let me guinea pig it). Now that we've been playing with it, and because the training class was available in Pittsburgh (no travel costs!), it seemed like a good time to move beyond learning from the books and web sites, and pretending, and get some actual training on the topic. I have to say, having sat through a lot of crummy training, and some good training, and having taught some classes myself (I used to be an MCT back in the VB 6-SQL 7.0 days), that Mark is a very good instructor, and I found the training to be valuable. At no point did I find my eyelids sinking.

Seriously, though, it was good to have been through the training. I found some things that we aren't doing that we should be doing, and some things that we are doing wrong. The one key take-away: if you are going to try out Scrum, even if you don't bother getting training (and you probably can fake it well enough just by following along with a book or web site (reviews of some of the resources I've used will be coming soon), you really should pick a project, and do ALL of Scrum. Not just a few things to get you going. Not everything but the 2 things you don't like. All of it. And then evaluate from there. Mark gave this advice, and having not done that on the project, I can definitely see how what we are doing isn't going to give us the same value as if we had done it right.

Smart Client Deployment with ClickOnce is probably the best book out there on ClickOnce. On the other hand, its also really the only book out there on ClickOnce. Its a very good summary of the somewhat convoluted info available on MSDN and other Microsoft sites - it definitely made some things much clearer. It is somewhat lacking in how you would actually use ClickOnce in the real world, unless you are developing internal apps and have a fair degree of control over your servers and your users.

If you are doing anything with ClickOnce, you should definitely buy this book. Just keep in mind that you'll probably need to do some digging on your own afterwards, but this book should make that easier, because it does cover most of the terminology you'll need, so you'll have some starting point for your search.

One thing that the book and my experimenting made very clear, however, is that ClickOnce is an awesome solution if you are in control of the infrastructure, but falls down completely if you aren't. For example, on the project I was looking to use ClickOnce for, we deploy a server and clients as near-shrinkwrap to hospitals. ClickOnce requires signed files, and so you would have to deploy the signing certificate on each of those servers, since one of the files that has to be signed is the configuation file, which tells the client where the server is. So, we would have had to come up with a way of deploying a certificate in such a way that nobody other than our personnel could get it, or we'd have to generate a cerificate for each customer, and keep track of who had what certificate, which would be a support nightmare. In the end, we elected to continue pushing out updates "by hand" (which is a real PIA) until we get the certralized application management suite we purchased fully ready to handle pushing out updates from our servers.

Real World Software Configuration Management is a decent introduction to the world of Software Configuration Management (SCM). It is a fairly light read (took me a weekend in between plays while watching college and pro football). Part of the reason for the light read is that is doesn't go into a lot of detail about anything you probably don't know, and does go into painstaking detail about build details you probably have seen before.

If you are looking for a lot of detail about how to manage Source Control for a complicated product development, or other large project, it probably isn't a very good book for you. I was looking for detail about how to best handling branching and promotion states, which are two topics it hardly mentions. It also dwells on CVS and VSS, which are now fairly obsolete source control systems. On the other hand, it does provide a pretty good introduction about SCM in general, and things that you should know about. Given that Amazon is now selling it for $10, its probably a good deal, if you need a good introductory tome about SCM. If you want more detail, go elsewhere.

...and I'm not sure I did very well. The test has a lot of questions about obscure stuff - and definitely assumes you do infrastructure, WinForms, AND WebForms. At least there wasn't anything about Culture and Globalization (two very big topics on the last round) - does anybody even do any of that?

A fair number of questions about threading, especially the BackgroundWorker. Quite a few about Master pages and Web Parts (which I haven't even played with yet - I think that gamble didn't pay off... :)) Click Once also figured heavily, as did security, both Identity/Role and Code Access Security.

I remember some questions about the new encryption classes, as well.

Several of the questions were well structured such that if you didn't know the exact details, but were familar with the concepts, you could manage to narrow it down to what was probably the right answer.

But therein lies the problem - I was hoping to see a test that probed you as much about your thinking as it did about your understanding of Microsoft .Net trivia, and that still is not the case. The process is still very much cram and rote, which doesn't do anybody any favors.

But, I'm sure I'll keep on the wagon because I'm [1] a glutton for punishment, and [b] a certification addict.

I'm taking 70-554 in two weeks - at least I have some idea what to expect.

You knew they would eventually, but they finally went and did it.

Less cynical people might instead think they crossed the Rubicon, and this is the beginning of great things, but everyone has tried to put a word processor on the web, and no one has bought it. I don't think this time will be any different.

red-gate software has released a new tool, SQL Dependency Viewer. It is currently free, but it is in beta. They haven't announced any pricing or bundling, so we'll see how that turns out, but I've used their comparison tools before, and have always been impressed with them.

It's not exactly feature rich - it just shows a diagram with all of your database objects in it. If your database is at all large, the diagram is pretty unwieldy. There doesn't seem to be any way to limit it to just a certain set of objects (like perhaps everything dependent upon one base table). I'm not sure it's terribly useful at the moment, but it has potential if they improve the navigation. The nice thing is it includes non-table objects, like stored procedures. It is an improvement of EntMan's dependency view (which isn't even resizable).