Set a low blocked process threshold. Here’s how to configure it using SQL Server Management Studio. Run a stored procedure sp_configure and look for a variable named blocked process threshold in its output. If the configured value (in seconds) is too high, run the following commands to set it to 5 seconds:

sp_configure 'blocked process threshold', 5

reconfigure

How to get Blocked process reports using SQL Server Profiler. Open SQL Server Profiler and start a new trace. In the TraceProperties dialog, Events Selectiontab, uncheck all events.

Check the Show all events check-box. In the long menu of events, expand the Errors and Warnings node and check Blocked process report. Check Show all columns and check all possible check-boxes in the Blocked process report row.

How to interpret the blocked process report. The report contains, in an XML-like format, information about the blocked and the blocking process. The inputbuf elements let you see the SQL code your program is running, but sometimes they only identify the executing database object by ID, like this:

Proc [Database Id = 11 Object Id = 1744113354]

Then a simple query (in SQL Server Management Studio)

select object_name(1744113354)

identifies this object as a certain stored procedure. Okay, I probably won’t forget this part.

The blocked-process element contains execution stack, but there is one problem: its frames are presented in a very cryptic way, like this:

<frame line="1" stmtstart="74" sqlhandle="0x02000000ec598609171ca0e0d3bae80cc5a4c0e34169572c"/>

To decode them, the following one-line query is handy:

select * from sys.dm_exec_sql_text(0x02000000ec598609171ca0e0d3bae80cc5a4c0e34169572c)

That’s about it for now. For real database knowledge, read Michael’s blog. Here, I just want to write down a few things that were important to me in the last few days to make sure I don’t forget.

<ArrayOfBase>
    <Derived1 />
    <Derived2 />
    <Derived1 />
    ...
</ArrayOfBase>

I remembered doing exactly that a while ago, but I couldn’t remember exactly what I did. But it wasn’t difficult for us and didn’t take long to find the answer. Here it is:

Class RowSet is a DTO (data transfer object) containing a matrix of data cells.

[Serializable]
public class RowSet {
    [XmlElement( ElementName = "row" )]
    public Row[] Rows { get; set; }
    ...
}

Note how the XmlElement attribute is applied to a collection. It defines serialization of individual elements rather than the collection itself. Row is defined as a one-dimentional array of abstract Cells.

[Serializable]
public class Row {
    [XmlElement( Type = typeof( DataCell ),
                 ElementName = "d" )]
    [XmlElement( Type = typeof( NullCell ),
                 ElementName = "n" )]
    public Cell[] CellArray { get; set; }
    ...
}

Cell is an abstract class and DataCell and NullCell derive from it. RowSet serialized into XML looks like this:

<rows>
    <row>
        <d value=... />
        <n />
        <n />
        <d ... />
        ...
    </row>
    <row>
        ...
    </row>
    ...
</rows>

Quite a few people used an app named Twifficiency, which advertised itself as follows: “In a nut shell, Twifficiency calculates your twitter efficiency based upon your twitter activity. This includes how many people you follow, how many people follow you, how often you tweet and how many tweets you read.”

The highlighted part looks like a red flag.

The test is based on a simple idea: answer 12 yes-or-no questions and if you answered “Yes” 12 times or close to that, you have a very mature and effective software engineering organization. If most of your answers were “No”, then you’re in serious trouble, or you will be when your hero programmer decides to leave. Regardless of how you score on this test, the questions you answered “No” tell you how you can improve.

Before you begin to criticize this test, consider that it was written a very long time ago and in what was a really a different era (the Agile Manifesto was published only the following year and we think Agile has been around for a while).

Over the last ten years, countless software developers asked themselves these questions, thought “we should really be doing this this…”, and then actually did it. At the same time, advancements in our profession were taking place and chipping away at the relevance of these questions.

Do you use source control? Is that even a question?

Do you make daily builds? Here, there may be a big difference between two ways to answer “yes”, for instance, between running a script every 24 hours just to build the thing and improvement based on continual feedback from a continuous integration system.

Do you have a spec? “No” may now even be the preferred answer. Imagine an awkward scene: someone walks into a room full of Agile Manifesto signatories and asks, “Do you guys have a spec?” True, there is an important place for specification in agile software development (such as executable specifications used in agile acceptance testing), but the spec described in the Joel Test is of a different kind, the big one written up-front and before everything else.

Do you do hallway usability testing? Okay, if you are a software developer and you never leave your desk and expect your manager to give you tasks, then you are probably developing something unusable. (Mike Cohn wrote in User Stories Applied that software development managers are some of the worst user proxies.) If that is your situation, you can discover a lot by stepping outside the cubicle and asking someone to use your program. But your team can probably discover the same insights, only earlier, by applying user stories and engaging in conversations with more relevant user proxies.

You would probably be right to interrupt me at this point by asking, wouldn’t such a list constitute a process? Doesn’t the Agile Manifesto teach that we should value individuals and interactions over processes and tools?

You would be right because the Agile Manifesto says nothing about using, for example, continuous integration. But how many of the early adopters of agile refuse to use it? Hardly any. At the same time, the word agile is used by many more people now than ten years ago and stories like “we’ve implemented scrum; we now hold status meetings daily instead of weekly” abound.

So, the list of recommended practices will of course come with disclaimers and caveats. Each listed practice is optional and following all of them won’t automatically make you agile. But let’s try to compile the list first.

I visited a blog, NOOP.NL, whose author, Jurgen Appelo, is both a recognized agile expert and seems to be a fan of top-100 lists. He did The Big Agile Practices Survey a while back and then published the results. Out of the survey’s many questions, I decided to consider the following three:

• Which practices are REALLY AGILE, or… highest level of agility?
• Which practices are REALLY IMPORTANT, or… highest level of importance?
• Which practices are REALLY APPLIED, or… highest level of application?

Which practices are REALLY AGILE, or… highest level of agility?

Which practices are REALLY IMPORTANT, or… highest level of importance?

Which practices are REALLY APPLIED, or… highest level of application?

Several observations can be made:

• Notice the amazingly high percentages of respondents who said that they associate a particular practice with agile, believe that it is important, and actually apply it.
• The identified practices are not constrained to any particular agile method. For example, there is no mention of pair programming (an XP practice) and the respondents didn’t say the scrum master has to be a designated person.
• Some of the practices are mentioned more than once. The Product Backlog occurs in all three lists.
• Let’s say you don’t have a product backlog. The Agile Manifesto doesn’t say you must have it. But it should be clear now that either you have a good reason not to have it or you are missing something important.

By joining the three lists and removing the duplicates, I got a list of 21 practices. I removed the percentages (they are now unimportant), grouped related practices together and renamed the areas. Here is the result:

Now I want to take one more simplifying step: get rid of the tabular form of information.

Start with people. You need a scrum master and a self-organizing team. Timing-wise, your process is iterative, uses fixed-length, time-boxed iterations and emphasizes sustainable pace and frequent releases. What do you do in each iteration? You start with a product backlog, which is maintained to reflect your current prioritization of requrements. Once you have it, you can hold an iteration planning meeting at the start of an iteration and select user stories into the sprint backlog. Now, what techniques to you use to engineer the solution to satisfy your customer? Well, source control is a must, daily, automated builds (probably enabled by a continuous integration system) are helpful. There are no recommendations on how to design and write your code, but it is recommended that you refactor it. Then there is a three-pronged testing strategy: unit-, acceptance and integration tests. (Serious QA strategy will have more prongs, but we are talking about the minimal agile-specific set.)

Lastly, and most importantly, there is feedback, lots of it and in various forms. The daily scrum (or, in a literal translation from one of the foreign languages, the synchronization reunion!) and the iteration demo, when there is no avoiding the question: what is our definition of done? Retrospectives to improve the teamwork and fine-tune the practices. Velocity is very important in agile estimation and planning and to track velocity you need story points.

OK, getting to this list was labourious, but the result itself is compact as I promised at the beginning of the post.

Here are the tabulated results. Not only there is no clear winner, we have several strong contenders.

I started following Top 200 Blogs for Developers posted on NOOP.NL in the first half of the year. Throughout the year, I found several cool blogs that weren’t originally on the list and unsubscribed from others to reduce the list to something that I both find useful and have time to read regularly. I didn’t use rankings or follow any algorithm; when I liked a blog post and found it relevant at the same time, I simply moved it into a separate folder.

What do these blogs write about? New trends in software, programming techniques, new languages and frameworks, software craftsmanship, clean code, test-driven development, managing software development, agile, and many more topics.

I’d probably go as far as to say this blogroll is probably the only thing of value this blog produced in 2009.

“Fission” is the name of Desire2Learn‘s internal software developers’ conference. The organizers chose this name apparently to be the opposite of the Fusion, which is the name of the annual user’s conference. My talk was on a general software development topic, didn’t contain any D2L-specific, so I made only a few minor edits to the slides.

I felt strongly about speaking on this topic. Writing good, maintainable unit tests is becoming increasingly more important, isolation (or mocking) plays a critical role in that, yet few developers really understand how to do it. My goal was to show why and when to isolate, how to do it right, what tools are available, clarify the most confusing terms (Mocks? Stubs?) and give listeners pointers to resources to learn more.

The talk was designed to fit into a 30-minute slot (it did!) with a few minutes left for Q&A. Enjoy!

But what was the problem?

First of all, the open-source product has two different distributions: downloadable binaries for end users and a source code repository for developers and contributors (and end users who want to peek at the source code!). The repository contains the production code, which compiles into those binaries, and — because it was written in the modern clean-code, TDD manner — a bunch of automated tests. The tests have dependencies on third-party tools. The problem is, can we include those tools in the repository? Is their license text required, no, is it even legal? What is the common practice?

It turned out not many people know the answer or understand this kind of stuff – just read the answers I got.

Before I reveal the correct answer, why do I want to check in those tools? I want to send a message that tests matter and this is how we do things here. At the same time, I want it to be very easy for the potential contributors to check out the code and run tests right away! I don’t them to worry whether they should download NUnit version 2.2.8, 2.4.7 or 2.5.2.

OK, the correct answer: based on my analysis, here, the common practice is to check in such dependencies. A copy of the license must be included if the third-party product’s license requires it. I learned along the way that the Apache license has such a requirement, while zlib and the New BSD License(a. k. a. the “three-clause BSD) do not.

Degrading Web Apps Gracefully (appeared on the Linux Foundation’s Web site in April) discussed how to build Web applications such that they work on many different browsers in use these days. I contributed two bits of advice. In the Write for the Audience section, I reflected on what we did at WhenU to collect data and know the breakdown of our userbase by the combination of OS and browser. In the following section, Testing is a Must, I described how virtualization technology, VMWare in particular, can be used to test those combinations. I also made a reference to the minor deviation of the HTTP protocol implementation on Chinese- and Korean-localized versions of Windows that burned us at the end of 2005.

While contributing to Convincing the Boss to Pay for Developer Training, I stated my belief that developers get a lot more from books kept on their desks than books kept on a common shelf or a company library that they have to walk to. They simply open the book much more often.

An finally, a great article Gosh, Things Are Better for Developers These Days came out in June. People were asked to name what is important in software development today that didn’t exist ten years ago. We actually found quite a few things that seemed new but existed in the 1990s and several things that seemed old but definitely invented after 2000. Although none of the contributors were mentioned by name, the “LinkedIn friend” in the 4th paragraph from the bottom, speaking about test-driven development, unit-testing and mocking frameworks was me. I also pointed out to the author that the Design Patterns book by the Gang of Four was published in 1994, so it was not 10, but 15 years old. I was very surprised myself when I looked that up and thought that was a good counterexample.