Invert Your Mind

If you don’t know Don Box or have ever been in a room with him I can only think of a few ways to describe:

- Don Box is the eloquent mad genius of Microsoft
- Don Box has a permenantly attached 150 gallon kool-aid container attached to his back, which is dispense via two WebService enabled super soakers.

Don did his same flashy intro as last year, except that he used scheme this year instead of notepad. He asks the audience for a list of questions and topics. Here’s his list of topics he was asked to cover:

1. EMCA-izing indigo
2. What is this shit?
3. BRE vs. DSLs
4. WTF - WTF?
5. Future of the ESB
6. What could suck more than C++
7. Java and Indigo
8. Code bloat and performance
9. Microsoft vs. SOAP
10. Interop
11. Canada vs. Microsoft
12. Indigo and reach (small devices etc.)
13. How would I simplify indigo and its components
14. Why did we build Indigo?
15. Disclose trade secrets (tell us what is next)
16. WS-* SOAP REST POX (plain old XML) et al
17. Why we use less CLR in Longhorn than we thought we would (my versioning question about data, characteristics, behavior, etc.)
18. Which sucks more CORBA or WS-*
19. Crackpot guidance from a random guy you don’t know nor can hold accountable (what should we use instead of CORBA or WS-*)

I could olnly write down a few things he said, but the majority of his message was WS*.

1. No plan to do this for WinFX.
2. Don explained all the acronyms of WinFX and all the other stuff they are working on, but I won’t cover those, just google for them.
3. Don had some very interesting stuff to say about DSLs and the death of the Object-Oriented coding style as well as for-loops. His contention is that when you get 7000 folks writing classes and for-loops you always get a huge complex pile of code. His contention is that DSLs are ideal for most business processes, workflow and the like. Of course I’m a versioning nut and really wanted to know what his thoughts were on versioning of DSLs and legacy DSL code. My contention is that DSLs in the hands of mortals are more dangerous than classes and for-loops because a bad version of a DSL can break all legacy code unless the DSL is intrinsicly versioned, which again is difficult for mere mortals. I don’t claim to know the solution to the versioning problem, but I know that DSLs must be written by those who are capable, like the language engineers at Microsoft, IBM and Sun and not allowed to flow freely from any old software shop. BRE is such a DSL it seems, but I don’t know if Don’s team has tackled the versioning problem with BRE.
4. Missed this one
5. Don’s comments on ESB started simple with a notion of normalizing the messaging stack and how they surface to the developer (WCF). Step one is a common abstraction for a message inside a Windows machine. This abstraction is called Message and is a type that can be handled by the developer. To me this is extremely similar to SDO. Second step is a common way to handle pub/sub and queuing, events, etc. I followed up with a question on SDO and SCA and how it compares with this Microsoft Message abstraction and Indigo. Don’s response was, “our messaging model is XML” and inside the machine SDO or Message are roughly equivalent because they are not wire models. I definitely agree on this but also using a non-standard API such as their Message API does make code less portable, but of course C# and VB currently aren’t totally portable. It would only boil down to Java and Python inside and outside the CLR.
6. Missed this one
7, 10, 14. Don’s always direct when you start talking about Java. He always says that Java is probably the largest reason they wrote Indigo. There is a ton of Java out there and working nicely with it is paramount. I doubt anyone would disagree with this.
8-9. Missed these
10. Same as #7
11-13. Missed these
15. One could only guess what’s inside Don’s head, I’d rather stay out of there and wait until he’s distilled things into something understandable.
16. Don’s comments about WS* and all the other XML stuff out there was interesting and he’s pretty much correct. Since XML is so open and accessibl and readable, it caused an enormous number of developers to reject it because they could see the SOAP overhead (minimal) and anything else in the document that they wouldn’t have put there if they were writing everything by hand. And then most of them went off and did just that via REST, XML-RPC, POX, etc. He also talked briefly about good ol’ binary protocols which were impossible for most developers to parse, making them excellent because then only the really anal retentive folks would turn up their noses because they would have spent the time to go byte by byte through a message to see what’s inside (or read the spec line by line). They would then reject it because they could think of a simpler or more concise and complex format if they were coding everything by hand and then go forth and do so. But the number of these people is so small that the technology would stick much easier. With this and the fact that IAP uses FastInfoset, I had to ask about FI and Fast WebServices. Don’s excellent at being Microsoft and waiting on this one like the rest of the world. He said that he wanted to see what customers wanted and what the industry asked for before going full force on FI. I personally think this is bogus, mostly because we all know that binary is better and Don know this as well. I don’t care if it’s FI or MSWSBF (Microsoft WebService Binary Format - I made this up since Microsoft loves acronyms), I just want a something I can build on and not have die a few months later.
17. This is definitely a Pontarelli question about versioning. Don mentioned that CLR doesn’t version easily and that in order to have some type of versioning, regardless of how poor it might be - which by the way is no more poor than Sun’s or anyone elses solution, they had to use less of the CLR than they had originally planned. Don’s final comments after I poked and prodded again pretty much concluded that Microsoft is still working on the versioning problem like everyone else and haven’t figured it out yet. I asked a lot of the same versioning questions last year and last year I think they were a bit scared of their lack of progress and said very little about what they had accomplished. A few engineers even made it sound like something really cool was on the horizon. I’m glad to hear from Don this year that they were no further ahead instead of some cheesy non-response that gets peoples hopes up. Honesty in this arena is best because eventually you have to show something and if you got nothing you look worse than if you’d just said you got nothing but are really investing in trying to get something.
18. CORBA but not by much
19. No clue I checked out after versioning.

I’m a geek but I’m wondering how quickly google will pick up the tags for MTS2006 in its searches. I’m not sure how well google will index into my blog, but we’ll see. If you see this post on google, add a comment and we’ll see how fast google is.

Addition April 14th, 2006:
Well, turns out Goole is really freakin’ fast. Only 2 days from this post being added and tagged until it shows up as the 4-6 result in a Goole search for “mts06″. Pretty good. Here’s the link:

http://www.google.com/search?hs=odt&hl=en&lr=&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=mts06&btnG=Search

I’m blogging today from the MTS2006 (Microsoft Technology Summit 2006). This year we have internet in the room, so hopefully I’ll be able to send out updates quickly rather than spatting out information in the evenings after a couple of drinks.

Anyways, Jim Hugunin is back this year talking about IronPython 1.0, which is close to release. He made a quick comment and got a cease and desist order from his boss in the corner. Talking about GTK on Windows, Linux and OSX and how IronPython hooks into it he said that GTK and IronPython work well on Linux and OSX currently and decent on Windows and then added the additional statement of “for now”. An interesting statement. The CLR/IL is an open standard and mono is out there. IronPython is also targeting .Net and Mono. In fact, Jim mentioned that the Mono folks are leveraging IronPython to work on their 2.0 release and stay up-to-date within 2-3 days of each IronPython release. Jim also mentioned that they are not working with Mono, but do release their tests, which are helping the Mono project considerably. So, what’s the secret? Are they working on solid ports for Mono and GTK on Linux and OSX or helping develop Mono 2.0 or planning on providing a .Net complie on other systems with GTK? No clue, but that slip more than likely means something’s coming and from what I could get from Jim, it could be a free or open source release of .Net for Linux and OSX sometime in the future, which would probably use GTK for the graphics engine.

Just ran into something and wanted to jot it down to remember it. ActiveRecord objects have two different methods of accessing their associated data: @foo and foo. The former references the container for the data and the latter references the accessor method. There is a subtle but monsterous difference between these two.

Unlike Hibernate which uses custom containers for its associations, ActiveRecord uses plain collections to store associated data (I’m partially guess here from the behavior I’ve seen. I haven’t verified this in the ActiveRecord code). This means that if you want to use associations you MUST reference them using the accessor, even if you are inside the ActiveRecord class. Here’s an example:

class User < ActiveRecord::Base
  has_many :roles

  def is_admin
    @roles.each do |r|
      # This will never be executed
    end

    roles.each do |r|
      # This will be executed
    end
    ...
  end
end

The accessor is where the code that loads the associations lives, not in the collection. This could probably be fixed in upcoming releases and might be (I haven’t played with 1.1 yet).

I’ve been working in WebWork2 lately trying to get a Java web application up and running. A few of the major downsides to WebWork2, making it nearly unusable, are that the documentation is really lacking in almost all areas, there are few examples and the framework does not behave in a consistent manner. My current pain point that illustrates this inconsistent behavior is this:

I wanted to use the WebWork2 auto validation to check my form fields. We’ll being a minimalist, I created my Action class and made it look like this:

public class MyAction implements Action {
 ...
}

I implemented Action because I didn’t really want to extend or implement anything and I figured implementing an interface was the lesser of the two evils. Well, the only problem is that WebWork as a framework doesn’t actually handle redirects or forwards when validation fails. You might think it does, but it doesn’t. Instead it relies on the Action classes to provide this functionality. Since my execute methods was useless since I was using named methods (it actually threw an exception) I kept being forwarded back to the input form after the action method had been called. This isn’t suppose to happen. A proper framework will never call an action method after validation has failed unless it explicit states it will always do so or allows some obvious configuration for controlling this.

As it turns out, if you extend the ActionSupport class instead of implementing the interface directly, things magically start to work. This looks like this:

public class MyAction extends ActionSupport {
 ...
}

If there are validation errors you are magically forwarded to the result named input. Very unexpected behavior from essentially the same class except for the implements/extends clause. So, what this means is that the WebWork2 helper class ActionSupport is actually doing framework work, which forces this class to be extended if you are doing validation. Not ideal in my opinion. This work should always be handled by the framework internally and exposed to the developer via concise configuration if at all.