Friday, May 18, 2012
Since I have been interested in cross-platform mobile application development, but reluctant to leave behind the IDE goodness that is Visual Studio, I was invited to participate in a private early beta program for VSNomad and asked to share my thoughts. One of the coolest things about the tool is that there is hardly anything to it, so most of this blog entry will be focused around the motivations for a tool like VSNomad rather than "all the things it does". Access to the early beta program is "by request" as opposed to "invitation only", so I would encourage anyone that has an interest in building cross-platform mobile applications to go to http://www.vsnomad.com, click the Download link, and sign up to be included in the beta.
In the desktop applications world, a reasonable argument can be made for creating native applications that are locked in to a specific OS vendor if accepting that lock-in will put you at a market advantage either by allowing you to create a better product, allowing the product to reach market more quickly, making the product less costly to build and maintain, or some combination of two or more of these factors. I say there is a reasonable market for this based on the sheer numbers. Even though Mac has very much increased in popularity and sales, much of that increase has been in the mobile space and many Mac users (even if grudgingly) accept that using VMWare Fusion or Bootcamp to make sure that they have an available instance of Windows available to run "that app" (whatever "that app" which requires Windows is for them). Various versions of the Windows operating system pretty much dominate the desktop market with the installed base of some Windows version sitting just over 92% of the market, leaving just under 8% for "everyone else" with most of that 8% represented by Mac machines.
The tablet and mobile device story is another thing altogether. The top players in this market (when lumped together) are the various flavors of Google's Android operating system at right about 50%, with Apple's more unified line coming in at about 30%, leaving still a fairly hefty 20% for "everyone else". In this world it becomes a much more difficult decision to decide that you're ok with limiting your pool of potential customers to the user of a certain mobile OS, so the drive to either create multiple versions of your app or write your app in such a way that it can be used across platforms is much stronger.
HTML and JavaScript immediately jump to the front when thinking of UI work because these are well-understood and have supporting applications across virtually any modern client computing platforms, but when I think of HTML, I usually think of a browser running "safe" code in a sandboxed environment as opposed to a rich programming platform capable accessing the wide variety of devices and sensors that mark most of today's mobile platforms. This creates the dilemna - how do we make use of the full capabilities of the device but write our applications in a way that allows us to easily support a variety of mobile platforms?
The Apache Cordova project answers the question quite nicely by providing an abstraction layer on top of the various devices and services that you can expect to encounter on a mobile platform. These devices and services include the Accelerometer for motion detection, Camera to capture images and video, Capture for audio, a Compass for directional information, network connectivity state information, a contacts list, basic device data (such as platform and identifying information), File I/O, Geolocation, Media, Notification services (sounds and "toast"), and a client side storage platform for data persistence. For these services, Cordova becomes the single platform that you code against. These libraries are packaged together with native shims which are responsible for handling the actual platform-specific interaction and allow the single set of application code to be built for any supported platform.
So now that I've shared the upside of Cordova and you're chomping at the bit to use your mad HTML skills to become a cross-platform mobile ninja, how do you get started? The answer if you're using Cordova out of the box is "it depends." The Cordova documentation actually has a seperate Getting Started section for each supporting platform, providing instructions including the installation of Eclipse, each of the supported platform-specific SDKs (for some platforms there will be multiple SDKs), and finally the installation of Cordova itself. Once all the installation work is done, it's a simple matter of creating a project with the appropriate structure, digging through a few properties files to get them set up for the intended project and target platform, copying jar and js files to the right location in the structure and creating a java bootstrapper to load start page. Then you can start writing your application. Doesn't that sound easy and like the developer workflow you'd like to follow? Me neither!
VSNomad smooths out many of the lumps in the COrdova workflow by providing a Visual Studio addin which is responsible for creating new Cordova projects with the necessary structure and starting files present and once the project is ready to be built for a device, a single button submits the project to VSNomad's cloud-based build service which handles integration with the appropriate SDK for the build target, leaving the developer's main focus on building a useful app. Using the standard Visual Studio Project Properties paradigm, the user can set an intentionally sparse number of project settings specifying the target platform and supplying any additional information such as developer/app keys for the iOS targets. Once you've clicked the button to submit your application to the cloud service, the cloud service packages up the application and the extension downloads the package which is now now ready to be deployed on your target device - in my case an apk file to be deployed on my son's Kindle Fire.
By default, the VSNomad project includes the Javascript library for Cordova and jQuery mobile, providing support building rich apps that default to an iOS look and feel. Import a library like Knockoutjs for its data binding and MVVM support and you've got a very capable stack supported by the productivity inherent to working in Visual Studio.
With Cordova, access to devices and services is made simple so that as a developer you can focus more on WHAT should be done with these capabilities to make apps useful instead of HOW to access them. VSNomad takes this story a step further by freeing you from mundane setup and configuration tasks and replacing them with a single button click.
Friday, April 27, 2012
The Service Locator pattern and Dependency Injection clearly take a much different approach to achieving Inversion of Control and these differences often lead to philosophical discussions about which is better. Rather than tag either as "better", it is much better to look at the advantages and disadvantages that each bring to the table and understand that at different times and in different scenarios each will assert an edge over the other that makes it the most appropriate choice for that scenario.
One of the biggest advantages that I see in using Dependency Injection (at least when contructor injection is used as opposed to property injection) is that the component provides a very clear advertisement in the form of constructor arguments as to what external services that it needs in order to complete its job. This also allows the component to be independent of the mechanism used to provide Inversion of Control because it does not need to be aware of any IoC container or service locator implementation. If you're not using some sort of framework that is responsible for "building up" components and ensuring dependencies are resolved, the injection approach can also lead to having to invent ways to pass references down through several layers of application code in order to make the reference available to the code that depends upon it, which makes changes at the component level that require the introduction of a new dependency bubble changes through multiple levels.
The biggest advantage that I see in the Service Locator pattern is a direct counter to the advantage of using Dependency Injection. Because the component does not advertise the dependencies that it has on external services to complete its work the code adheres more closely to the concept of encapsulation. By advertising external dependencies required to complete work, it can be said that that components using Dependency Injection reveal a bit more of "how" the work is done instead of leaving the entire focus on "what" work is to be completed. Using the Service Locator approach, there is no need to ensure that service references are passed from layer to layer that may not need them. This advantage to some degree is countered by the fact that many developers using Inversion of Control will also be using some sort of framework that will handle resolution of dependencies. Additionally, by removing the explicit advertisement of dependencies on object construction the risk of finding that a necessary service has not been registered late in the process increases and the component cannot "fail early".
All other things being equal, I find that my preferences lean to the explicit model provided with constructor injection and allow whatever IoC container that I am using handle many of the drawbacks of this approach. This allows me to quickly look at the method signature of the constructor for any class that I have built using this model and understand what it needs to get its job done - a big advantage when trying to quickly understand problems with production code. There are some times when you find that your component MUST support a public constructor with no arguments and others when it is not required but does make sense to do so. In these cases, the Service Locator becomes a valuable tool to make services available to your component.
Wednesday, April 18, 2012
Have you heard about this new Cloud stuff? It's a new programming model that is introduced with Microsoft Windows Azure, Amazon's EC2, and other large data center providers and it's going to radically change the way that we approach programming. Among some of the key changes to recommended programming practices are:
- Make sure to use coarse grained interfaces. When calling across logical tiers, assume that you will at best be crossing processes and very likely be crossing machine boundaries, so make as few calls as practical to get the job done.
- Design long running processes so that markers or some similar mechanism can give you the necessary information to resume processing instead of double-processing.
- Use of queue-based processing will allow for either scaling out by adding more processors or, when possible, allow load to be leveled over time with fewer processors. This will also allow components or subsystems to function while others are not running or are running at diminished capacity.
- State in our services should be avoided if at all possible
Come to think about it, maybe this is that new Microsoft Transaction Server thing I've been hearing about.
The fundamentals of good programming don't change when we move to the cloud - they're just repackaged and brought back into the spotlight. You may not be ready now or even ever to take your apps to the cloud, but what's wrong with programming now like you're already there?
Thursday, March 22, 2012
Yes, Bob is my uncle too. I also think the points in the Manifesto for Software Craftsmanship (manifesto.softwarecraftsmanship.org) are all great. What amazes me is that tend to confuse the term “well crafted” with “perfect”. I'm about to say something that will make Quality Assurance managers and many development types as well until you think about it as a craftsman – “Stop trying to be perfect”.
Now let me explain what I mean. Building software, as with building almost anything, often involves a series of trade-offs where either one undesired characteristic is accepted as necessary to achieve another desired one (or maybe stave off one that is even less desirable) or a desirable characteristic is sacrificed for the same reasons. This implies that perfection itself is unattainable. What is attainable is “sufficient” and I think that this really goes to the heart both of what people are trying to do with Agile and with the craftsmanship movement. Simply put, sufficient software drives the greatest business value.
I've been in many meetings where “how can we keep anything from ever going wrong” has become the thing that holds us in analysis paralysis. I've also been the guy trying way too hard to perfect some function to make sure that every edge case is accounted for. Somewhere in there, something a drill instructor said while I was in boot camp occurred to me. In response to being asked a question by another recruit having to do with some edge case (I can barely remember the context), he said “What if grasshoppers had machine guns? Would the birds still **** with them?” It sounds funny, but there's a lot of wisdom in those words.
“Sufficient” is different for every situation and it’s important to understand what sufficient means in the context of the work you’re doing. If I’m writing a timesheet application (and please shoot me if I am), I’m going to have a much higher tolerance for imperfection than if you’re writing software to control life support systems on spacecraft. I’m also likely to have less need for high volume performance than if you’re writing software to control stock trading transactions.
I’d encourage anyone who has read this far to instead of trying to be perfect, try to create software that is sufficient in every way. If you’re working to make a component that is sufficient “better”, ask yourself if there is any component left that is not yet sufficient. If the answer is “yes” you’re working on the wrong thing and need to adjust. If the answer is “no”, why aren’t you shipping and delivering business value?
Monday, March 19, 2012
One of the earliest lessons I was taught in Enterprise development was "always program against an interface". This was back in the VB6 days and I quickly learned that no code would be allowed to move to the QA server unless my business objects and data access objects each are defined as an interface and have a matching implementation class. Why? "It's more reusable" was one answer. "It doesn't tie you to a specific implementation" a slightly more knowing answer. And let's not forget the discussion ending "it's a standard". The problem with these responses was that senior people didn't really understand the reason we were doing the things we were doing and because of that, we were entirely unable to realize the intent behind the practice - we simply used interfaces and had a bunch of extra code to maintain to show for it.
It wasn't until a few years later that I finally heard the term "Inversion of Control". Simply put, "Inversion of Control" takes the creation of objects that used to be within the control (and therefore a responsibility of) of your component and moves it to some outside force. For example, consider the following code which follows the old "always program against an interface" rule in the manner of many corporate development shops:
1: ICatalog catalog = new Catalog();
2: Category[] categories = catalog.GetCategories();
In this example, I met the requirement of the rule by declaring the variable as ICatalog, but I didn't hit "it doesn't tie you to a specific implementation" because I explicitly created an instance of the concrete Catalog object. If I want to test the functionality of the code I just wrote I have to have an environment in which Catalog can be created along with any of the resources upon which it depends (e.g. configuration files, database connections, etc) in order to test my functionality. That's a lot of setup work and one of the things that I think ultimately discourages real buy-in of unit testing in many development shops.
So how do I test my code without needing Catalog to work? A very primitive approach I've seen is to change the line the instantiates catalog to read:
1: ICatalog catalog = new FakeCatalog();
once the test is run and passes, the code is switched back to the real thing. This obviously poses a huge risk for introducing test code into production and in my opinion is worse than just keeping the dependency and its associated setup work. Another popular approach is to make use of Factory methods which use an object whose "job" is to know how to obtain a valid instance of the object. Using this approach, the code may look something like this:
1: ICatalog catalog = CatalogFactory.GetCatalog();
The code inside the factory is responsible for deciding "what kind" of catalog is needed. This is a far better approach than the previous one, but it does make projects grow considerably because now in addition to the interface, the real implementation, and the fake implementation(s) for testing you have added a minimum of one factory (or at least a factory method) for each of your interfaces. Once again, developers say "that's too complicated and has me writing a bunch of useless code" and quietly slip back into just creating a new Catalog and chalking any test failures up to "it will probably work on the server".
This is where software intended specifically to facilitate Inversion of Control comes into play. There are many libraries that take on the Inversion of Control responsibilities in .Net and most of them have many pros and cons. From this point forward I'll discuss concepts from the standpoint of the Unity framework produced by Microsoft's Patterns and Practices team. I'm primarily focusing on this library because it questions about it inspired this posting.
At Unity's core and that of most any IoC framework is a catalog or registry of components. This registry can be configured either through code or using the application's configuration file and in the most simple terms says "interface X maps to concrete implementation Y". It can get much more complicated, but I want to keep things at the "what does it do" level instead of "how does it do it". The object that exposes most of the Unity functionality is the UnityContainer. This object exposes methods to configure the catalog as well as the Resolve<T> method which is used to obtain an instance of the type represented by T. When using the Resolve<T> method, Unity does not necessarily have to just "new up" the requested object, but also can track dependencies of that object and ensure that the entire dependency chain is satisfied.
There are three basic ways that I have seen Unity used within projects. Those are through classes directly using the Unity container, classes requiring injection of dependencies, and classes making use of the Service Locator pattern.
The first usage of Unity is when classes are aware of the Unity container and directly call its Resolve method whenever they need the services advertised by an interface. The up side of this approach is that IoC is utilized, but the down side is that every class has to be aware that Unity is being used and tied directly to that implementation.
Many developers don't like the idea of as close a tie to specific IoC implementation as is represented by using Unity within all of your classes and for the most part I agree that this isn't a good idea. As an alternative, classes can be designed for Dependency Injection. Dependency Injection is where a force outside the class itself manipulates the object to provide implementations of the interfaces that the class needs to interact with the outside world. This is typically done either through constructor injection where the object has a constructor that accepts an instance of each interface it requires or through property setters accepting the service providers. When using dependency, I lean toward the use of constructor injection because I view the constructor as being a much better way to "discover" what is required for the instance to be ready for use. During resolution, Unity looks for an injection constructor and will attempt to resolve instances of each interface required by the constructor, throwing an exception of unable to meet the advertised needs of the class. The up side of this approach is that the needs of the class are very clearly advertised and the class is unaware of which IoC container (if any) is being used. The down side of this approach is that you're required to maintain the objects passed to the constructor as instance variables throughout the life of your object and that objects which coordinate with many external services require a lot of additional constructor arguments (this gets ugly and may indicate a need for refactoring).
The final way that I've seen and used Unity is to make use of the ServiceLocator pattern, of which the Patterns and Practices team has also provided a Unity-compatible implementation. When using the ServiceLocator, your class calls ServiceLocator.Retrieve in places where it would have called Resolve on the Unity container. Like using Unity directly, it does tie you directly to the ServiceLocator implementation and makes your code aware that dependency injection is taking place, but it does have the up side of giving you the freedom to swap out the underlying IoC container if necessary. I'm not hugely concerned with hiding IoC entirely from the class (I view this as a "nice to have"), so the single biggest problem that I see with the ServiceLocator approach is that it provides no way to proactively advertise needs in the way that constructor injection does, allowing more opportunity for difficult to track runtime errors.
This blog entry has not been intended in any way to be a definitive work on IoC, but rather as something to spur thought about why we program to interfaces and some ways to reach the intended value of the practice instead of having it just complicate your code. I hope that it helps somebody begin or continue a journey away from being a "Cargo Cult Programmer".
Sunday, March 18, 2012
This blog entry is intended to provide a narrow and brief look into a way to use the Select extension method that I had until recently overlooked.
Every developer who is using IEnumerable extension methods to work with data has been exposed to the Select extension method, because it is a pretty critical piece of almost every query over a collection of objects. The method is defined on type IEnumerable and takes as its argument a function that accepts an item from the collection and returns an object which will be an item within the returned collection. This allows you to perform transformations on the source collection. A somewhat contrived example would be the following code that transforms a collection of strings into a collection of anonymous objects:
1: var media = new[] {"book", "cd", "tape"};
2: var transformed = media.Select( item =>
3: {
4: Media = item
5: } );
This code transforms the array of strings into a collection of objects which each have a string property called Media.
If every developer using the LINQ extension methods already knows this, why am I blogging about it? I’m blogging about it because the method has another overload that I hadn’t seen before I needed it a few weeks back and I thought I would share a little about it with whoever happens upon my blog. In the other overload, the function defined in the first overload as:
1: Func<TSource, TResult>
is instead defined as:
1: Func<TSource, int, TResult>
The additional parameter is an integer representing the current element’s position in the enumerable sequence. I used this information in what I thought was a pretty cool way to compare collections and I’ll probably blog about that sometime in the near future, but for now we’ll continue with the contrived example I’ve already started to keep things simple and show how this works. The following code sample shows how the positional information could be used in an alternating color scenario. I’m using a foreach loop because IEnumerable doesn’t have a ForEach extension, but many libraries do add the ForEach extension to IEnumerable so you can update the code if you’re using one of these libraries or have created your own.
1: var media = new[] {"book", "cd", "tape"};
2: foreach (var result in media.Select(
3: (item, index) =>
4: new { Item = item, Index = index }))
5: {
6: Console.ForegroundColor = result.Index % 2 == 0
7: ? ConsoleColor.Blue : ConsoleColor.Yellow;
8: Console.WriteLine(result.Item);
9: }
Wednesday, March 14, 2012
If you're like a lot of people I've known, worked with, and been, you have a history of either installing Visual Studio (or getting a computer from IT with Visual Studio already installed), selecting a preset option from the "what kind of development work do you do?" menu, and coding away. I spent years occasionally hearing words like "CodeRush" and "Resharper" without really knowing what these things were or giving a second thought to how a productivity tool like them could help my work. A couple years ago I happened to win both a CodeRush and Resharper license in drawings at the same conference. JetBrains sent me a license activation key the same day and DevExpress took a couple months to send theirs, so by the time I received the CodeRush key I was already used to Resharper and didn't spend much time with the DevExpress tool. I mention that not to disparage the folks at DevExpress in any way because it's cool that they participate in developer community events and give away licenses at all, but to establish the reason that my discussion of productivity addins centers mostly around the way that Resharper helps me. There are several great productivity addins available right now and I think it is much more important that a developer uses one of them than it is which one the developer chooses.
One of the features that developer productivity addins are known well for is the active analysis of code to detect not only syntax errors, but goes beyond red squiggles and shows deviation from accepted coding practices, language constructs that could introduce runtime or logical errors in your application, and opportunities to use alternative language features. In the case of Resharper, this is accomplished by using a color-coded "Marker Bar" which gives a visual indication of the location and category of detected code issues as well as a menu option that allows you to retrieve a full listing of all the issues detected in the project/solution. This feature works best in a team setting when all of the developers are committed to keeping their code as "green" as possible. While automated analysis of the code cannot guarantee that the code is doing the right things and suitable for a business purpose, it does allow code review sessions to be focused on answering these questions because the more mechanical concerns have already been addressed.
Another feature that I find valuable in a coding assistance tool is coding assistance. In the case of Resharper, this comes in the form of extending upon the built-in Intellisense feature with additional code completion techniques, stubbing out language constructs that have required elements (such as for loops), and converting looping constructs into their LINQ equivalent. These features in Resharper have become an integral part of my development workflow to the point where I find myself forgetting that they are added by an addin and I expect them to be on every Visual Studio installation I use - which can be a bit disorienting when I use a computer that doesn't have Resharper installed. It also helped immensely while I was learning LINQ because the tool would suggest converting my loops to LINQ and I could examine the result of the conversation in a context that was very pertinent to me and the work I was doing.
The other feature of Resharper that I use quite a bit and is present in other addins is refactoring. This goes beyond the built-in refactorings offered by Visual Studio and can take a lot of the work out of keeping code organized. For one usage example, consider an organization that is committed to programming to interfaces, so there is always at least a small amount of duplication in that method signatures must be defined both in the interface and in the concrete class implementing the interface. The benefits of interface-based development often outweighs this duplication, but it is still an annoyance in the workflow and Resharper helps me reduce the overhead through the "Pull Members Up" refactoring. When doing green field development I can create an empty interface, develop the class implementing the interface (still empty) to satisfy its responsibility and then use the "Pull Members Up" refactoring to have Resharper do the repetitive work for me. This is just one example of the many time-saving refactorings available.
In this post I have tried to stress the benefits that a productivity addin can bring to a developer's workflow without being too much of a cheerleader for the one I happen to use. If you're not using a productivity addin today you should take one for a spin for a couple weeks. Some of the features do need to grow on you a little, so don't just give it a few minutes.
Wednesday, March 07, 2012
With as often as I write code that does not perform as well as I would like for it to, I can’t believe how hard it is to write slow code on purpose! My last post gave a mile-high overview of the new version of Redgate’s ANTS Performance Profiler and promised more detail to come. True to my word (this time), this post aims to take a fairly simple application with common “opportunities” and use ANTS Performance Profiler to quantify these opportunities and measure the results. If you’re working along at home, I’ll provide the solution files and you will need to provide an environment where Visual Studio 2010 (I use Ultimate, but in this case any SKU should be fine), Redgate ANTS Performance Profiler (see my previous post for a link to the trial version), SQL Server Compact Edition 4.0, and the Visual Studio SQL CE Tools are installed. To make it easy to get up and running, the solution uses the Code First approach for Entity Framework and will create the database and test data if they don’t already exist, so you will probably want to start by running the solution without measuring anything so this creation overhead doesn’t skew your measurements.
Our project centers around the need for a console application to list events that occur within a given month. The takes a date, and then lists all the days that occur within the same month and and events that may be scheduled on that date. The data model is pretty simple and looks like this:
This post isn’t (overtly) about Entity Framework, so I won’t get into the gritty details on creating the entity objects and their associated object context, but please do peruse the code. The starter solution can be downloaded at https://skydrive.live.com/redir.aspx?cid=0adb9450bcc3d727&resid=ADB9450BCC3D727!370&parid=ADB9450BCC3D727!369
Once you’ve downloaded the solution, open it up, run it, and poke around a bit. When you’ve got an idea of how things work, let’s start a profile session. From the ANTS menu in Visual Studio, click “Launch ANTS Performance Profiler”
Use the settings from the screenshot below to model your settings and then click “Start Profiling”
The app will run and a few seconds later, you’ll be presented with the profiling results. There’s a lot of great information here, but this is intended to be a quick and dirty on how quickly we can make your app faster, so we’ll cut straight to what I see as the shortest path to measurable gain. The bottom pane of the results window shows the source of your application as below:
The key pieces of information in this view to help you make decisions are the Hit Count, which tells you how many times each line of code was hit, the Avg Time (%), which tells you on average how much of the overall run time each time the line of code executed took, and Time (%), which tells you the percentage of the run time that the cumulative executions of the line took. In the right-hand column, clickable colored indicators allow you to quickly zoom in on the lines of code that take the most time.
While not the most cumulative execution time, a quick and easy optimization that jumps out is the code at line 28. The metrics we’re given by ANTS shows that this line was executed 150 times, each execution took an average of .053% of the total execution time, and the cumulative executions took 7.9% of the total execution time. In other words, since the code could be rearranged to have the context instantiated only once, 7.9% of the run time is spent accomplishing what could be done in .05%. I’m given clear direction that a measurable gain can be had by moving the instantiation of the context out of the loop. When I move the code outside the loop and re-execute, the new profile tells me that this line no longer has any significant impact on the performance profile.
There are some other obvious places where optimization can be applied such as executing a query for each day instead of the entire month, so give them a try and see how the profile results shift. Just remember you can never get rid of your worst performing line of code because something will always hold that distinction.
The purpose of this post and my previous post on this subject was to encourage thinking about taking a measured approach to optimization and to demonstrate how easy Redgate ANTS Performance Profiler makes this. We’ve only brushed the surface of the capabilities of the tool, so if I’ve peaked your interest be sure to check out the features and tutorials available at Redgate’s site (http://www.red-gate.com/products/dotnet-development/ants-performance-profiler/)
Wednesday, February 29, 2012
In this blog post I intend to capture some thoughts on code optimization in general and on how the new version of RedGate's ANTs Performance Profiler can be used to "optimize optimization".
As developer's trying first to drive business value, many latch onto the mantra "Don't optimize too early". As with many axiom's, the spirit is right on - if you allow solving the business problem to wait while you shave milliseconds off of a process that takes minutes or you have found the best memory management technique in the world that renders your code completely unreadable, then you fail in your primary task. A much better approach is to solve the problem in as straight-forward a manner as possible, keeping in mind standard coding practices in regards to performance and scalability. Once you have working code that solves the business problem, you can decide if it's time to optimize.
So, why optimize something that's working and meets a business need? In my opinion, there are two main reasons. The first reason would be that the application is not performing to expectations. This could be a very specific measure in the rare case where non-functional requirements actually exist that define performance metrics or general reports of "it's too slow" coming from users testing or using your application. The second reason is that you find yourself with some spare bandwidth and schedule an optimization pass. Either way, if you're like me you want to get the absolute best return on any investment that you put into optimization.
How do you approach optimization? I ask this question often of people that I am interviewing and usually the reply is some variation of "well, I read the code and look for things that I know are bad, change those things, and run the code again to see if it's better". I wouldn't want my auto mechanic being paid by the hour to do that, so why do we think it's a reasonable approach for a developer? I think the answer lies in the fact that most developers do not have a tool to help plan optimization sessions that is easy to use and understand. We spend a lot of time learning the facets of our trade that directly correspond to delivery, which leaves little time or desire for becoming experts in the tools that Microsoft provides. In order for me to add an auxilliary tool to my belt, it needs to save me time and not require to become an expert in the tool itself.
I decided to start looking at Redgate's ANTS Performance Profiler 7.0 (trial downloaded from http://www.red-gate.com/products/dotnet-development/ants-performance-profiler/download) last night following a couple discussions at work last week about optimization and receiving an email about the tool. My initial pass at the product was an evaluation against the "it just works" test. I wanted to know if I could install the tool and without referencing any documentation profile an application and comprehend the results. The install went as smoothly as you'd expect of any modern Windows application with the exception of having received an error message referencing the initialization of Reflector (which also installed with the trial) that I used the automated error reporting to send to Redgate. I wrote a quick console application utilizing three different methods of building a large string ("+=" concatenization, StringBuilder, and StringBuilder initialized with a capacity equal to the size of the string that would be built). I clicked the "start profile" button from my ANTS menu, received a message that I needed to build first, built the project, clicked the menu item again, and a couple minutes later (I made some REALLY big strings) had a an interactive report in front of me whose default view contained a timeline of performance counter information, a treegrid labeled "Call Tree" that had already expanded a "hot path" drilling down to the method using the most overall time in the application run, and a third pane that I couldn't initially tell it's use but displayed source code and metrics when I selected a method in the Call Tree (this is where Reflector comes in).
The basic "does it just work" test passed with flying colors. The setup work required to profile the application was no more than the setup work required to run the application and, as a "mere mortal" developer, I was able to immediately get derive value from the results with no investment in learning the tool. I can easily see this tool paying for itself in the time saved on a single optimization session by taking the guesswork out of where the most impactful changes can be made (do I focus on the method that executes in 500ms and is called once or the one that executes in 50ms and is called 1000 times?).
I plan on spending quite a bit more time over the next week or so with this tool and dig into less trivial examples and features that actually require some study. My next couple posts will focus on nuggets gleaned from this exploration. If you have found any cool features of this product I'd love to hear about it as well.
Thursday, December 29, 2011
I'm a big believer in the benefits of having automated tests live with your code. I'm not an aspirant to Red-Green-Refactor Nirvana, but I believe there is a huge value to be gained by taking the code from Button1_Click in the only Windows Form application you've ever written and placing it instead into a method that can be used by a unit test framework. Some of the benefits that I glean from this include my test being preserved past the initial implementation (when you write the next feature of course you're going to replace the code in Button1_Click to test what you're working on right now) which provides some level of regression testing, a clear expression of what the developer intended the code to do (this is improved even more with good naming of test methods), and working examples of how to make use of the API you've developed. This last benefit can be broken down even further in that a side-effect of writing the tests can be noticing ways to make your API easier to use.
Now that I've established that I really like the idea of automated testing, let me get to the point of this post - don't bother writing unit tests if you're not going to use them to prove your code works. When I am familiarizing myself with a project, one of the first things that I do after going through whatever high level information is available is attempt to do a "get latest" from source control, build, and run the unit tests. This gives me a good idea of what remains to be implemented unless the tests don't actually prove anything. Let's start with a blaringly obvious example:
1: [TestMethod]
2: public void VacationManagerShouldValidateUserHasAccruedRequestedTime()
3: {
4: }
It's very likely that the (fictional) author of this test was trying to be proactive and stubbed out all the tests that would be needed for the functionality they were working on, but when I run all the tests in the solution I see the name of the test method with a green "Passed" next to it. It's a great idea to decide what tests you'll need in advance and actually an approach that I recommend as a way to keep focus on progress against requirements, but instead of allowing the lack of hitting a failure condition make the test report as successful the test could start out like this:
1: [TestMethod]
2: public void VacationManagerShouldValidateUserHasAccruedRequestedTime()
3: {
4: Assert.Inconclusive("functionality hasn't been written yet");
5: }
Another similar option would be to throw NotImplementedException, but this doesn't quite as clearly identify that you just haven't gotten around to it yet.
Another common problem with automated tests is that many do not actively check for the post-conditions that prove the call was successful. Building on our fictional example, let's say the test author this time actually put some code in the test:
1: [TestMethod]
2: public void VacationManagerShouldValidateUserHasAccruedRequestedTime()
3: {
4: var target = new VacationManager();
5: var employeeId = "12345";
6: var beginDate = new DateTime(2011, 12, 21);
7: var endDate = new DateTime(2011, 12, 23);
8: target.SubmitRequest(employeeId, beginDate, endDate);
9: }
In this case, context clues and experience tell me that the test author "knows" that if the employee does not have enough time accrued the method will throw an exception, causing the test to fail. I contend that unit testing is much more about what you can prove than what you know. If it was about what you know, then you wouldn't have written the test in the first place because you already know your code works. Let's peek inside VacationManager and see what happened:
1: public void SubmitRequest(int employeeId, DateTime beginDate, DateTime endDate)
2: {
3: //*****************************************************
4: //*****************************************************
5: // HISTORY:
6: // 8/21/2010 initial code complete by Joe Developer
7: //*****************************************************
8: // 4/19/2011 updated by Maintenance Guy to fix issue
9: // where user received timeout error message
10: //*****************************************************
11: //*****************************************************
12: try
13: {
14: // ... some information gathering
15: if(numDaysAvailable < numDaysRequested) throw new Exception("not enough time");
16: // ... update the data and kick off approval workflow
17: }
18: catch(Exception e)
19: {
20: // don't show user the error (MG 4/19/2011)
21: }
22: }
Guess what - when Maintenance Guy runs the Unit Test Suite after making his changes the test will still pass. Think back to when you were still hammering out code in Button1_click. One level of testing was to click the button and step through the code, but you (hopefully) also had a tool handy to look into the database and see that the record made it and all the fields were populated appropriately. Take your own fingers and eyeballs out of the equation and you'll find that your automated test needs to do the functional equivalent. This can either be through directly querying the data store or, if available, using the retrieval mechanisms of your API which of course have their own tests to prove they are trustworthy.