I spent a fun week in Redmond, in the Patterns and Practices Summit.
James Newkirk is my new hero. He gave a very good presentation about xUnit, and said some things that it's good to hear these days, like "dependency injection is not required by most applications", and that it reminded him about when one learns about the "Visitor Pattern", and wants to apply it in every place but at the end of the day in a lot of contexts there are much simpler solutions. I proudly got a signed copy of TDD Driven Development in Microsoft.NET to take home with me. I like pragmatic people.
Looks that Patterns and Practices team is having a hard time deciding if they should focus on just guidance or in code + frameworks, or deciding how to balance them. The fact that most people takes the frameworks they produce as "Microsoft Products" from which they expect support and back compatibility makes things more complex. I prefer some form of code than just documentation, and frameworks instead of just samples. Now, if the people expect their deliverables to be products, perhaps they should be, and they should try to convince whoever needs to be convinced inside Microsoft to productize their efforts. There are a lot of big customers who depend on their bits.
The Nerd Dinner in Crossroads was a lot of fun too. Some pictures here. John Lam attended and IronRuby almost monopolized the conversation.
Scott Hanselmans' second presentation about himself and his first weeks in Microsoft was hilarious. He mentioned LolCode and John Lam stepped in to show the LolCode implementation on top of the Dynamic Language Runtime.
I'll be presenting the new
Infragistics Aikido Framework in a lunch-time session in the Patterns and Practices summit.
Aikido is quite cool. It's very well designed and it makes very easy to create advanced controls that support advanced features like DataBinding, Templating and Appstyling. I'll show how to build a control from scratch that takes advantage of it.
The summit content looks quite promising. I'll spend the whole week there, and post my impressions here.
BTW, Scott Hanselman is organizing a nerd dinner for Thursday. I'll be there.
I did a presentation on LinQ last Wednesday in the Buenos Aires CodeCamp.
The event was quite fun. I attended to a presentation by Damian Galletini about Robotics Studio that was quite enlightening. The Robotics Studio runtime is built on top of WCF, and Robotics Studio itself has a very interesting DSL for programming the Robots. I did not know anything about Robots. It's quite easy and fun to use. Anyway I'll need to wait a couple of years until I have an excuse to buy my older kid a Lego Mindstorm NXT.
I had a great time with the Southworks guys who acted as my hosts in Buenos Aires. Johnny Halife and Paulo Arancibia also presented.
Jonas Stawski had the idea of doing it in Buenos Aires, and Pablo Michelis and his girls organized it. Congratulations to all of them!
InfoQ posted a very interesting video from the ‘Democratizing the Cloud’ presentation by Erik Meijer in QCon.
Democratizing the cloud means “Make easier to program distributed applications”. He wants us to build a single tier app and publish it in multiple tiers.
He describes an IL to JavaScript compiler (like Script#) and a MapReduce implementation for LinQ. You can then write C# code and later decide to run it in the browser, or specify a query that today executes over a SQL database but when your application is successful and is used by millions of users, scale it over a cluster of distributed applications servers using MapReduce.
Of course that we’d love to have that.
The only element that I don’t find consistent with his vision is the ‘refactoring’ he needs to split the applications in tiers. Up to then, all the magic was performed by the compilers and runtimes, but for this one we need different code, so once the decision is made, it cannot be changed. He talks about ‘making irreversible decisions at the last responsible moment’. The problem is to agree when that moment is ;). Things like ‘code webservices as if they are stateful’ probably are a heresy for some people.
This kind of functionality has only been provided by code generation tools, where you generate multiple tiers or single tier applications from the same specification, but never at the language level.
He also has some interesting opinions on SQL and DSLs.
I've started reading a lot about UI in the last couple of months. During the Office 2007 beta process I run into some blog posts from Jensen Harris that I found interesting but I never followed his blog.
Now I found a post that aggregates all the content about the Office 2007 UI, and it's a fascinating read.
I had an ambivalent relationship with the Ribbon but after reading about it I love it ;).
Pat Helland has been talking about immutable data for a while. He last post on 'Normalization is for sissies' is quite fun. A not-very-accurate post from Dare made me remember about it and pushed me to post this.
Pat is playing with two ideas.
One is that immutable data should not be normalized as normalization is designed to help you dealing with updates.
Another is that you actually don't need to delete/update the database. 'Deleting' a row means setting a InvalidationTimestamp = now(), and updating a row means setting InvalidationTimestamp = now() and inserting a new row with SinceTimestamp = now() and InvalidationTimestamp = null (you actually need two sets of dates, but that's for another post).
Now, if you put the two ideas together, all the data is immutable, so you don't need to normalize anything. This means you will have a record that have all the 'extended table': the 'base table' and all the fields from related tables in your normalized model. If you have Orders, Customers, Countries, your tables will look like
Order: OrderId, OrderDate, CustomerId, CustomerName, CountryId, CountryName, SinceTimeStamp, InvalidationTimeStamp
Customer: CustomerId, CustomerName, CountryId, CountryName, SinceTimeStamp, InvalidationTimeStamp
Country: CountryId, CountryName, SinceTimeStamp, InvalidationTimeStamp
You will be wasting a lot of disk space, but that's not something to worry about. The advantages of this approach are very important. You don't need to join, and you can cache/replicate most of your data.
The main physical issue I find today with this approach is that database engines have a limit in the number of columns they can store, and an approach like this one will require a large number of columns per table.
I wonder how a model like this will impact O/R mapping tools.
They can probably hide this kind of schema automatically by changing the semantics of delete/update, writing Order.Customer.Name should return the name in the Order row.
How would they handle object identity? Now if I have 'Customer #1' in memory, every reference to Customer #1 points to the same instance. This is because the object model is normalized. Now they should point to different read/only instances.
The sample code that ScottGu showed for LinQDataSource made it look like it should be called LinQToSqlDataSource.
After installing Beta2 I took a look at it.
It only has design time support for LinQ To SQL, but you can bind it to any LinQ query in the _Selecting event:
protected void LinqDataSource1_Selecting(object sender, LinqDataSourceSelectEventArgs e)
{
e.Result = from c in MyCustomer.GetCustomers() select new { c.Name };
}
I did not find a way to handle insert/update/delete, so it looks that any third party O/R mapper will need to implement its own DataSource to handle it. However, in the LinqDataSourceView, there are some implementation details that make me hope they fix that. They have protected virtual methods with the following signature:
protected virtual void UpdateDataObject(object dataContext, object table, object oldDataObject, object newDataObject)
Note that the 'dataContext' is 'object', so if you have other datacontext type that it's not LinQToSQL's one, you could access it from there. In order to try that, I needed to replace the DataSourceView that theLinqDataSource control uses, so I subclassed LinQDataSource so the GetView(string) returned my instance, but it did not work, as the LinQDataSource internally asks for the view to another method that is not virtual.
Other interesting stuff I found digging with Reflector:
- The DataSource only returns one view, so if you have a control that can bind to hierarchical structures, you will not have a good design time experience with LinqDataSource, as the control can't know the structure of the nested views. The same happened with the DataSource controls that shipped in ASP.NET 2.0, but in some of them it did not make sense (like the SqlDataSource) but in others did and it was not supported (XmlDataSource).
- The LinqDataSource supports specifying a where clause, like
Where="Name.CompareTo(@TextValue)>0"
to do this, they should have a framework to create a LinQ query from a string. As I implemented pretty limited one sometime ago, I was eager to see how they did. There is an internal System.Web.UI.WebControls.DynamicQueryableWrapper class that does exactly that. I thought it would be a good idea to make it public, but today I found this Building LINQ Queries at Runtime in C# article that looks like a much better solution. I need to take a deeper look at it.
We won't have PDC this year.
PDC is always the time when MS unveils totally new stuff. I don't think it's possible to do old-style PDCs in these new times of 'transparency', early CTPs and public Alphas. I wonder if MS will redefine PDCs or they will still keep some 'secrets' to surprise us.
Frans rants about paging support in SQL Server. I obviously agree with him.
The good thing is that given that MS is working in a couple of O/R mappings products, they are probably facing the same challenges we face. As that the Entity Framework is built by the SQL Server team, I won't be surprised if Katmai has better support for paging ;).
I was going to write
a blog post on Astoria but Pablo's post says almost everything I was going to
say.
I fully agree with
him, in that there are multiple scenarios where the default implementation will
be good enough, and it's much more productive than what we have today.
The fact that you can further filter the results of methods like 'CustomersByCity' is a significant step forward compared to the static service interfaces we usually have today.
On the other hand,
the client-side library has a WebDataContext class that knows how to track
changes in the client. The problem is that as the EF does not have a
change-tracking serialization mechanism (see previous posts) the way they have
to post a set of changes to the server is by executing multiple HTTP requests,
which is obviously a bad thing.
The good news is
that I think there's no way they can ship Astoria this way, so they'll need to
come up with a good disconnected story ;).
Pablo also mentioned
in his presentation that you'll be able to upload your EF model and the Astoria
live service will create the tables in the database and host up to 100Mb of
data. That's quite interesting, and it means they'll need to tackle another problem
(which it's solved quite well in DeKlarit) which is how to keep your data
stable when you deploy a new version of your model.
More Posts
Next page »