Frans Bouma's blog
The blog of Frans Bouma, creator and lead developer of LLBLGen Pro and ORM Profiler.
-
The Undo-Redo paradox
In July 2008 I started development on LLBLGen Pro v3's new designer. The first thing I realized was that I needed a good, solid, generic framework to base the new designer on, especially because v3 would introduce a new big feature: model-first entity model development. In short, model-first means that the user starts the designer and can build an entity model from scratch (so no meta-data available whatsoever) and create meta-data and mappings from that entity model, or modify an existing or reverse engineered model by adding new elements. So the user will edit, delete, and do other things which aren't based on any meta-data, but based on theory, thought processes and perhaps trial/error. In short: the user will make changes to a live model in memory and will try to undo and redo these changes during the process. Everywhere. Always. So undo/redo has to be present everywhere, and always in every situation. Removing an element, like an entity definition, should remove all its related and depending elements or at least make them update themselves and undo-ing that removal should restore the original state.
-
[Dutch] Devnology Code Fest
(Sorry English speaking visitor, this post is in Dutch, as it's about a Dutch user group meeting)
-
Choose .Concat() over .Union() if possible
Update: I've reworded a sentence as it was too vague. Sorry for that.
-
Winforms Gotcha: Form.Close() doesn't always call Dispose()
I just ran into a weird issue. During profiling I saw that controls on a form which was already closed were still reacting to events. I checked whether the Dispose() routine of the particular Form was called, but it wasn't. However, the Dispose() routine of other forms was called after it was closed, as in: immediately.
-
Soft-deletes are bad, m'kay?
Have you ever ran into database tables with a field which is used to mark if a row has been 'deleted' ? Probably. These fields are used to implement 'soft-deletes'. For the soft-delete impaired, a quick introduction. Soft-deletes are row deletes which are not really happening: instead of removing the row from the database table, a field in the row is set to a value which signals that the row is officially 'deleted'. Every SELECT statement on that table is then filtering on that field's value so only rows which aren't marked as 'deleted' are returned (as the deleted data is not there anymore, semantically).
-
Happy 2009!
To all my readers, and everyone else: I hope you all have a great, productive, healthy, awesome 2009!
-
Small interview with me about blogging
Andreas Håkansson did a couple of interviews with various people from the .NET blog community about... blogging
. The interview with me is now available here.
-
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.