I have been working on a couple ASP.NET applications. I have been using AJAX.NET with the applications. AJAX.Net offers an easy way to include ajax into you web pages.
One thing Dan and I came across as we were using the UpdatePanel of the AJAX.NET framework was for some reason it would not work with with RadioButtonList (RBL) control. We had no problems getting async post backs to work on control changes of DropDownList, CheckBox, and Button controls, but for some reason the RBL control doesn't quite work right.
I could go on to explain why but I think this post does the best job of describing the problem and the solution.... http://smarx.com/posts/the-case-of-the-radiobuttonlist-half-trigger.aspx
Other than that problem the AJAX framework has worked well.
Tuesday, July 31, 2007
Monday, July 30, 2007
Smallville
So over the 4th of July weekend my Dad sort of got me hooked on Smallville.
Smallville is the TV show about how Superman became Superman, along with how Lex Luther became evil. I have only seen seasons 1 through 4 and I have to say that for the most part I really like the show.
What pulls me to the show is really the concept. I like the idea of seeing Clark Kent learn about his new abilities and how they relate to the people around them. I think the way the writers develop the characters is really good too. The other thing that is done well is the music selection. The use of new music along with older music and per haps songs that are not very common but yet go with mood of the show.
Another interesting aspect is how they bring in outsiders that we all know, like the Flash, or other Justice League of America heroes. Plus the use of one liners in the show are just great. My favorite so far is when Lex is returning from Egypt after finding the first stone, and Clark is flying to the jet to recover it, and the pilots see him on radar and give the old, "Is it a bird? Is it a plane?" line.
I actually created a Smallville Season One playlist on Yahoo Music.
I am looking forward to watching season five, but since my Dad has not finished it yet I won't get it until he is done. Season Six will be released on September 18th I think.
If you are a fan of Superman I would say you should check it out.
Smallville is the TV show about how Superman became Superman, along with how Lex Luther became evil. I have only seen seasons 1 through 4 and I have to say that for the most part I really like the show.
What pulls me to the show is really the concept. I like the idea of seeing Clark Kent learn about his new abilities and how they relate to the people around them. I think the way the writers develop the characters is really good too. The other thing that is done well is the music selection. The use of new music along with older music and per haps songs that are not very common but yet go with mood of the show.
Another interesting aspect is how they bring in outsiders that we all know, like the Flash, or other Justice League of America heroes. Plus the use of one liners in the show are just great. My favorite so far is when Lex is returning from Egypt after finding the first stone, and Clark is flying to the jet to recover it, and the pilots see him on radar and give the old, "Is it a bird? Is it a plane?" line.
I actually created a Smallville Season One playlist on Yahoo Music.
I am looking forward to watching season five, but since my Dad has not finished it yet I won't get it until he is done. Season Six will be released on September 18th I think.
If you are a fan of Superman I would say you should check it out.
Monday, July 23, 2007
Subversion Repository
When developing software you need to store your code in a repository that will maintain versions, and also allow for merging and branching of the code base. At work we use Subversion.
When we set up a project for a client we try to use a standard directory structure. We do this so that no matter what project we are working on we can easily move to another project to do work if the need arises. The structure looks like the following...
When we set up a project for a client we try to use a standard directory structure. We do this so that no matter what project we are working on we can easily move to another project to do work if the need arises. The structure looks like the following...
- client name
- Project One
- Trunk
- bin
- docs
- lib
- src
- Tags
- Tag_1
- branches
- branch_1
- Project Two
Tuesday, July 17, 2007
Reporting Services
As a technical lead there are some advantages and draw backs to the position. The advantages are you get to always learn new things, and if they interest you, you can really explore the topic. A draw back is there is so much to know, you can't know it all and with topics that don't excite you, in my case things like databases, and reporting, you tend to only skim the the talking points.
So, where I work, we have a few clients that have reporting needs, and I usually recommend or push SQL Server Reporting Services if the client is a .Net Framework user.
Why do I push it?
Well, I really don't have a great reason other than it ties nicely to SQL Server and the .Net Framework. As a tech lead I usually can make this decision and let the developers figure out the really in depth details. Sounds great I can continue to learn what interest me while the work still gets done.
Here's the catch. When people ask me questions about Reporting Services or the developers ask questions or tell me an answer to a question I might have, I have know way of knowing what is correct. I trust my developers but at the same time people make mistakes, take short cuts, or don't follow best practices. So for the next few weeks I will be on a crash course of SQL Server Reporting Services learning.
If anyone out there knows of good resources like books, web casts, samples or whatever please let me know.
So, where I work, we have a few clients that have reporting needs, and I usually recommend or push SQL Server Reporting Services if the client is a .Net Framework user.
Why do I push it?
Well, I really don't have a great reason other than it ties nicely to SQL Server and the .Net Framework. As a tech lead I usually can make this decision and let the developers figure out the really in depth details. Sounds great I can continue to learn what interest me while the work still gets done.
Here's the catch. When people ask me questions about Reporting Services or the developers ask questions or tell me an answer to a question I might have, I have know way of knowing what is correct. I trust my developers but at the same time people make mistakes, take short cuts, or don't follow best practices. So for the next few weeks I will be on a crash course of SQL Server Reporting Services learning.
If anyone out there knows of good resources like books, web casts, samples or whatever please let me know.
Monday, July 16, 2007
But it Worked in QA
As a developer how many time have you heard "But it works in QA.", after a bug was found in production.
When a bug can't be reproduced in QA usually there a few reasons why.
The first reason could be that the version of application running in QA is different than in production. This is an easy test and if it is the case then then then next time you do a production promotion the bug should go away.
Another possibility for bugs in production and not QA are configuration settings of the application. Things like connection strings, web service urls and any other custom settings might not be configured properly for the production environment. Again this is an easy thing to check and correct.
These two solutions will probably fix most of the problems when a bug is not reproducible in a QA environment. But what do you do if it doesn't?
This was the case I just recently had. The client stated their users were reporting errors and they were having trouble reproducing them in their QA environment. So I started to look into the problem and saw the actual error on a user machine. The error the users were running into was a low memory error. The error was surprising since our development machines and QA machines were not having the same problem. Turns out the production devices were running on only 512mb of ram and the QA machines has 1gb. See the production devices need to be very strong and unbreakable, so to save money they purchased the base unit without the memory upgrade. Since in testing the devices aren't in the field they were using a different device, however thought the specs to be the same.
Errors like this is why it is very important to have QA and Production environments the same. Hardware, software running, and permissions should all be the same so that applications will react the same in both environments. There may be times that you can't set up both the same due to cost, time or whatever reason, but these differences should be documented and when testing the testers should try to determine the effects the differences will have.
When a bug can't be reproduced in QA usually there a few reasons why.
The first reason could be that the version of application running in QA is different than in production. This is an easy test and if it is the case then then then next time you do a production promotion the bug should go away.
Another possibility for bugs in production and not QA are configuration settings of the application. Things like connection strings, web service urls and any other custom settings might not be configured properly for the production environment. Again this is an easy thing to check and correct.
These two solutions will probably fix most of the problems when a bug is not reproducible in a QA environment. But what do you do if it doesn't?
This was the case I just recently had. The client stated their users were reporting errors and they were having trouble reproducing them in their QA environment. So I started to look into the problem and saw the actual error on a user machine. The error the users were running into was a low memory error. The error was surprising since our development machines and QA machines were not having the same problem. Turns out the production devices were running on only 512mb of ram and the QA machines has 1gb. See the production devices need to be very strong and unbreakable, so to save money they purchased the base unit without the memory upgrade. Since in testing the devices aren't in the field they were using a different device, however thought the specs to be the same.
Errors like this is why it is very important to have QA and Production environments the same. Hardware, software running, and permissions should all be the same so that applications will react the same in both environments. There may be times that you can't set up both the same due to cost, time or whatever reason, but these differences should be documented and when testing the testers should try to determine the effects the differences will have.
Subscribe to:
Posts (Atom)