August 2004 - Posts
Longhorn news today.
The bad news is that we won't have WinFS when Longhorn ships. The good news is that we'll have Avalon and Indigo in WinXP. We developers will be able to use those technologies sooner as we won’t need Longhorn clients. Indigo was supposed to work on XP but Avalon was not.
From the marketing point of view, I think they made the right choice. They'll sell more Longhorns because of Avalon than because of WinFS, so if they need to drop one, WinFS was the logical choice. That's because Avalon is a luxury item and people wants to have luxury items ;). On the other hand, there won't be another operating system with a file system like WinFS in 2006, but there are already operating systems that look better than Windows and that are increasing their market share because of that.
From the developer/power user point of view, I'd better have WinFS, but I know I’m not in the target market for operating systems vendors.
I wonder what this means for ObjectSpaces and MBF ;). I guess they will ship in the Orcas wave, after Longhorn.
A couple of weeks ago flying back from Redmond I read 'Coding Slave'. I did not like it. It's a quick read but I found it too pretentious. Anyway, one of the claims (I hope that not serious) of the book is that as programmers are the ones that do the real job then they (we) have a lot of power, so we need to organize, etc.
At this point of history we should probably know that if you are easily replaceable, then no matter how important your job is you have no power at all. Unions can make it harder, but in the long term if the task you do adds no value, you won't be doing it for a lot of time. Most of the programmers in the world are easily replaceable. Of course I think I'm not, but that's what everyone thinks of itself.
Most of the job that's done by programmers today is tedious and repetitive code that should not be written anymore. That's the kind of job that's being off-shored.
We should find ways to not to write that kind of code anymore. Code generators/MDA tools try to achieve that. Software Factories too. That's the way to go. You could feel that those kinds of tools are too generic and won't fit you, and you could be right. But you could also be wrong, and if you are, you are in danger of being disposable.
On the other hand, we as software developers like the feeling of being craftsmen, writing carefully thought code, very well designed, using 'test driven development', etc. I love to do this. But when we do this, we are creating a very expensive, one of a kind, high quality product, as craftsmen do. You probably know those kind of products are very hard to market. Sure, they could be very profitable, but only high reputation brands can do it successfully. I'm not sure if that's the kind of product most people should build.
We could work this way if we get high quality pre-built components. Then we could still be craftsmen and apply the finishing touches.
The way ASP.NET works with Visual Studio was completely rebuilt in VS.NET 2005. The reason is that they wanted VS.NET to embrace the ASP.NET runtime build model. In VS.NET 2003, you were 'forced' to work in a way that did not take advantage of the ASP.NET runtime build model.
In VS.NET 2005, you don't even need to build an ASP.NET project. All compilation can be done in runtime. There's no 'code behind assembly'. There's no ASP.NET project file, you just drop files in a folder and that's the ASP.NET application.
Try doing an 'Add Web Reference' from a Web 'project' in VS.NET 2005. You'll get a .WSDL file but the proxy source code won't be generated. The proxy will be generated and compiled in runtime. This is managed by the <buildProviders> entry in machine.config (you can find it the machine.config.comments in the framework 2.0 config folder), with something like:
<buildProviders>
...
<add extension=".wsdl" appliesTo="Code" type="System.Web.Compilation.WsdlBuildProvider" />
...
</buildProviders>
You get intellisense in VS.NET based on the WSDL file itself, not on the proxy.
This architecture is quite similar to WebMatrix. VS.NET 2005 is more similar to WebMatrix than to VS.NET 2003.
If you want to ship a compiled version of your website, you can still do it by running the 'Publish web site' project in VS.NET or running the aspnet_compiler.exe tool. Then you get a set of weird assemblies in a bin folder, with some '.compiled' files and a dummy .aspx page for each page that reads "This is a marker file generated by the precompilation tool, and should not be deleted!".
I'm really not sure if all of this is related to the lack of design-time component support in VS.NET 2005 but anyway I'm not sure if I like it. I guess we'll all get used to it.
Daniel complained about the lack of design-time component support in VS.NET 2005 for ASP.NET.
I also think this is a big issue. In addition to the Daniel's reasons, it makes the Windows Forms and ASP.NET design-time experience completely different, and that’s even worse when working with data.
Windows Forms have a 'Data Sources Window' where you can have your custom objects or datasets, and assign default controls for them (like when you drop a 'Gender' field in a form have VS.NET to add it like a ComboBox instead of a TextField). But ASP.NET does not use it! So even if you invest a lot of time of building your DataSources window, you’ll need to start again in ASP.NET.
One of the things that are lost in ASP.NET is design time support for binding typed datasets. If you built an assembly with typed datasets and you want to bind that to a web grid, you cannot do that from the designer. You could do it in VS.NET 2003 and it as a very common scenario.
They could make that work somehow if they shipped a 'TypedDataSet DataSource' in addition to the SqlDataSource, ObjectDataSource, etc, but it seems they won't ship it. There was a 'DataSetDataSource' in Beta 1 that won't be in Beta 2, but it was not designed to bind to typed datasets, even if the name implied it.
You can make this work by building own custom DataSource that works with typed DataSets, and we'll do that, but I think is something it should ship out of the box in VS.NET.
More Posts