Day of .Net in Ann Arbor this fall is on October 18th:
Saw a great post about the Snipping tool in Vista: The Blog at the End of the Universe : Why Vista? (Volume 4 -- Snipping Tool). For an old-time Alt+Print Screen guy, this thing is great. But the first time I looked for it, it wasn't there (I'm using Vista Business). I guess by default it isn't always installed, but it is available, there is an article describing how to activate the Snipping Tool at PCWorld.
I am continually humbled by the amount of stuff I don't know in the areas where I generally feel good about my level of knowledge....
Today I learned about conditional comments. This is an IE specific trick, but in my case I'm trying to have different CSS for a certain class so it behaves properly in IE6 and standards compliant browsers. The problem is using .png files that have transparency. IE6 totally botches .png files. But it turns out there is an IE-specific filter (progid:DXImageTransform) that causes IE6 to render a .png properly. An older article at A List Apart describes how to use it, along with conditional comments.
Conditional comments allow IE to display the content between the comments based on an expression. In this case, the expression is testing for the browser version:
<!--[if IE 6]>
<link rel="stylesheet"
type="text/css"
href="ie6.css"
/>
<![endif]-->
So this code snipped would cause IE 6 to load this custom stylesheet. IE7 interprets the comment correctly and doesn't load the stylesheet. Other browsers interpret this as a comment and ignore it. Very nice.
As developers, we struggle daily to be the most productive in our craft. Sometimes interruptions and counter-productive days are unavoidable, but there are number of things we can control to become more productive. These include how we behave, what we do with our work environment, and how we use the tools available to us. This article focuses on the soft skills you can develop to become more productive.
Behavior
Flow or “In the Zone”
As developers, I am sure we have all experienced flow, or being “in the zone”. You really dig in to your task, time passes quickly, and you just knock out code left and right. This effect is a pretty well documented, and as you probably experienced, it is sometimes hard to get the right momentum going. Often it takes about 15 minutes for a developer to get into the flow, but it only takes a short interruption to lose it. As a developer, you need to do your best to encourage flow. This means minimizing distractions. Be busy or away on your IM, don’t answer it. Turn off your Outlook notifications of incoming emails. Email is not a time-sensitive medium, treat it that way.
One of the best ways to keep your flow effective is to take a break when the flow breaks. You can’t be totally effective and in the flow all the time. Take time to recharge. The flow can’t continue endlessly. When you are not being productive in the flow, take a break.
Focus on the Task: Task Lists and Goals
Keeping focused on the task you are working on also encourages flow. Task switching is an expensive activity; it interrupts the flow. Set aside time to respond to emails and IM’s.
To help keep yourself on task, create task lists for the activities you need to accomplish each day. This is one of the productivity benefits of Agile/Scrum practices, it allows the team to set a daily goal, minimizing task switching. Organize your time to work on those tasks. Being organized helps minimize task switching and last minute tasks that slipped through the cracks while you were busy keeping the flow going.
Learning
Few things you can do to increase your productivity have more effect than learning. Knowing the right patterns and concepts up front directly impacts your coding productivity. An article published in Scientific American postulates that experts are made, not born. The article determined that expertise allowed chess masters to easily recognize complex patterns, and find effective solutions in much shorter times than non-masters. This was not due to better analysis skills, but resulted from a larger store of structured knowledge. Experts simply get the job done more efficiently. Additionally, motivation was found to be more important than innate ability when developing expertise. Being better at what you do is simply a matter of putting in the required time to reach the level of expertise you need.
When I am interviewing potential new developers for my firm, one question I often ask is “Do you have a server in your home?” For me this is an indicator of someone who has the motivation to become an expert, they are exploring technology on their own. Obviously not everyone can be a giant in the industry, but the only person holding you back is reading this article. Become an expert, if even in a small space, and increase your productivity.
Environment
Obviously, environment affects your ability to get into the flow and stay there. For many of us, noise is a major flow killer. We usually have little control over our direct environment, such as having an office or a cube. But there are actions we can take to make our environment more effective at certain times.
Distraction and Noise
If you have an office door, close it. This is one of the best ways to minimize distraction. If anyone is able to walk up to you and ask a question, they will. Obviously not all interruptions are bad or unnecessary. In order to encourage flow, time needs to be set aside specifically for flow-oriented tasks. Make it clear to others that you are busy, but also make it clear when you will be available again. Take the opportunity to ask to put off a request until you are free.
Set your phone to forward to voice mail, set your cell phone to silent. Set aside time later in the day to answer messages.
If you use an Instant Messenger (IM), make frequent use of the status feature. Others will notice that you do, and will understand that “busy” or “do not disturb” mean just that. Use your email client to schedule work time as appointments. This way you do not look “free” on your calendar or corporate IM.
If you don’t have a door, take advantage of rooms that do have one. Schedule a conference room for yourself for a time when you need to be busy; take your laptop, close the door. This both reduces noise and minimizes distractions, since you are not at your normal location.
Of course headphones are boon to those of us that don’t have a door. Typically, a cube or open environment has conversations going on around you. If you can’t hear them, you are less likely to get pulled into them.
Colleagues
Choosing to work with a strong team will increase your productivity. A strong team environment promotes learning, which in turn improves your productivity. Colleagues or mentors who are more experienced can also enable your own learning and efficiency. Seek them out and learn from them. If you don't have them at work, find them somewhere else. Look at all the folks blogging, experts abound and they are obvious. Contact them, build a relationship if you can. User groups or developer events, like those put on by Microsoft, or Geek dinners, are another good place to find experts and colleagues.
Next up Part 2: How you can use technology to help you be a more productive developer.
Resources
The Expert Mind
Life Hacker: Interruptions
Task Switching
Microsoft Content Management Server (MCMS) and Team Foundation Server (TFS) in Visual Studio 2005 don't play nice together. Since MCMS is a dead-end product, I don't expect there will be an actual fix.
The KB Article fix (sort of).
Stefan's workaround. Essentially you need to use them separately, TFS with Visual Studio and a standalone version of the MCMS Template Explorer.
Ran into a performance issue in a .Net remoting situation. A Winforms app is calling an application server asking for data. A relatively large DataSet (>10,000 rows, <6 columns) being passed over the wire was causing a performance problem. The database and application servers processed it quickly. Examining the transfer with WireShark showed that the transfer wasn't so bad either. There was a flurry of data passed, and then a bunch of waiting on the client-side, with the client CPU usage around 50% the entire duration of the wait. Turns out there is a calculated column in one of the data tables. The column is not calculated on the application server-side, so as not to pass a bunch of data across the wire that would be unnecessary. The calc happens on the client. That was the source of the slowdown and CPU usage. In the end the solution to the problem was not using the calculated column, we found a different solution to fix the business problem. I suppose you could perform the calculation in the SQL statement that was ultimately filling the DataSet. That might take longer to transfer, but won't slow down the client app.
- Work on a dummy TFS project that you can delete. Delete the project before you deploy for production.
- Not all the attributes for Work Item layout are documented.
- A Work Item Type defined in more than one project is sort of shared between the two. The definition can be different, but the name is shared. So anything you want to change or remove in one has to be done in the other. See item 1.
- Work items are not easy to delete. It can only be done through the database. See the SQL statements for doing removing work items. I found a GUI tool for this, but ultimately it was executing the SQL statements.
- Work Item Type fields are not easy to modify. Essentially you have to delete it and re-add it. The basic steps are:
- Remove the field(s) from the Work Item Type XML definition (both field and in the layout)
- Re-import the Work Item Type XML so the definition in use no longer contains the field(s)
- Delete the fields using the TFS command line tools. This also deletes any data you had stored for existing work items using your custom type.
- Re-process the cube using the TFS web service
- Update the Work Item XML with the updates you need
- Re-import the Work Item Type XML
Of course, after-the-fact I found a good overview of the custom Work Item process.
I deployed a site today that has some code in the Global.asax event handlers. I let Visual Studio 2008 add the file to my project when I created it, and it put the code directly in the file inside <script runat="server"> tags. I went with it. So when I deployed the file, none of the events fired. Ever. The lesson is: Don't put your code in the global.asax file. Apparently this problem is by design. There is a vague KB Article on this problem, but the solutions aren't all that helpful, I didn't want to pre-compile, and the first solution made no sense at all. A little searching and I found one good solution: put a class that inherits HttpApplication in the App_Code folder as described here. What I don't understand is why Visual Studio adds the file that way if it isn't going to work on an xcopy deployment. Microsoft seems to go out of their way to protect us from ourselves so often that I am surprised the IDE does something intentionally that won't work.
While looking for a URL rewriting tool for a client I found a reference to a tool, clicked the link and got a 404 error.
There is an article in Dr. Dobbs that describes a survey performed by the author. The survey was intended to query Project Managers, IT Managers, IT staff and business stakeholders on what defined the success of a project.
There were definitely some interesting findings:
- The IT industry has a long way to go to achieve a 100% success rate for projects
- Agile projects were more successful than traditional waterfall projects
- Off-shored projects were most likely to fail
- Respondents rated quality as the most important issue, and rated the importance of following items this way when analyzed as a group:
Quality > Scope > Staff Health > Time of Completion > Money
- Project managers differed significantly from all other groups in their perception of success, rating time and money over quality.
- Business stakeholders placed a higher value on ROI and and shipping when ready than the rest of the groups
- A majority of respondents in all groups worked on projects they knew would fail from the start, but canceling a troubled project was not viewed as a successful outcome
I am not surprised by project managers having a different view, given that they are trained to value on-time and on-budget projects. Someone has to keep an eye on the bottom line, but I have experienced this gap when a project runs into trouble. I have been thinking about the differences between Agile and Waterfall-style projects and how they differ. I think there is some middle ground between the two that is yet to be identified that gives us the benefits of heavier requirements and design and the responsiveness to change.
In Reporting Services reports, page breaks occur when the size of the body exceeds the page size. The crux of the lesson I learned is that the size of a sub-report cannot exceed the size of the parent containing it. Funny page breaks occur in the PDF output if this is the case.
Brian Welcker posted some terrific details on how page breaks work in Reporting Services, this post is essential if you are creating reports.
I recently gave a talk about Open XML, and found that there were not many complete code samples out there which described how to build Office 2007 documents using .Net and SpreadsheetML. Most of the examples I ran into were snippets or functions, or just examples of the SpreadsheetML. As one of my demos, I created a C# class which builds a basic spreadsheet. This post describes that class.
There are prerequisite installs required to run this code:
- .Net 3.0 Framework (System.IO.Packaging is part of WPF)
- SDK for Open XML Formats, which is currently a CTP, so the code is subject to change if the object model changes at all with the final release (so therefore does the code in this post).
- Code Snippets that are available for Open XML.
The class (called Spreadsheet) does two basic things:
- Create a spreadsheet package
- Insert data into a worksheet in the newly created package
The first step is creating the package, which consists of XML files for the SpreadsheetML and XML files which manage the relationships between those files. In an Open XML spreadsheet, the minimal spreadsheet package requires three documents containing SpreadsheetML:
- A workbook file
- A worksheet file
- A relationship file
Additionally, SpreadsheetML uses a concept called "Shared Strings". SpreadsheetML dictates storing Shared Strings separately from the worksheet in their own document, so the document stores less data if the document re-uses strings. Strings can also be added to the spreadsheet "in-line" and not used Shared Strings storage. For this example labels are stored as Shared Strings to demonstrate the concept, therefore the spreadsheet package also requires a Shared Strings document.
The SDK for Open XML Formats provides a new component, Microsoft.Office.DocumentFormat.OpenXml.dll, that wraps some of the functionality of creating an Open XML document with System.IO.Packaging. Essentially it manages creating the files and the relationships between the files in the package. Once you have created the files and relationships, you still need to create code to insert actual data into the documents. This example uses two steps:
- Create the basic XML document using a template of existing XML
- Insert data into the existing XML.
The following are the contents of three small XML files created and added to a Templates directory in the solution. These three files are the basis for the required parts of the package:
The workbook template
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workbook xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">
<sheets>
<sheet name="{1}