TFS : The Real Picture

For every technology, there is the theory you learn and then you have to implement it in real world. You can find books for theory but for real implementation, there are hardly any. For TFS though, there is a guide on CodePlex which describes how TFS should be used in real projects. Excerpts from the site:

This guide shows you how to make the most of Team Foundation Server. It starts with the end in mind, but shows you how to incrementally adopt TFS for your organization. It’s a collaborative effort between patterns & practices, Team System team members, and industry experts

patterns & practices: Team Development with Visual Studio Team Foundation Server


Trigger Gotchas

While working with triggers, I noticed a couple of unexpected behaviors in SQL Server.

1. Let’s say you have an INSERT statement something like this:

INSERT INTO SomeTable VALUES (Col1, Col2)
SELECT Val1, Val2 FROM SourceTable WHERE 1=0

The select statement is never going to return any rows due to the where clause (always false) and nothing would be inserted into SomeTable. So, if there is an AFTER INSERT trigger on SomeTable, what do you think about it. Should it fire? Remember, there is not going to be any insert.  If your answer is NO ( as it was mine and few others too), think again. Because it DOES fire.

2. Another situation. Lets have the same INSERT statement but without any WHERE clause. So the query will be something like this:

INSERT INTO SomeTable VALUES (Col1, Col2)
SELECT Val1, Val2 FROM SourceTable

In this case if SourceTable has 100 records and there is an AFTER INSERT trigger on SomeTable, how many times that trigger should fire. Remember, there are going to be 100 new rows in SomeTable. If you answer is 100 (as it was mine too, again), check Books Online once more. The trigger is going to fire ONLY once.

One thing to note in both situations is that the LOGICAL tables have the correct information. That said, INSERTED logical table is going to be empty in first example and it will have 100 rows in second one. So, these logical table are your best bet. This behavior is same for DELETE and UPDATE after trigger too. Means, if you execute a delete or update statement which will not affect any row, triggers will fire regardless and it will fire once per statement NOT per affected row.

Hope this will helps. Enjoy!

Coder to Developer

I read something which was fun, reality and worth reading. Joel Spolsky wrote foreword to Mike Gunderloy’s book, “Coder to Developer”. Here it follows as is:

You know what drives me crazy?

“Everything?” you ask. Well, OK, some of you know me a bit too well by now.

But seriously, folks, what drives me crazy is that most software developers don’t realize just how little they know about software development.

Take, for example, me.

When I was a teenager, as soon as I finished reading Peter Norton’s famous guide to programming the IBM-PC in Assembler, I was convinced that I knew everything there was to know about software development in general. Heck, I was ready to start a software company to make a word processor, you see, and it was going to be really good. My imaginary software company was going to have coffee breaks with free donuts every hour. A lot of my daydreams in those days involved donuts.

When I got out of the army, I headed off to college and got a degree in Computer Science. Now I really knew everything. I knew more than everything, because I had learned a bunch of computer-scientific junk about linear algebra and NP completeness and frigging lambda calculus which was obviously useless, so I thought they must have run out of useful things to teach us and were scraping the bottom of the barrel.

Nope. At my first job I noticed how many things there are that many Computer Science departments are too snooty to actually teach you. Things like software teamwork. Practical advice about user interface design. Professional tools like source code control, bug tracking databases, debuggers and profilers. Business things. Computer Science departments in the most prestigious institutions just won’t teach you this stuff because they consider it “vocational,” not academic; the kind of thing that high school dropouts learn at the local technical institute so they can have a career as an auto mechanic, or an air-conditioner repairman, or a (holding nose between thumb and forefinger) “software developer.”

I can sort of understand that attitude. After all, many prestigious undergraduate institutions see their goal as preparing you for life, not teaching you a career, least of all a career in a field that changes so rapidly any technologies you learn now will be obsolete in a decade.

Over the next decade I proceeded to learn an incredible amount about software development and all the things it takes to produce software. I worked at Microsoft on the Excel team, at Viacom on the web team, and at Juno on their email client. And, you know what? At every point in the learning cycle, I was completely convinced that I knew everything there was to know about software development.

“Maybe you’re just an arrogant sod?” you ask, possibly using an even spicier word than “sod.” I beg your pardon: this is my foreword; if you want to be rude write your own damn foreword, tear mine out of the book, and put yours in instead.

There’s something weird about software development, some mystical quality, that makes all kinds of people think they know how to do it. I’ve worked at dotcom-type companies full of liberal arts majors with no software experience or training who nevertheless were convinced that they knew how to manage software teams and design user interfaces. This is weird, because nobody thinks they know how to remove a burst appendix, or rebuild a car engine, unless they actually know how to do it, but for some reason there are all these people floating around who think they know everything there is to know about software development.
Anyway, the responsibility is going to fall on your shoulders. You’re probably going to have to learn how to do software development on your own. If you’re really lucky, you’ve had some experience working directly with top notch software developers who can teach you this stuff, but most people don’t have that opportunity.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
He praises the book here in one paragraph and then continues on the topic :).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Being a software developer means you can take a concept, build a team, set up state of the art development processes, design a software product, the right software product, and produce it. Not just any software product: a high quality software product that solves a problem and delights your users. With documentation. A web page. A setup program. Test cases. Norwegian versions. Bokmål and Nynorsk. Appetizers, dessert, and twenty seven eight-by-ten color glossy photographs with circles and arrows and a paragraph on the back of each one explaining what each one was. (Apologies to Arlo Guthrie.)

And then, one day, finally, perhaps when it’s too late, you’ll wake up and say, “Hmm. Maybe I really don’t know what it really takes to develop software.” And on that day only, and not one minute before, but on that day and from that day forward, you will have earned the right to call yourself a software developer. In the meantime, all is not lost: you still have my blessing if you want to eat donuts every hour.