Month / September 2008

by Aaron

Oslo — what?

According to Don Box, the best explanation of Oslo is here at eWeek.

I read it.

Oslo is aimed at empowering nondevelopers to build distributed applications. The initial version of Oslo won’t let a complete novice build applications, but it will ease development. It will also, hopes Microsoft, broaden the developer base.

It goes on to detail all the elements…

Box said that Oslo is designed to capture people’s ideas, requirements and hopes for software, “so that we can then do all kinds of processing on top of it. But we’re really trying to turn the software development problem into a data design—that’s the simplest way to talk about what we’re doing. And so part of that premise is making it easy for people to interact with that data. And one way to interact with data is through visualizations and diagrammatic things, box and line designers, all kinds of charts.”

Oh, I get it. It’s diagrams and stuff. :) And a software package that captures hope? That’s power.

I’ll be at PDC and probably see more about it, but I remain skeptical.

How will they empower non-developers to build a distributed application? How will it efficiently access data and not thrash database servers with generated queries, etc.? Who is this marketed to? The article refers to business analysts? What kind of market will that be? Is it worth spending all this Microsoft brainpower on this problem? How does it interact with other languages (like .NET?).

Why a new language? Because to pull off the Oslo goal, “we needed a revolution in developer productivity,” said Steven Lucco, a distinguished engineer in Microsoft’s Developer Division who helped develop the vision for CSD and the Oslo effort.

It goes on …

An Oslo user need not learn the D language to use Oslo, however. “The language is a technical detail for a certain audience,” Lovering said.

So, they needed a new language that the user doesn’t need.

If Microsoft had taken a poll — is this what their bread and butter audience would have voted for? Would you? I’ll reserve final judgement until I see it.

by Aaron

Coding Challenge #22

Coding Challenge Series / Technical Interview Series

Now that you’ve become an expert in efficiently copying bytes (you did solve the last challenge, didn’t you?), I have an even more challenging question….

You have a large block of byte oriented data representing a 256-color LCD panel. Each byte represents the color of the pixel.

You’ll need to write a Copy Image function for me …

Your function is provided: width and height of the LCD panel, a reference (or pointer) to the LCD pixel storage, an array with the new colors to set, and a rectangle with the bounds for the new pixels.

The LCD display’s size may not be evenly divisible by 8, yet a pixel row must end on a boundary that is evenly divisible by 8. The image bytes as being provided do not have this behavior.

Copy the new pixels/colors into the LCD storage.

by Aaron

Microsoft AutoCollage 2008

Microsoft AutoCollage web site

I was tempted to try this new application out for a few reasons:

  1. It was new
  2. It was from Microsoft Research and claims some interesting features (like object and face recognition)
  3. It seems to be built using WPF (the screens all look WPF-ized)

Then, before I downloaded it and installed it, I decided I wouldn’t bother for a few reasons:

  1. It’s $20US (a research project?! — just drop the “Research” part!!!)
  2. I didn’t care for any of the sample collages that they have on the web site – the results look amazingly average.
  3. I didn’t know what I’d do with an image that was produced. I suppose I could have emailed it, but I’d rather send full photos than a blurry mess of photos.

They have a flickr group (but ironically they only have 1 member and no collages published as of Sept 4, 2008?! Not even a sample?! That’s awful marketing. Maybe that’s why they’re in research. :)

In any case, if you’re interested, there’s an image gallery here (that for some reason includes head shots of the people who “incubated” the project, the logo, and a photo of the building. Oh, and a few samples and shots of the product.

by Aaron

Where do you "event"?

From JohnPapa.net, “Siliverlight 2-Tip – Declaring Events.”

He thinks that the place to wire up an event is always in code rather than in markup (like XAML).

“What’s my opinion? I firmly believe the handlers belong in the code and not in the XAML.”

I’d suggest that’s not always right either (and maybe not the right question to ask). This technique doesn’t allow the designer to have freedom to decide how to build the interface freely. If you wire up to a “button” click, then the designer has to implement a certain UI feature as a button. Maybe that’s not what they wanted. The UI/code are wound together extremely tightly when using this pattern.

A command/message driven architecture that splits the actual implementation as much as possible is the best pattern for growth and true separation of roles. That being said, it’s not always practical to build a system like that.

I like the CONCEPT of WPF’s RoutedCommand system which is a way in WPF to handle this pattern, but I don’t care for the way that things are enabled and disabled via the CanExecute event handlers. The event handlers can be called hundreds of times a minute depending on your user interface.

The bad news is that Silverlight doesn’t lend itself easily to a message/command driven architecture (as the RoutedCommand system isn’t available in Silverlight 2.0). So what’s a developer to do? :)

I like the ‘toolability’ of doing inline (in XAML) wire-up of events. If the developer just provides a common set of end-points (events) to the UI designer, then they may have an opportunity to more freely control and adjust the user interface as needed without requiring code changes.

So in John’s example code, instead of

btnAddToCard.Click += new RoutedEventHandler(btnAddToCard_Click);

It might be better to provide a method called:

AddToCard(object sender, RoutedEventArgs e) {

}

That way, the designer can wire-up any way they want.

Or, I suppose one could build a rudimentary message/command system by using attached properties and a common event handler which handles all command driven user interface elements. (And now that I think about that more — I think that could end up being quite slick if done carefully).