Feb 182007
 

I just went over to MSDN to look for my product keys from my subscription which I received at last years Microsoft Technology Summit. However, looks like someone really messed up a deployment of that application and I got one of those nasty ASP.Net errors, which anyone who has ever developed in .Net knows very well.

So, I figured I’d call MSDN and let them know. Well, the MSDN office is closed on the weekends and I tried calling Microsoft support direct to let them know. However, the call center employee I talked to had no clue how to let the folks who manage the website know. When I heard that I was floored. A company as large as Microsoft should at least have so kinda of system that employees can use to raise alarms about website failures so that they get handled. Hell, Orbitz call centers could always contact Orbitz headquarters to let them know the site was down. But most of the time we already knew that since the website is monitored 24/7. Well, guess I just have to wait for them to restore the website but here’s the screen shot I grabbed just for fun.

Enjoy!

Screenshot-Runtime Error - Firefox.png

Apr 192006
 

I totally spaced putting this picture up. Steve Loethen from MS sent this to me from last years MTS. That’s me and Brett up front (I’m the idiot in the picture as always haha) and a few other developers. You can also spy a few other notorious Java folks in the background. First person to identify anyone else in the booth directly behind me wins the “Most hardcore Java geek award”. Email me or leave a comment with your guesses.

Apr 122006
 

LINQ is a query language built into C#. For C# 3.0 Microsoft has added a large number of keywords into the language that allow a developer to query into objects in a SQL fashion. This can also be used to select from a database when the Object being queried is a DB mapping object. Like Hibernate, they have an ORM mapping from a database to a class and a session (called DataContext) that is used as the glue. Nicely, for the RAD folks this can all be auto-generated or done by hand for those who don’t like generation. Very rails like in concept when considering the generation, the database is defined and then the code created by a tool. Rails does this at runtime, but the concept of database creation first and by hand is the same.

Unlike Java and rails, you don’t need to use the full blow Objects for result from LINQ. Instead you can create structs on the fly that contain only the fields you have selected. You can unit test this by mocking out the struct by hand. Although interesting, I’d think that this would only be useful in select cases considering that design by contract makes most sense on the domain of the application rather than an anonymous class created by the language at runtime. For distinct DB code snippets where performance is necessary and the data is confined, these structs will be ideal.

In terms of performance, Microsoft stated that LINQ does not cache at all and leaves this to be done outside of LINQ. Cache, distribution and the like are difficult and it does seem like they have punted on this instead of addressing it. Considering that hibernate and most other tools provide this and will handle distribution if the correct caching provider is supplied as well as handle no caching with simple configuration makes me think that LINQ just didn’t have time or didn’t want to try.

LINQ handles transactions as expected. Programmatic transaction can be done via the DataContext. If you have a distributed transaction then LINQ will participate in that transaction. If the backend doesn’t support transactions then it is not supported by LINQ because internally it goes directly to the data source during any execution statement.

My main concern with LINQ is that they have add to the keyword namespace of the language and reduce the user namespace, which will no doubt make old code break everywhere or reduce the chance for upgrades. This doesn’t bother me too much I guess when considering that this release is a major release (3.0) and Java suffers from the inability to add keywords that would make life easier for developers simply because they refuse to break old code. Still, the reasoning behing using keywords is not clear and Microsoft did not provide a distinct reason they used keywords rather than a block. The also had no idea off hand how many keywords LINQ uses up. They tried to use the blocks are ugly argument, which is not true considering that ruby does this nicely with 3 distinct characters and 4 total characters.

Apr 122006
 

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.