April 2007 - Posts

Finally Some Patent Progress

SCOTUS found KSR's arguments convincing, ruling that the Federal Circuit had failed to apply the obviousness test. "The results of ordinary innovation are not the subject of exclusive rights under the patent laws," Justice Anthony Kennedy wrote for the Court. "Were it otherwise, patents might stifle rather than promote the progress of useful arts."

[1] http://arstechnica.com/news.ars/post/20070430-supreme-court-ruling-makes-obvious-patents-harder-to-defend.html 

Posted by Jesse Ezell with no comments
Filed under:

Vista Died Today

All of the sudden Vista just broke. I can't connect to the internet. Initially, the DHCP client just refused to start. I resolved that problem by granting some permissions and setting a registry key, but I still can't use the internet.

Well, that's not exactly true... I can connect to any machine by IP only. All name lookup queries fail (even those in hosts file like localhost or other computers on the internal network won't resolve). DNS service is running, DHCP service is running, etc. When I try to resolve the problem, Vista tells me it found an error it can't resolve.

 Any networking gurus have any idea what's going on? This issue blows.

Posted by Jesse Ezell with 8 comment(s)
Filed under:

WPF/E = Silverlight

One of the reasons WPF/E is going to give Flash a real run for it's money is the video story. Unlike Flash, Silverlight (the new name) will support DRM, it supports the industry standard VC-1 codec used in HD-DVD and Blueray, and it can take advantage of the built-in media streaming capabilities of IIS. The video story is better just about any way you look at it with Silverlight as far as content providers are concerned. It's cheaper, it's faster, etc.

Add to that the fact that you get to use C# instead of actionscript as well as use XAML for your UI dev and Adobe should really be pissing their pants right now. Silverlight is so much better than Flash in just about every way. It's about time someone got it right.


Posted by Jesse Ezell with 8 comment(s)
Filed under: , ,

Who Needs ORM, I've got SQL 2005

One of the coolest features of SQL 2005 is the XML support. With the recent enhancements to the FOR XML option, you can really get a lot of mileage out of SQL. A common task in a lot of applications involves retrieving an item with many children. Due to the way a lot of systems are built, this usually ends up resulting in a lot of extra queries. For example, suppose I have a customer entity like so:

public class Customer
  public int CustomerID;
  public string Name;
  public string State;

  public Collection<HistoryItem> History;

When I want to get a list of customers in a certain state, along with their histories, I might do something like this:

SELECT * from Customer where State = 'CA'

Then for each customer returned:

SELECT * from CustomerHistory where Customer = @CustomerID

The, for each of the result sets that is returned, you need to write code to take the info out of the data reader or data table and place it in your objects. As more customers are returned, the number of addition queries I need to make starts skyrocketing. The problem only gets worse as the number of levels deep increases. With SQL 2005's great XML path support, there is a really sweet thing you can do to get rid of all those extra queries and all that extra code.

SELECT CustomerID as "@CustomerID", Name as "@Name", State as "@State",
  (SELECT CustomerHistoryID as "@CustomerHistoryID", SomeOtherField as "@SomeOtherField" from CustomerHistory Where CustomerHistory.CustomerID = Customer.CustomerID FOR XML Path('HistoryItem'), TYPE ) as "History"
 from Customer FOR XML Path('Customer'), Root ('Customers'), Type

This ends up returning something like so:

  <Customer CustomerID="123" Name="Jesse Ezell" State="CA">
       <HistoryItem CustomerHistoryID="456" SomeOtherField="Blah" />

Here's where the magic comes in. Now, you've squished all those queries into a single command, and, if you execute your command with ExecuteXmlReader, you can pass the XmlReader straight to an XML serializer and return your object graph without having to write all that tedious get / set nonsense.

Posted by Jesse Ezell with 26 comment(s)
Filed under: , , ,

Tray and Play: ClickOnce for PC Games

Console'ish load times for PC games on first run coming to a PC near you:

Posted by Jesse Ezell with no comments
Filed under:

JD Confused

JD is confused about the statement made in a MS presentation with don and chris:

Chris: We’ve made our intentions clear with WPF/E; we’re not pretending [like Adobe is with Flash] that it is some kind of open standard. People are saying that Flash is good and WPF/E is evil, but we actually think our story is better [for the community] here.

JD says:

But I'd still like to hear from Chris and Don what they actually said and meant with quotes like "adobe pretends flash is standard"...

Adobe pretending Flash is an open standard is really quite easy to understand. Adobe gives the impression that Flash is open and does things like put out specs for each revision of the file format... however, unlike truely open specs, you don't even get to see the spec until a year or two after they ship the product that the spec corresponds to. Even then, the format itself contains proprietary sections like On2's video format. You can't even deal with those parts of the format without paying ridiculous licensing fees (like, $60,000 to get started with the On2 SDK and then royalties on your product). So, is Flash really open? Far from it. Remove the proprietary garbage or offer free SDKs to deal with it, or the format will never truely be open. If all you do is create content with Flex or the Flash IDE, this isn't something you have to worry about, but if you work for a vendor that creates tools that use the Flash file format as I do, then it becomes a huge pain in the ass.


[1] http://weblogs.macromedia.com/jd/archives/2007/04/understanding_f.cfm 

Posted by Jesse Ezell with no comments
Filed under: , ,

Frans on ORM

Frans has finally pulled the discussion out of SOA land back to DB land. With his post "Why change-tracking has to be part of an entity object."

I'm looking at the original post that started this debate, and I must say that it sounds like everyone is blowing everything out of proportion. In fact, the reason Daniel Simmons posted the description of the entity framework was precisely because someone at MSFT was concerned about performance issues if the entity framework did have implicit change tracking forced upon every object:

"Recently a fellow Microsoftie posted a question on an internal discussion list asking about building an n-tiered, stateless application.  In particular, they were wondering about how the Entity Framework computes update statements.  They assumed that it keeps a copy of the original values and were concerned that such a mechanism would be incompatible with their target architecture."

Daniel goes on to explain that the default mechanism is that the entity framework has property change notifications that handle everything for you. However, there is another approach where you can explicitly manage the changed values yourself and pass directly to the framework which values have changed on an entity so that you can have complete control over the memory usage and concurrency issues. Now, I might have missed something, but I don't see what all the fuss is about. As far as I can tell, Daniel never said you have to roll your own change tracking solution, just that you have the option to do so.

Information Software and the Graphical Interface

Excellent paper that you should not pass up reading. If you read one thing this week, it should be this: "Information Software and the Graphical Interface"

"Today, software consumers demand technological features because software marketing presents features. Consumers ignore design because marketing ignores design. The cycle is vicious, but perhaps vulnerable too—some brilliant new software with engineering, design, and marketing all in sync may raise the bar for everyone."


What is software?

Graphic design




Changing the world

[1] http://worrydream.com/MagicInk/

Udi On SOA (Part 2)

Udi, continuing the SOA discussion, suggests a solution to the transaction issue:

The client would generate an instance of the appropriate message class as the user finishes each sub-task, saving them up. When the user would click “confirm”, the client would send all these message objects to the server in one go with this API,

void IBus.Send(params IMessage[] messages);

Like so:

myBus.Send(addOrderLineMsg, delOrderLineMsg);

The bus would take all these objects and wrap them in a single SOAP envelope, and send them to the server, probably on a transactional channel, but that’s a configuration issue. At the server side, the bus would activate the transaction (because of the transactional channel) and start dispatching each of the specific messages to its message handler, one at a time, in the same thread.

So as you can see, there is no “transactional conversation”, and therefore we’re not locking tables in between calls, because we’ve gotten rid of “in between”. It’s just like the generic update in terms of transaction time and network hops, just with specific, simple business logic. [1]

While this sounds good in theory, this approach itself doesn't really solve any special problems. In fact, without a proper service oriented architecture and messages that are constructed based on tasks instead of CRUD operations, you will end up in the same boat as if you hadn't implemented this approach. For example, take the situation where your app needs to preform a read and modify it's data based on the results of that read (say, for instance, discounts on a shopping cart). If you continued to code your methods the same old way, you might have a call to get the discounts, then apply those discounts and save the order. Of course, if you had architected your messages properly, you would have been sending a distinct PlaceOrder message and letting the server do all the discount calculations as those are part of one discreet task. So, while Udi's proposal is an interesting one and solves some transaction issues, it isn't a silver bullet that lets you make the same calls you've always been making and still be SOA. Contrary to popular belief, simply passing your data in a message doesn't make your application service oriented.

[1] http://udidahan.weblogs.us/2007/03/31/tasks-messages-transactions-%e2%80%93-the-holy-trinity/

More Posts