So....
is %file.delete(); badly named or is it actually nuking the file after reading it?
So....
is %file.delete(); badly named or is it actually nuking the file after reading it?
Would you settle for being able to see the past? 2010 has IntelliTrace.
That's pretty awesome, I need to keep that reference handy.
So in dealing with the WTFs I posted in here (mainly the bug fix) I pushed out a new build that had everything fixed. Mind you, the bugs I were fixing were bugs the original coder made. Well it seems the Development team doesn't trust that I can program and I know what I am doing, so they had someone do some before and after tests to verify the script it outputs is correct (even though I already did that in fixing this bug). I can guarantee they NEVER doubted the original programmer that wrote the bugs originally. I've also since found other WTFs in there that I don't really feel like writing a whole post on.
In other news, I just got a full time developer job at a good company and gave my current place 2 weeks notice, so someone else can deal with this piece of crap.
Is your student loan website ACS-Education? Wells Fargo sold my student loans to these retards, and I have been frustrated ever since. Their website is routinely down and having issues, and I could write a book on all the WTFs in their system (for example I accidentally gave them the wrong bank account # when I changed banks, and I got a month of payment free because their system didn't recognize that the payment was rejected).
@DaveK said:
@KallDrexx said:
@DaveK said:Well, on VMware there's a menu option (in the management interface) or button you click (on the virtual console window toolbar) that snapshots the entire state of the virtual machine, and another one that rolls back your VM to the last taken snapshot. I don't know but would expect other VMs to have similar facilities. In the last resort, you could choose whatever option to sleep/suspend the VM that the software offers, and then take backups of the VM state files to recopy back later, but I'd be surprised if that was actually necessary.Ugh. Having to debug problems in third-party code with no sources is definitely not fun.How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?
[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]
OMG, how do you do this? That would be amazing to know.
Oh, for a minute I thought you were referring to the .Net CLR. I would give an arm and a leg if Visual Studio had the capability to do that.
@DaveK said:
Ugh. Having to debug problems in third-party code with no sources is definitely not fun.How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?
[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]
OMG, how do you do this? That would be amazing to know.
@C-Octothorpe said:
@KallDrexx said:
Is the txtSqlScript a custom control (sorry if you already answered this question). If so, why not just run through the code of the txtSqlScript.Text setter, or if you don't have access to the source, just use reflector on it and see what's going on inside.I wasn't talking about maintaining your own programs. Anyone can do that. I was referring to maintenence of tools others have written and abandoned (like you described in the original post).Oh right, I read that wrong.In reference to the bolded text...I'm not sure I follow you. I'm guessing (haven't touched C# in at least 5 years) that this is a property setter? Was the text getting mangled at that point? And then when you fetched it from the control, it was bad?Exactly. So when I ran txtSqlScript.Text = PostFormattedText; and then looked at the txtSqlScript.Text value, that value was the mangled text, even though PostFormattedText string was still the correctly formatted string.
The control is a proprietary rich text box by Infragistics. The fact that it's manipulating the string it's supposed to be displaying (instead of using the string it's given and rendering it correctly) is ridiculous and unacceptable in my opinion. I should be able to retrieve the pre-rendered string from the text box. Yes, I could use reflector to see what it's setter is doing to modify the string, but what's the point? Furthermore, the only purpose of the text box on the GUI is to display the sql script, that in 100% of all use cases the user is going to copy all of the text into sql server management studio. There's no purpose to rich text formatting this at all.
I wasn't talking about maintaining your own programs. Anyone can do that. I was referring to maintenence of tools others have written and abandoned (like you described in the original post).
Oh right, I read that wrong.
In reference to the bolded text...I'm not sure I follow you. I'm guessing (haven't touched C# in at least 5 years) that this is a property setter? Was the text getting mangled at that point? And then when you fetched it from the control, it was bad?
Exactly. So when I ran txtSqlScript.Text = PostFormattedText; and then looked at the txtSqlScript.Text value, that value was the mangled text, even though PostFormattedText string was still the correctly formatted string.
@frits said:
@KallDrexx said:
@frits said:Because internal tools are usually not written with maintenance and quality ideals in mind. Maintaining these things usually requires someone to just do what needs to be done, while resisting the urge to refactor, which may open up cans of multiple cans of worms. Due to their pedantic nature, QA folks are usually not a good fit for this.Having a QA dev maintain internal tools sounds like a productivity nightmare to me.
Why? It's what I was hired to do, to create and maintain automation and internal tools to streamline our QA processes. It's just expanded from just QA tools to process management and misc internal tools.
I guess it depends on how much oversight you have. I'm given pretty good freedom here so I make sure to write all my tools in a maintainable way, because I know that I am going to have to fix any issues with it and respond to changes in processes. I have done some pretty big refactoring when required, but then again my boss trusts me that when I say that I need to fix some issues with my tool that I'm not just wasting time and that I know what I'm doing / talking about. But then again that probably also stems from being in QA and not product development
This is the sort of situation where it seems like logging could more easily narrow down the point where it happens. That way you can let it run, and just come back at the end and see where the change occurred. At least, that's where I might have started. If the real problem is the 3rd party control like you think, one run through should have told you that.
Yeah probably. Long story short I was thrown off because it didn't happen before some changes I made in the HTML stripping method (which fixed another issue), so I was more focused on the stripping code was working properly. However, I finally figured out it was the third party code by changing the method to
private void SetDdl(string ddl) { PreFormattedLastGeneratedDDL = ddl; PostFormattedLastGeneratedDDL = StringHandler.GetTextOutOfHtml(ddl); txtSqlScript.Text = PostFormattedLastGeneratedDDL; }
because I saw that the pre and post formatted DDLs were correct, but after the method run txtSqlScript.Text was mangled. However, when I took the same exact pre formatted DDL in and on page load called SetDdl() with it, the text box was formatted correctly (thus only formatted incorrectly when run from the other thread after the whole process), which made things confusing. I should also mention that I wasn't focused 100% on this for 3 days straight, but I was working on other stuff in that time.
If there is *Ever* the possibility of a UI becoming multi-threaded [can you ever guarantee what will happen to the code in the next 5 years? I cant'. So the safe presumption is that at some point the code may become used in a MT environment] then having the InvokeRequired conditional code is the way it should be coded from day 1. If I had $10 for each time a piece of UI code eventually became problematic because of a threading issue (which did not exist at the time the code was originally written and tested) I would have already retired.
Thanks, I honestly didn't know that. Though usually in this case I use a .Net backgroundworker thread, so my UI updates do occur on the GUI thread properly anyway.
@DaveK said:
@KallDrexx said:
The whole backend is intertwined, so in order for me to step through the application to debug this issue I have to run through the whole 1.5 hour process, because I literally have to rewrite his code in order to be able to do something as simple as "run the code for only one specific TFS changeset", and instead I have to tell it to run through ALL labels.@KallDrexx said:Meanwhile I've spent a good bit of the last 3 days trying to debug this issue, since I can only get the issue to happen when I run through the full hour and a half process.Can you seriously really not find a way to work smarter not harder using conditional or counting breakpoints?
I'm not an idiot, I've been programming for quite a while. I started with conditional breakpoints, but it's not as easy as it sounds. The problem is that the final string output of the application is being mangled in some way that is ruining the Sql Scripts it's supposed to be displaying. I've already set up MSTest unit tests on the actual string manipulation functions and verified that they are not the cause of the mangling. The sql script concatenation is handled at the very end of the process, after it runs through and performs all the queries on the TFS database for every single changed file in every single changeset in the list between the two TFS labels (yes it's inefficient, yes I need to go through and redo all of his code to make it not take an hour and a half, but that's no trivial matter in the way he architected this code).
When I call the code to on form load to display the sql script in the text box (providing the final output) everything displays properly, but it only doesn't display properly when it runs through the whole processes. I think I have tracked it down to a retarded Infragistics rich text control that seems to arbitrarily mess the text up, and I'm testing it now, but I can't find a way to repeatably cause the third party control to mess the text up without running through the whole process.
I replaced the Infragistics text box with a normal text box and I think that'll fix it but I"m waiting for the whole process to run through so I can verify it. P.s. He used his personal Infragistics license for this tool, and was telling me that legally I should change out Infragisistics controls with either Telerik (which we have a license) or just winforms to keep it legal. *sigh*
@frits said:
Having a QA dev maintain internal tools sounds like a productivity nightmare to me.
Why? It's what I was hired to do, to create and maintain automation and internal tools to streamline our QA processes. It's just expanded from just QA tools to process management and misc internal tools.