Rants Tagged with “Silverlight”
As many of you who've been following know, I use a simple database of XBox game data as my example database. I usually remember to include it on the server project but in some examples its been forgotten. In other cases I've shipped with a 2008 version of the database instead of the 2005 version. To address this, I've uploaded .zip'd versions of both the 2005 and 2008 databases for anyone to use for any reason. This includes my RIA Services sample (which is using a SQL Server 2008 version) or my MVVM MSDN article sample which also uses a 2008 version. They include a MDF and a LDF. If you have trouble attaching them to an existing database, try deleting the LDF file. Go grab there here:
Any questions/problems, post a comment!
While in Sweden for OreDev, Microsoft pulled me aside to do a quick interview about Silverlight, Data and the reported death of WPF. Daniel Mellgaard Frost does a great job of asking me the tough questions about Silverlight. Note that this interview happened before Silverlight 4 was announced so some of my answers would be different today.
As many of you don't know, I was previously known as "The ADO Guy" so of course my first jump into the new Silverlight 4 bits was to play with the new Data Binding changes. The improvements aren't dramatic but they do fill several key holes that existed in the earlier versions. Let's take these changes one at a time.
DependencyObject Binding
Prior to Silverlight 4, in order to support data binding, the object had to derive from the FrameworkElement class which left out some key objects including Transformations. Now data binding works on any object that derives from DependencyObject (which is most of the Silverlight 4 framework). You can see this in the example below. (Note, you can also see the CompositeTransform which lets you set transformations of all four types in a single transform):
<Grid x:Name="LayoutRoot"
Background="White">
<StackPanel Width="400"
Height="300">
<StackPanel.RenderTransform>
<CompositeTransform
ScaleX="{Binding Value,ElementName=stretcher}"
ScaleY="{Binding Value,ElementName=stretcher}" />
</StackPanel.RenderTransform>
<ListBox ItemsSource="{Binding}"
Width="400"
Height="300">
</ListBox>
</StackPanel>
<Slider Minimum=".5"
Maximum="4"
x:Name="stretcher"
Value="1" VerticalAlignment="Top" />
</Grid>
By adding the ability to use data bindings on DependencyObject derived objects, Silverlight 4 opens up using UI interactions through XAML.
String Formatting
Additionally, Silverlight 4 adds the ability to do string formatting directly in the data binding. Previously you would have to use a Converter to format data during binding. This greatly simplifies straightforward formatting of data into strings like dates and money values. It even uses the format to perform parsing for two-way data binding. To use it, simply use the markup extension "StringFormat" and the format (short or long form) as shown below:
<TextBox Text="{Binding ReleaseDate, StringFormat='MMM dd, yyyy',
Mode=TwoWay}" />
<TextBlock Text="{Binding Price, StringFormat='c'}" />
Null and Fallback Values
Data binding has also added the ability to specify what to show in certain cases. These cases include when the value is NULL and when the value fails to load. There are two markup extensions that support this. First the TargetNull markup extension lets you specify what to show when the bound value is null. Secondly, the FallbackValue is used in the same way but is shown when the value cannot be loaded through data binding (normally when the DataContext is null or fails to find the property on the bound object). Here is an example of how that works:
<TextBlock Text="{Binding Developer, TargetNullValue='(None)'}" />
<TextBlock Text="{Binding Publisher, FallbackValue='(Nope)'}" />
CollectionViewSource Changes
For all of you who are doing grouping (using the DataGrid or similiar controls), good news. The CollectionViewSource now supports data binding to the GroupDescriptions so you can more easily describe your grouping in XAML.
Error Propogation
The Silverlight 3 validation stack was a good start, but still left a bit to be desired. Following the request from the community, controls will now use the IDataErrorInfo interface to get error information on your bound objects if it is available. To make this facility even better, they've introduced INotifyDataErrorInfo interface so that live bindings can efficiently know about changes to the IDataErrorInfo interface's data.
Overall I am happy with the set of data binding functionality. Enjoy playing with Silverlight 4 and let me know what you think of these changes!
As noted in Scott Guthrie's keynote early, Silverlight 4 is now in beta. But what does that mean to you? Silverlight 4 Beta does not have a go-live license, so if you're building something to be released soon, I would stick with Silverlight 3. In contrast if you're working on a longer term project, especially a line-of business application, you'd be crazy to not look at Silverlight 4. Here are some of the major changes in this release:
General
- Printing Support
- Implicit Styling
- WebCam/Microphone Support
- RichTextArea Control
- Right-Mouse Button Events
- Drag-n-Drop/Clipboard Access
- UDP/Multicast Support in Networking
Out of the Browser Improvements
- Elevated Trust
- WebBrowser Control
- Controlling the Window
- Notification Windows (e.g. Outlook popup's)
- COM Integration
Data Binding Improvements
- Binding to DependencyObjects (used to be FrameworkElement)
- StringFormat Markup Extension
- TargetNullValue Markup Extension
- FallbackValue Markup Extension
- Support for IDataErrorInfo and new INotifyDataErrorInfo for reporting validation errors.
- Binding to String Indexers
- GroupDescription support on CollectionViewSource for simplified grouping.
That's a splendid list of improvements. I will be writing blog entries about some of my favorites this week. So keep an eye out for some examples!
Last week I had the pleasure of presenting again at the SDN Conference. I had a great time at the conference. I ended up presenting (or co-presenting) six talks at the conference. The Silverlight talks were some of my favorites:
In addition, I gave a breakout session at the Windows 7 launch (where they gave away 100 copies of Windows 7). My talk at the launch was:
- Adding Windows 7 Features to Your .NET Applications
I was able to show off how to create TaskDialogs, Taskbar features like progress, thumbnails and jumplists. I had a lot of fun doing that talk (et lekker!).
A couple of days before the talk, I noticed that Ted Neward and I had a similar talk on MGrammar so we decided to co-host both sessions. Since Oslo is early, there were a lot of skeptics in the rooms; not all did we convert but it did create some very interesting discussion of what is a Domain Specific Language and whether Oslo is the key to DSLs in the Microsoft space. The talks I did on Oslo included:
Of course conferences are not just about doing talks. They are also about visiting with *my* favorite speakers. The usual bunch were there:
Carl Franklin
Steve Forte and Richard Campbell
Beth Massi
Ted likes his soup:
Paco Likes Soup too (aka Hadi Hariri)
Its been a fun time, and almost 1/2 over.
While in Bulgaria, I was asked to sit down with Tibu Tiberiu “Tibi” Covaci for five minutes for a short list of questions. He's released the short podcast and go take a look here if you're interested in hearing what I have to say about the future of technology.
http://www.cloudcasts.net/ViewWebcast.aspx?webcastid=2521462397756387551
Before I left for Europe, I had a chance to sit down with Richard and Carl and espouse my views on views. Specifically we discussed how the separation of UIs (in declarative UI's like XAML and JavaScript templating) may help developers know specifically when they are in or out of the user interface part of their project. Hopefully this will make it easier to keep our code from getting tangled. Watch out for the bad pizza/spagetti code reference...
As I've been on the mend lately, i've been looking deep into how Validation should work in Silverlight. As I am trying to expand some of hte validation scenarios in Silverlight (in my Niagara project), I'd like to see how you are feeling about Validaiton.
Currently (as my previous post mentioned), the current validation stack is pretty tightly coupled to RIA Services (though with some work you can get it working with other data stacks). But the question is really which validation stack does Silverlight really need. Let's discuss the two I've been looking at: DataAnnotations and Enterprise Libraries' Validation Application Block.
DataAnnotations
Let's talk history. Back in .NET 3.5 SP1 (ok, I know many of you are still in .NET 2.0, my apologies), the DataAnnotations assembly was shipped. My assumption that this was to accomodate the newly christened Dynamic Data Web projects. Dynamic Data needed a way to communicate information it couldn't discern (like required fields, string length, etc.) The way that it did this was via a set of attributes in the System.ComponentModel.DataAnnotations. For example:
public class GameInfo
{
[Required]
[StringLength(100)]
public string Name { get; set; }
[Range(0d, 1000d)]
public decimal Price { get; set; }
}
The problem with this approach was that in most cases, the classes were generated via an ORM (LINQ to SQL, Entity Framework, etc.) and adding these attributes on generated code just doesn't work. So someone came up with a workaround (or a hack if you prefer): the Metadata Type.
The idea behind a metadata type was that with partial types, users can add attributes to a class (but not a property) so by adding an attribute to each entity class that said, the metadata (e.g. validation attributes) for this class are stored in this metadata type that is never used except as a payload for the metadata about our entity. For example:
[MetadataType(typeof(Game.GameMetadata))]
public partial class Game
{
internal sealed class GameMetadata
{
// Metadata classes are not meant to be instantiated.
private GameMetadata()
{
}
public string Description;
public string Developer;
public EntityState EntityState;
public int GameID;
public Genre TheGenre;
public string ImageUrl;
[Required]
[StringLength(100)]
public string Name;
[Range(0d, 2000d)]
public Nullable Price;
public string Publisher;
public Rating TheRating;
public Nullable ReleaseDate;
}
}
Early on, using the metadata classes to add these bits of data may have made sense because the sites you were creating were quick and dirty data editing sites. The problem is that this stack was adopted by RIA Services to allow for better validation in the Silverlight space (and eventually other platforms).
The DataAnnotations in RIA Services are a bit fractured as well. There are no less than three versions of the DataAnnotations that can cause confusion. The atttributes lists are different in these three versions:
- .NET 3.5 SP1's System.ComponentModel.DataAnnotations
- RIA Services's System.ComponentModel.DataAnnotations
- Silverlight's System.ComponentModel.DataAnnotations
The three versions can cause some confusion as the attributes that you can use are duplicative (See .NET 3.5 SP1's Description attribute versus RIA Service's as an example).
The current Silverlight validation stack relies on exceptions to be thrown during set property setters (or you can validate the whole objects yourself). While this works, it does seem at odd with the work at hand and having a simple Validation model that returned results would be better IMHO. I understand that RIA Services was trying to fit into an existing Silverlight model but that doesn't mean I have to like it.
This stack may be good enough, especially with the ability to do custom validation with RIA Services but I sense that it may be too shallow for real validation.
Enterprise Library's Validation Application Block
On the other side of the coin is the Patterns and Practice team's Validation Application Block (VAB). This is a set of code that allows you to specify validation using either attributes or configuration files. While the Validation Application Block doesn't support Silverlight directly, I've been investigating it as an alternative design.
The Validation Application Block's design is focused on some of the same principals as the DataAnnotations but they were trying to solve some different problems. Some of the features of that design that may be of use in Silverlight are:
- Multi-level validation (e.g. Validates with And/or clauses: "NULL or StringLength 5-25")
- Configuration doesn't rely on attributes but can use them
- Uses a provider model for specifying the validation so other sources of validation metadata are possible
- Large number of built-in validations
- Support for multiple sets of validation (RuleSets)
- Validation is object-based to allow for cross validation (Either Name or CompanyName but not be null).
- Fail-over validation detection (e.g. look for attributes, if not found look up configuration, etc.)
- Validation returns simple ValidationResults which can be parsed or shown to the user. No Exceptions requried.
For example a typical attribute scenario for validation looks a lot like the RIA Services' approach:
[StringLengthValidator(1, 50,
Ruleset="RuleSetA",
MessageTemplate="First Name must be between 1 and 50 characters")]
public string FirstName
{
get { return firstName; }
set { firstName = value; }
}
[StringLengthValidator(1, 50,
Ruleset = "RuleSetA",
MessageTemplate = "Last Name must be between 1 and 50 characters")]
public string LastName
{
get { return lastName; }
set { lastName = value; }
}
[RelativeDateTimeValidator(-120,
DateTimeUnit.Year, -18, DateTimeUnit.Year,
Ruleset="RuleSetA",
MessageTemplate="Must be 18 years or older.")]
public DateTime DateOfBirth
{
get { return dateOfBirth; }
set { dateOfBirth = value; }
}
[RegexValidator(@"\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*",
MessageTemplate="Invalid e-mail address",
Ruleset = "RuleSetA")]
public string Email
{
get { return email; }
set { email = value; }
}
[ObjectValidator("RuleSetA", Ruleset = "RuleSetA")]
public Address Address
{
get { return address; }
set { address = value; }
}
[RangeValidator(0, RangeBoundaryType.Inclusive,
1000000,
RangeBoundaryType.Inclusive,
Ruleset = "RuleSetA",
MessageTemplate="Rewards points cannot exceed 1,000,000")]
public int RewardPoints
{
get { return rewardPoints; }
set { rewardPoints = value; }
}
In addition it supports a configuration-based solution:
<validation>
<type assemblyName="ValidationQuickStart.BusinessEntities,
Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null"
name="ValidationQuickStart.BusinessEntities.Address">
<ruleset name="RuleSetB">
<properties>
<property name="City">
<validator lowerBound="1"
lowerBoundType="Inclusive"
upperBound="30"
upperBoundType="Inclusive"
negated="false"
messageTemplate=""
messageTemplateResourceName=""
messageTemplateResourceType=""
tag=""
type="Microsoft.Practices.EnterpriseLibrary.
Validation.Validators.StringLengthValidator,
Microsoft.Practices.EnterpriseLibrary.Validation"
name="String Length Validator" />
<validator characterSet="1234567890!@#$%^&*()-="
containsCharacter="Any"
negated="true"
messageTemplate="City may not contain numbers"
messageTemplateResourceName=""
messageTemplateResourceType=""
tag=""
type="Microsoft.Practices.EnterpriseLibrary.Validation.
Validators.ContainsCharactersValidator,
Microsoft.Practices.EnterpriseLibrary.Validation"
name="Contains Characters Validator" />
<validator negated="false"
messageTemplate=""
messageTemplateResourceName=""
messageTemplateResourceType=""
tag=""
type="Microsoft.Practices.EnterpriseLibrary.Validation.
Validators.NotNullValidator,
Microsoft.Practices.EnterpriseLibrary.Validation"
name="Not Null Validator" />
</property>
</ruleset>
</type>
</ruleset>
</validation>
This syntax while it works, its pretty terse and unreadable (as configuration tends to be). But it is decoupled which is nice.
While many of these features are laudable, it feels a bit over-engineered and complex. The VAB uses Validators for a number of cases where its just a grouping technique so debugging individual validations can be complex.
"Just Right?"
So here is where I put it to you, my readers:
"What do you need in Silverlight?"
- Is the RIA Stack good enough?
- Do you want validation regardless of what the transport is (ADO.NET Data Services, WCF, REST)?
- Is using RIA Services' CustomValidation with method name good enough for custom scenarios?
- Do you need complex validation (where AND/OR validation is necessary)?
- How important is decoupling your validation metadata from the model?
- Do you detest metadata types or is it just a necessary evil?
Please comment here so we can start a dialogue to help me understand what the development community is thinking about validation.
As some of you may know, I am a contributor to the SilverlightContrib open source project. Recently this project and the Silverlight Extensions open source project (also know as SLExtensions) decided to merge to create a single place for a lot of interesting functionality.
I want to highlight some of the pieces that I didn't contribute as I've seen a lot of really great functionality for those of you who are building Silverlight Applications. I honestly have no idea how many parts this blog series will be, as long as I have parts that are interesting, I'll continue to post about them.
First up is SLExtension's Bootstrapper functionality. If you are currently using Prism or a related technology to compose your application at runtime, this functionality is lost on you. The Bootstrapper functionality is for that middle-ground where you want to break up your project into a small number of .xap files that are loaded when the project loads up but don't need a full composition engine with MEF or Prism.
The Bootstrapper functionality is in a separately assembly in the SLExtensions project (SLExtensions.Bootstrapping.dll). This is a small assembly (so that your main project loads fast). The way it works is to have you change the derived class for the App.xaml to a BootstrapApplication:
public partial class App : BootstrapApplication
{
Since its the App.xaml class, you'll need to change the XAML as well:
<bs:BootstrapApplication
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="FunWithBootstrapper.App"
xmlns:bs="clr-namespace:SLExtensions.Bootstrapping;
assembly=SLExtensions.Bootstrapping">
<bs:BootstrapApplication.Resources>
</bs:BootstrapApplication.Resources>
</bs:BootstrapApplication>
Once you have the application changed, you will need to override the Xaps property to supply the list of XAP files to load:
protected override IEnumerable<Uri> Xaps
{
get
{
// Must be absolute Uris so we steal it from the host
return new Uri[] {
new Uri(new Uri(Host.Source.AbsoluteUri), "SecondApp.xap"),
new Uri(new Uri(Host.Source.AbsoluteUri), "ThirdApp.xap"),
};
}
}
At this point it will load up the other .xap files but we won't be able to do anything with them. So let's look at the other projects briefly.
The other Silverlight projects are actually full Silverlight Applications (not Client Library projects). The Bootstrapper is usually used to create a 'splash screen' xap file that loads the other parts of the applications. Again, not real composition like Prism, but something less than that.
In the main project, you will make a reference to the other application projects. That's how you'll be able to reference the code from the other xap files (though only once they've been loaded).
To help you know when its updated, the Bootstrapper application has two facilities:
- Progress event
- OnApplicationReady overridable method
Now that you have a bootstrapping application, you want to be able to work with it. The first thing I usually do (because I want to use the Bootstrapping API's from anywhere without casting) is create a new static property on the Application class:
// Better access to the bootstrapping app
public static App MyApp
{
get { return Current as App; }
}
Then I can use the Progress event to show the user some progress like so:
void MainPage_Loaded(object sender, RoutedEventArgs e)
{
App.MyApp.Progress +=
new EventHandler<BootstrapEventArgs>(Bootstrap_Progress);
}
void Bootstrap_Progress(object sender, BootstrapEventArgs e)
{
thePartProgress.Value = e.StepProgress;
theFullProgress.Value = e.OverallProgress;
}
I'd like to be able to know when the application is completely loaded too. Unfortunately the Progress event tends to not return 100% at any time. I haven't figured out why yet, but to get around that you can use the OnApplicationReady overridable method:
public partial class App : BootstrapApplication
{
...
protected override void OnApplicationReady(StartupEventArgs e)
{
// Do startup behavior
}
...
}
While this works, I often don't want to do this work in the App class, but instead in other parts of my application (e.g. MainForm.xaml.cs). So For my use, I usually expose an event as well:
public event EventHandler<StartupEventArgs> StartupComplete;
protected override void OnApplicationReady(StartupEventArgs e)
{
if (StartupComplete != null)
{
StartupComplete(this, e);
}
}
By throwing an event when the application is ready, I can register for this event and do the startup once I know all the code is available:
// MainPage.xaml.cs
void MainPage_Loaded(object sender, RoutedEventArgs e)
{
App.MyApp.Progress +=
new EventHandler<BootstrapEventArgs>(Bootstrap_Progress);
App.MyApp.StartupComplete +=
new EventHandler<StartupEventArgs>(Bootstrap_StartupComplete);
}
void Bootstrap_StartupComplete(object sender, StartupEventArgs e)
{
// Use the loaded types
// (SecondApp.MainPage and ThirdApp.MainPage)
theSecondApp.Children.Add(new SecondApp.MainPage());
theThirdApp.Children.Add(new ThirdApp.MainPage());
}
Note that once the bootstrapping has completed you can use the assemblies in the other .xap projects. If you attempt to use them before, you'll get an exception that it couldn't load the type.
Just to prove the point, here is a list of the .xap files. Notice that the 2nd and 3rd .xap file are pretty big but even with the bootstrapping assembly, our code is only 10K which means it should load very fast:
Neat? What do you think?
You can get the source to my example here:
http://wildermuth.com/downloads/FunWithBootstrapper.zip
If you're a regular reader of my blog, you'll probably remember my pithy blog post where I stated that "It all depends..." to the question "Which Data Access Should I Use for Silverlight 3?" The reality is that much like the similar question I am confronted with at user groups for the past decade ("What data access should I use in my .NET app?"). The reasons for picking a strategy are wide and varied so I will not try to analyze all possible outcomes, but I think the different strategies need to be explained better.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
- Web Services: Interface-based Data Access
- ADO.NET Data Services: LINQ-based Data Access with change management
- RIA Services: Interface-based Data Access with change management
Let's dive deeper into explaining these differences and why that might matter.
Web Services
Using web services is the tried and true method for communicating across the firewall. This pattern is well known and reliable. In general this requires you specify an interface for the CRUD operations as separate operations on a web service then dutifully call them in your Silverlight code.
Reasons to Use: Any existing investment in web services can be a great reason to use them (whether in code or skillset). Also, web services are often used in cases where a project wants a very close control over the flow from the application to the database.
Reasons to Avoid: With web services you end up having to keep track of the changes yourself and know what services to call with updates. Any need for batching or transactional support gets cumbersome and code-intensive.
ADO.NET Data Services is a simple REST-based facility for data access. It relies on the HTTP stack to help define the interface. GET calls become Reads, POST becomes Updates and so on. It uses ATOM or JSON for its serialization format so it is consumable by a variety of clients.
Underneath its covers it takes this URI based API and converts it into a LINQ call for GETs and to API calls to the provider for inserts, updates and deletes. That means that ADO.NET is a thin layer who's purpose is to translate the URI model to data access code. But its better than that...
The real power of ADO.NET Data Services for Silverlight is the inclusion of the Client Library. This client library allows you to issue LINQ queries defined in the client and executed on the server. While the LINQ syntax is somewhat limited when compared to the server, it fulfills the 80% case and ADO.NET Data Services allows you to add operations to fill in the rest when necessary. In addition, the client library includes a powerful data context class that can monitor changes and issue changes in batches with transactional support.
Exposing your data access with ADO.NET Data Services is about exposing queryable end-points instead of defining an interface. This is what makes is unique. For example, we can query our service using a LINQ Query like so:
// Silverlight Code
// Create the query using LINQ
var qry = (from g in ds.Games
where g.Price < 50m
orderby g.Name
select g) as DataServiceQuery<Game>;
// Execute the Query
// (This part is getting cleaner in ADO.NET Data Services v1.5)
qry.BeginExecute(new AsyncCallback(r =>
{
games2.ItemsSource = qry.EndExecute(r).ToList();
games2.DisplayMemberPath = "Name";
}), null);
Reasons to Use: Want a simple, secure model where the developers can define the queries they need in code instead of changing the interface as the needs change. The ADO.NET Data Services' client library makes the amount of code you write on the client small as it becomes LINQ calls and working with the context class.
Reasons to Avoid: When you want tight control over the interface to your data access and do not want developers issuing LINQ queries directly from the client code.
RIA Services
As the new kid on the block, RIA Services has a lot to offer. RIA Services is based on the idea of creating a data access API on the server and at the same time creating the client code in Silverlight (and other platforms in the future). Its focused on sharing code between the client and the server including validation logic. In addition, while it allows you to create a set interface, it also provides a context object which can monitor changes on the client and batch those changes back to the server. In some ways RIA Services is like a hybrid of Web Services and ADO.NET Data Services.
Because RIA Services is based on a server-side query defined in its interface, on the client we call the query by calling the call on the interface:
// Silverlight Code
// The context object that tracks changes
XBoxGamesContext ctx = new XBoxGamesContext();
// Our RIA Query, really a call to an interface
var qry = ctx.GetGamesByGenreQuery("Shooter");
// Bind the data
theList.ItemsSource = ctx.Load<Game>(qry).AllEntities;
While in ADO.NET Data Services you are issuing LINQ queries, RIA Services also allow you to add LINQ constraints to the query endpoints. For example instead of just creating a query by calling the interface, you can add LINQ expressions to the endpoint like so:
var riaQry = ctx.GetGamesQuery()
.Where(g => g.Price < 50m)
.OrderBy(g => g.Name);
LoadOperation<Game> op =
ctx.Load<Game>(riaQry);
Reasons to Use: RIA Services is a good choice if you expect to develop a straightforward application minimum number of tiers. It works best in Rapid Application development scenarios versus large architected applications. RIA Services does support a mix between the interface based from Web Servics and and LINQ based querying that is supported by ADO.NET Data Services.
Reasons to Avoid: RIA Services leverages a lot of magic code generation to make it work and that is harder to debug than it should be. Integration with large enterprises is possible, its not as easy it as it should be.
"So Which Would You Suggest?"
While I paint this picture of data access in Silverlight with a broad brush, I still get the question to suggest one over the other. The fact remains that there isn't a right/wrong answer here. A lot of it depends on the environment, project and skillset of the developers. So, no...I won't tell you what I suggest because I don't know the requirements and environment you work in. That's why they pay you the big bucks to be a developer, right?
