New App Hub Features Still Need Work

The July 18 Marketplace updates look like they still need some tweaking. I updated one of my apps and set the publish status to “hide” after certification. After app certification approval, for  some reason, it showed an update to the app on my phone (doesn’t seem hidden to me). I updated the app to the new version, and the splash screen was updated, but the icons were not updated and the application just showed a “My Application” header at the top of the page with no app content at all.

I thought maybe that was the result of the “Hide” status. So I un-hid the app in the marketplace. It didn’t prompt another update so I uninstalled the app from my phone. When I searched in the marketplace for my app to reinstall, it could not be found.

In order to reinstall the app, I had to navigate to my Lean Bites website on my phone and click the Zune Marketplace deep link in the right column of the website. After following that procedure, the app installed and is working correctly again with the new updated version.

I hope Microsoft gets these issues worked out before the consumer frustration gets to a new high and it doesn’t make my app look like it’s the problem. With so much riding on the new Windows Phone platform, it is unfortunate to see them stumbling over issues that probably should have surfaced in beta testing.

Five Reasons to Use a Staging Server

If you are interested in avoiding common and difficult to reverse issues when deploying new or updated software to a production environment, use a staging server – at a minimum. Your staging server should be configured as closely as possible to the production server. With virtualization, the process of cloning a server becomes a relatively trivial task.

A staging server provides a safe vehicle to “discover” and prevent commonly overlooked deployment issues:

1. missing assembly references or resources. This is a frequent occurrence if you use third party tools like Infragistics, Telerik, or another. When you install the development tools, they often add the assemblies to the GAC on your development box and scripts and images to “special” virtual directories. If you blindly deploy an application to production without making sure you have the assemblies either in the GAC or referenced properly in your application, it can frequently lead to run time errors and the yellow screen of death. Even items you might think are part of the .Net Framework that are pre-loaded in your Visual Studio toolbox, such as the ReportViewer control require the installation of a ReportViewer Redistributable executable.
2. dependencies on physical hardware. Depending on how the application is configured, your application may unwittingly be relying on a writeable F drive where on the server the F drive may not exist or may be a CD-ROM drive. Or require a 64 bit processor on a 32 bit server. It is better to catch these issues before deploying to production.
3. require elevated file system permissions. If your application is writing XML files or storing media, the application upload path will require Write permissions for the accessing account. Permissions requirements should be part of the installation/upgrade process, not left to post installation troubleshooting.
4. require least privileges on database permissions. You may be using the sa account (not recommended)on your development box, but your production DBA and/or company policies won’t appreciate that in production. This is an opportunity to make sure your application is running under an account or group with the least privileges necessary to run the application and make sure if your installation process is dropping/re-adding stored procedures or tables, you are also adding the appropriate grant select, insert, update, delete, execute, bulk insert, or truncate permissions to avoid unexpected SQL errors.
5. require configuration changes to interface with other services, such as IIS version differences, SMTP, or Message Queues. On your development box, for simplicity, you might be using a local IIS SMTP service, or file system implementation to test emailing functionality, but if the production environment only allows mail to relay through a Microsoft Exchange endpoint, you have some additional configuration to do. Making sure all the appropriate accounts are understood and configured properly often takes coordination with other IT specialists. They’ll appreciate it if you coordinate it at their convenience on a staging server instead of elevating the issue to a production emergency.

This isn’t intended to be an all inclusive list, but hopefully if you are not using one today, it will inspire you to consider using one in the future. Prevention is the best medicine for software implementation.

The staging process provides an opportunity to perfect the installation process for a problem free installation. Additionally, having the installation process consolidated to a single series of installation and configurations steps in a single package with all the necessary files and scripts can simplify recreating software versions for disaster recovery purposes or for replicating to additional installation deployments, such as for different customers or at a different site.

Photo credit: Anirudh Koul / CC BY 2.0

The Value of Peer Code Reviews

Fellow .Net Users Group members Richie, President Armanda, and I facilitated a Round Table discussion on Peer Code Reviews. In the words of one of the attendees,

“That was one of the best topics and Round Table discussions we have had.”

I agree completely, although I am a little biased because I suggested the topic. The discussion covered the following:

• reasons for code reviews (best practice, quality, compliance)
• benefits
• who to include (and exclude)
• cultural prerequisites – not to be used in performance evaluations
• pre-review prep (code standards, guidelines, checklists, individual review/notes)
• the review itself (frequency, roles, scope, mechanics, tools, demonstration)
• metrics
• most common findings
• software available – code coverage, standard practices compliance (styleCop and fxCop type software), code review itself

In addition to improving the quality of the code under review, almost unanimously the greatest value is that the process makes better developers. It provides a process that facilitates improvement through:

• self motivation to improve – respect from peers
• understanding your personal “most likely to miss” types of bugs or coding practices
• coaching, teaching, and mentoring from other team members
• understanding the expectations of your programming and testing responsibilities

Additional related resources:

SmartBear Software - Best Practices for Peer Code Review

Roiy Zysman's Code Review Checklist (or how to avoid the code review reaper..)

Charles Vas's Code Review Checklist

Photo attribution: http://www.flickr.com/photos/sebastian_bergmann / CC BY-SA 2.0