Archives

Archives / 2008
  • If the Chief-Architect doesn't decide... who does?

    Yesterday I read this great article about VS.NET's technical roadmap, posted by Rico Mariani. Rico is the Chief Architect of Visual Studio, and he explains what that title means as follows:

    I am the Chief Architect but I'm also *only* the Chief Architect, I don't make the final decisions about what goes in the product, not even combined with the other architects. Jointly we come up with the long term technology roadmap, it indicates key problems that need to be solved for the long-term health of the product among other things, but these things cannot usually be mapped directly in to features in a particular release. So, while it's true that I have a significant effect on what we do, it is inadvisable to take any of what I write as some kind of commitment to deliver particular features; rather I talk about examples of things that we might do that are in line with the roadmap.

  • Baby-sitter Framework 2.0: Change tracking in the EF v2, it's still your problem

    More than 1.5 year ago (!) I wrote an article about why change tracking of changes of an entity should really be inside an entity object. Change tracking is the concern of the O/R mapper and the entity object, not the developer using the entity object and the O/R mapper. Imagine using an entity object a .NET application and you are in charge of taking care of what changes happened inside the entity object when it was used by some routine so you can decide which routine to call: the InsertNewEntity() routine or the UpdateExistingEntity() routine. Isn't that the concern of the framework you're using? I.o.w.: why do you need to baby-sit the changes of an entity and make sure these changes are propagated along the same path over which the entity travels?

  • Designing a language is hard, and M won't change that

    I was a bit surprised about the large scale of the positive hype around 'M' in Oslo. Fortunately, Roger Alsing wrote a 'Back to reality' post about M which stood out as a single critical remark against the sea of positivism. I like it when someone chooses to be the more sceptical voice in the crowd: this way an outsider gets a better chance to see the whole picture instead of just one side. This post is written in that light, to give my two cents in line with what Roger said and to give some more background in what I think he meant.

    What's the idea of 'M', the codename for the textual language in Oslo? It's supposed to make it easy to write DSLs. A DSL is a 'Domain Specific Language', which in short is a name for a language (in any shape or form!) to express behavior, data structures, data and what have you, for a specific, narrow, well defined domain. So if you want your application to have a custom set of rules, definable by the user, a DSL might be a good mechanism to formulate these rules in. Make no mistake about what a DSL is though: a grid, form, text in a textfile, can be a representation of a DSL. It's a concept, not a physical toolkit.

  • from el in world.ExtensionMethodsLibraries group el by el.Method into g select g;

    Everyone who's doing .NET 3.5 development these days will likely run into the same problem I ran into this morning: your set of extension methods grows beyond the level of a single file and you need to group them into separate sets of files or worse: you discover you have several distinct projects which all have extension methods and it's better to group them into a single library.

  • Is BDUF really BDUF?

    Justing Etheredge posted a great article about that Design Up Front (DUF) is something else than Big Design Up Front (BDUF). He discusses the misunderstanding that just because BDUF is considered harmful in a lot of projects, it's not said that DUF is too and one should just jump in, start hammering in code and hope for the best. As an example of BDUF, Justin uses the example of a car manufacturer and asks himself why a car manufacturer uses BDUF (according to Justin) and we in software land often don't or at least try to avoid it.

  • Software Patents are evil, here's why

    I was looking for a reference in ADO.NET Entity Framework documentation (via Google) if a Complex type in an EDM could be part of an association (relationship) like Hibernate supports. I needed this for some tool I'm working on . Google gave me an interesting link, namely to a patent held by MS about relationshipsets in the EDM. It refers to other patents of similar straight-forward concepts, either based on stuff defined by Codd or defined by other O/R mapper frameworks like Hibernate or Toplink long before the filing took place. Why these common concepts are even patentable (as they're discoveries in math-space, so not really inventions) is beyond me.

  • "The Entity Data Model is much bigger than just an ORM" -- Stephen Forte

    With almost bleeding ears I'm currently listening to show #369 of .NET Rocks!, which has Danny Simmons and Stephen Forte as guests. Danny is of course known of his major role in the Entity Framework (EF) design and Forte is one of the Council of Wise Men (TM) which are advising the EF team how to make the EF a better product / system / whatever.

  • The evil of the Office UI ribbon license

    For the next major version of a certain application I'm working on (gee, what might that be ) I'm researching some UI frameworks and techniques. In the past few months I've spend most of my time working on application support library code, language designs, algorithm design etc. etc. (more on that in a later article) and I arrived at the point where I wanted to see how my vision for the major version would work in a draft application, just to see how the various elements would work together visually.

    One of the first questions one would ask these days when a new desktop application is started is: WPF or Winforms? The current version is build with Winforms all the way though it's tempting to go for WPF, as it's new, has nice performance and great looks (if you're able to cook up the styles). After a day or 2 of fiddling with the various WPF docking frameworks out there, there's one firm conclusion to be drawn: WPF isn't up to par with Winforms when it comes to serious applications which use a normal windows look and feel: automatic menu, buttonbar handling based on selected docked window for example, one of the cool features of many winforms control libraries, is one of those things which is hard to do in WPF (at least, it's not directly available/build in). One other thing which made me draw the above conclusion was that it in general sucks bigtime when you have a normal windows application with normal menus: the text is in general blurry (or at least blurry in a short period of time after a move/open) and to make the menus to look like normal menus like in VS.NET is a pain (it doesn't get close).

    Because we will need a custom rendering system in this major version for some areas, we do need WPF. However, one can host a WPF control just fine in a winforms application, so re-using our already written winforms skeleton was a choice I didn't expect at first but which makes sense.

  • Linq to LLBLGen Pro: feature highlights, part 2

    In the first part of this series I talked about the fact that Linq to LLBLGen Pro is a full implementation of Linq and why it's so important to use a full linq provider instead of a half-baked one. Today, I'll discuss a couple of native LLBLGen Pro features we've added to our Linq provider via extension methods: hierarchical fetches and exclusion of entity fields in a query. Furthermore some other features will be in the spotlight as well. What I also want to highlight is that using an O/R mapper is more than just filling dumb classes with dumb data: it's entity management, and the O/R mapper framework should offer you tools so you will be able to manage and do whatever you want with the entity graph in memory with as less problems and friction as possible. After all, the task you have isn't writing infrastructure code, entity classes nor code to make these interact with eachother, your task is to write code which consumes these classes, and works with these classes. This thus means that you should be able to work on that code from the get-go, as that's what your client expects from you .

  • Email form disabled again...

    I've again disabled the email form on this blog, because I now get about 15 spam emails every 5 minutes through this form and enough is enough. Apparently it's not fixable by the blog-engine overloads, so this is the only option. If you want to contact me, my email address is on the about page.

  • Linq to LLBLGen Pro: feature highlights, part 1

    Some people asked me what the highlights are of Linq to LLBLGen Pro, which was released this week, as it seems that Linq support is apparently growing on trees these days. In this and some future posts I'll try to sum up some of the characteristic features of Linq to LLBLGen Pro, so you don't have to wade through the 15 articles I wrote about writing Linq to LLBLGen Pro . I'll write several of these articles, this is the first one. I hope to write more of them in the coming weeks.

  • LLBLGen Pro v2.6 has been released!

    After almost 11 months of design, development, beta testing and adding final polish, it's here: LLBLGen Pro v2.6! This version, which is a free upgrade for all our v2.x customers, has a couple of major new features, the biggest of course being the full implementation of Linq support in our O/R mapper framework. The work on our Linq provider, which we've dubbed 'Linq to LLBLGen Pro', lasted almost 9 months and was discussed on this blog in a series of articles, which I'll linq () to below.

    In the beginning of writing the Linq provider, I was pretty optimistic that it would be easy and quick, but after a while I got very pessimistic and wanted to skip it entirely as it would simply cost too much effort, and therefore time and money. The main reason was the lack of serious documentation and background on various essential details like which expression trees were formed from which linq queries, and how to understand them in full so a meaningful query could be produced from them to run on the database. Anyone who has written some form of Linq provider or is currently busy doing so will run into this problem. Doing trial-error development/research for a couple of months in a row isn't a picknick, but it's also part of being a Software Engineer so it always left me with a mixed bag of what to think of it: it's exciting and interesting, but also frustrating.

    A good example of the lack of serious documentation on expression trees is the way the VB.NET compiler compiles a group-by query into an expression tree vs. how the C# compiler does that: the C# compiler always adds a separate .Select() method call, the VB.NET compiler doesn't. In theory, the VB.NET compiler is right: the group-by clause has to be in the same query scope as the projection, but as C# has to be supported as well, you have to build some form of 'look-ahead' inside the tree to see when / if / how the projection is present after the group-by expression is seen. This isn't documented anywhere. Another one is the way how anonymous types are detected. There's no boolean on the Type object which tells you 'This is an anonymous type'. So you check the name. The C# compiler generates names which start with <>, the VB.NET compiler generates names which start with $VB$. And probably yet another language which runs on the CLR and which adds Linq support might choose another prefix. Nowhere is this documented but it is sometimes required to know that the type you're dealing with is an anonymous type.

  • VB.NET: Beware of the 'Aggregate' keyword (updated)

    UPDATE I tested this initially with EmployeeID and noticed the strange behavior. Writing this blogpost I thought the max of the employeeID was a little artificial, so I changed that in OrderDate. But... what happened (see my reply to this blogpost below in the comments) ? When o.OrderDate is used, the VB.NET compiler produces a proper expression tree! But when EmployeeID is used, it doesn't. Both are nullable types. When using CustomerID it also works properly. It's beyond me why it fails to produce a proper expression tree when EmployeeID is used. Nevertheless, the advice I gave below is still valid: do yourself a favor and call the aggregate extension methods of All, Any, Max, Min, Sum etc. when you want to obtain these values from a set in a scalar query.

  • See you at DevDays 2008!

    Tomorrow, May 22nd, and Friday, I'm present at the Microsoft DevDays 2008 in Amsterdam. I'm told we get special t-shirts, so it shouldn't be hard to find me . I'll be at the Microsoft Community Booth or in some sessions. If you want to say hi, please stop by! See you tomorrow!

  • Why use the Entity Framework? Yeah, why exactly?

    Danny Simmons wrote a marketing piece about the project he's been working on for so long: "Why use the Entity Framework?". I don't expect Danny to be unbiased towards his own work, so at first I just ignored it: Microsoft produces these kind of 'use our stuff, it's better than sliced bread'-articles a dozen times a day. However, this particular article seems to be a discussion subject and is supported by non-Microsoft people on other blogs, so it's time to stop ignoring it and start to refute the contents of the article, despite it being marketing. After all, it doesn't look like it's marketing.

  • Linq to Sql support added to LLBLGen Pro

    Imagine, you're sitting at your desk and you're using the Linq to Sql designer in VS.NET 2008 and you have, say, 50 entities in your model. You're happy about how things are progressing. It took a while to get the model set up, considering the wicked table and field names they cooked up in the DBA dungeon, but after some swearing and too much caffeine, it's done. The model which is smiling back at you is what you had in mind.

    Rain slams against the window and the DBA you have heard about but never had the chance to meet in person, walks into your office and with her whiskey-shaped voice she almost whispers into your left ear:
    "Son, I've updated a few tables in your catalog schema, hope you don't mind. See ya!"
    Before you can ask her why she found it necessary to do such a terrible thing to you, she's dissapeared, back to her basement.

    In shock, you stare at your shiny Linq to Sql designer, in it your 50 entities in full glory. Which tables were changed? What has she changed? WHAT!? You start telling yourself not to panic, when the idea of checking manually each and every of those 50 tables for changes, manually rebuilding the Linq to Sql model, re-doing your inheritance hierarchies, renaming the fields is causing a slight increase in sweat production. Why did you decide to wear this grey shirt to work, today!

  • Dynamic Data and 3rd party o/r mappers is a fact

    In the latest public preview of Microsoft's Dynamic Data, they've added something else besides what's publicly advertised: support for 3rd party O/R mappers!

    A couple of weeks ago, Bryan Reynolds mailed me about LLBLGen Pro support in MS Dynamic Data. I initially hadn't payed much attention to Microsoft's upcoming Dynamic Data initiative, as it's more geared towards web developers and was Linq to Sql / Entity Framework only as it seemed. He gave me a demo of Dynamic Data using Shared View (which works pretty well) and it got my attention. It's a clean, easy to use technology to get smaller websites which have to deal with data-entry, up and and running in no time.

  • Anti-agile hatemail

    Today I received through the contact form on this blog a hate-mail from a guy who called himself 'Ryan'. Ryan used a fake, non-existing email address so the only way to respond to him is via my blog, hence this post. Let's look at the email first:

    From: ryan@notanoob.org
    Subject: (Frans Bouma's blog) : anti-agile

    Your post on Jeffrey Palmero's blog is laughable. He is a smart and successful person and is involved in practices that you do not understand. Your post makes you look like a moron. You obviously have a lot to learn about agile development.

    The ONLY thing that works on large .net projects is the platform independent knowledge that the java / C++ / small talk community has learned over the past 20 years. I know because I work on a 3 million LOC, 200+assembly .net product every day. MS built the best development platform, but what MS teaches is crap. In the end, the culture of the development shop is what makes or breaks it. Agile practices focus on that culture. Tools and processes are secondary.

    One day when you work on a real app that is more than 100K lines of code maybe you'll understand. You should not venture outside of the realm of your fan base, which is newbie developers that have a background in ASP.

    I would love to see your product choke on several of our 100+GB databases.

    Thanks.

  • Beta of Linq to LLBLGen Pro released!

    Today we released the beta of Linq to LLBLGen Pro to our customers so they can dig in and check if we provided the right code, if everything works allright etc.! If you're an LLBLGen Pro v2.x customer and you want to check out our Linq implementation, please check the customer area to download the beta package.

  • Developing Linq to LLBLGen Pro, part 14

    (This is part of an on-going series of articles, started here)

    We're getting closer to the goal: a full-featured Linq provider for LLBLGen Pro. Hopefully next week the Linq CTP for LLBLGen Pro is ready for release to customers, fingers crossed! Last time I talked about the function mapping support for database functions and in-memory function/method/property access extravangansa, today I'll discuss one of the cornerstones of using an O/R mapper in the first place: fetching trees of objects using hierarchical fetches.

  • Developing Linq to LLBLGen Pro, part 12

    (Updated Wednesday 30-jan-2008). It was mentioned that we would implement 'Skip' as well, although we already had a paging method added, TakePage(). After carefull analysis, we decided not to implement Skip for now. The reason is that it can lead to confusing queries, while paging is what the developer wants. We believe TakePage() serves the developer better than a combination of Skip / Take (Take is still supported separately) which won't work in a lot of cases if Skip is specified alone.

  • To the new weblogs.asp.net bloggers

    First of all: welcome. Now, as you all might know, this blog site, http://weblogs.asp.net, has a grouped RSS feed (a couple actually), which is called the 'main feed'. If you place your post in a category which is in the default list of this site, your post will automatically end up on the main feed. This is a nice feature, but as it is used now it kills the site.