Last week I went to the MIX07 conference and blogged a lot. I acted like an intrepid reporter, posting up reviews of each session as I went to them. MIX07 became a top ten search term in technorati, so I received quite a bit of traffic to my blog.
So I wanted to find out - what is the half life of a successful blog entry? How much time does a blog entry live?
My conclusion - the half-life of a successful blog entry is about a week. After a week, traffic is almost completely gone from sites such as technorati, shoutwire, digg, etc. In addition, there doesn't seem to be much loyalty factor at least for my small blog - I haven't built enough brand power yet that I'm getting a lot of repeat visitors. Almost 70-80% of my visitors are brand new to my blog.
I'm not sure if this is typical, but it shows that attrition is very high and that bloggers who are not committed to posting every 2-3 days are not going to get any follow through in traffic. Its either post or perish in the blog world!
Showing posts with label MIX07. Show all posts
Showing posts with label MIX07. Show all posts
Monday, May 7, 2007
Wednesday, May 2, 2007
MIX07 72 Hour Conversation Archive
Here is a list of the posts I made throughout the MIX07 conference. These were done in near real time as sessions ended. Enjoy!
MIX07 Update: The Impact of Bloggers on Public Relations
CIO.com reports that there was a disappointing talk at the MIX07 conference on "digital entertainment". I didn't attend they keynote (preferring to take the time to put up some blog posts instead) but the immediate reaction shows the power of bloggers controlling news.
Before even the talk was concluded, people were blogging about how poor the talk was in near real time. It shows how important the blogging community has become in the following ways:
1. News is released in real time by thousands of bloggers. MIX07 and Silverlight both made the top ten searches in Technorati. Managing this spin cycle in real time becomes increasingly important for any PR department or agency.
2. The news dies quickly. I was blogging every 3-4 hours, and my the time my post was up on Technorati, the last one was already buried off the first couple pages. The best thing you can do from a PR perspective is to flood the network with news - this helps to bump older content down the list and traffic to those news items dies as a result. I have personally seen a massive drop-off even with my own posts after about 24 hours in traffic coming from news search engines such as Digg, Shoutwire, Technorati, etc.
3. Reading is happenning in real time as well. I was blogging throughout the MIX07 and I could see through analytics each post was getting traffic within minutes of being posted. Its hard to tell whether these readers are people at the conference or those simply visiting from the outside and experiencing it vicariously, but if you can generate enough awareness there will be a large amount of readers who will grab your message in near real time.
4. Its a bit hard to understand the impact of blogging on conference goers themselves. For example, did enough people start reading blog entries or news sitting in the talk that they got the message to walk out? Given the number of blackberries and wireless laptops in the room, its a possibility.
Before even the talk was concluded, people were blogging about how poor the talk was in near real time. It shows how important the blogging community has become in the following ways:
1. News is released in real time by thousands of bloggers. MIX07 and Silverlight both made the top ten searches in Technorati. Managing this spin cycle in real time becomes increasingly important for any PR department or agency.
2. The news dies quickly. I was blogging every 3-4 hours, and my the time my post was up on Technorati, the last one was already buried off the first couple pages. The best thing you can do from a PR perspective is to flood the network with news - this helps to bump older content down the list and traffic to those news items dies as a result. I have personally seen a massive drop-off even with my own posts after about 24 hours in traffic coming from news search engines such as Digg, Shoutwire, Technorati, etc.
3. Reading is happenning in real time as well. I was blogging throughout the MIX07 and I could see through analytics each post was getting traffic within minutes of being posted. Its hard to tell whether these readers are people at the conference or those simply visiting from the outside and experiencing it vicariously, but if you can generate enough awareness there will be a large amount of readers who will grab your message in near real time.
4. Its a bit hard to understand the impact of blogging on conference goers themselves. For example, did enough people start reading blog entries or news sitting in the talk that they got the message to walk out? Given the number of blackberries and wireless laptops in the room, its a possibility.
Tuesday, May 1, 2007
MIX07 Update: The Future of N-Tier Architectures
As a Director of IT, one of my principle jobs is to recruit talent. During our interview process, we start by asking a candidate about a project they designed, coded and deployed and we present them this picture:
The interview discussion focuses on answering what replaces the question mark - what is the appropriate N-Tier Architecture for their application. You can use this question for any developer because its open to multiple solutions - the junior developer might answer that there is an ASP.NET page that connects using the supplied wizards to an ADO.NET connection that then talks to the database. For a more seasoned architect, they should answer with a much richer domain model, database access layer, proxies for web service or other distributed calls, monitoring and configuration management layers, class factories, etc.
That's why the question is an interesting question for interviewers - it forces the discussion to question design decisions. Why did they use ADO.NET? Why did they choose web services instead of remoting? Why did they choose to keep code in separate objects instead of in the code-behind files? Why did they choose particular design patterns, etc.?
As web technologies have evolved is that they have focused on adding maturity in the tiers. A classic ASP site with some ASP page code, some VB 6.0 objects and a connection to the database through ODBC is now an ASP.NET page, a code-behind file, some domain model objects, some ADO datasets, web service proxy classes, etc. Now there are dozens of options on implementation of that middle-tier and the role of the architect is to decide amongst a selection of options which is appropriate for the particular application being built.
What has happened as these technologies have evolved is an explosion of tiers. In the last enterprise application I managed, we had the following tiers: 1) reverse proxy; 2) HTTP handlers/modules; 3) ASP.NET page; 4) code-behind files; 5) value objects or business entities; 6) web service client stub classes; 7) web service handler classes; 8) data access layer objects; 9) Microsoft Enterprise Library; 10) the Database!
At least it was still easier than using classical J2EE! :)
What seems to be happening as Microsoft technologies evolve is a resolving of this tier explosion through a few different strategies:
1. Use of LINQ to simplify data access and consolidate the data tier into some SQL like statements.
2. Code generation techniques for automating plumbing code (the LINQ designer for example will build your domain model simply by pointing at a schema).
3. Smarter web controls that require less code - Dynamic Data Controls for example.
4. Integration of .NET into Silverlight to put more smarts into the client instead of requiring web service calls for every function.
5. Greater focus on Plain Old .NET Objects - LINQ in particular moves from the heavy Dataset based approach that ADO.NET uses as value objects and can instead populate simple lightweight classes that the developer can design as required.
6. Greater focus on declarative languages - LINQ and also use of IronPython and PHP for example. Instead of focusing on imperative languages that specify the algorithms on how to do instructions, a declarative language allows the developer to focus on business rule declaration and specify what is required and delegate implementation to the framework.
7. On the client side, dramatic improvements in rendering in Silverlight especially in 3D based applications.
All these developments are promising. If the technology works as advertised then development of basic plumbing operations such as CRUD operations with a database, web service calls, etc. should be dramatically easier to code and maintain.
However, "works as advertised" is always the challenge. Developers who have worked with O/R mappers for years have experience with frameworks that claim to hide away details but then also hide away performance bottlenecks, poor implementation strategies and developers are increasingly dependent on the framework to work in the background.
And from what I have seen at the conference so far, its really too early to tell - we're still at the "Just use the wizard" stage where Microsoft demos a cool technology by running a dinky unrealistc demo. Don't be the fool to take the sample code and consider it ready for production without some serious design review!
The interview discussion focuses on answering what replaces the question mark - what is the appropriate N-Tier Architecture for their application. You can use this question for any developer because its open to multiple solutions - the junior developer might answer that there is an ASP.NET page that connects using the supplied wizards to an ADO.NET connection that then talks to the database. For a more seasoned architect, they should answer with a much richer domain model, database access layer, proxies for web service or other distributed calls, monitoring and configuration management layers, class factories, etc.
That's why the question is an interesting question for interviewers - it forces the discussion to question design decisions. Why did they use ADO.NET? Why did they choose web services instead of remoting? Why did they choose to keep code in separate objects instead of in the code-behind files? Why did they choose particular design patterns, etc.?
As web technologies have evolved is that they have focused on adding maturity in the tiers. A classic ASP site with some ASP page code, some VB 6.0 objects and a connection to the database through ODBC is now an ASP.NET page, a code-behind file, some domain model objects, some ADO datasets, web service proxy classes, etc. Now there are dozens of options on implementation of that middle-tier and the role of the architect is to decide amongst a selection of options which is appropriate for the particular application being built.
What has happened as these technologies have evolved is an explosion of tiers. In the last enterprise application I managed, we had the following tiers: 1) reverse proxy; 2) HTTP handlers/modules; 3) ASP.NET page; 4) code-behind files; 5) value objects or business entities; 6) web service client stub classes; 7) web service handler classes; 8) data access layer objects; 9) Microsoft Enterprise Library; 10) the Database!
At least it was still easier than using classical J2EE! :)
What seems to be happening as Microsoft technologies evolve is a resolving of this tier explosion through a few different strategies:
1. Use of LINQ to simplify data access and consolidate the data tier into some SQL like statements.
2. Code generation techniques for automating plumbing code (the LINQ designer for example will build your domain model simply by pointing at a schema).
3. Smarter web controls that require less code - Dynamic Data Controls for example.
4. Integration of .NET into Silverlight to put more smarts into the client instead of requiring web service calls for every function.
5. Greater focus on Plain Old .NET Objects - LINQ in particular moves from the heavy Dataset based approach that ADO.NET uses as value objects and can instead populate simple lightweight classes that the developer can design as required.
6. Greater focus on declarative languages - LINQ and also use of IronPython and PHP for example. Instead of focusing on imperative languages that specify the algorithms on how to do instructions, a declarative language allows the developer to focus on business rule declaration and specify what is required and delegate implementation to the framework.
7. On the client side, dramatic improvements in rendering in Silverlight especially in 3D based applications.
All these developments are promising. If the technology works as advertised then development of basic plumbing operations such as CRUD operations with a database, web service calls, etc. should be dramatically easier to code and maintain.
However, "works as advertised" is always the challenge. Developers who have worked with O/R mappers for years have experience with frameworks that claim to hide away details but then also hide away performance bottlenecks, poor implementation strategies and developers are increasingly dependent on the framework to work in the background.
And from what I have seen at the conference so far, its really too early to tell - we're still at the "Just use the wizard" stage where Microsoft demos a cool technology by running a dinky unrealistc demo. Don't be the fool to take the sample code and consider it ready for production without some serious design review!
MIX07 Update: Silverlight 1.1 and .NET Development
I went to a session this morning on Silverlight 1.1 Alpha which is the next version of the product. It features a number of interesting features:
1. Complete CLR .NET based framework - write your Silverlight applications in VB.NET, C#, IronPython, etc. using standard .NET classes. What ships with Silverlight is a stripped down version of the .NET framework in order to shrink the plug in size. For example, XML document reading is included, but XSD validation and XPATH are not included.
2. Silverlight runs 100% client side all the managed code runs within the plug in and will run the same on a Macintosh as it does on the PC (although I have heard this before with Java applets and it never quite worked 100%).
3. Serving Silverlight apps can be done any web server that can serve files. So if you want to deploy your apps to an Apache server, no problem.
4. If you choose to serve your Silverlight apps from ASP.NET you get some advantages and tight integration with your ASP.NET page.
5. Debugging support is built in, including debugging via a proxy client on a Macintosh. Debugging is standard Visual Studio debugging with breakpoints, stepping through, etc.
6. LINQ for objects is supported with LINQ for databases (DLINQ) and LINQ for XML (XLINQ) on the road map.
7. There is the ability to interop between HTML and Silverlight. You can access the HTML DOM from Silverlight, and you can expose your objects in Silverlight to javascript by using a simple [Scriptable] attribute.
8. Web services support is very strong with wizards for generating all the stub code including support for Windows Communication Foundation (WCF).
In general, I was pretty impressed and the 1.1 version is the obvious target for traditional .NET developers. From my perspective, the killer application for Silverlight isn't the animation sitting on web page that makes some animation go in as static content. Where its going to pulverize Flash is where you have .NET application developers who want a rich user experience without having to learn an entirely new programming language in ActionScript. Even in 1.1, the CLR in Silverlight seems much more robust than typical ActionScript code and more importantly for .NET developers is familiar territory.
1. Complete CLR .NET based framework - write your Silverlight applications in VB.NET, C#, IronPython, etc. using standard .NET classes. What ships with Silverlight is a stripped down version of the .NET framework in order to shrink the plug in size. For example, XML document reading is included, but XSD validation and XPATH are not included.
2. Silverlight runs 100% client side all the managed code runs within the plug in and will run the same on a Macintosh as it does on the PC (although I have heard this before with Java applets and it never quite worked 100%).
3. Serving Silverlight apps can be done any web server that can serve files. So if you want to deploy your apps to an Apache server, no problem.
4. If you choose to serve your Silverlight apps from ASP.NET you get some advantages and tight integration with your ASP.NET page.
5. Debugging support is built in, including debugging via a proxy client on a Macintosh. Debugging is standard Visual Studio debugging with breakpoints, stepping through, etc.
6. LINQ for objects is supported with LINQ for databases (DLINQ) and LINQ for XML (XLINQ) on the road map.
7. There is the ability to interop between HTML and Silverlight. You can access the HTML DOM from Silverlight, and you can expose your objects in Silverlight to javascript by using a simple [Scriptable] attribute.
8. Web services support is very strong with wizards for generating all the stub code including support for Windows Communication Foundation (WCF).
In general, I was pretty impressed and the 1.1 version is the obvious target for traditional .NET developers. From my perspective, the killer application for Silverlight isn't the animation sitting on web page that makes some animation go in as static content. Where its going to pulverize Flash is where you have .NET application developers who want a rich user experience without having to learn an entirely new programming language in ActionScript. Even in 1.1, the CLR in Silverlight seems much more robust than typical ActionScript code and more importantly for .NET developers is familiar territory.
Silverlight and MIX07 Are Now in the Top 10 Searches in Technorati
The traffic coming from the MIX07 conference is having an impact on the blogosphere.
Mix07 currently sits at #3 and Silverlight sits at #5. Silverlight is now officially more hyped than Paris Hilton - congratulations, Microsoft! :)
MIX07 Update: Evolution of Declarative Programming in .NET
One of the key messages from the MIX 2007 conference is the evolution of the .NET framework to support a much more declarative programming style.
Anders Hejlsberg made the claim that the potential productivity improvements from imperative programming are limited - we've essentially already invented all the major programming constructs and he doesn't see much more productivity improvements - we're not going to invent the equivalent of a new type of FOR LOOP - we've got them all.
Declarative programming paradigms have some significant room to improve developer productivity by simply changing the game - instead of making developers focus on statements that construct the logic on how something gets done, declarative programming frameworks can allow programmers to focus on focusing on domain level concerns.
An example of this is LINQ - instead of writing a data access layer for every table, with LINQ you can simply write declarative SQL like syntax. The data access layer is automatically generated for you. In addition, the power you get in the LINQ for declarative SQL like logic means that you can do all sorts of database operations in code that would have taken tonnes of imperative style coding previously:
var wordGroups =
from w in words
group w by w[0] into g
select new { FirstLetter = g.Key, Words = g };
Just imagine the amount of plumbing code you would need to do this in today's .NET or Java frameworks - this is the power of declarative programming styles.
The same is true on the interface side - the power of languages such as HTML, CSS, PHP, Python, etc. are declarative languages that allow the user to use a declarative programming style instead of an imperative set of instructions.
In HTML, the imperative version would be what we used to do with old CGI or classic ASP applications to generate HTML programmatically. It would look something like this:
Response.Write("<html>")
Response.Write("<body>")
' build a table with n rows and m cols
Response.Write("<table>")
for i = 1 to n
Response.Write("<tr>")
for j = 1 to m
Response.Write("<td>")
Response.Write("</td>")
next j
Response.Write("</tr>")
next i
Response.Write("</table>")
etc.
This type of programmatic approach to HTML generation has almost entirely disappeared as declarative programming styles have now allowed interface developers to simply write HTML directly.
Expect more of this declarative style in deeper layers of the architecture and for the syntax of the declarative constructs to support more complicated and domain driven programming patterns. This will hopefully have an impact on the amount of plumbing code required for core business logic domain problems such as O/R mapping, value object design, web services coding, security/user/authentication problems, profile mapping, configuration management, etc.
In addition, one of the key frustrations with declarative programming for me has always been the sacrificing of strong types, IDE integration, compile time checking, object oriented principles (try doing inheritance or encapsulation with HTML!), etc. But with technologies such as LINQ we may be at the stage where we don't have to make such a sacrifice and integration of declarative and imperative programming styles can happen in the same environment allowing for both styles to work where appropriate.
Anders Hejlsberg made the claim that the potential productivity improvements from imperative programming are limited - we've essentially already invented all the major programming constructs and he doesn't see much more productivity improvements - we're not going to invent the equivalent of a new type of FOR LOOP - we've got them all.
Declarative programming paradigms have some significant room to improve developer productivity by simply changing the game - instead of making developers focus on statements that construct the logic on how something gets done, declarative programming frameworks can allow programmers to focus on focusing on domain level concerns.
An example of this is LINQ - instead of writing a data access layer for every table, with LINQ you can simply write declarative SQL like syntax. The data access layer is automatically generated for you. In addition, the power you get in the LINQ for declarative SQL like logic means that you can do all sorts of database operations in code that would have taken tonnes of imperative style coding previously:
var wordGroups =
from w in words
group w by w[0] into g
select new { FirstLetter = g.Key, Words = g };
Just imagine the amount of plumbing code you would need to do this in today's .NET or Java frameworks - this is the power of declarative programming styles.
The same is true on the interface side - the power of languages such as HTML, CSS, PHP, Python, etc. are declarative languages that allow the user to use a declarative programming style instead of an imperative set of instructions.
In HTML, the imperative version would be what we used to do with old CGI or classic ASP applications to generate HTML programmatically. It would look something like this:
Response.Write("<html>")
Response.Write("<body>")
' build a table with n rows and m cols
Response.Write("<table>")
for i = 1 to n
Response.Write("<tr>")
for j = 1 to m
Response.Write("<td>")
Response.Write("</td>")
next j
Response.Write("</tr>")
next i
Response.Write("</table>")
etc.
This type of programmatic approach to HTML generation has almost entirely disappeared as declarative programming styles have now allowed interface developers to simply write HTML directly.
Expect more of this declarative style in deeper layers of the architecture and for the syntax of the declarative constructs to support more complicated and domain driven programming patterns. This will hopefully have an impact on the amount of plumbing code required for core business logic domain problems such as O/R mapping, value object design, web services coding, security/user/authentication problems, profile mapping, configuration management, etc.
In addition, one of the key frustrations with declarative programming for me has always been the sacrificing of strong types, IDE integration, compile time checking, object oriented principles (try doing inheritance or encapsulation with HTML!), etc. But with technologies such as LINQ we may be at the stage where we don't have to make such a sacrifice and integration of declarative and imperative programming styles can happen in the same environment allowing for both styles to work where appropriate.
MIX07 Update: LINQ finally brings OR Mapping to .NET
I mentioned in my last post that the recommendation for dynamic data controls was to use the LINQ data source, and that it had better be good in order to handle all the different types of data sources, object collections and heterogeneous data objects we as developers might want to use.
The good news is that the last session I saw today was on LINQ and in general I was very impressed. It's exactly what .NET developers have been missing since ADO.NET came out ages ago. Java has had decent (if not perfect) O/R mapping libraries for years both in commercial products (TopLink for example) and open-source (Hibernate for example). In the .NET world, there have been some modest attempts at open-source O/R mapping layers (NHiperbate, Gentle.NET, etc.) but because ADO had such a stranglehold on the developer culture they never have flourished. ADO.NET as an O/R mapping layer has been very weak since day one - its more of a basic table gateway pattern than a full O/R mapping layer.
Enter LINQ to the rescue. Here is what I saw demonstrated today:
1. In C# 3.0 or VB 9.0 (shouldn't they reconcile these version numbers at some point), declarative SQL like commands are embedded into the language allowing for strongly typed variables, mapped objects and a SQL query type language.
2. LINQ can currently map to objects, SQL Server, and XML. This might be limiting for the non-Microsoft databases (Oracle, ODBC, Sybase, etc.) but I would expect these to be vendor provided at some point in the future.
3. Based on what I saw, performance looks pretty good in terms of the SQL produced by the layer. One of the smart things that the code does is that it doesn't actually execute until the list of objects is iterated allowing for the combination of queries, filters, etc. that doesn't actually hit the database until you grab the final result set. This allows LINQ to optimize joins, sorts, group by, etc. based on all the combined SQL queries you join together. In addition, parent/child relationships and how they are loaded is configurable based on the context, so you can decide whether it makes sense to lazy load or pre-load your child objects based on your performance needs.
4. Object mapping is done as pure value objects which allows for good separation between the data layer and your domain. So for example, you can define an order object which has nothing but properties and then use either XML, SQL or any IEnumerable collection to load a list of those objects.
5. There is an included designer which allows for code generated classes from existing stored procedures, tables, views and functions. Stored procedures can be assigned for selection, inserts, updates and deletes. If a stored procedure isn't specified, then LINQ will generate the SQL for CRUD operations dynamically. From what I could see in the log, the generated SQL was as it would be expected.
The bad news - LINQ is just in Beta 1 and isn't arriving in final until the next version of Studio 2005 (2007? 2008?) In addition, using LINQ will require at least .NET 3.0 and maybe 3.5, so it will require a framework upgrade to use it.
In general, I was pretty impressed - if Microsoft had this type of technology a few years ago then they would have smoked J2EE before it even got started. In general, they have recognized that the road to developer productivity is to simplify the middle tier. LINQ looks to go a long ways to reduce the amount of basic plumbing required to persist data whether its to an object collection, XML file or SQL database.
The good news is that the last session I saw today was on LINQ and in general I was very impressed. It's exactly what .NET developers have been missing since ADO.NET came out ages ago. Java has had decent (if not perfect) O/R mapping libraries for years both in commercial products (TopLink for example) and open-source (Hibernate for example). In the .NET world, there have been some modest attempts at open-source O/R mapping layers (NHiperbate, Gentle.NET, etc.) but because ADO had such a stranglehold on the developer culture they never have flourished. ADO.NET as an O/R mapping layer has been very weak since day one - its more of a basic table gateway pattern than a full O/R mapping layer.
Enter LINQ to the rescue. Here is what I saw demonstrated today:
1. In C# 3.0 or VB 9.0 (shouldn't they reconcile these version numbers at some point), declarative SQL like commands are embedded into the language allowing for strongly typed variables, mapped objects and a SQL query type language.
2. LINQ can currently map to objects, SQL Server, and XML. This might be limiting for the non-Microsoft databases (Oracle, ODBC, Sybase, etc.) but I would expect these to be vendor provided at some point in the future.
3. Based on what I saw, performance looks pretty good in terms of the SQL produced by the layer. One of the smart things that the code does is that it doesn't actually execute until the list of objects is iterated allowing for the combination of queries, filters, etc. that doesn't actually hit the database until you grab the final result set. This allows LINQ to optimize joins, sorts, group by, etc. based on all the combined SQL queries you join together. In addition, parent/child relationships and how they are loaded is configurable based on the context, so you can decide whether it makes sense to lazy load or pre-load your child objects based on your performance needs.
4. Object mapping is done as pure value objects which allows for good separation between the data layer and your domain. So for example, you can define an order object which has nothing but properties and then use either XML, SQL or any IEnumerable collection to load a list of those objects.
5. There is an included designer which allows for code generated classes from existing stored procedures, tables, views and functions. Stored procedures can be assigned for selection, inserts, updates and deletes. If a stored procedure isn't specified, then LINQ will generate the SQL for CRUD operations dynamically. From what I could see in the log, the generated SQL was as it would be expected.
The bad news - LINQ is just in Beta 1 and isn't arriving in final until the next version of Studio 2005 (2007? 2008?) In addition, using LINQ will require at least .NET 3.0 and maybe 3.5, so it will require a framework upgrade to use it.
In general, I was pretty impressed - if Microsoft had this type of technology a few years ago then they would have smoked J2EE before it even got started. In general, they have recognized that the road to developer productivity is to simplify the middle tier. LINQ looks to go a long ways to reduce the amount of basic plumbing required to persist data whether its to an object collection, XML file or SQL database.
Monday, April 30, 2007
MIX07 Update: Dynamic Data Controls
I just attended a session by Polita Paulus and Mahesh Prakriya on Dynamic Data Controls in ASP.NET.
Here is the basic concept behind these controls - take the standard grid controls and instead of configuring them, point the controls instead at a database and they configure themselves.
Polita demonstrated simply taking a page, calling it the name of the table you want to display, and up comes all the controls you need for editing, filtering, deleting, inserting and linking to child/parent tables. Pretty interesting stuff especially for those creating quick one-off web apps. You can extend the controls pretty easily as the dynamic data controls can extend any of the standard ASP.NET data driven controls such as DataGrid, DataList, etc. You can then extend them as normal using data binding, custom formatting, extension through event binding, etc.
The current CTP only supports the SQL Datasource through connection strings. Forget the idea of using these dynamic data controls to build off of objects, web services, XML, etc.
The bad news is that the only recommendation for these types of heterogeneous (e.g. any serious real world scenario these days) provided seems to be to support a LINQ data source, which is Microsoft's new way of doing O/R mapping and language integrated query. The answer to having heterogeneous data sources, classes, business rules, etc. from Polita was wait until you get the LINQ datasource and then use that as the basis for all your data needs.
I'm going to the LINQ data source presentation next, but this seems problematic and limiting as an overall one size fits all strategy. When we use ASP.NET data controls today, we rarely use the Wizard type approach - instead we're doing heavy duty business objects that generate very simply array lists of custom built value objects. This is especially true with distributed scenarios such as web services integration.
But I'm onto the LINQ presentation next, so maybe it's the panacea after all! :)
Here is the basic concept behind these controls - take the standard grid controls and instead of configuring them, point the controls instead at a database and they configure themselves.
Polita demonstrated simply taking a page, calling it the name of the table you want to display, and up comes all the controls you need for editing, filtering, deleting, inserting and linking to child/parent tables. Pretty interesting stuff especially for those creating quick one-off web apps. You can extend the controls pretty easily as the dynamic data controls can extend any of the standard ASP.NET data driven controls such as DataGrid, DataList, etc. You can then extend them as normal using data binding, custom formatting, extension through event binding, etc.
The current CTP only supports the SQL Datasource through connection strings. Forget the idea of using these dynamic data controls to build off of objects, web services, XML, etc.
The bad news is that the only recommendation for these types of heterogeneous (e.g. any serious real world scenario these days) provided seems to be to support a LINQ data source, which is Microsoft's new way of doing O/R mapping and language integrated query. The answer to having heterogeneous data sources, classes, business rules, etc. from Polita was wait until you get the LINQ datasource and then use that as the basis for all your data needs.
I'm going to the LINQ data source presentation next, but this seems problematic and limiting as an overall one size fits all strategy. When we use ASP.NET data controls today, we rarely use the Wizard type approach - instead we're doing heavy duty business objects that generate very simply array lists of custom built value objects. This is especially true with distributed scenarios such as web services integration.
But I'm onto the LINQ presentation next, so maybe it's the panacea after all! :)
MIX07 Update: Feedback on Expression Web
I just attended a seminar on Expression Web 1.0 and while it seems to be definitely a 1.0 product (e.g. nothing too flashy, not that mature quite yet) it has some interesting features.
What makes it cool:
What makes it cool:
- Really strong CSS editing - ability to diagnose inheritance issues, see what styles are applied, etc.
- Refactoring support - easily rename styles, move styles from to page, promote styles from page level to an external style sheet, etc.
- Word like style support. Think of the Word 2003 Format Styles dialog box for HTML. This would make it really easy to apply pre-defined styles especially for non-technical users.
This product seems to be really an HTML editor with very little integration. There was some discussion that this developer/designer integration is coming in the 2.0 product, but I wonder why they couldn't include the same CSS/HTML editing tools in VS 2005 or the next version of it? In my experience, one of the biggest challenges is interface and back-end HTML integration, and having everything in one tool would certainly help on this front. I've had too many experiences where the interface developer creates a beautifully formatted static HTML template and then either one of two things happen: 1) the CSS is so complicated that the ASP.NET team cannot inject their code into it easily or 2) the ASP.NET team ends up creating subtle HTML/CSS bugs when the dynamic code is inserted. I'm not sure how ExpressionWeb really helps in this regard, but I've only so far seen the demo.
Saturday, April 28, 2007
Bringing You The Best from MIX07
I will be flying to the Mix 2007 Conference in Las Vegas on Monday. Stay tuned and I'll post highlights of what I see including pictures, videos, etc.
