A Tour of LINQ to XML
I tried to come up with a snappy title for this one, but it's not possible. It was Mike Taulty again, this time with, yes, a tour of LINQ to XML. There's really no other way I can slice it.
Visiting this session turned out to be a mistake, as I had trouble keeping my eyes open while Mike patiently (and professionally, I must add) explained concepts I already knew. The problem, if you can call it that, is that LINQ to XML is very easy to understand if you already know LINQ (which would be a good start). Now, just before the DevDays, I read an excellent document that explains it all, so Mike's presentation was completely wasted on me. Again, this was none of Mike's fault.
Fortunately, I had an ex-colleague sitting beside me who was new to it, so I could share some of his enthusiasm. And, to be sure, using XElement to create XML is just about the best thing since sliced bread. At one point, the audience actually applauded when Mike composed and ran a sample that outputted an XML document containing a list of processes in the system together with the number of threads in each — I think it was the shock of seeing the features of the Process class combined with LINQ to XML to achieve something so powerful in mere minutes (or seconds, really, since Mark is an impressively fast typer).
A funny moment in the presentation came when Mike demonstrated the extensions in VB.NET 9 for LINQ to XML, which are extremely cool. When he was done and closed the Visual Studio hosting the VB.NET code, one guy actually applauded him for getting rid of the yucky VB.NET — the audience was apparently made up of the usual contingent of C# weenies. "Stop that," Mike berated him while laughing. He had a little trouble regaining his composure after that, which is always fun to see.
Is LINQ Your DAL? I Don't Know Either
Next up was, I shall not mince words, the most disapppointing presentation I attended in the two days I was there: "Is LINQ Your Data Access Layer?" by Anko Duizer. By what I'm sure is an unfortunate coincidence it was also the only session in Dutch.
Now when I say it was disappointing, I should qualify this by saying that the quality of the presentations at DevDays was generally very high. The presentation failed therefore not by being bad but by simply not being very good. The room was absolutely packed, showing that many people had an interest in the subject (which is not surprising, since "how should we use LINQ, if at all" is probably a question on many people's minds). I was one of them, but I didn't leave satisfied.
Anko Duizer meandered on the role of LINQ to SQL in your DAL (whether it could or should be used as a DAL on its own, and the consequences of merely using it behind a wrapper) but his presentation ultimately failed by neither making clear what the goal was nor reaching any sort of conclusion other than "it depends on all sorts of factors". That's OK if you raise interesting questions and challenge the audience to come to a conclusion themselves, but unfortunately there was none of that either. The whole thing felt as a personal journal of one man's quest to give a new concept a home, and it was not insightful. He was the only speaker I actually caught on having a few factual errors in his presentation (such as stating that LINQ's mapping is one-to-one to the point of requiring you to change your data model if you rename a field, which anyone who's played around with it should know to be untrue). This was nothing major, but it reinforced the impression that the whole thing was rather unstructured.
His speaking style deserves separate mention, because it contributed a lot to the annoyance. He often repeated what he just said in a slightly different way. In other words, he just reiterated his previous statement with small modifications. In bad cases he actually managed to subtly restate his earlier utterances twice. I trust I'm getting the point across — developers know all about how you shouldn't repeat yourself, and having had little sleep the previous night, I was in real danger of dozing off at a few points.
The speaker went into overtime as the information system boomed the message that lunch was being served. Eventually, when the audience got to ask its first question (which was virtually inaudible because there was no walkabout mic), a group of exceptionally rude people pretended the presentation was over, applauded halfheartedly and hurried for the lunchroom, even as the question was being answered. This is something I wouldn't wish on any speaker and it was inexcusable, even if I could sympathize with the frustration (I was hungry and bored too). On behalf of the rest of the audience, my apologies.
I Am IronPython
Next up on my schedule, I was supposed to visit "Understanding ADO.NET Data Services", another Mike Taulty feature, but this sounded boring (sorry, Mike, nothing personal — AJAX and REST just aren't my thing). I knew my colleague was probably having fun visiting "Development of Social Networks", and this combined with the sour taste the previous session had left encouraged me to go visit something I might actually enjoy: "IronPython and Dynamic Languages", by Harry Pierson.
Well, this proved to be just what the doctor ordered for getting my spirits up. After getting used to Harry's impressive volume, the audience was treated to a very enthusiastic and personal presentation about what the incredibly small team working on dynamic languages at Microsoft is doing with Python, and a few glimpses at what they're doing with dynamic languages in general.
Though I'm not a Python programmer (what do you call those, Pythonistas? Pythonians? Monties?) I did know some Python before coming here, and the presentation was not about what I actually expected to hear: how IronPython is actually implemented in the CLR. Harry made it clear that he was not on the up-and-up on the technical side of matters. What I did get to hear more than made up for it, though.
IronPython is an almost full-fledged implementation of Python in the CLR, which means it not only benefits from the CLR's JIT-compiled infrastructure, but also that it has access to all of the .NET Framework. This is interesting because, as Harry explained in an insightful summary of the age-old dispute between proponents of static and dynamic typing, dynamic languages are better at some things (like mock testing) than static languages. Effectively, you can use IronPython to do things in .NET you couldn't realistically do (or would even want to do) with C# or VB.NET.
I care about this because I've always wanted a way of playing around with .NET classes that was easier than going through the motions of a C# program and/or firing up the debugger. Ideally, I'd like a .NET scripting language — and I don't mean a standalone application like PowerShell, which requires you to adopt a whole new mindset just to do administrative tasks. Python is very easy to pick up (as evidenced by the fact that the samples Harry showed, some doing pretty advanced stuff, could be fully understood without a language tutorial). It borrows some powerful features from functional programming, including list comprehension, which I love (whereas C# first had no way of doing this, it now has too much ways of doing it, with the addition of collection initializers, LINQ and lambdas). It integrates with the .NET Framework in a very obvious way. In short, I think I've found my scripting language! I'm certainly going to look into doing unit tests with it.
The implementation is open source and the whole thing has an air of pioneerism around it that's quite invigorating. Harry clearly loves both his job and talking about it, which virtually guaranteed the success of his speech even if he had been bad at speaking (which he certainly wasn't). If you already knew Python, I can't imagine you learned a lot of new things in this session, but I also can't imagine that you walked away with anything but enthusiasm.
Cycles Are Free, So I Can Kill Them All
The odd title is an actual quote from the next session: "Parallel Extensions to the .NET Framework", by Daniel Moth. I won't try to recreate the context, you had to be there.
Daniel was very upfront about what his presentation was going to be about, and he warned people that if they had already seen the existing material on the Internet, they weren't going to hear anything new, and offered them a chance to leave. Nobody did, despite some admitting that they'd already seen the material.
Daniel's presentation was another one of inspiration more than technical content, because the API he demonstrated is simplicity itself — almost boring. The results, however, are not boring at all: with just a few lines of code he showed how tasks could be parallelized and evenly distributed over the available cores while taking into account such things as canceling the possibly complex web of tasks, waiting on tasks and dynamically shifting workloads as cores become available.
The coup de grace, however, was definitely Parallel LINQ, or PLINQ, which can be used to parallelize a LINQ query almost transparently by calling a single extension method that switches to the parallel implementation (which would eventually utilize the parallel task API demonstrated). Because LINQ is almost functional programming (not quite, but it's heavily inspired by it) and functional programming languages are unusually easy to parallelize because of the absence of side effects, I expect dramatic gains indeed with very little developer investment. What's impressive here is not the added support for parallelization, but that it's made easy. Now this is something we positively, definitely need if we're going to capitalize on modern multicore hardware, because you do not want to be bothered with threading and synchronization issues for every single application you'll write in the future.
Parallel Extensions is, to put it most bluntly, the successor to the .NET thread pool. It isn't there yet, not by a long shot, but mark my words, it's going to get there. We have a chance to see it at its earliest stages and watch it grow (and even influence its growth to some extent by our feedback) which couldn't be more exciting.
I would customarily add some notes on Daniel's style as a speaker, but seriously, I can't be bothered. He was good, let's leave it at that. I was too interested in the content to pay attention. I'd imagine the rest of the audience was, too, as he was nearly unable to continue with his presentation at one point after being bombarded with questions. He eventually had to cut it off and defer the questions to after the session, otherwise I'd doubt he would have finished at all. You know it's good when the audience can't keep quiet to listen.
Wrapping It All Up
The last session of the day (and hence the DevDays) was "Leveraging C# 3.0 and LINQ (Best Practices)" by Krishnan Subramanian. At this point it was not the session I had wanted to visit — I wanted to visit Harry Pierson's second session. This despite the fact that it involved Silverlight, which I have no interest in at all. He really caught my attention with the IronPython session, and I wanted to hear him speak again. As it turns out, I really should have avoided this session, as I again heard nothing new and my colleague (whom I expected to appear elsewhere) had decided to come over and get a whiff of LINQ too, making my presence entirely superfluous.
Not that it was a bad session, not at all (by now you should have noticed the pattern of me being ungrateful of perfectly good sessions delivered by perfectly good speakers). Krishnan gave a run-down of LINQ as it trickles through your application layers, briefly stopping at each point to give some do's and don'ts (hence the "best practices"). These have to be taken with a grain of salt, though, because they ranged from immediately obvious to obvious within not too short a time of sinning against them. Still, it neatly structured the presentation. He also did a good job of explicitly clearing up the understandable confusion that still resided with a lot of people about the difference between LINQ to SQL and LINQ to Objects, and when exactly you're going from one to the other.
There were obvious and interesting parallels between this session and Anko Duizer's session. Krishnan also dealt with LINQ to SQL as your DAL — he even literally asked at one point "Is LINQ your DAL?", echoing the title of the other presentation. Odd as it was, I think it really was a coincidence. In a sense Krishnan's presentation was everything Anko's should have been, for better or worse answering the questions he had left unanswered. Krishnan made it clear, for example, that using LINQ consistently will effectively cause your DAL to be distributed evenly over the entire application, bringing the whole concept of a "layer" into question.
As a speaker, Krishnan made a few errors which must have detracted from the fun for some people — he failed to make all of his Visual Studio instances by ramping up the font, needlessly struggled a bit with the layout and didn't use the zoom feature enough to highlight things the audience in the back couldn't possibly see. I wouldn't have mentioned this if I hadn't seen the other speakers do this pretty consistently over the previous sessions. Fortunately he never failed to explain exactly what he was doing, so people could get the gist of it, but it's always nicer to see things up front.
The End
I'm very tired as I'm writing this, so you'll forgive me or indeed thank me if I don't extemporize on my lunch or the other goings-about on the second DevDay. I primarily came for the sessions, and I must say I wasn't disappointed. The lesson to take home for next time (and there'll probably be a next time) is to not visit sessions if you already have a good idea what you're going to hear, as this happened to me a few times too often.
No comments:
Post a Comment