I've linked to a couple cheat sheets in the past (Powershell and CSS), but I've run across a post that lists a bunch for different languages and frameworks. Most of them are available as PDFs. See webtecker.com.

The image is from a VisiBone advertisement. That company sells some great cheat sheets and cheat books.

Here's a very interesting interview of Jason Fried (of 37signals) by Walt Mossberg. It's from a conference on innovation in business. Jason explains how 37signals' business model helps them avoid the pressures of feature creep and how that makes his product a success. He emphasizes the use of the word "No" in developing software and trying to please everyone is the road to mediocrity. He comes up with a fitting analogy using Italian restaurants, but you'll have to watch the interview to hear it. The interview goes on to examine how feature creep affects the success of open source.

Here's an interesting write-up that summarizes several sources of information about Amazon and high scalability systems. I thought some of the bullet points were pretty insightful...

• Between 100-150 services are accessed to build a page.
• Take it for granted stuff fails, that's reality, embrace it. For example, go more with a fast reboot and fast recover approach.
• Work from the customer backward. Focus on value you want to deliver
  for the customer. Start with a press release of what features the user will see and work backwards to check that you are building something valuable.
• Use measurement and objective debate to separate the good from the bad. Referred to as getting rid of the influence of the HiPPO's, the highest paid people in the room. This is done with techniques like A/B testing and Web Analytics. If you have a question about what you should do, code it up, let people use it, and see which alternative gives you the results you want.

If you haven't seen all the video clips for Microsoft Surface yet you'll have to check them out. Surface should be really cool and should enable some giant steps forward with user interfaces. Your typical windowed application will be a thing of the past and that should also carry over into desktop computers. I'd expect some multi-touch flat panels for your PC too.

From what I've read, all the apps shown on Surface were written using WPF on the .Net Framework. Silverlight is another technology from Microsoft that brings WPF and .Net to the web browser (cross-platform even). Silverlight is the re-branded WPF/E code and is the next big thing from MS as far as the visual web goes. We used Silverlight (then WPF/E) for a SalesWorks demo back in February. Think of Silverlight as Microsoft's version of Flash.

To see something really neat, check out this demo of a Surface-style app using Silverlight in your web browser. You'll need to install the Silverlight Alpha to see it (just click thru the steps to install it). Yeah, that's a video file running in there. It's really amazing. You just want to put your fingers to the screen and start dragging the pictures around. 

I don't use MS PowerShell very often, but sometimes it does come in handy for testing .NET components. It seems like every time I want to use it I am Googling for basic commands to use with it. I've run across this handy little cheat sheet that you can print out. PowerShell Cheat Sheet Redux

One of the web services I've been working on has the requirement to send out formatted emails to internal user and external customers. In order for the service to go live we needed to take any day-to-day maintenance duties away from the developers of the project. One aspect of those duties is to keep the email messages that go out up-to-date. We store the addresses, subject and body of the various emails in the database. With the message bodies, we've designed it that the author can insert various macros that will get replaced with contextual values.

For example, when a new account is created a new email is fired off to our customer. That email needs to list all the specific details of the new account. The email message will have macros available like $AccountId$, $ContactFirstName$ or $InitialPassword$. When we generate the email, we call a simple function that uses reflection to pull the properties out of the Account object and replace the macros within the email message. Below is the VB.Net function that does that.

PublicSharedFunction ReplaceMessageMacros(ByVal Msg AsString, ByVal Obj AsObject, ByVal ObjType As Type) AsStringDim objectType As Type = Obj.GetTypeDim pi As PropertyInfo()
    Dim i AsInteger' get the property list from the object passed in
    pi =  = objectType.GetProperties(BindingFlags.PublicOr BindingFlags.Instance)
    
    ' loop thru all properties of object and see if a macro exists in the MsgFor i = 0 To (pi.Length - 1)
        Dim val AsStringTry
            val = pi(i).GetValue(Obj, Nothing).ToString()
        Catch ex As Exception
            val = ""EndTry' replace the macro with the property value
        Msg = Replace(Msg, "$" & pi(i).Name & "$", val)
    NextReturn Msg
EndFunction

Make sure you import System.Reflection

I occasionally get questions on how I do my thumbnail images for my photo gallery. This site runs on ASP.NET and the photo section automatically creates thumbnails of JPEG images on the fly. In the real world, a web site like flckr.com wouldn't work if thumbnails were always created on the fly, but for my small amount of pictures it works just fine. Below is the code that creates a scaled thumbnail from a JPEG path and writes it back to the browser. This code is used within an HTTP handler that just serves thumbnails.

A couple points of interest. The code encodes the thumbnail at 75% quality. If the original image is smaller than the requested width and height, it won't scale it but will send it to the browser.

   1:  PublicSub ScaledImage(ByVal Path AsString, ByVal Width AsInteger, ByVal Height AsInteger)

   2:  Dim originalWidth AsInteger

   3:  Dim originalHeight AsInteger

   4:  Dim image As bitmap = bitmap.FromFile(Path)

   5:   

   6:      originalHeight = image.Height

   7:      originalWidth = image.Width

   8:   

   9:  Dim heightRatio AsDouble = CDbl(originalHeight / originalWidth)

  10:  Dim widthRatio AsDouble = CDbl(originalWidth / originalHeight)

  11:   

  12:  Dim desiredHeight AsInteger = Height

  13:  Dim desiredWidth AsInteger = Width

  14:   

  15:      Height = desiredHeight

  16:      Width = Convert.ToInt32(Height * widthRatio)

  17:  If Width > desiredWidth Then

  18:          Width = desiredWidth

  19:          Height = Convert.ToInt32(Width * heightRatio)

  20:  EndIf

  21:   

  22:  If Height > originalHeight Or Width > originalWidth Then

  23:          Height = originalHeight

  24:          Width = originalWidth

  25:   

  26:          image.Save(Response.OutputStream, ImageFormat.Jpeg)

  27:  Else

  28:  Dim thumb As Graphics

  29:  Dim bitmap As bitmap = New bitmap(Width, Height)

  30:          thumb = Graphics.FromImage(bitmap)

  31:          thumb.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic

  32:          thumb.DrawImage(image, 0, 0, Width, Height)

  33:   

  34:  Dim codec As ImageCodecInfo = GetEncoderInfo("image/jpeg")

  35:   

  36:  Dim eps As EncoderParameters = New EncoderParameters(1)

  37:          eps = New EncoderParameters

  38:          eps.Param(0) = New EncoderParameter(Encoder.Quality, CLng(75))

  39:   

  40:          bitmap.Save(Response.OutputStream, codec, eps)

  41:   

  42:          thumb.Dispose()

  43:          bitmap.Dispose()

  44:          eps.Dispose()

  45:  EndIf

  46:      image.Dispose()

  47:   

  48:      Response.ContentType = "image/pjpeg"

  49:      Response.End()

  50:  EndSub

  51:   

  52:  PublicFunction GetEncoderInfo(ByVal MimeType AsString) As ImageCodecInfo

  53:  Dim myEncoders() As ImageCodecInfo = ImageCodecInfo.GetImageEncoders()

  54:  Dim myEncoder As ImageCodecInfo

  55:  ForEach myEncoder In myEncoders

  56:  If myEncoder.MimeType = MimeType Then

  57:  Return myEncoder

  58:  EndIf

  59:  Next

  60:  ReturnNothing

  61:  EndFunction

Hashing is a reproducible process to calculate a hash value from some data. The hash values are unique and specific for the data it was derived from. Wikipedia has a good explanation of hashing. i will be showing some VB.Net code in this article that uses the SHA1 algorithm to do some hashing.

Hashing by itself does nothing to prevent tampering with the data. Message Authentication Codes (MAC) are a way to prevent this. MACs use symmetric encryption methods to protect the sent hash. Symmetric encryption uses one private session key and both the sender and receiver require to have a copy of this key.

Below is the VB.Net code to generate a MAC using HMACSHA1:

   1:  Imports System.Security.Cryptography

   2:   

   3:  PublicSharedFunction ComputeHash(ByVal Data AsString, ByVal Key AsString) AsString

   4:  ' initialize the keyed hash

   5:  Dim sha1Algo AsNew HMACSHA1(System.Text.Encoding.ASCII.GetBytes(Key))

   6:   

   7:  ' compute hash 

   8:  Dim hash AsByte() = sha1Algo.ComputeHash(System.Text.Encoding.ASCII.GetBytes(Data))

   9:   

  10:  ' convert to string and return

  11:  Return System.BitConverter.ToString(hash)

  12:  EndFunction

  13:   

  14:  PublicSharedFunction VerifyHash(ByVal Received AsString, ByVal Data AsString, ByVal Key AsString) AsBoolean

  15:  ' hash our data

  16:  Dim hash asString = ComputeHash(Data, Key)

  17:  

  18:  ' compare strings

  19:  Return (Received = hash)

  20:  EndFunction

  21:   

This code was derived from a more in-depth article: Hashing, MACs, and Digital Signatures in .NET.

I have been evaluating WPF/E for add-ins to my company's products. One screen we have been thinking about for a while is a lead pipeline that shows lead stages in a graphical way. Our products leverage IE for the presentation layer and it is tough to do a compelling pipeline with just DHTML.

WPF/E brings a lot to the table. First of all it is very easy to incorporate into our screens, I simply insert the control code and link in the aghost.js file. It also enables us to easily separate the markup from the script. The HTML file orchestrates the screen while the script and XAML reside in separate files. I also like the division of labor. As shown in these screenshots I've coded the pipeline screen as a segmented pipe along the top of the screen. As the developer I just created simple XAML objects that represented the different elements of the pipeline, nothing too fancy. I then hook up my script to control click-thrus and mouse-overs (the second screen shows how the mouse-over affects the pipeline). In production I would then had the XAML source over to a designer and they would take my rudimentary design and create something beautiful from it. They'd send me the updated XAML file and I just insert back into the development tree and everything should still work with changes. In this case I was the designer too, but you should start to see how this should make development easier.

Another thing that I experimented with was trying to use the same XAML objects and provide an entirely different look and feel for the screen. The final screen shot shows how that turned out. This pipeline demo is very simple, but it starts to paint a picture of how WPF and WPF/E can be used in software. I can imagine that things are not quite as simple when more complex functionality is needed. When trying to change the pipeline into a vertical funnel, I did have to adjust some of my code to make it work.

I did try to use Microsoft's new Expression Design application to create the XAML I used in this demo. I designed the circular pipeline segments and exported them as WPF/E XAML code. That sort of worked, but It generated everything as complex paths and was hard to modify by hand. By the time I had finished the demo, I ended up starting from scratch with the XAML objects. Still, the tools are great and they look very promising.  

In my previous post I had only been using Expression Blend and wasn't able to figure out how to get it to generate content for WPF/E. It turns out that only Expression Design can export WPF/E compatible content (thanks ADO Guy).

If you download and install Expression Design, you can create vector-based elements to include in your WPF/E-based web pages. Expression Design is very similar to Adobe Illustrator. Once you've completed your design, click on File>Export>XAML. This will prompt you for a filename then it brings up a XAML Export window like the one on the right. If you select the Document Format dropdown you can select the WPF/E format. I've tried a couple simple tests that displayed correctly in WPF/E Pad.

This is a good step and may be all we need, however I was expecting this same type of functionality with all the Expression tools. Is that coming?

I first crossed paths with Windows Presentation Foundation/Everywhere (WPF/E) on Mike Harsh's blog post about the Mix '06 event in March of 2006. I knew about XAML and where Microsoft was going with their presentation layer tools, but our company creates mass-market desktop software that doesn't utilize the .Net Framework yet. This meant any XAML or WPF was off limits for us. That is until MS announced WPF/E.

In Mike Harsh's words "(WPF/E) is a cross-platform, cross-browser web technology that supports a subset of WPF XAML.  WPF/E also has a friction-free install model and the download size we’re targeting is very small.  WPF/E supports programmability through JavaScript for tight browser integration.  The WPF/E package also contains a small, cross platform subset of the CLR and .NET Framework that can run C# or VB.NET code."

So XAML and WPF can now be hosted in Internet Explorer. Since my company's desktop applications host IE for the presentation layer, then our presentation layer can take advantage of XAML and WPF. Unfortunately there was not much to be heard of WPF/E since March, but this month MS released a CTP of WPF/E.

where to get started

Probably the best place to get started is the WPF/E Dev Center on MSDN. Download and install the SDK so you can start trying the examples. The Dev Center has a few that you can look at. Mike harsh has also built a cool little application that let's you test your XAML code, called WPF/E Pad. Once you have the SDK installed you can run the WPF/E Pad and try some of the built in examples. After you get a feel for what can be done try entering some of your own XAML. Try copying and pasting the source from below into the bottom panel of WPF/E Pad and clicking the Load button.

<Canvasxmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"x:Name="_037_bugs_logo"Width="1056"Height="816"><EllipseHeight="200"Width="200"Canvas.Left="30"Canvas.Top="30"Stroke="Black"StrokeThickness="10"Fill="SlateBlue"/><RectangleHeight="100"Width="100"Canvas.Left="5"Canvas.Top="5"Stroke="Black"StrokeThickness="10"Fill="SlateBlue"/><LineX1="280"Y1="10"X2="10"Y2="280"Stroke="black"StrokeThickness="5"/></Canvas>

You should end up with something like the screenshot to the left. The XAML creates an ellipse, a rectange and a line. This is not a very compelling example (it was taken from the MS SDK download) but it gives you something to start with. What's nice about the technology is that it allows you to interact with the XAML code using JavaScript. So you can create a bunch of objects using the XAML markup and embed it in your web page, then use JavaScript to program those objects. For example you can attach events to the XAML objects (similar to DHTML) and handle those events in your JavaScript. WPF/E Pad doesn't support event handling at the moment, so you have to take the next step and create your own web page to test out event handling. Those steps are covered in detail within the WPF/E SDK.

what's next?

What makes all this really interesting is how Microsoft is backing up this technology with their development tools. They've recently released an entire suite of apps to generate, manage and debug XAML. Check out their Expression Suite. I think the development tools will be able to target WPF/E versus WPF at some point. Exciting stuff.

The blog content for this website is managed and rendered by a custom version of the dasBlog Weblog. I've refactored the dasBlog ASP.NET application code into a reusable .NET library that can basically be called by any .NET client app. In this case the client is our home-grown site hosting software. I'll go into a little more detail about how this was accomplished.

Here's a little background about the client. Our hosting software is a simple ASP.NET web application that uses modules to render parts of the page. There are 3 content panels for each page (not including the headers and footers) that contain the user's HTML. The simplest way for content to be rendered for these panels is to use the HTML module that simply pulls content from a .htm file on the server. We have more complex modules for showing forms, photo albums and blog articles. A simple configuration file tells the site engine which module a content panel should call to get HTML to show. In this blog there are two content panels: a center panel and a right panel. The right contains some blogging tools and the main, center panel contains the blog articles. This is where the dasBlog code comes in.

The original dasBlog application is a full blown weblog application that handles everything from displaying and posting articles to site templates to usage statistics. I wanted these tools as well, but I didn't want them in the form of a website. All I needed was to be able to call into a library to get the HTML for a list of blog articles or single blog articles. I also wanted to take advantage of the blog api's used by blog publishing clients so there would be a way to get the content into it.

I started with dasBlog version 1.8.5223.2. The application was designed to mostly handle a single blog and its content. Most of the code assumed global classes for getting the content and settings stored on disk. What I did was create a BlogContext to hold all the global class instances. The single, global class which encapsulated all the original global variables enabled me manage multiple sets of blog content and settings. I wrote another couple classes to manage the multiple instances of the BlogContext class.

To give you an view at how this all works together, I'll show you a code sample. One of the handlers within our site engine module is OnColumnRender(...). It gets called in the module when the site engine needs it to render some HTML for a content panel. It gets passed a Column arg and a Holder arg. The Column arg gives the module a reference back into the APIs in the site engine. The Holder arg is just a typical ASP.NET Control that represents the content for a panel. The following code sample gets a reference to a BlogContext and uses it to fill in the Holder Control class.

   1:  PublicSub OnColumnRender(ByVal Column As PageColumn, ByVal Holder As Control) Implements SiteModule.OnColumnRender

   2:  ' get a reference to a blog context. a single site (SiteInfo.Key) can contain multiple

   3:  ' blogs identified by Column.Key

   4:  Dim blogContext AsNew BlogContext

   5:  Dim blogEngine As BlogEngine

   6:      blogEngine = BlogEngines.GetBlogEngine(Column.Page.SiteInfo.Key, Column.Page.SiteInfo.ContentFolder)

   7:      blogContext = blogEngine.GetBlogContext(Column.Key)

   8:  

   9:  ' set the root for our engine

  10:      blogContext.SiteConfig.Root = Column.Page.Url.Root

  11:  

  12:  ' tell the blog engine where to get its templates

  13:      blogContext.TemplateFolder = Column.Page.Template.Folder("blog").Path

  14:      blogContext.TemplateURL = Column.Page.Template.Folder("blog").VirtualPath

  15:   

  16:  Try

  17:  ' now tell the blog engine to process the bodyText macro

  18:  ' and fill the Holder with blog controls. it takes the

  19:  ' the ASP.NET page class as an argument. those familiar

  20:  ' with dasBlog recognizes the %bodyText% macro as the

  21:  ' actual portion of the page where article content is put

  22:          blogContext.Process(Holder, "<%bodyText%>", Column.Page)

  23:  Catch (Exception ex)

  24:          Column.Page.HandleModuleException(ex)

  25:  Finally

  26:  ' set the page description based on the blog content

  27:  If blogContext.Description.Length > 0 Then

  28:          Column.Page.Description = blogContext.Description

  29:  EndIf

  30:  

  31:  ' add our blog stylesheets

  32:          Column.Page.StyleSheets.Add(blogContext.TemplateURL & "/styles.css")

  33:  

  34:  ' add a RSD tag

  35:          Column.Page.HeadTags.Add("<link rel=""EditURI"" type=""application/rsd+xml""" & _

  36:  " title=""RSD"" href=""" & Column.Page.Url.Root & "/" & Column.Key & ",rsd"" />")

  37:  EndTry

  38:  End Sub

 
The result is a set of modified dasBlog libraries, some web.config settings and a site engine module library that gets registered with the site engine. There are many details that I've skipped over, like how the blog clients interact, how the generated content is modified by user interaction and how the right content panel shows details about the blog itself. I will likely give more details a sample code if there is interest.

Based on a previous post of mine, I started hunting for a source code repository to use. I found several. The one I liked the best was snipplr.com. There were a few reasons I liked this service. It has a very simple, clean interface. It has a simple, open API for accessing your snippets from other applications. It keeps track of snippet changes. It handles colorizing source code. It provides tagging of my snippets. I've also had no problems reaching it and it seems snappy.

As an experiment, I've added a snippet sidebar to my source code editor, Parachute, which can be downloaded from my website. Just open the options and enter your snipplr API key. Your snippets should show up and can be filtered by the tag bar at the top. Double-click on a snippet to paste it in the editor pane. Please try it out and let me know how you like it.

I've seen some pretty impressive digital rendering before, but I had know idea it was this close to being mainstream. Microsoft will be releasing DirectX 10 on Windows Vista. DX 10 is a total re-write. I think gaming is going to jump to the next level. I also think it's a good idea for Microsoft to only make DX 10 available on Vista. It gives the gaming community and home users good incentive to move to that platform, even if business users have no motivation. Then again maybe it's not a marketing tactic since the article says "The new display driver or graphics model in Windows Vista, WDDM (Windows Display Driver Model), is the main reason for DirectX10’s exclusivity to the operating system".

In continuing to review the good and bad aspect of our last product cycle I ran across a discussion on the Coding Horror website called What is "Modern Software Development". The topic of the discussion is about identifying an essential checklist for good software development. There were existing lists from Joel Spolsky and Steve McConnell as well as new suggestions. It inspired me to compile an essential checklist for our development team. I used items from the original lists and added some of the suggestions from the discussion. Here is the list with how I feel we currently stack up.

1. Do you use source control?
Yes. All our source and documentation is in source control and backed up nightly, offsite. We use Subversion and TortoiseSVN.

2. Can you make a build in one step?
Yes. Each of our projects have build scripts so they can be built and packaged with single commands.

3. Do you conduct code reviews on a regular basis?
No. We have a small team of experienced programmers who all sit around a big desk in our dev room. This makes communication much easier, but it's still no excuse for being more formal about code reviews. This needs to happen.

4. Do you have a common code repository?
No. This is not so crucial for our small team, but as we grow it will be important. We find ourselves constantly asking "Hey Steve, where did you implement that XXX portion of code" so we can copy it in another place.

5. Do you have a bug database?
Yes. We use Bugzilla for recording bugs.

6. Do you fix bugs before writing new code?
No. We do fix bugs and supporting our customers is a top priority, but during a product cycle bugs are usually the last thing that are done and also the most likely to get short-changed.

7. Do you have an up-to-date schedule?
No. Scheduling is kinda done at the watercooler. This needs to be more formalized and done across the entire product team.

8. Do you have detailed activity lists?
No. We should be able to extract detailed activity lists from our specs. Currently this is not possible because our specs are not as detailed as they should be. I think these are important because it is a good litmus test for our spec process.

9. Do you have unit tests?
No.

10. Do you conduct regular usability testing?
No.

Whew. After going thru all that it appears we have a long way to go. It's not totally as bad as it seems. If there was a slight bit of doubt in answering the question, I listed No. Some of the items we do to a certain degree but I felt we need to address it better. Hopefully in the upcoming months we can improve on these items now that they are identified.

Part of finishing up a product cycle involves a postmortem. It's a chance to reflect back and identify the positive and negative things that contributed to the success of a product release. Hopefully identifying the positive and negatives will help us improve the quality of our software and increase our efficiency in building products.

We have just finished up a particularly long and grueling cycle for GiftWorks Volunteers. While I'm sure the actual product will surpass the expectations of our customers, the process of getting there was not a model of efficiency. We had several slipped deadlines. I've spent a lot of time tracing the steps along the way, trying to come up with a short list of points to carry forward to the next project. One point that keeps coming up is time estimation. Our company and our competition work on "Internet time". Release early, release often. It is critical for us to deliver our products as fast (if not faster) than our competition. Our customers demand it. But our customers also demand quality, and that is the challenge.

Time estimation comes up at several places during a product cycle. When a product idea is formed there are always rough estimates made as to how long it would take to release. There are time estimates for coming up with product specifications, time estimates for doing the development and testing, time estimates for beta releases. There are even time estimates for coming up with time estimates. These estimates allow us to plan ahead and are necessary. From the very beginning, "do you think we can get this done for a fall launch?", "can testing begin next month?", "how long will it take to get feedback from customers?". Time estimates also have a major impact on the overall product, and I think that impact can easily be underestimated (no pun intended).

Early, "back-of-the-napkin" time estimates are sometimes used to set deadlines for a product release. I'll call these "artificial" deadlines. They are deadlines that are set based on information other than the project schedule created after a functional specification has been reviewed and all teams have had a chance to provide time estimates. The artificial deadlines may be marketing driven, competition driven or come from somewhere else. They are not wrong, but do add a degree of risk to the product cycle.

There are several variables that can be used to represent a product cycle. Here is how I picture the formula in my mind: Resources + Time is proportional to Functionality x Level Of Quality. Where the Level Of Quality is a constant, or at least I think it should be. Generally, the more resources or time you add to a project, the more functionality you'll end up with. For example, assuming constant resources and level of quality, a four month product cycle will yield more functionality than a