Rants
For the upcoming San Francisco stop of the Silverlight Tour starting May 28th, there are only five seats left. If you want to spend days with me discovering Silverlight 2, Beta 1, your time is running out.
You can see a full outline of the three day course here:
http://silverlight-tour.com/outline.aspx
I've known Julie Lerman (or is it Julia these days ;) for a long time now. She's an excellent resource for everything data related. In particular she's been keeping up with the Entity Framework and ADO.NET Data Services (formerly Astoria) updates in .NET 3.5 and VS SP1 Beta that was just released this week. If you are upgrading projects (like I am), she has two excellent blog posts about how to upgrade your projects:
New Entity Framework Changes
New ADO.NET Data Services (Astoria) Changes
I was teaching the Silverlight Tour this week and a student asked me some advice on how to implement uploading status messages using Silverlight. The question stuck in my brain last night and I came up with a quick example but quickly hit the 4MB upload limit of standard ASP.NET Requests. I knew I could create a web-service or web page that could handle chunking the larger pieces but I was concerned about the problem of incomplete transfers and leaving a mess on my web server's disks.
It seemed to me there had to already be a solution that I could adapt for Silverlight. After a quick Twitter plead, Jon Galloway had a great link for me that had already done it in Silverlight (though it might be Silverlight 1.1). Wilco Bauwer had a good example using Silverlight and a HttpHandler to do uploads to ASP.NET. Follow the link above for a solution. I suggest getting the code and reading it. What he is doing is pretty interesting and informative.
JavaFX was announced at JavaOne this week. What is it? Its a RIA platform for creating compelling in-browser applications. Certainly this looks like its a competitor for Flash and Silverlight. Interestingly, instead of being able to write Java (at least from the quick look I had), it looks like they created a new script language (called JavaFX Script) for it. Seems like a step backwards...but that's just me.
What it does have going for it that Silverlight doesn't is interoperability with NetBeans and tools for the Mac. I don't think NetBeans interoperabilty is important, but tools for the Mac is IMHO. What do you think?
With the asynchronicity question still dogging Silverlight 2, I thought I'd mention an oft forgotten little class in Silverlight (and in WPF) called the Dispatcher. Much of the confusion with asynchronous programming seems to stem from the fact that developers over complicate the problem. Think that they need to handle the cross thread calls themselves. They tend to create two way communications for this or overuse the BackgroundWorker's ReportProgress functionality.
The key to simplifying calling the UI thread is the Dispatcher class. This class supports a static (or shared) interface for executing code on the UI thread. For example, you can call Dispatcher.BeginInvoke to invoke some arbitrary code on the UI thread:
// With Simple Lambda
Dispatcher.BeginInvoke(() => DoSomething());
// Also With Lambda
Dispatcher.BeginInvoke(() =>
{
DoSomething();
}
);
// or with Anonymous Delegate
Dispatcher.BeginInvoke(delegate()
{
DoSomething();
} );
This is all is required to execute code on the UI thread. The Dispatcher guarantees that this code is executed on the main UI thread. This is simplified versus the same WPF code. The Windows Presentation Foundation uses a a prioritized message queue so that the Dispatcher really allows developers to not only make calls to the UI thread, but do so with some priority attached. (See my MSDN article on the Dispatcher in WPF for a more detailed explanation). In Silverlight 2, the model is simplified (for better or worse). When calling the UI thread, you simply need to specify the code to call on the UI thread...the priority is gone.
Unfortunately there is no way currently to reliably test for the UI thread (again unlike in WPF where the DispatcherObject was part of the object hierarchy so you could call CheckAccess to see if you were on the UI thread). Because of this Silverlight 2 has a fundamental problem. It is unclear when we are on the UI thread. This is especially problematic for the event driven architecture that Silverlight 2 employs. This is exemplified by the fact that during some events (WebClient calls are especially prone to this behavior) seem to fail silently when you try and update the UI. This is unlike the BackgroundWorker who throws an UnauthorizedAccessException (with the message of Invalid Cross Thread Access). So at times I find myself throwing in Dispatcher.BeginInvoke calls if the UI is failing to update in events (both control events and other events). This isn't a great solution but it does solve the issue much of the time.
I've attached a simple Silverlight 2 sample that shows this technique. Let me know if you have any questions about this sample.
I hate to just link other blogs, but this example from Brad Abrams is a biggie. In this entry he shows how to consume the ASP.NET Authentication, Profile and Role Providers from Silverlight 2 code. It is an impressive example and is well worth the time to dig into the code.
The Expression team has released a new Beta version of the Deep Zoom Composer with a plethora of changes. These include:
- Better Exporting
- Improved Design Experience
- Better Collection Exports
- Help Actually works.
If you're looking at Deep Zoom, this is a must have.
In an interesting development that I can only assume means that Silverlight is having an impact on Adobe, they've decided to open and standardize their FLV and SWF formats so that anyone can build them. Not only are they opening the formats but also removing licensing fees for mobile platforms. Nice!
This is good news for Flash/Flex/AiR developers out there. In my opinion this also bodes well for Silverlight as it means that Adobe is taking the Microsoft platform as a serious competitor.
What do you think?
Originally I had planned to start my screencast this week with a how-to on creating a sort of fake dialog window in Silverlight 2. Unfortunately I got the flu so I've decided to put off the screencast for another week but share with you how to create the fake dialog, but in full fidelity text and code examples. If you cross your eyes, it looks like its even in 3D.
The cornerstone of creating a fake dialog in Silverlight 2 is the Popup control. The Popup control is a special container that when shown always shows up over other controls without taking up any space. For example, here is a simple Silverlight 2 app with a Rectangle and a Button. In addition, we've added a Popup with a simple Grid inside it:
<UserControl x:Class="PopupFun.Page"
xmlns="http://schemas.microsoft.com/client/2007"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
<Grid x:Name="LayoutRoot" Background="White">
<StackPanel Width="200" Height="200" VerticalAlignment="Top">
<Rectangle Fill="Blue" Width="100" Height="100" />
<Button x:Name="showButton" Content="Click Me" />
</StackPanel>
<Popup x:Name="fakeDialog">
<Grid x:Name="theBack" Background="#80000000">
<Grid.RowDefinitions>
<RowDefinition />
<RowDefinition Height="Auto" />
<RowDefinition />
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition />
<ColumnDefinition Width="Auto" />
<ColumnDefinition />
</Grid.ColumnDefinitions>
<Border BorderBrush="Black"
BorderThickness="2"
Background="WhiteSmoke"
CornerRadius="15"
Grid.Column="1"
Grid.Row="1">
<StackPanel Margin="8" Width="200" >
<TextBlock TextWrapping="Wrap">
This is just some sample text. It doesn't
matter what it says as long as it is long
enough to actually wrap
</TextBlock>
<Button x:Name="closeButton"
Content="Close"
VerticalAlignment="Bottom" />
</StackPanel>
</Border>
</Grid>
</Popup>
</Grid>
</UserControl>
When we show the page initially, the Popup is hidden (because it's IsOpen property is false by default):
But when we change the IsOpen property (in the Click eevent of the Button),. the Popup is shown on top of the existing content:
What is particularly interesting about the Popup control is that it takes no space in whatever container it resides in. The Popup control is meant to shown over the existing content. The problem is that you will want to take over the entire screen with the fake dialog. In this case the size of the Popup won't cover the entire screen by default. To fix this we can register for the Application's Resize event to change the size of the Grid (named "theBack") inside our Popup:
App.Current.Host.Content.Resized += (s, e) =>
{
theBack.Width = App.Current.Host.Content.ActualWidth;
theBack.Height = App.Current.Host.Content.ActualHeight;
};
This will resize the Grid whether the Popup is shown or now. Now that we have the resizing code in place, the dialog takes over for the entire screen:
There are a number of things you can do with a Popup control, but this should give you a quick primer on how the Popup control really works. The source project can be downloaded at the link above.
I've spent a lot of time the last few weeks looking at some of the new buzz words in software development. Domain specific languages, dynamic languages, TDD, DDD, *DD, etc.. Most of these ideas have definite benefits to the work of software development but I think they miss the mark on what is really hard in software.
In most projects I've worked on the past twenty some-odd years, the hard part is not how to architect a project, not how to tune a database and not how to eke out every CPU cycle of a function call. In fact the hardest part has always been in understanding how a business does business. There are many names for this but I like to think of this as domain specific knowledge. It's the time in the meeting room with the business veterans (stakeholders of one sort or another) that understand how it really works. Whether that is how freight is shipped across country, how users register with forums or how those scanners at the grocery stores actually work; in all cases these stake holders already know how they do or want to do their job. It is our work as developers into transitioning that into actual software.
Eric Evans talks about this in his Domain Driven Design book, but I think some readers of his book seem trapped into thinking that the magic of the domain is the top-down design of a system. In my opinion they are missing the point. Turning domain knowledge into a system is hard work, no matter what design methodology you use.
It's a people problem. We engineers talk in terms of code, architecture and data. We have our private language that helps us communicate. If you don't think that's true, ask your spouse/partner what happens when they hear you talk about work with your friends. The thing is that in most industries this is true. When you talk to stake holders, they have their own language too. Our job is to pull that information from them and translate it into software designs. Often a small misunderstanding can be the cause for large changes in a system. Getting this knowledge transfer right is crucial. For the most part we do an admirable job of it, but I think it is critical to understand how essential this is. Constant communication with the eventual users of a system is a key to the long-term success of any project.
So, if you've stayed with me this far we're probably in agreement about the importance of domain knowledge. Here's where I get incensed. So much of development these days is being done by outside developers. The strategy of business to keep developers around has vanished. This is evidenced by off-shoring, outsourcing and contractor-based development. Companies are attempting to cut costs by using cheaper developers as well as development teams they can cut loose once a project is complete.
The problem with this strategy is that all the domain knowledge is leaving the enterprise. Companies spend a lot of money for a project and some percentage of that money is in teaching the development team about the problem domain and the way that the company does business. By having short-term development strategies all this knowledge isn't being recouped by the companies. I don't think they understand yet what a bad deal this is for them. But it's not just bad for companies, it is also bad for developers.
In some sense we developers are part of the problem. Quitting your $75K/yr job to be hired back at $75/hr seems like a good deal, but in fact it is not a good deal for either party. Your loyalty is to the paycheck and when you leave, the domain knowledge goes with you. This extra knowledge can help if you stay in the same industry but that's pretty rare. Usually you go to a new type of company and spend time 'ramping-up' on how they do their business. This seems bad for developers because most of the ones I know have passion for technology. They want to be part of a winning team. By being a well-paid mercenary it becomes easy to not care about what you are doing. At the end of the contract you just move on, forcing you to divest in a personal stake. I miss that part of this business. I have had more enjoyment about projects that didn't work than all the mercenary positions I've ever held (yes, I am looking at you Gen<X>).
The dirty little secret in my house is that I'd give up my business and go work for a company if I could believe in them and believe that I was part of something special. In some ways I think most developers are like that. But in this atmosphere of short sightedness, it just doesn't exist.
So do I have a call for action? No. I think that domain knowledge is an important idea that both developers and companies need to address, but I don't have a nice and tidy solution. This is a shift that I think has to happen in software development. Both sides of the table need to look long at the last five to ten years and determine if what we're doing now is better than before. Does it only feel better because each line of code is cheaper to produce (mostly a product of better platforms, not better coders). I hope this can change.
UPDATE: Here's an interesting link that has a different opinion of this subject:
http://thedailywtf.com/Articles/Up-or-Out-Solving-the-IT-Turnover-Crisis.aspx
