In current project, I use a lot of out-of-band AJAX requests. In an out-of-band request, individual request does not flow into its own standard ASP.NET page life-cycle but instead calls another page and follows the flow of the corresponding page.
There has been a growing debate regarding the pros and cons of out-of-band request. In the cons side, the out-of-band request breaks ASP.NET model. Developers do not code in the usual manner they are used to do for years. Instead they have to create another page to server AJAX request. In my company, we call this page as 'handlers' or 'AJAX handlers', or simply 'AJAX servers' to less-technical people :) Whatever the name is, programming this handler is usually more raw and messy since we have to let go some nice ASP.NET features like ViewState that makes web programming easier and more intuitive (more like an event-driven programming).
In the pros side, the out-of-band request is more efficient since it only carries data that the handler need. It does not need to carry hefty payload from ViewState. The server side processing is also more efficient since it does not to reconstruct the state of the whole control hierarchy. Moreover, the handler also promote reusability and clear separation of responsibility, since a handler's only responsibility is to provide correct response based on received request. It does not need to know how the UI is rendered. Thus a handler can be used by several UIs.
So which kind of request to choose? It really depends on how you structure the content of the page. In a common ASP.NET project where one screen in the specification translates into one ASPX page, then you can safely avoid out-of-band request. Microsoft ATLAS does this. The programming model does not change dramatically.
However, the moment you want to promote reusability, you will start using ASCX (user controls) inside the ASPX and later, to promote even further reusability, use custom controls. In this case, the out-of-band request is a better option (and perhaps the only way to implement AJAX request). Consider that it is too expensive to reconstruct the whole page (and reinstantiate all user controls/custom controls in the page) only to serve a single AJAX request.
Saturday, February 25, 2006
Thursday, February 23, 2006
Visual Studio 2005 Licensing
This afternoon, we went to Microsoft office to have a discussion with Rashish Pandey, Product Marketing Manager (Developer Tools) for Microsoft Singapore. The agenda of the meeting is to discuss various options to buy Visual Studio 2005 for our plan to migrate to Visual Studio 2005.
Noted below are what I extracted from the discussion plus a few hours of surfing Microsoft site to seek further clarification. Bear in mind that those notes are my personal opinion and should not be taken as it is. If you are in the position of evaluating VS.NET 2005 licensing as well, I suggest to start from Microsoft site then seek more explanation from Microsoft representative.
To begin with, Visual Studio 2005 licensing scheme is per user/developer basis, not per installation basis. Simply speaking, if there are 20 developers, then we need 20 licenses to adequately cover all the usage, regardless on how many instances of Visual Studio is installed.
VS.NET 2005 comes in 4 editions: Express, Standard, Professional, and Team System. Visit Visual Studio 2005 Product Feature Comparisons for more comprehensive comparison among those editions. In my opinion, the Express and Standard editions are more suitable for hobbyist or individual developer working at home rather than for enterprise use. Both editions come bundled with SQL Express Edition, so we know how Microsoft positions these editions. Surprisingly, both Express and Standard editions support SQL Reporting Service, so theoretically they can be used to create and publish reports to SQL Reporting Service.
Beginning from the Professional Edition and up, there are SQL Server 2005 integration and XML/XSLT editor, two major features which are missing in the first two editions. Microsoft positions the Professional edition for individual developers, but I believe in practice due to overwhelming features and high price tag of the Team System edition, most companies will stick to the Professional edition.
In the high end side of the product line is Visual Studio Team System, which consists of 4 products offered in 5 different packaging. The products are Architect, Developer and Team Tester, each one targets specific role in the software development lifecycle, plus the Team Foundation Server to enable collaboration among those roles. You can buy the Team System Suite which consists of 3 Team System, one copy for each role, bundled together. The Team Foundation Server is sold separately and will be available in March 2006.
Users connecting to the Team Foundation Server needs a license known as CAL (Client Access License). Every individual Visual Studio Team System edition comes with 1 CAL, which means the user automatically has license to access the Team Foundation Server. The Professional edition does not include CAL, so you need to buy a CAL if you want the developer using the Professional Edition to use the Team Foundation Server.
Microsoft has a scheme called Software Assurance, which entitles you for free upgrade to the next version of the product as long as you has a valid subscription for the corresponding product. In VS.NET 2005, MSDN Subscription is a superset of Software Assurance. Other than offering free upgrade to the future release of Visual Studio, it also gives you phone-based support, newsgroup support, and a bundle of Microsoft operating systems, server products, betas, etc. licensed for development and testing only (Developer Edition). In my view, this is the most important benefit of MSDN Subscription. Developers can try various Microsoft products and run their applications in various environments without needing to buy licenses.
The Team System edition with MSDN Subscription bundle comes with a 5-user-limited edition of the Team Foundation Server called 'Workgroup Foundation Server'. This product is functionally equivalent to the Team Foundation Server, but it is limited for 5 users only. IMPORTANT NOTE: You cannot buy extra CALs to increase beyond 5 users.
Finally, there is a downgrade licensing scheme available for VS.NET. It means you can buy VS.NET 2005 to license your VS.NET 2003 installation. It sounds uncommon, but it might be useful in the situation where you still have projects in VS.NET 2003, not quite ready to jump to VS.NET 2005, and need more licenses to cover additional developers.
Noted below are what I extracted from the discussion plus a few hours of surfing Microsoft site to seek further clarification. Bear in mind that those notes are my personal opinion and should not be taken as it is. If you are in the position of evaluating VS.NET 2005 licensing as well, I suggest to start from Microsoft site then seek more explanation from Microsoft representative.
To begin with, Visual Studio 2005 licensing scheme is per user/developer basis, not per installation basis. Simply speaking, if there are 20 developers, then we need 20 licenses to adequately cover all the usage, regardless on how many instances of Visual Studio is installed.
VS.NET 2005 comes in 4 editions: Express, Standard, Professional, and Team System. Visit Visual Studio 2005 Product Feature Comparisons for more comprehensive comparison among those editions. In my opinion, the Express and Standard editions are more suitable for hobbyist or individual developer working at home rather than for enterprise use. Both editions come bundled with SQL Express Edition, so we know how Microsoft positions these editions. Surprisingly, both Express and Standard editions support SQL Reporting Service, so theoretically they can be used to create and publish reports to SQL Reporting Service.
Beginning from the Professional Edition and up, there are SQL Server 2005 integration and XML/XSLT editor, two major features which are missing in the first two editions. Microsoft positions the Professional edition for individual developers, but I believe in practice due to overwhelming features and high price tag of the Team System edition, most companies will stick to the Professional edition.
In the high end side of the product line is Visual Studio Team System, which consists of 4 products offered in 5 different packaging. The products are Architect, Developer and Team Tester, each one targets specific role in the software development lifecycle, plus the Team Foundation Server to enable collaboration among those roles. You can buy the Team System Suite which consists of 3 Team System, one copy for each role, bundled together. The Team Foundation Server is sold separately and will be available in March 2006.
Users connecting to the Team Foundation Server needs a license known as CAL (Client Access License). Every individual Visual Studio Team System edition comes with 1 CAL, which means the user automatically has license to access the Team Foundation Server. The Professional edition does not include CAL, so you need to buy a CAL if you want the developer using the Professional Edition to use the Team Foundation Server.
Microsoft has a scheme called Software Assurance, which entitles you for free upgrade to the next version of the product as long as you has a valid subscription for the corresponding product. In VS.NET 2005, MSDN Subscription is a superset of Software Assurance. Other than offering free upgrade to the future release of Visual Studio, it also gives you phone-based support, newsgroup support, and a bundle of Microsoft operating systems, server products, betas, etc. licensed for development and testing only (Developer Edition). In my view, this is the most important benefit of MSDN Subscription. Developers can try various Microsoft products and run their applications in various environments without needing to buy licenses.
The Team System edition with MSDN Subscription bundle comes with a 5-user-limited edition of the Team Foundation Server called 'Workgroup Foundation Server'. This product is functionally equivalent to the Team Foundation Server, but it is limited for 5 users only. IMPORTANT NOTE: You cannot buy extra CALs to increase beyond 5 users.
Finally, there is a downgrade licensing scheme available for VS.NET. It means you can buy VS.NET 2005 to license your VS.NET 2003 installation. It sounds uncommon, but it might be useful in the situation where you still have projects in VS.NET 2003, not quite ready to jump to VS.NET 2005, and need more licenses to cover additional developers.
Thursday, February 16, 2006
Separation of Roles
As a software developer, sometimes I come into situation when I have to code in all layers/tiers of the application. In the web development context using Microsoft technology (where most of my experience is in), it means writing code in Javascript, deal with divs and tables in HTML, write business logic in C# and all the way down to writing stored procedures. Working in this manner is nothing bad, since I can get the full picture of the process, from the moment the user input the data to the data being saved in the database. Quite surprisingly, this happens in most of the companies that I have worked for, regardless of the project size.
The multi-responsibility role that a developer has to bear is quite common nowadays. Take a peak at the online job posts and you can easily notice that most developer job openings always look for the all-rounder candidate who can do from A-Z and has experience working in all tiers.
I agree in a small development project, we don't have the luxury of proper design and planning. Thus work items are actually screens from a prototype, and often a single developer is assigned to code the screen from UI tier to database tier. However, when the project gets larger and more developers join in, I suggest developers are split into several distinct roles:
1. UI/Front-end developers. These people are most experienced in event-driven nature of UI programming. In the web development projects, these are the type of developers who are fluent in client side scripting, prefer to hand code HTML code, fully understand the difference between a listbox and a dropdownlist, etc.
2. Middle tier developers. These people deals with business object classes, web services, and data access layer classes.
3. Database developers. They live in different side of the world than the other two types of developers. They speak only in TSQL. Their tools is Enterprise Manager and Query Analyzer instead of Visual Studio.
Those projects who have clear separation of roles enjoy the following benefits (which are derived from my experience working in such project):
1. The right man on the right place. Almost like a cliche, but it is true. Most developers will say 'yes' they can work in every tier, but in fact they are more effective working in one tier compared to other tiers. A developer's past experience can tell much about this. Face this fact: developers who write well in object-oriented Javascript may not effectively write a business object classes in C#, or even write a sophisticated stored procedure in TSQL with proper error handling management.
2. Promote separation of responsibility on each tier, an important concept in object orientation. Alhough only by a proper design a truly separation of responsibility can be achieved, having different developers on each tier will ensure there is no code that sit in the wrong place because they are written by different developers.
3. Each tier can be planned and progressed independently. For example, after the database design is done, the database developers can start working on the stored procedures. Meanwhile, once the class diagram is done, the middle tier guys can start creating classes. Usually, the UI developers will start later and finish later as they have to work on the prototype and go through iterative release-feedback process with the client.
4. Easier to implement programming standard and convention. Take this example: Naming convention for strongly-typed C# is different from loosely-typed Javascript. Syntax in TSQL are more effective in resultset, while C# developers are more used to loops.
5. Promote communication. In my previous company, developers on the same role sit next to each other on the same corner, thus promoting communication and code reuse among them. In a 20-people team which everybody works on the stored procedures, not everybody know what other people have done.
As I mention earlier, the separation of roles may not be suitable for a small project where resource is limited. It is also not an all-good solution. The following are some disadvantages:
1. Developers may know understand the whole picture as they only work in one tier instead of all tiers.
2. Harder to track bugs and performance issues that run across tiers and other performance issues because of point no 1. If bug tracking is not manage properly, developers may start finger pointing on each other.
The multi-responsibility role that a developer has to bear is quite common nowadays. Take a peak at the online job posts and you can easily notice that most developer job openings always look for the all-rounder candidate who can do from A-Z and has experience working in all tiers.
I agree in a small development project, we don't have the luxury of proper design and planning. Thus work items are actually screens from a prototype, and often a single developer is assigned to code the screen from UI tier to database tier. However, when the project gets larger and more developers join in, I suggest developers are split into several distinct roles:
1. UI/Front-end developers. These people are most experienced in event-driven nature of UI programming. In the web development projects, these are the type of developers who are fluent in client side scripting, prefer to hand code HTML code, fully understand the difference between a listbox and a dropdownlist, etc.
2. Middle tier developers. These people deals with business object classes, web services, and data access layer classes.
3. Database developers. They live in different side of the world than the other two types of developers. They speak only in TSQL. Their tools is Enterprise Manager and Query Analyzer instead of Visual Studio.
Those projects who have clear separation of roles enjoy the following benefits (which are derived from my experience working in such project):
1. The right man on the right place. Almost like a cliche, but it is true. Most developers will say 'yes' they can work in every tier, but in fact they are more effective working in one tier compared to other tiers. A developer's past experience can tell much about this. Face this fact: developers who write well in object-oriented Javascript may not effectively write a business object classes in C#, or even write a sophisticated stored procedure in TSQL with proper error handling management.
2. Promote separation of responsibility on each tier, an important concept in object orientation. Alhough only by a proper design a truly separation of responsibility can be achieved, having different developers on each tier will ensure there is no code that sit in the wrong place because they are written by different developers.
3. Each tier can be planned and progressed independently. For example, after the database design is done, the database developers can start working on the stored procedures. Meanwhile, once the class diagram is done, the middle tier guys can start creating classes. Usually, the UI developers will start later and finish later as they have to work on the prototype and go through iterative release-feedback process with the client.
4. Easier to implement programming standard and convention. Take this example: Naming convention for strongly-typed C# is different from loosely-typed Javascript. Syntax in TSQL are more effective in resultset, while C# developers are more used to loops.
5. Promote communication. In my previous company, developers on the same role sit next to each other on the same corner, thus promoting communication and code reuse among them. In a 20-people team which everybody works on the stored procedures, not everybody know what other people have done.
As I mention earlier, the separation of roles may not be suitable for a small project where resource is limited. It is also not an all-good solution. The following are some disadvantages:
1. Developers may know understand the whole picture as they only work in one tier instead of all tiers.
2. Harder to track bugs and performance issues that run across tiers and other performance issues because of point no 1. If bug tracking is not manage properly, developers may start finger pointing on each other.
Wednesday, February 15, 2006
GPL vs LPGL
The company I am working on is heading for the annual audit process. Apart from the security and compliance issues that the internal auditor needs to find, the auditors will find whether we have unlicensed and underlicensed applications. Underlicense situation will rise if the current licenses we have do not adequately cover all the software installation or deployment.
In our discussion, we come across several licensing schemes and surprisingly nobody has a clear understanding about them. Two most prominent licensing schemes: GPL (General Public License) and LGPL (Lesser GPL) seems to confuse many as they look similar but actually are very different.
The GPL license allows free use and modification of the software, as long as we credited back to the original author and release the application (that utilizes the GPL'ed software) as open source. This is a major road block for commercial project to use GPL'ed software.
On the other hand, the LGPL license does not require the application to be distributed as open source and thus can be used in a commercial application. This licensing is increasingly popular among software libraries. However, there is an extra complication: any modification or addition (and even wrapper) to the LGPL'ed library must also be released under LGPL/GPL scheme. Other parts of the software which do not use the library are not affected and therefore can be released under any licensing scheme. Therefore, in practice, if we create a wrapper class of the LGPL'ed library, or create a class that inherits from the library, then our library code must be released under LGPL scheme. In the .NET project, as a class library is compiled into an assembly, then the assembly and its source code must be released under LGPL. Not a pretty situation for a commercial project!
In summary, whenever your software project needs to use a third-party library/application, make sure you understand its licensing very well and judge carefully whether it fits with the licensing of your software.
In our discussion, we come across several licensing schemes and surprisingly nobody has a clear understanding about them. Two most prominent licensing schemes: GPL (General Public License) and LGPL (Lesser GPL) seems to confuse many as they look similar but actually are very different.
The GPL license allows free use and modification of the software, as long as we credited back to the original author and release the application (that utilizes the GPL'ed software) as open source. This is a major road block for commercial project to use GPL'ed software.
On the other hand, the LGPL license does not require the application to be distributed as open source and thus can be used in a commercial application. This licensing is increasingly popular among software libraries. However, there is an extra complication: any modification or addition (and even wrapper) to the LGPL'ed library must also be released under LGPL/GPL scheme. Other parts of the software which do not use the library are not affected and therefore can be released under any licensing scheme. Therefore, in practice, if we create a wrapper class of the LGPL'ed library, or create a class that inherits from the library, then our library code must be released under LGPL scheme. In the .NET project, as a class library is compiled into an assembly, then the assembly and its source code must be released under LGPL. Not a pretty situation for a commercial project!
In summary, whenever your software project needs to use a third-party library/application, make sure you understand its licensing very well and judge carefully whether it fits with the licensing of your software.
Friday, February 10, 2006
A del.icio.us way to search
A simple idea turned into a great web application, that's what I like about del.icio.us
Del.icio.us is an online bookmark repository. Instead of adding your favourite urls to the browser's bookmark, you can post them to Del.icio.us and access them from any computers on the web. Simple concept, but that's not all. You can also search what other people bookmark and see how popular those bookmarks are.
Again, the power of virtual community is used here to leverage the usefulness of the site. The more people use Del.icio.us to post their bookmarks, the bigger the bookmark repository, and more useful search result can be returned. I believe Del.icio.us is waiting for that critical mass moment to happens, before they can truly reap the profit of running this service.
Alas, Del.icio.us' infrastructure doesn't seem to cope well with the site growth. In the past few weeks, the site was down several times due to power failures in their colocation servers. These issues should be taken care seriously before people giving up and turning to alternative sites.
Infrastructure issue aside, it is a great experience to use Del.icio.us on my daily surfing activity. I use the site to:
- Manage my bookmarks. I surf at work and home, so having a single bookmark repository is really helpful. Assigning tags also helps me to categorize the bookmarks based on the keyword, which I find is easier to remember than file system-like structure in the classic bookmark system.
- Share my technical bookmarks to my colleagues more easily. Just point them to my Del.icio.us url. No need to cut and paste the link in the email or IM. However, privacy is a big concern here because they can also get my personal bookmarks
- Do search on the internet. See what other people bookmarking! Think Del.icio.us as an alternative to Google search.
- Learn about the web interface... simple but powerful. More about this in the next post.
Other that privacy issue, my other concern is if some people start to misuse the system by posting urls for advertising rather than their actual bookmarks. More and more people post the same url, the more popular the bookmark is. This will taint the usefulness of the site as an alternative way to search the Internet.
New Year, New Life, New Resolution
One of my new year's resolution is to blog more actively. Looking back at my first post in April 2005, it was 10 months ago and there is only 5 messages so far. What a shame... I should do better this year!
In 2006, I also start a new life, as a married man to a lovely wife Josepha. It has been about a month since we moved from Novena to an HDB flat in Braddell. Initially, the flat was pretty empty. Only basic furnitures like bed, L-shaped sofa, washing machines and fridges are left by the owner and previous tenant. But after a few trips to IKEA shop, we finally furnished our unit to a comfortable state.
Now, I have a place to put the laptop and YES, we have a broadband Internet connection at home. So let's start blogging :)
In 2006, I also start a new life, as a married man to a lovely wife Josepha. It has been about a month since we moved from Novena to an HDB flat in Braddell. Initially, the flat was pretty empty. Only basic furnitures like bed, L-shaped sofa, washing machines and fridges are left by the owner and previous tenant. But after a few trips to IKEA shop, we finally furnished our unit to a comfortable state.
Now, I have a place to put the laptop and YES, we have a broadband Internet connection at home. So let's start blogging :)
Subscribe to:
Posts (Atom)
