Friday, 27 June 2008

Rewriting history?

I very often update and modify my posts until I feel they carry the meaning I intended. With English being a foreign language to me, there are many instances where my posts end-up being interpreted the wrong way or don't represent my message really well.

I'll be migrating this blog over to my own servers quite soon, and I've been wondering if all those edits should be done the way they are now, without history, or if I should adopt a more bliki approach and leave anyone to see the variations and edits I do on posts.

Does historic truth matters to you? Do you want to see my edits? Or do you only care about the end result?

Thursday, 26 June 2008

Linq-to-Entities and me: Does what it says on the tin

For those not reading on the web, the subtitle of my blog is the result of a lovely name-calling session by an anon on this site. Proof that it works, another person has now proclaimed that I am indeed what it says on the tin.

The same blog argues that alt.net has turned into the nHibernate mafia, and that we all have a vested interest in nHibernate and are trying to defend our territory. One of the tenets of alt.net is to be pragmatic about the tools we use, and I've delivered projects with nHibernate, activerecord and linq2sql, and will use whichever tool works for the job. I don't have dogma for one tool over the other when they deliver what I need.

And to be absolutely clear, some of my clients will eventually, for better or worse, use the Entity Framework, and I'll have to use that tooling, be it that it fits or not in my personal practices.

On a more positive note, there's been some very interesting comments to my entry. I thought I'd highlight my understanding of the discussion so far. If I've misunderstood those arguments, feel free to respond in the comments or insult me by messenger, I'm always available.

Proponents of L2E argue that this new framework has been developed to provide the same tooling for modelling your entities across your different needs: reporting, data access, etc. As such, it should be seen as a tool that lets you re-use knowledge across models. Furthermore, it should not be understood as a tool to create global entities shared across applications.

This could very well be the case, and indeed bring benefits for people using Reporting Services and other data-centric tools that are apparently a pain. But if we see L2E as a tool, then for reasons that have been highlighted previously, they won't fit my toolbox because they do not support the development model I have adopted.

That said, other people still look affectionately at the idea of a global model for your application / applications. My projects tell me those models fail and my experience shows me that a DTO approach to boundary crossing is more effective.

I have expressed concerns at the fact that L2E has been at the core of  other frameworks (like ado.net data services), because it brings the fundamental idea that the same model could be exposed as a REST service, sent over a WCF service to another windows client, and put in a can of Coke to the moon. Doing each of those things represents a completely different set of challenges, each with a different model. Maybe if LinqToEntities could fit in my toolbox, I could reuse it to model every single of those different entities I need to have for each boundary in my application. But I don't believe the power of the designer is going to solve any of my issues, and will probably introduce more.

I stay unconvinced but I'm overall happy to realize that many proponents of linq2entities have an understanding of the issues with a unique entity data model and with sharing of models.

The Entity Framework - don't get fooled in what is wrong about it

[edit: modified text slightly to more accurately reflect my point and remove references to Julia being fooled, which apparently has been interpreted as Julia being a fool. Apologies.]

I'm off to bed, but thought I'd end up the day on a note. There are many flaws in the programming model adopted by the Entity Framework and they've been documented enough. But this is not what makes me cringe the most.

The Entity Framework team responds to the vote of no confidence by proposing fixes to programming issues in v2, talks of openness in the design of the next version, and have got people thinking that we object with the programming model. They even suggest that it's alright for Microsoft to deliver a tool that violates best practices established by people that built real systems.

[edit: I don't believe this is done with malicious intent, but I do believe there is a fundamental misunderstanding of the arguments that have been put forward, both by the EF team and their supporters and by the signatories of the letter]

The idea that a conceptual model can represent everything for everyone through designer-generated angle-bracket files is the issue. The fundamental of selling your product as one model crossing tiers and being standardized to all is a sweet dream that will end up biting anyone getting in contact with such a system. When Microsoft says transparently, I hear painfully.

The EF team explain how to fix the syntactic sugar without addressing the elephant flaw in the model is equivalent to telling people disagreeing with the one conceptual model to rule them all that they're just nitpicking over syntax. It's quite amazing that the people voicing their anxiety at the ripple-effect of introducing EF are being discarded as a small minority of weirdos that shouldn't complain because their way is not being adopted until v2. The reality is that a majority of those people are leading the industry in interesting directions discovered through experience and reflection, and their ripple effect is wide. . There is no wonder why TDD and BDD (and DDD and DDDD and all those acronyms I hate so much because of their opacity) all started with a couple of people, not with a couple of tools and designers.

Microsoft has a responsibility, because of its size, to not screw the people that are trying to promote a better craft. When those people react to a technology like they have with the Entity Framework, they should be listened to, because by delivering yet another monster (sharepoint anyone?), Microsoft may generate business but in the process degrade the overall quality of their development ecosphere. In the long term that may just end-up killing them, as the market will decide on better, simpler and more efficient tools. It's the law of two feets. But this movement takes years and impacts everyone that has to maintain a system.

As for Entities, they exist as several transpositions adapted to not only the programming model but also the context in which you use them. My notion of a user and your notion of a user only share a couple of trivial rules. If you ever, ever try to come up with one model that covers everything, you'll be too flexible or not enough, and your project, and the projects depending on your project, will fail. Full stop. It's been tried and tested. It is wrong. Like putting mustard in your corn flakes.

[updated for clarity and minor adjustments]

Wednesday, 25 June 2008

Jesus is back and His name is... svn?!?

image

Picture worth a thousand bibles.

Tuesday, 24 June 2008

Linq2sql running on Sql Compact Edition - calling on VistaDb to clean-up their act

There is a lot of misunderstanding on this subject. Even competitors of Microsoft seem to not understand fully what Linq2sql is made of or what it actually covers. One of these competitors is Vistadb that says on their product comparison:

SQL CE users will have to wait until the Entity Framework release before they can use LINQ against a SQL CE database.

I sent them an email to warn them that their comparison was erroneous, and an exchange has started in which they've assured me I was in the wrong and have neither acknowledged the confusion nor updated their comparison. As such I feel inclined to bring the conversation to the community, to get knowledge out there. I have not received their authorization to reproduce the exchange, so I'll have to represent as accurately as I can, in my own word, the different points they made. And I hereby invite them, and you dear reader, to the conversation.

Before you begin reading this, please note I do like the work the vistadb guys have been doing, I think it's a great internal database, and I probably would use their product still. But with greatness comes responsibility yada yada.

There is no provider model in linq2sql

This is an easy mistake to make if you don't spend your time in reflector. Linq2sql *has* a provider model that has been marked as internal late in the process, as described on the Wayward Weblog. If I was to guess the reasoning, I'd guess that there would've been a conflict of interest for partners to support both the Titanic Entity Framework model that leverages updates to the core ado.net classes and a provider model where they would've had to rewrite the sql code generation from the ground-up in linq2sql.

But I would concede that, as it's not public, for all intent and purposes, there is no provider model *you can build against*.

Linq2Sql gives you a Visual Studio GUI and a mapping tool

This is accurate, and very relevant to our conversation. There is several aspects to linq2sql.

  • A provider model, with a provider implementing access to Sql Server 2000, 2005 and 2008, as well as Sql Compact Edition 3.5. This is the bit of code responsible for translating between the model and the sql code
  • An abstract mapping model defining types such as MetaTable, MetaType and MappingSource, that let you implement different mappings. Linq2sql ships with two of those, one for xml mapping files, one for attributes.
  • Visual studio ships with a designer that lets you generate an xml mapping file through a point-and-click UI. This only supports the full-fledge Sql Server, and this is where the confusion may be coming from.

So there is a bit more than a GUI and a mapping tool. It's a GUI, a mapping model and a provider model.

Sql Compact Edition queries don't support Linq, the compiler does

Well I've struggled quite a bit to understand that one. Linq queries are compiled by the compiler as extension methods or interfaces defined by the implementations of Linq (Xml, object, Sql, etc). However, I fail to see any connection with Sql Ce itself, as the one querying the database is the provider that, indeed, supports Linq2sql just fine. The provider is indeed distributed with Sql Ce 3.5.

Microsoft does not use Linq2sql as a term that covers Sql Compact Edition and it's unsupported

I don't see how it relates to the technical conversation. And the download page of Sql CE 3.5 specifies the following.

SQL Server Compact 3.5 introduces a host of new features including LINQ to SQL support

Again, it doesn't seem like unsupported to me.

Conclusion

Vistadb is a strong product in its own right. The product comparison however contains a mistake and the company hasn't responded to the two emails I've exchanged with a catchall email address.

All in all, this highlights two points. Microsoft has a communication problem around Linq2sql; Iif your competitors don't understand your product well, imagine your customers. Secondly, if you want to put product comparisons you should *really* double-check your facts. Responding in person to emails rather than through a customerservices@... address, and double-checking before responding the second time would probably have kept me a bit happier.

The Entity Framework paves the way to years of uneducating the masses

This is in substance the bitter taste that's left in my mouth as EF v1 gets ready to be released.. I've been debating on this topic in user groups, meetings and within my clients: adopting EF as it stands would be a mistake as it introduces fundamental issues in the way we write code and in the way we design our architectures. We will spend years undoing the massacre done by introducing that technology as it stands, just like we still have to suffer DataSets today.

That's why I signed the ADO .NET Entity Framework Vote of No Confidence.

And today, it was announced that the Entity Framework team would adopt a transparent process in the same way as the ado.net data services team has. In this respect I'll have to remark that the ado.net data services team took the decisions they wanted to take, even when the community advised against them.

Furthermore, the objections that were made against the Entity Framework have been around for a while and apparently didn't make it into the V1.

I'll try and have an open and positive attitude towards this opening-up, but I'll notice that already there's a push within MS to adopt the entity framework everywhere. If you push for adoption of your v1 in the company and respond to criticism by promising to fix  fundamental scenarios in v2, you're doing more damage than good, and this is why I have a trust problem vis-a-vis the Entity Framework and its design team.

Tuesday, 17 June 2008

A real 3d-enabled web browser for WPF?

I know, some of you think that the browser control in the latest WPF 3.5 SP1 is the dog's bollocks. Sadly, it suffers from its origin as a wrapper around good old GDI and the lack of GDI redirection imposed by supporting WPF in Windows XP environments.

One thing I keep track of very closely is what the mono guys do. This is a fantastic pool of resources, skills and code, and if I had time to hack I'd probably join one of their many projects. And on their feed I came across Alp's post describing a WebKit-based 3d web browser. I can't wait to have a play with the code.

Technorati Tags: ,,,

Thursday, 12 June 2008

Alt.net London Beers #2 - 17th of June 2008

It's this time of the month again, and we continue with the tradition of organizing alt.net beers events monthly.

As usual, it's casual, it's about chit chat on alt.net things and its about beer.

The venue has kindly reserved a couple of tables in their upstairs bar where we'll be having some food and of course beer.

Don't hesitate to mail the details around, the more the merrier!

The Blue Posts
18, Kingly Street
London W1B 5PX


View Larger Map

Wednesday, 11 June 2008

NxtGenUG PreFEST08 Dinner & Fest08

NxtGenUG is the most thriving user group community around. They're organizing a dinner tonight, so come and join if you're around Reading (only 29 minutes on the train from London)

And of course, tomorrow is a day of pure geekiness with the Fest08 event in Reading. Come say hi!

Hello twitter?

Craig has been selling me twitter over the last few months and I always kept it on the back of my mind. From this morning twitteroo is installed and I'll be able to start moaning on my twitter feed about the poor QoS as soon as I get it. Right now it just looks like a web-based IRC to me.

Side note, when is too much information too much? Mailing lists, messenger (and often during the day visitors of this blog chatting away, usually introducing themselves with asdf or the time-proven testing), maybe I'm overcommitting?

Tuesday, 3 June 2008

Agile smell

Anthony talks about a potential agile smell and the concept of self-organizing teams. As with his brother's blog, I still can't figure out how to post a comment so it ends up on my blog. If I was to bother with putting categories on my entries, I'd probably have one specifically for commenting on other posts when I've been too dumb to find the reply or the register button.

Let's first separate Agile (as an enforced, recognized and lucrative book publishing business, as well as quite a bit of ego and a general lack of understanding or intelligence in applying the ideas), agile (as a bunch of methodologies you pick and choose from to try and get as many benefits as you can out from what others have spent years experimenting with, and that we alt.netters would consider the pragmatic choice), post-agile as a poorly worded (imho) variation of pragmatism, and scrum (as one particular self-organizing methodology, one of the most popular but also one of the most badly applied). They each represent different things and different steps you can and should follow in becoming more agile, and everybody should try to get more agile even when not wanting, refusing or considering being past the stage of, Agile.

Back to Anthony's post. He talks about a "conflict" with someone telling him that he should have chosen a story to pick on his own because teams are self-organizing, and Anthony argued that without prioritizations he should ask before committing to the work.

I'm not entirely sure which variance of agile that company is using, but here's what we do here. Stories are written on the wall and are negotiated with the client, and doesn't involve the dev team much at the early stage outside of simple feasibility study (when we're lucky). They get used for us to produce both the scenarios for the tester's acceptance criterias and the product backlog.

The product backlog is the one being prioritised: high-level functionality cards of a couple of days, and the prioritization is done by us from the knowledge we extract painfully from the project managers. Sometimes they even come and do it themselves, but sadly that's as common as a solar eclipse.

From this, we commit at the beginning of the sprint to the amount of work we think we can deliver. After a couple of sprints we know roughly from our estimates how many virtual hours we deliver per sprint, aka how many of the hours we have estimated we manage to deliver. This is usually quite accurate even though the number itself doesn't mean much at all.

The team is self-organizing from that point because the *team* has committed to the *whole* of the sprint backlog. If we had over-committed we would've de-scoped. In that sense, at the stage of a daily stand-up, I'd agree that a team member asking what to do next is usually a practice smell:

  • Priorities of tasks mostly don't exist as we're committed to all of them
  • The ones that need to be worked on first are based on dependencies rather than priorities. If you ask you probably forgot what depended on what. With short sprints, that's the last thing you would forget when you've spent 3 or 4 hours deciding all of those on the Monday.

We use the wall for roughly clustering tasks that are inter-dependent, and the bottom of the wall for the nice-to-have. When you commit to a task, you commit to the team that you're wishing to do a task, so you probably don't have a reason to ask for permission.

The final thing that I've experimented on my latest project is to decouple the sprint backlog maintenance and the daily stand-up. It's now a real-time wall: you add, remove, complete and reshuffle tasks when you feel like it, the wall is visible and people will see the changes as they happen. The daily is a summary of all those movements: this relieves the pain of updating the wall, makes it more entertaining, and no one asks what to do next because they've either not finished their current task yet or they've already chosen their new one.

Being agile share many of the tenets of alt.net: flexibility, lookout for the best solution, pragmatism. In that respect I'll agree with Anthony that an Agile Anal can be annoying. But on the other hand (and I'll leave that to another post), only the teams that tried and mastered Agile can allow themselves to deviate to agile. If you've not tried hard enough a change in mentality in the way you work, you will fail, and what some would call "adapted agile" I call "bad habits are back".

[Updated: s/Jason/Anthony]