June 10, 2010 at 10:19 am
I work as a sql support analyst, identifying issues in sproc logic or sproc design, logging bugs and advising devs how they shoudl be fixed.
All our sprocs are called from a web application. All logic used to be in the db but they have started adding some of it to the web middle tier.
I managed to procure the VS project files for the web app and its massive. It is quite old and has been continually updated so it contains pages with classic asp, asp.net java script xml config files and the solution contains perhaps 15+ projects.
It also uses some services i need to install onto my machine. I am not a web developer, or any other type of developer. Installing this project so i can place breakpoints into it to debug is going to be a nightmare.
I am wondering, if any of you are both sql analysts/dba's and web developers, and how did you ramp up to understanding the layout of a large web app?
June 10, 2010 at 10:35 am
winston Smith (6/10/2010)
any of you are both sql analysts/dba's and web developers, and how did you ramp up to understanding the layout of a large web app?
Yes, me! I was an interim webmaster until about a week ago, when they took the "interim" off my title!
In terms of understanding the web infrastructure, it's been a slow (and sometimes, painful) process, and I'm still learning. Since taking over this position, I've discovered how much of a kludge our website is. One of my long-term projects is to streamline the infrastructure (including database and folder structures), but that's another story for another time.
Probably one of the big things that has really helped has been taking stock of exactly what I've been dealt. I've created a web map in MS Visio that shows me what pages link to what. (Because of the number of pages and links, it's a HUGE undertaking! I've even been referring to the document as the "flight map" because of its resemblence to an airline route map!) I'm documenting as much as I can; not just in the flight map, but also in a Word document that I'm developing as I go along. I also opened a command prompt, went to the web site root directory, and did a "dir /ogs /s > WebSiteDirectory.txt" to get a list of files and folders used by the web site.
In terms of identifying which pages are data driven, I'm still trying to figure that out myself (and if anyone else reading this has any input, please chime in). So far, the best I've been able to do is do a "find '[DB include statement]' *.asp" in my file directories to find lines that tip me off that the page is accessing the database. I've been trying to figure out a way to do that in all subdirectories; I believe there's a way to do that in UNIX/AIX, but alas, I'm working in a Windows environment, and haven't found a good way to do it.
Don't know whether or not this helps you out. If you have any more questions, please feel free to post them.
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
June 10, 2010 at 10:43 am
I've done it, and I learned by digging in years ago into ASP and ASP.NET. Just getting a project going, and slowly learning how one thing learned, how it fit, and then slowly gaining an understanding. I'm not sure I'd try to get it into debug at first, but you can try.
I'd look at a page, slowly learn how it works, find another one, repeat.
June 10, 2010 at 10:45 am
I would not say I am a developer as much as I am a tincker'er (I just made that word up :-D)
I would say however that I have had to do this sort of think before and all you can really do assuming you have the resources, time, and patience (this is the most important part) is weed your way through the code. It is helpful to create a road map if you will. Using Visio, word, a piece of paper, what ever you have available. Create a map of the flow of tasks (how does a user move through the program). The knee bone connects to the thigh bone type stuff. Understanding the flow and being able to document that will help as you progress. Then document the projectes used by each step of the flow. Then define the key elements of the step in the flow. (Open ticket, enter notes, close ticket) these are the primary tasks that the program was created to fulfill. Then open the code and try to identify those key tasks. as you do DOCUMNET DOCUMENT DOCUMENT leave your self notes in the code in the form of comments. I go a bit over board with this but for example at the beginning of each function you will see something like
'***** This function will be used by the following process #Web app hello# user for the purpose of saying hello to the user
Each section of code then has a beginning and ending comment so I know what the code was for and where that section of code ends.
'This section of code will tell the user hello
msgbox("Hello User")
'End Hello User section
In an ideal world this would have already been done and you would already have a road map telling you what the primary function are but I find this is rarely done. Or if it is done it is done in such a manner that only the developer who wrote the program has any idea at all what it meant.
In general there are no magic wands here but if your start with the basic elements of why the process was created. you should begin to develope a decent understanding of the program flow and the code behind it. you may not agree and you way ask What where they thinking often but that is part of the game.
Dan
If only I could snap my figures and have all the correct indexes apear and the buffer clean and.... Start day dream here.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply