Posted by Ramani Sandeep on January 30, 2010
The Exceptional Performance team has identified a number of best practices for making web pages fast. The list includes 34 best practices divided into 7 categories.
- Minimize HTTP Requests
- Reduce DNS Lookups
- Avoid Redirects
- Make Ajax Cacheable
- Post-load Components
- Preload Components
- Reduce the Number of DOM Elements
- Split Components Across Domains
- Minimize the Number of iframes
- Use a Content Delivery Network
- Add an Expires or a Cache-Control Header
- Gzip Components
- Configure ETags
- Flush the Buffer Early
- Use GET for AJAX Requests
- Put Stylesheets at the Top
- Avoid CSS Expressions
- Choose <link> over @import
- Avoid Filters
- Put Scripts at the Bottom
- Remove Duplicate Scripts
- Minimize DOM Access
- Develop Smart Event Handlers
- Reduce Cookie Size
- Use Cookie-free Domains for Components
- Optimize Images
- Optimize CSS Sprites
- Don’t Scale Images in HTML
- Make favicon.ico Small and Cacheable
- Keep Components under 25K
- Pack Components into a Multipart Document
Posted by Ramani Sandeep on January 29, 2010
In this article, I will show you a different way of doing a multi-select in an ASP.NET page. I will keep this article short and sweet so you can just use the code in your applications.
We are going to put our CheckBoxList ASP.NET control inside an HTML div object. I have also added code to support changing the background color of the selected row.
Posted by Ramani Sandeep on January 28, 2010
These concepts can be applied to any Application which is a good candidate for a SaaS application.
- SaaS- Introduction
- SaaS -Challenges
- SaaS -Solution to challenges
A SaaS application can be defines as any “Software deployed as a service and accessed using internet technologies”. In order to realize a SaaS solution (in fact any solution) we need to do two things:
1) Build our application which can be used as a service over internet by different clients. This could range from a programmatic service (accessed programmatically by other softwares) to a stand-alone application used by different clients. This step is involves us to follow certain steps that are different than developing a normal “On-Premise” or simply called a non-SaaS application.
Typically when we develop an application (a non-SaaS application) then we do assume two things:
Application will be installed at client side (e.g., a desktop application) be it through a CD or downloading via internet. This also implies that the client will have to do the maintenance (like upgrading to new version, apply patches, maintain databases etc.) of application even after he has bought the application (not true for Application Service Provider model). This fact is not true in terms of a web application. So we can say that any web application forms a different category of application since it is not installed at client side. But still we cannot call ANY web application a SaaS application.
Application will be served to requirement of a particular client. If another client needs some changes in the application, we will make changes in the application source code and then run another instance of that application for the new client. So in nutshell, we assume that one application is meant for one client only. This assumption is true even for a web application.
Here comes the difference! The core of a SaaS application is based on the opposites of these two (above mentioned) assumptions. The following are assumptions that are true for a SaaS application.
Application will be typically deployed and maintained by a hosting provider. So, clients don’t have to invest in terms of buying hardware resources and employing the IT staff to manage the application. This will be done by the hosting provider.
Application will be accessed by clients using internet. In special cases where a SaaS application is hosted inside the enterprise itself this is not true but still the clients accessing the hosted application will still use internet technologies to access the application.
A single SaaS application (in fact a single database too) serves more than one client having different needs. So the application will be designed in such a way that only a single application instance will be able to provide different functionalities to different clients. This model is more popularly known as Multi-tenant model.
Among these assumptions, the last assumption related to multi-tenancy requires a SaaS application to be architected in a special way keeping in mind about certain aspects of a multi-tenant application. These aspects form the challenges of building a SaaS application and also our next topic of discussion.
2) SaaS world does not end just by building the application that satisfies SaaS characteristics. Deploying a SaaS application forms another set of challenges. Typically a SaaS application is deployed by a SaaS hosting provider and the hosting provider is responsible of maintaining the application. So, not only clients get rid of maintaining the application but also ISVs get rid of that aspect.
Microsoft provides end to end resources in developing and deploying a SaaS application. It provides resources ranging from development frameworks and technical resources used to build and design the application to hosting options that assist in deploying the application.
Posted in Enterprice Applications | Tagged: Saas, Software as a Service | 2 Comments »