Playing with Blocks: Episode 2

When you start to design an application for producing drawings in Silverlight, there are some things you don’t have to worry too much about. You don’t have to come up with definitions for shapes, or figure out a fast way to render them. You don’t have to define a color space, and gradients, and geometries for clipping and filling. You don’t even have to define what a surface is and how shapes interact with it. Windows Presentation Foundation takes care of all of that stuff, and quite nicely too.

What you do have to think about is how to organize and present that capability to the user, and how to connect the user’s intentions to the underlying systems. You need to think about how to do all that in a robust and extensible manner, in an environment that is quite a bit more constrained than the context in which a normal WPF app runs. In other words, you need everything but all the stuff I mentioned above, and that still leaves quite a lot to chew on.

Continue reading

Playing with Blocks: Episode 1

I’ve decided to write a couple of posts about the design and execution of a Silverlight application I’m working on. If you’re not familiar with Silverlight, here it is in one sentence: Silverlight is a downloadable subset of the WPF containing just enough of the framework to execute specialized WPF applications in a browser window. It’s a competitor to Flash, without doubt, but since I never really went in for doing games and demos in Flash I don’t really think about the positioning. Silverlight lets you animate, and play sounds, and do all that cool stuff that I think of when I think of Flash. But Silverlight also has everything you need to do lightweight, browser-hosted, net-delivered applications. I don’t know if people do many apps in Flash, but that’s the part of Silverlight that gets me excited. If you think about all the datacenter cycles that get spent pushing ASP roundtrips to update the front-end, Silverlight starts to look pretty damn appealing.

Continue reading

A Silverlight Gradient Designer

One of the projects I’m working on is a drawing program for Silverlight. It needed a gradient editor so that users could define brushes to fill shapes, etc. Last week I wrote about the color picker I developed. This week I’ve added a gradient editor to the ColorTools package. The gradient editor combines a color picker and a visual gradient designer. In order to get all of this working I was forced to create some geometry editing tools that will come in very handy in the drawing application. As soon as I had the gradient editor control finished I used it to created a gradient designer application for Silverlight developers. Gradient Maker is a visual tool for defining gradients that produces cut-and-paste code for brush definitions in XAML, C#, and VB. Give it a try, and let me know what you think. I haven’t yet released a new version of ColorTools including the gradient editor control, because the code needs a little more work and I would like to test it a bit. But I hope to get it out early next week.

Color Tools for Silverlight 2

A Silverlight project I am working on required color picker controls – those boxes you find in programs like Paint, Photoshop, and others that allow you to choose a specific RGB color. After doing a little research I wrote two Silverlight user controls, a system color picker that enumerates the available colors from the System.Windows.Media.Colors class properties, and an ‘HSV’ color picker that sports the traditional hue slider, saturation/value box, color swatch, and hex display. You can try out these controls on my ColorTools demo page.

I want to credit the excellent examples by Page Brooks in his article on building a Silverlight color picker. Specifically his rather cool tricks for creating the color gradients using XAML, and his implementation of a ported javascript HSV-to-RGB conversion, which I have more or less cribbed in wholesale fashion. To his basic concept I have added a routine for converting from RGB-to-HSV, in order to allow setting the selected color from code. I have also fleshed out the dependency properties for both controls in order to make them useful. Feel free to download and use these controls in your own applications. Links to source and binaries appear below. There is no documentation yet, mostly because I have just installed Vista and haven’t put Sandcastle back on yet, but the controls are very easy to use, and the demo page shows the basic XAML and C# needed.

ColorTools for Silverlight Runtime
ColorTools for Silverlight Source

The GSearch Lib – Google Searches from .NET and Silverlight

In the process of working on GMemory, a Silverlight 2 game I wrote as an exercise a couple of weeks back, I became familiar with Google’s RESTful webservice API. Using this API applications can execute searches and receive results back. The API is not a complete drop-in replacement for the full-blown Google search engine – it can produce at most 64 results (8 items per page over 8 pages), for example – but it is an interesting and useful way to incorporate search results into your applications. Results come back in the form of some nested JSON types, which are easily deserialized into .NET classes once you understand the structure and get the type definitions correct. I had to do that for image searches to make GMemory work, so once that was done I decided to go ahead and implement the rest of the search types as well.

The result is GSearch, a library of classes for searching Google from .NET 3.5 and Silverlight 2 managed code. The library encompases all the supported search types on the current version of the Google API, meaning blogs, books, images, locations, news, patents, video, and web pages. The classes are very easy to use, and you’ll find some examples in the readme files accompanying the runtime packages. The .NET distribution also includes GSearchPad, a WPF example program that will allow you to execute any of the search types with custom arguments and display the results.

GSearch is copyrighted software released under a BSD Permissive license. Feel free to play around with it and use it in your own commercial or noncommercial apps. This is the first release, and there are sure to be some warts left in it. If you find one, or have a question, please feel free to drop a comment here or shoot me an email.

Programming and Production

I went down a six hour sinkhole last night on a project I’ve been working on for the last week or so, and that got me thinking about some realities of software development that I believe we have lost sight of. One of them is six hour sinkholes and why they happen. The problem is that we have come to believe that programming is production, when it is not. In production a six-hour failure to be productive is a horrible anomaly. It shouldn’t happen, because production is predictable and well-understood, and proceeds at a linear pace. When that pace is interrupted management is called on the carpet to explain why.

And it is a fair question. Production is quantitative. By the time you start production all the messy qualitative work has been done. Production should not, therefore, be hampered by the unforseen. Of course it often is, but then that unforseen is accounted for, the mechanisms and processes adjusted, and before too long you have a soda canning line running at 5000 cans an hour for years without stopping for anything other than maintenance. The equivalent in our business would be programmers that produce 100 lines of code an hour, every hour, except when they are out to lunch. The idea is as absurd as it sounds.

Why? Because programming is not production. It is also not a commodity, but that’s a lesson for a different time. I mention it only because once you start thinking about programming as production it’s pretty easy to think of it as a commodity. Both views are wrong. In fact, it’s pretty obvious that, as Jack Reeves has said, programming is design. It is a qualitative process that proceeds uncertainly until some level of “good enough” has been reached and the final product can be produced. And where is the production happening? Where do we have a linear and predictable process of converting raw input and specifications into a final product? In the build, of course, and that’s the whole damn problem.

In software our product is “constructed” of symbols, and the definition of those symbols and how they can be used is fully specified before one iota of our product comes into being. Therefore once we design the set of symbols we need, the production process is fast and dirt cheap. As Reeves points out, it’s essentially free. That’s the problem: programming is all design and almost no production. If you’re a manager you can say concretely how many soda cans will be filled in 12 hours, but if you venture the same prediction about a software team’s delivery of features in the same period you’ll be stepping out on a limb. They may run into a six hour sinkhole. Because they are designing, not producing.

Which is not to say that design is an unmanageable activity. Lots of companies manage it. They design to specific goals, over specific timeframes, with hard milestones. But in all of these kinds of environments there is a lot of flexibility with regard to the micro view of progress, rather than the macro. A “design team” sounds like something different than a “programming team” doesn’t it? It sounds like the kind of group you would find working to flexible schedules in a cool, intellectually stimulating environment where good ideas are prized above all else. A “programming team” brings to mind more the image of a hundred young Japanese women hunched over tables in an electronics factory soldering assemblies.

If business understood programming as design, I suspect there would be fewer projects, but better ones, and less inclination to shop coding out to the lowest global bidder. After all, it’s usually the productive piece of the pipeline that gets outsourced, not the creative piece.