In the week just gone by, I received a web app from one of my colleagues who was on medical leave. This was supposed to be a prototype of what I will be developing in the days to come. However, there were many issues with the UI of the site. The color scheme though looked good did not match with the logo of the company and had to be changed.
It took me some time to realize that the CSS file being used was one within the App_Themes folder and not the one outside. I had been making changes to the wrong file, hence the changes I was making were not reflecting. But hang on!! Now I was making changes to the correct file but still I could not see the changes reflecting in the front end. I double checked and was stumped. Just moments ago the changes made to the CSS were reflecting in the UI. What could be the possible reason now?
Somehow I had the feeling that I should refresh the page once(probably because of my experience with Service Desk Customization) and Bingo!!
Now I again I made some changes mainly changing the logo, but again it wasn't reflecting. I refreshed. Nothing!! Now what could be the reason? Thankfully I had a backup of the original CSS file. I compared that with the modified one. I realized what was happening. To work faster I was using the build style option in Visual Web Developer. When you use this a Window opens where you can visually set the CSS properties. I was using this to set the background image to the one I had created. The location of this image was "App_Themes/Theme1/Images/Image1.gif". So what was happening was the in the CSS the same url for the image was getting stored. But as my CSS file was already located at "App_Themes/Theme1/" the correct url for the image should have been "/Images/Image1.gif". I changed the Url and Voila!!
As I had posted earlier, Microsoft is always trying to simplify things by allowing you to code Visually. But this Visual coding style has pitfalls and is a sure source of many bugs in applications. My advice to all is "Be Extra Careful when writing code Visually!"
Cheers!!
Wednesday, December 19, 2007
Thursday, December 13, 2007
About Gathering & Understanding Requirements, and AGILE Development Model
All Software Engineering text books talk about how important it is for a Software Team to understand the requirements that their software will fulfill. So a person who is gathering requirements from the stakeholders needs to really understand what is desired. Requirements gathering is THE most important stage in the SDLC. Yeah, even I was aware that!
But again textual knowledge and practical knowledge are 2 different cups of tea(or coffee if you're an American reader :P ) I never really understood its importance until I myself was developing software. (okay I was customizing something already built, but then again I was developing features to meet the requirements from a certain POV..) My development was basically to do what I was told to do. Never really thought about the requirements!! But when whatever I was told to do wasn't impressing the stakeholders, I was puzzled. My senior used to tell me the requirement and then tell me what should I do to achieve it. But since this wasn't resulting in something which was desired, I was intrigued. The problem wasn't that I was being communicated incorrect information. Rather I would say it was incomplete information. From the point of view of the functionality required I was told only a part. But later as i discovered, what I was being asked to develop was something that would integrate 2 business process to make one complete process. Also whatever solutions were being suggested by my senior would provide the User with functionality that the Business Process demanded but unfortunately, not what the User demanded. Whatever was being developed initially would never be accepted!
The problem here is that nowadays people define the process flow and the requirements based on that(at least whatever I have come across...I am sure things are not so bad in other companies..) But a very important factor is to understand who are the people who will use the software and what could be the features that they want. Unfortunately even in the age of Orkut, companies are failing to recognize the fact that a person who is exposed to easy to use web applications like Orkut will hardly like to use a web-app with a boring interface like Service Desk. They will use it not because they like it but because they have to. And this in my view is a factor that decreases productivity and which will drive Enterprise Applications in the coming years.
Another important aspect is if the Users are aware of whether the requirements they want is something which they will use. Most of the times that may not be the case and the person gathering requirements should question the user at each and every stage of the requirement gathering. A very good example is what I encountered today. The Web App I will be developing in the coming days has a forum feature where anybody can post questions. However only people who are considered SME's in that particular area will be allowed to answer the question!! First of all, why shouldn't I, not being an SME, be allowed to answer. I may know things that the SME might not or I may be able to provide an answer quickly as the SME(s) might be busy with some issues in the production systems. Secondly if the SME is my dear colleague who sits right next to me would I post on a forum or ask directly to him. The forum thing will work if your organization has a large volume of employees. But in this case, I have a hunch that we are building software which will never be used.
Anyway, whatever the case maybe, what I am learning is programming in C# and ASP.NET and hence I am satisfied! Also the AGILE model of development is followed so should be interesting!
More about agile development some other time!! Till then.... Happy Programming!!
But again textual knowledge and practical knowledge are 2 different cups of tea(or coffee if you're an American reader :P ) I never really understood its importance until I myself was developing software. (okay I was customizing something already built, but then again I was developing features to meet the requirements from a certain POV..) My development was basically to do what I was told to do. Never really thought about the requirements!! But when whatever I was told to do wasn't impressing the stakeholders, I was puzzled. My senior used to tell me the requirement and then tell me what should I do to achieve it. But since this wasn't resulting in something which was desired, I was intrigued. The problem wasn't that I was being communicated incorrect information. Rather I would say it was incomplete information. From the point of view of the functionality required I was told only a part. But later as i discovered, what I was being asked to develop was something that would integrate 2 business process to make one complete process. Also whatever solutions were being suggested by my senior would provide the User with functionality that the Business Process demanded but unfortunately, not what the User demanded. Whatever was being developed initially would never be accepted!
The problem here is that nowadays people define the process flow and the requirements based on that(at least whatever I have come across...I am sure things are not so bad in other companies..) But a very important factor is to understand who are the people who will use the software and what could be the features that they want. Unfortunately even in the age of Orkut, companies are failing to recognize the fact that a person who is exposed to easy to use web applications like Orkut will hardly like to use a web-app with a boring interface like Service Desk. They will use it not because they like it but because they have to. And this in my view is a factor that decreases productivity and which will drive Enterprise Applications in the coming years.
Another important aspect is if the Users are aware of whether the requirements they want is something which they will use. Most of the times that may not be the case and the person gathering requirements should question the user at each and every stage of the requirement gathering. A very good example is what I encountered today. The Web App I will be developing in the coming days has a forum feature where anybody can post questions. However only people who are considered SME's in that particular area will be allowed to answer the question!! First of all, why shouldn't I, not being an SME, be allowed to answer. I may know things that the SME might not or I may be able to provide an answer quickly as the SME(s) might be busy with some issues in the production systems. Secondly if the SME is my dear colleague who sits right next to me would I post on a forum or ask directly to him. The forum thing will work if your organization has a large volume of employees. But in this case, I have a hunch that we are building software which will never be used.
Anyway, whatever the case maybe, what I am learning is programming in C# and ASP.NET and hence I am satisfied! Also the AGILE model of development is followed so should be interesting!
More about agile development some other time!! Till then.... Happy Programming!!
Saturday, December 8, 2007
Web Basics
My preparation for the Application Development Foundation Exam of MCTS hasn't been going very well. Mostly because it contains a lot of things which are new to me and I will take some time to understand. However this morning I was just having a look at Web Client Development Exam, and read the first chapter. This was mainly because the contents of the first chapter were interesting and more aligned with what I am doing or will be doing now onwards. Here is just a brief of what I read, and is being posted more as a ready reference for me than anything.
The first thing that is talked about the Web Server and how it has changed from being a simple server returning data(response) to requests by the web browser without any state, to being a complex contraption managing state between web pages, accepting data and responding to it. Also, the growing importance of web browsers with Client Side scripting technologies like AJAX creating new ways of addressing things.
Mostly, it is an introduction about the HTTP or the Hyper Text Transfer Protocol.(I was once dumb enough to think that whatever acronym ended with a P had to be some protocol. Though FTP, HTTP, SMTP, SNMP etc. are all protocols this doesn't necessarily hold true for everything. In an interview once I was asked about OLAP. I was definite that I had heard about it somewhere but answered in the negative. Once outside I was discussing with a friend as to what could OLAP be and came up with Object Layer Access Protocol!! For the uninitiated it is On-Line Analytical Processing.)
It talks about the various HTTP methods like GET, POST, HEAD etc. and also something about Distributed authoring and Versioning or DAV, something built on top of HTTP 1.1 which enables easier web development in a team scenario. I also got to know about the standard codes in HTTP. Remember the 404 Page not Found Error!!
Basically there are 5 Status-Code Groups
1xx
2XX
3XX
4XX when there is error on the browser
5XX When there is an error on the server
HTTP uses MIME types and you should know some of the common MIME types. You also learn a bit about how data is posted back to server, HTTP GET and POST and finally about POST BACK and HTTP debugging!
I am finding this interesting! Might just post some more cool stuff to know about the web!
The first thing that is talked about the Web Server and how it has changed from being a simple server returning data(response) to requests by the web browser without any state, to being a complex contraption managing state between web pages, accepting data and responding to it. Also, the growing importance of web browsers with Client Side scripting technologies like AJAX creating new ways of addressing things.
Mostly, it is an introduction about the HTTP or the Hyper Text Transfer Protocol.(I was once dumb enough to think that whatever acronym ended with a P had to be some protocol. Though FTP, HTTP, SMTP, SNMP etc. are all protocols this doesn't necessarily hold true for everything. In an interview once I was asked about OLAP. I was definite that I had heard about it somewhere but answered in the negative. Once outside I was discussing with a friend as to what could OLAP be and came up with Object Layer Access Protocol!! For the uninitiated it is On-Line Analytical Processing.)
It talks about the various HTTP methods like GET, POST, HEAD etc. and also something about Distributed authoring and Versioning or DAV, something built on top of HTTP 1.1 which enables easier web development in a team scenario. I also got to know about the standard codes in HTTP. Remember the 404 Page not Found Error!!
Basically there are 5 Status-Code Groups
1xx
2XX
3XX
4XX when there is error on the browser
5XX When there is an error on the server
HTTP uses MIME types and you should know some of the common MIME types. You also learn a bit about how data is posted back to server, HTTP GET and POST and finally about POST BACK and HTTP debugging!
I am finding this interesting! Might just post some more cool stuff to know about the web!
Labels:
HTTP,
Web Basics
The New VWD 2008 Express
I wasn't aware that its already out! Yes, Visual Studio 2008 Express Editions were available for download from Monday, 19 Nov, 2007 says the news channel on my newly installed Visual Web Developer 2008 Express. Yeah I installed it last night! Still exploring and will post what I like about it, but in the meantime you can check out Scott Mitchell's review on 4guysfromrolla.
To Install Visual Web Developer 2008 Express, go here
To Install Visual Web Developer 2008 Express, go here
Wednesday, December 5, 2007
A Little About Databases
One of the huge disadvantages of using Microsoft Products I find is that you tend to do things improperly! Let me share with you something I learnt today.
I have installed the SQL Server 2005 Express Edition as the default database to use with Visual Studio for my projects. Working in an Enterprise Software Services Firm I am aware that you have special roles for a database administrator. The DBA will never share the system admin or db admin login credentials with you. For your application to access the database in a safe manner a new user is generally created for you to use! At least in my limited experience that is what I have come to know!
So for my demo project I decided to create a new user and not use the sa login. I named this user dba. When deciding on what would be the default schema of this user I decided on db_owner to avoid any access issues later on. ( My database knowledge is limited to RDBMS concepts, writing Queries, Sp etc. I have never undergone any training or ventured on my own into what one would call the DBA's domain). Using this user I created the tables required for my application. The tables created appear as db_owner.assets.
Now I am using the same user to connect from my app to db. I had no issues in visually building the Connection String which I promptly stored in my web.config file. I had no issues in building TableAdapters with simple SELECT statements as well. However, no I decided to graduate to the next level and create my own Stored Procedures. I try to do this Visually once again but I get a failure message saying the schema dba does not exist or does not have sufficient permissions. OOPS!!
How is that possible? I made dba the db_owner. I check and surely dba still is db_owner. I wonder what could be wrong. Maybe I should try and create the stored procedure from Management Studio Express instead of Visual Studio. Fails again with the same message!
I examine the stored procedure to find "CREATE PROCEDURE dba.assets AS ...". Oh! the schema. When dba created the tables they where created as db_owner.assets. So I expanded the nodes in the Management Studio Express and went to schemas to find that indeed no schema named dba existed. So I created a schema named dba as I saw fit and then tried creating the stored procedure. Voila!
Microsoft assumes a lot of things when it Visually creates anything for you. It sure makes things a lot simple and easy to use but can lead to simple errors like this. If only such an error were to creep up in a production environment!!In this case Microsoft should have taken care that the default schema for dba was db_owner.But that is what software is all about I guess; finding new improvements from time to time.
I have installed the SQL Server 2005 Express Edition as the default database to use with Visual Studio for my projects. Working in an Enterprise Software Services Firm I am aware that you have special roles for a database administrator. The DBA will never share the system admin or db admin login credentials with you. For your application to access the database in a safe manner a new user is generally created for you to use! At least in my limited experience that is what I have come to know!
So for my demo project I decided to create a new user and not use the sa login. I named this user dba. When deciding on what would be the default schema of this user I decided on db_owner to avoid any access issues later on. ( My database knowledge is limited to RDBMS concepts, writing Queries, Sp etc. I have never undergone any training or ventured on my own into what one would call the DBA's domain). Using this user I created the tables required for my application. The tables created appear as db_owner.assets.
Now I am using the same user to connect from my app to db. I had no issues in visually building the Connection String which I promptly stored in my web.config file. I had no issues in building TableAdapters with simple SELECT statements as well. However, no I decided to graduate to the next level and create my own Stored Procedures. I try to do this Visually once again but I get a failure message saying the schema dba does not exist or does not have sufficient permissions. OOPS!!
How is that possible? I made dba the db_owner. I check and surely dba still is db_owner. I wonder what could be wrong. Maybe I should try and create the stored procedure from Management Studio Express instead of Visual Studio. Fails again with the same message!
I examine the stored procedure to find "CREATE PROCEDURE dba.assets AS ...". Oh! the schema. When dba created the tables they where created as db_owner.assets. So I expanded the nodes in the Management Studio Express and went to schemas to find that indeed no schema named dba existed. So I created a schema named dba as I saw fit and then tried creating the stored procedure. Voila!
Microsoft assumes a lot of things when it Visually creates anything for you. It sure makes things a lot simple and easy to use but can lead to simple errors like this. If only such an error were to creep up in a production environment!!In this case Microsoft should have taken care that the default schema for dba was db_owner.But that is what software is all about I guess; finding new improvements from time to time.
Subscribe to:
Posts (Atom)