Month: October 2006

This article on how to spot bad security/cryptography by Bruce Schneier dates back to 1999, but is still relevant today. I have several of Bruce’s books; he’s always a good read.

Rob Farley just pointed me to Crucible’s blog where he has a write up on the sessions held at SQL Code Camp in Wagga over the weekend. Sounds like it was well worth attending. Some of the material is available online from the various presenters blogs. We were lucky to have Greg Linwood here in Perth a few days earlier where he presented two SQL Server indexing talks, so I didn’t miss out entirely!

Planning the Meeting

• Whenever possible do not meet!
  – Meetings are time consuming, so decide whether a meeting is the best way to handle the issues/topics?
• Define the purpose of the meeting
  – Write down a clear goal and desired outcomes
  – Decide who should attend based on the desired outcomes
• Keep meetings short
  – Do not allow meetings to overrun
  – If there is unfinished business, schedule for another time
• Always issue a meeting notification
  – Give attendees sufficient notice to enable them to prepare any relevant material
  – State the place and time for meeting
  – State the duration of the meeting
  – Confirm attendees acceptance
• Always distribute an agenda to attendees before the meeting takes place
  Include:
  – Meeting objectives
  – List of discussion topics
  – Place highest priority items first on agenda
  – Provide attendees with any required background information
• Make sure that speakers are prepared for the meeting
  – Unprepared speakers will contribute little
• A meeting should have an owner or chairperson
  – The chairperson should open the meeting by describing the meeting objectives and expected outcome of the meeting
  – The chairperson should ensure speakers adhere to the agenda and time allocated
• Make sure that speakers are prepared for the meeting
  – Unprepared speakers will contribute little
• Make sure the facilities are prepared for the meeting
  – Arrange any audio-visual equipment or materials in advance. Arrive early to set up and make sure everything is ready to use

Running the Meeting

• Start the meeting on time
  – Do not wait for latecomers
• Start the meeting by reviewing the meeting agenda and objectives
  – Begin by introducing anyone who is not known to the other attendees
• Appoint someone reliable to take minutes
  – Ensure that the minutes are accurate
  – If it is not recorded it probably will not happen
• Stick to the agenda
  – Maintain focus, keep the discussion on track
  – Summarise conclusions or decisions as each agenda item is completed
  – Non-agenda issues/topics should be noted and discussed in the last 5 minutes of the meeting, and if unresolved, tabled for another meeting.
• Assign action items
  – Identify and assign any action items to specific people with completion dates
• Explicitly close the meeting
  – Before closing the meeting determine if the objectives were met
  – Request comment from all attendees, and enter into the minutes
  – Chairperson should provide a concise summary of the meeting’s outcome
  – Issues/topics requiring further discussion should be noted
• End the meeting on time
  – Often people will have other scheduled work to go to
• Minutes should be published and made available to all attendees

Meeting Follow up

• Communicate the meeting’s decisions to those who are affected by them
• Make sure copies of the minutes are distributed
• Remind people what they agreed to do

I was interested to see that Nick Randolph mentioned the role of interaction designer recently on his blog, when discussing the demarcation of roles in the design/development process, prompted by disagreeing with Brian Madsen’s blog post, following Greg Linwood’s presentation. I’ve been talking about this essential role for a number of years and I mostly get blank stares or a bit of eye rolling, and/or finger twirling when I do!

Although I agree that interaction design is a vital part of the development process, I disagree with Nick when he states “This role [developers] should NOT be concerned with how indexes are structured etc,…”. I believe that developers SHOULD have an understanding of how indexes are structured and used. In fact, the principle of treating systems in a more holistic fashion avoids ‘pigeon holing’ and the “it’s not my problem attitude”. In larger teams, it is highly beneficial to have people spanning roles so that they can bring understanding and promote communication between disciplines and teams.

Interaction Design is something I passionately believe in as a way of ensuring that software meets and (better still) exceeds users’ expectations. The aim should be to create applications that need little or no help, “I shouldn’t have to read the manual to understand how it works”. It is possible. I have used the technique to produce a very successful application, which required minimal training even though the system contained a reasonable amount of complexity. One recent UI technique that I think should be highly valued is the ability to add ‘watermarked’ text (pale gray) to empty controls. For example, in a person’s name control you could set the watermark text to “Wheat, Mitch” explicitly showing the format the field expects data to be entered in. This eliminates ‘cognitive friction’ on the part of the user because they don’t have to think “Is it last name first, followed by a comma, or should a name be entered the way it is read?”.

In fact, more than just creating systems that are easy to use, our aim should be to create passionate users. Kathy Sierra and others, post wonderful articles on creating passionate users here.

Interaction design is something Alan Cooper (the father of Visual Basic) has been involved with for some time (you could even say he pioneered it), and has published several great books on the topic, the most notable being The Inmates are Running the Asylum, but also About Face 2.0.

For anyone about to convert an existing .NET 1.1 application to 2.0, here is a list of runtime breaking changes.

These four words encapsulate the most important and fundamental rule of design:

Be Your Own Client

or to put it another way: Put yourself in the place of the user (consumer).

One of the most common uses of reflection is in the use of plug-ins, such as toolbars or hosting third party plug-in functionality. A developer I worked with recently was unaware of the appropriate uses of reflection (let’s call him Bugsy!). I’d like to direct him to the words of Joel Pobar, who you might say is an expert on this topic (Joel is a Program Manager on the common language runtime (CLR) team at Microsoft, at least he was till last week!):

When Should You Use Reflection?
You should always think carefully about how you’re using reflection. Using reflection occasionally without enforcing strict performance criteria is probably fine. If reflection APIs are only invoked when you’re calling the part of your app that loads and invokes a third-party plug-in, then the cost should be reasonable. However, if your scenario involves a high-volume ASP.NET Web site that requires good throughput and response times, and if it makes significant use of the heavy reflection APIs in your “fast path” (the code in the application that must run very fast and is used repeatedly), you should really consider an architectural review to decide if you’ve made the right decisions on your use of reflection.

Where was he using reflection? Between the business rule and data access layers in an ASP.NET 2.0 financial application! (and no, he seemingly had not heard of code generation, despite several attempts to enlighten him). That architectural review sounds appropriate…

Relative performance of Invocation Mechanisms (image from MSDN article)

Scott Hanselman has a Hanselminutes webcast on the subject here.

How can you improve the speed of reflection based calls? J.D. Meier’s post details the use and the performance benefits of the new .NET 2.0 reflection API:

“RuntimeMethodHandle works approximately twice faster than compared to equivalent GetXxx API call, if the MemberInfo is not present in the back-end .NET cache”

To round off this post, here’s yet another free resource from Microsoft “Improving .NET Application Performance and Scalability” (all 1150 pages of it!)

“Information is segmented by roles, including architects, developers, testers, and administrators, to make it more relevant and actionable. This guide provides processes and actionable steps for modeling performance, measuring, testing, and tuning your applications.”

By complete coincidence, I’ve been talking to a colleague about .NET performance tuning and I’m hoping to put an article together in the near future, so stay tuned.

Greg Linwood gave an excellent presentation of his SQL Server “Indexing for Developers” talk at the Perth .NET User Group last night. He covered the use of clustered and non-clustered indexes and how they actually work ‘under the hood’.

I believe that it is important for developers and architects to understand these topics, as databases are often created without regard to how they will be used in production, with the effect that production systems do not perform as well as they could do.

Greg is presenting another talk this evening (details here) aimed at database administrators (but also relevant to developers) on managing indexes. If you work with SQL Server, I strongly recommend you attend these talks when Greg presents them at a local User Group near you.

If you don’t receive the MSDN Flash email, you may not have come across RSSBus. It allows creation of RSS feeds from a variety of sources, such as databases, spreadsheets, e-mails and folder content. It looks very interesting and I can think of a number of uses within an enterprise.

Fancy a few nuggets, without the secret herbs and spices? I stumbled across the MSDN Nuggets site at Microsoft UK. It has been created by the Microsoft UK Developer and Platform group, and looks interesting. As a nice touch, the monthly archives are downloadable as a single zip file (why can’t you do this with webcasts by track on the main Microsoft site? Please?).

Don’t have the time to read a 10-page how-to article or watch a full length
webcast? Try an MSDN Nugget, a webcast that takes you step-by-step to
discovering new functionality or exploring a hot developer topic, all in 10-15
minutes. View them online now or download for later reference.

Mike Ormond‘s blog has links to online/offline viewing tools here.