Lately we've had a lot of custom web development projects where we are inheriting someone else's code, and we need to take over the project and make updates to it. It's been a bit crazy lately, and sometimes a bit frustrating. I just wanted to start keeping a log of things that other developers do that drive me crazy.
1. Having a method call another method when that's it's only purpose, and the other method isn't called from anywhere else. Something like:
public void RunCode() {
DoSomething();
}
public void DoSomething() {
int a=1;
int b=a+1;
..whatever...
}
If DoSomething() isn't called by anything else, what is it's purpose? Just put everything under RunCode(), no?
2. Making a database call on each row of a repeater (or datalist or gridview or whatever) Something like:
public void MyDataGrid_ItemDataBound(object sender, EventArgs e) {
Label lblFirstName = (Label)e.Item.FindControl("lblFirstName");
int userid = Convert.ToInt32(MyDataGrid.DataKeys[e.Item.ItemIndex]["userid"]);
Member oMember = new Member(userid);
lblFirstName.Text = oMember.FirstName;
}
This might look ok on the surface, but how are we populating the oMember object? We're making a database call right there in the constructor. This is not good practice because as the datagrid grows, every time it loads it will make a database call on every row. If you have many users hitting this page, your database activity could skyrocket unnecessarily. You should try to bind elements of your repeaters and datagrids to a single query that returns all the data you'll need to populate all of the fields, and don't make any database calls in repeating events.
3. SQL Cursors. Ugh, this is a real sore spot for me. I see so many developers using cursors, and 90% of the time, I am able to rewrite the query using a set-based query. I don't know why people use cursors so much. If you are writing a SQL cursor, you should just think it through and see if you can use a set-based query instead.
4. The Session object. This is perhaps the most widely abused object in all of web development. Every book I read about ASP.Net has at least a whole chapter devoted to the session object, its no wonder so many people use it. For one, using the session object causes the web server to have to allocate memory to EACH user who is using the website. When building web based applications, you want to minimize the amount of resources each user takes up on your web server so that you can grow without bringing the server down. People needlessly store variables in the session object so they can use them later instead of intelligently designing their application in such a way so as not to need the session object. On all of our web servers, we have the session object turned off right in the IIS settings and in 12 years I've never had the need to use the session object for anything.
Tuesday, June 2, 2009
Thursday, May 21, 2009
Classic ASP vs. ASP.Net
Just what is the difference between the deceptively similar technologies of ASP and ASPX? What does it say about a website that still uses ASP pages versus one that uses ASPX pages?
In speaking with people every day, it seems this is a pretty common point of confusion. Most people who aren’t developers figure that since “ASP” is so close to “ASPX” that the differences between the two technologies can’t be all that extensive. After all, ASP is technically 75% of ASPX, so upgrading to ASPX will only give 25% more in features or capabilities. When I tell them that the differences between the two technologies are pretty vast, they are often quite surprised.
From a user’s perspective, it is hard to make the differences obvious. After all, a web page that ends with an .asp extension can look pretty similar to a web page that might end with an .aspx extension. The two pages might even have the same functionality and operate in much the same way. So then what is the difference, and why does anyone care?
Back in 1996 (or thereabouts) when Microsoft came out with Active Server Pages (ASP), the web was still in its infancy. ASP was a new technology which solved a lot of the limitations of HTML and CGI, and was very easy to use. Because of this, ASP caught on and became hugely popular. ASP is a server based technology, where the server can perform some function and the client’s browser can just see the output. For example, an ASP page can ask you for some contact information in a form, once you press the Submit button, the ASP code on the server will gather your responses and send out an email, and then generate a message that gets sent to the user saying “Thank you for your submission”. The client entered the data and saw the thank you message, and the server did the work of gathering the data and sending the email.
In 2001, Microsoft released the first version of ASP.NET. Web pages that end with “.aspx” are pages using this newer technology, whereas pages ending with “.asp” still use the older technology, commonly referred to as “Classic ASP”.
One of the biggest problems with Classic ASP was that it was so darned easy to use, anyone with some basic knowledge could create ASP pages. Once ASP started to catch on, anyone and everyone suddenly became a “web developer” and was creating website code which was (and in many cases, still is) being used in production environments all around the globe. As a true developer, this was extremely frustrating, because my profession was being flooded with amateurs and websites were being created left and right using all kinds of poor coding practices.
The other big problem with ASP was that for any task, there are an average of 10 ways to accomplish it. There are very few standards with Classic ASP. Whichever way the web developer felt like solving a problem, that’s how it was done without regard to programming standards, memory utilization, bandwidth, cpu cycles, scalability, etc. And with many ASP developers not being real “web developers”, the code that was being generated and put into production was many times poorly designed and completely inefficient. Out of the 10 ways to write a block of code, it was rare that the “best” option was chosen.
So along comes ASP.NET, a new technology which is very impressive, and very different from Classic ASP. Perhaps the biggest difference between the two is that Classic ASP is an interpreted language, whereas ASP.NET is a compiled language. With Classic ASP, all you needed was FTP access to the web server, and you have all of the code for all of the features of the website. With ASP.NET, if all you have is FTP access, then it is possible you only have access to the front end graphics and web page html code, but none of the actual source code being used to provide the back end features of the site. ASP.NET effectively split the source code which runs on the server from the client code which is sent to the users browser.
The other major advancement with ASP.NET is that it is harder to develop in. Many of those Classic ASP “web developers” were unable to make the transition to the more structured ASP.NET platform. ASP.NET is more of a true programming platform, it is fully object oriented, supports inheritance and delegation and remoting and all of those advanced programming features foreign to Classic ASP developers.
Lastly, perhaps the most important concept regarding ASP.NET is simply that it is a current generation platform for websites. Classic ASP is part of the previous generation of web technologies and has dwindling support from Microsoft and is riddled with security flaws. There are many thousands of developers out there still coding web pages in Classic ASP and selling them to clients who don’t know any better. ASP.NET came out in 2001, which means that it is now 6 years old and for an internet technology, that’s a lifetime. If your programmer is still developing your site in Classic ASP, it’s time to ask him why. ASP.NET is quicker to program in, has much more company and community support, and has a virtually endless amount of 3rd party companies writing software to integrate and improve the features and capabilities of it.
If your website is still using Classic ASP, it is now time to upgrade. If your developer is still suggesting Classic ASP over ASP.NET, it is time to get a new developer.
In speaking with people every day, it seems this is a pretty common point of confusion. Most people who aren’t developers figure that since “ASP” is so close to “ASPX” that the differences between the two technologies can’t be all that extensive. After all, ASP is technically 75% of ASPX, so upgrading to ASPX will only give 25% more in features or capabilities. When I tell them that the differences between the two technologies are pretty vast, they are often quite surprised.
From a user’s perspective, it is hard to make the differences obvious. After all, a web page that ends with an .asp extension can look pretty similar to a web page that might end with an .aspx extension. The two pages might even have the same functionality and operate in much the same way. So then what is the difference, and why does anyone care?
Back in 1996 (or thereabouts) when Microsoft came out with Active Server Pages (ASP), the web was still in its infancy. ASP was a new technology which solved a lot of the limitations of HTML and CGI, and was very easy to use. Because of this, ASP caught on and became hugely popular. ASP is a server based technology, where the server can perform some function and the client’s browser can just see the output. For example, an ASP page can ask you for some contact information in a form, once you press the Submit button, the ASP code on the server will gather your responses and send out an email, and then generate a message that gets sent to the user saying “Thank you for your submission”. The client entered the data and saw the thank you message, and the server did the work of gathering the data and sending the email.
In 2001, Microsoft released the first version of ASP.NET. Web pages that end with “.aspx” are pages using this newer technology, whereas pages ending with “.asp” still use the older technology, commonly referred to as “Classic ASP”.
One of the biggest problems with Classic ASP was that it was so darned easy to use, anyone with some basic knowledge could create ASP pages. Once ASP started to catch on, anyone and everyone suddenly became a “web developer” and was creating website code which was (and in many cases, still is) being used in production environments all around the globe. As a true developer, this was extremely frustrating, because my profession was being flooded with amateurs and websites were being created left and right using all kinds of poor coding practices.
The other big problem with ASP was that for any task, there are an average of 10 ways to accomplish it. There are very few standards with Classic ASP. Whichever way the web developer felt like solving a problem, that’s how it was done without regard to programming standards, memory utilization, bandwidth, cpu cycles, scalability, etc. And with many ASP developers not being real “web developers”, the code that was being generated and put into production was many times poorly designed and completely inefficient. Out of the 10 ways to write a block of code, it was rare that the “best” option was chosen.
So along comes ASP.NET, a new technology which is very impressive, and very different from Classic ASP. Perhaps the biggest difference between the two is that Classic ASP is an interpreted language, whereas ASP.NET is a compiled language. With Classic ASP, all you needed was FTP access to the web server, and you have all of the code for all of the features of the website. With ASP.NET, if all you have is FTP access, then it is possible you only have access to the front end graphics and web page html code, but none of the actual source code being used to provide the back end features of the site. ASP.NET effectively split the source code which runs on the server from the client code which is sent to the users browser.
The other major advancement with ASP.NET is that it is harder to develop in. Many of those Classic ASP “web developers” were unable to make the transition to the more structured ASP.NET platform. ASP.NET is more of a true programming platform, it is fully object oriented, supports inheritance and delegation and remoting and all of those advanced programming features foreign to Classic ASP developers.
Lastly, perhaps the most important concept regarding ASP.NET is simply that it is a current generation platform for websites. Classic ASP is part of the previous generation of web technologies and has dwindling support from Microsoft and is riddled with security flaws. There are many thousands of developers out there still coding web pages in Classic ASP and selling them to clients who don’t know any better. ASP.NET came out in 2001, which means that it is now 6 years old and for an internet technology, that’s a lifetime. If your programmer is still developing your site in Classic ASP, it’s time to ask him why. ASP.NET is quicker to program in, has much more company and community support, and has a virtually endless amount of 3rd party companies writing software to integrate and improve the features and capabilities of it.
If your website is still using Classic ASP, it is now time to upgrade. If your developer is still suggesting Classic ASP over ASP.NET, it is time to get a new developer.
Thursday, April 9, 2009
Outsource Your Web Development.... to an American Company
Outsourcing doesn't necessarily mean foreign countries
When choosing an approach for your web development needs, certainly one of the major issues to evaluate is outsourcing. If you are looking to outsource because of a lack of in-house talent or because you are looking to save money or for other reasons, there's a lot to consider. Here we explore some of these issues with some specific recommendations on how to keep the money right here in America.
Reasons to Outsource: There are many reasons to outsource, the top 5 that I've heard are below:
1. You do not have the web development talent in-house to accomplish your needs. This is the traditional reason most companies rely on consultants to perform projects that require a higher level of skill than they might have in-house.
2. You are looking to cut costs. Sure consultants may be expensive, but they are usually only used for short periods of time which makes them cheaper than hiring employees.
3. You are looking to cut staff. Maintaining staff can be very costly. Hiring a web developer to work for you full time will cost more than just his/her salary. You have to factor in the cost of the payroll taxes, healthcare, training, plus the cost of managing this person and making sure they grow and are happy and so forth.
4. You are looking for more stability. If you have someone in-house, what happens if they quit? How do you transfer their knowledge to someone else, especially if you don't hire someone new right away.
5. You don't have enough work to keep someone occupied for 40 hours per week.
Whatever the reason, in a lot of cases outsourcing can make a lot of sense. Now comes the enlightening part, you don't have to outsource to a company in a foreign country. There's plenty of talent here in the USA and more often than not, its better than what you would get from a foreign country.
If you are looking at foreign companies for outsourcing, consider the following points:
1. Distance DOES matter.
When the people you are dealing with are far away, they might not be working at the same time zone as your own business hours. This might mean that if you have a problem, you have to wait until the next day to get it resolved if you are communicating via email. This can become increasingly frustrating when they don't get it right the first time, because now you have to wait even longer for something to be changed or fixed.
2. Language barriers can hurt your project.
It is important for the technical people who are working on your website to speak your language fluently. If they don't, miscommunications can occur fairly easily and impact your project's budget and timeline. The other reason language is important is because the developer will most likely be the person typing in the content for your website. One of the most overlooked pieces of content is your site's error messages. If your user mistypes their password, you want them to get a friendly, readable error message, not something like "User input not password" (actual example). These are often overlooked as clients are proofreading their website.
3. Price is cheaper, but...
Don't forget the old saying that you get what you pay for. Also, you are usually going to be paying an hourly rate, so if it takes them 4 times as long as someone who is in your same timezone and speaks your language and has your same cultural background and will do it right the first time, then you're really not saving much if anything at all.
4. Contingency? What contingency?
You need to be prepared for the possibility that the project won't go the way you intended and that you will now have to turn to another company to finish the work. So now the money you saved is now completely obliterated and you have now lost money.
Fortunately, outsourcing doesn't necessarily mean that you have to deal with these issues. You could outsource your web development to an American company and avoid just about all of the issues associated with working with people overseas. Outsourcing allows you to expand and contract based on your needs, without having to hire or lay off people. If you do choose to outsource your web development to an American company, make sure to ask if they use developers from overseas. Also, make sure they have been in business for a while (over 10 years is recommended), and make sure they fully understand your business and guarantee their work.
If you're looking for a recommendation, Business Edge Services & Technologies is a New Jersey based corporation specializing in Microsoft centric web development and has been in business for over 12 years. Check them out at http://www.busedge.com.
When choosing an approach for your web development needs, certainly one of the major issues to evaluate is outsourcing. If you are looking to outsource because of a lack of in-house talent or because you are looking to save money or for other reasons, there's a lot to consider. Here we explore some of these issues with some specific recommendations on how to keep the money right here in America.
Reasons to Outsource: There are many reasons to outsource, the top 5 that I've heard are below:
1. You do not have the web development talent in-house to accomplish your needs. This is the traditional reason most companies rely on consultants to perform projects that require a higher level of skill than they might have in-house.
2. You are looking to cut costs. Sure consultants may be expensive, but they are usually only used for short periods of time which makes them cheaper than hiring employees.
3. You are looking to cut staff. Maintaining staff can be very costly. Hiring a web developer to work for you full time will cost more than just his/her salary. You have to factor in the cost of the payroll taxes, healthcare, training, plus the cost of managing this person and making sure they grow and are happy and so forth.
4. You are looking for more stability. If you have someone in-house, what happens if they quit? How do you transfer their knowledge to someone else, especially if you don't hire someone new right away.
5. You don't have enough work to keep someone occupied for 40 hours per week.
Whatever the reason, in a lot of cases outsourcing can make a lot of sense. Now comes the enlightening part, you don't have to outsource to a company in a foreign country. There's plenty of talent here in the USA and more often than not, its better than what you would get from a foreign country.
If you are looking at foreign companies for outsourcing, consider the following points:
1. Distance DOES matter.
When the people you are dealing with are far away, they might not be working at the same time zone as your own business hours. This might mean that if you have a problem, you have to wait until the next day to get it resolved if you are communicating via email. This can become increasingly frustrating when they don't get it right the first time, because now you have to wait even longer for something to be changed or fixed.
2. Language barriers can hurt your project.
It is important for the technical people who are working on your website to speak your language fluently. If they don't, miscommunications can occur fairly easily and impact your project's budget and timeline. The other reason language is important is because the developer will most likely be the person typing in the content for your website. One of the most overlooked pieces of content is your site's error messages. If your user mistypes their password, you want them to get a friendly, readable error message, not something like "User input not password" (actual example). These are often overlooked as clients are proofreading their website.
3. Price is cheaper, but...
Don't forget the old saying that you get what you pay for. Also, you are usually going to be paying an hourly rate, so if it takes them 4 times as long as someone who is in your same timezone and speaks your language and has your same cultural background and will do it right the first time, then you're really not saving much if anything at all.
4. Contingency? What contingency?
You need to be prepared for the possibility that the project won't go the way you intended and that you will now have to turn to another company to finish the work. So now the money you saved is now completely obliterated and you have now lost money.
Fortunately, outsourcing doesn't necessarily mean that you have to deal with these issues. You could outsource your web development to an American company and avoid just about all of the issues associated with working with people overseas. Outsourcing allows you to expand and contract based on your needs, without having to hire or lay off people. If you do choose to outsource your web development to an American company, make sure to ask if they use developers from overseas. Also, make sure they have been in business for a while (over 10 years is recommended), and make sure they fully understand your business and guarantee their work.
If you're looking for a recommendation, Business Edge Services & Technologies is a New Jersey based corporation specializing in Microsoft centric web development and has been in business for over 12 years. Check them out at http://www.busedge.com.
Friday, April 3, 2009
Do YOU GotCrowd?
I created this cool video/media sharing website. We have investors and a few partners and it will be the next big thing (hopefully!). If you have a talent, you should really check it out.
gotcrowd.com
Do YOU GotCrowd?
gotcrowd.com
Do YOU GotCrowd?
Subscribe to:
Posts (Atom)