07/21/2009 07:49 PM -
at the major insurance provider where i work, we don't have software deployments -- we have software space shuttle launches. there exists a data problem that i was assigned to address. the data problem exists in two places: a db2 database, and a sql database. if it were on a single database platform, i'd have written a complex query to fix it. but it's not, so i got to write some code! i spent about two hours writing the code, and i've been going through the red tape to get it executed for the past six weeks. there is a level of bureaucracy necessary to accomplish a software cycle: first there's work (analysis). second and third are the fun part (design and development). then the project goes to test and the developer should never get involved again except to fix test issues. from there it's deployed to production (read: "files are copied"), maybe an app pool is recycled or a program run, and we move on to the next project. that process isn't enterprisey enough for this company. there exists lots and lots of process for any given task, but the process is never explained until someone skips it. i was unaware of some processes, and thus the processes were explained to me after the fact - and a bit too late. so i proceeded happily along the standard path: i analyzed, designed, developed, and handed the project off to my tester. everything was going smoothly and we were on schedule for a production deployment today. that was, until last thursday. last thursday, we were in a standard pre-(deployment meeting)-meeting, when several concerns were presented by our plentiful levels of management:this is going to do three million sql queries in a row? that needs to be stress tested!we have standard practices for database access. have you been following them? who signed off on them?you can't just deploy code to a server and ask someone to run it; you need to schedule it for execution via a ca-7 job! ugh. fine, so i zipped through the process of pushing code to the stress testing region and training the stress tester on how to run it. she monitored the server, the dba monitored the sql server, and i monitored the tool's progress remotely while it ran. lo and behold, it passed with flying colors. this "zipping" took two days. yes, i followed the standard practices you sent out via email two weeks ago - even though that was long after the coding was done, i went back and updated it to meet your standards. nobody signed off on it because when i sent out a meeting invite two months ago, nobody showed up, so there was nobody to sign off on it! oh, now that a senior director has visibility to it, it gets addressed right away. i meet the appropriate people, make changes as required, test it, and pass it on to the tester for final approval. someone can't just run this .exe in the production region? oh, fine, but fortunately we have people to manage deployments and servers and stuff, so one of them agreed to submit the ca-7 job. "it takes 2-3 days for this to get completed and approved" -- huh? fine. of course the ca-7 request required information we didn't have yet, like where it's going on the server. we literally wasted two man-hours of the company's time just in deciding where the files need to go when they can just be deleted after it runs (and therefore, in practice, it can be placed anywhere). fine, so i collect the requisite information and we get the ca-7 job finished. an emergency deployment meeting was scheduled for today to sync up on the project progress. really, you could call it a post-(pre-(deployment meeting)-meeting)-meeting. some action items were brought up and addressed later that day, and we had a follow-up meeting in the afternoon. that afternoon, at the post-post-pre-deployment meeting-meeting-meeting-meeting, yet another roadblock came up: the executables in source control were built on my machine instead of on the build server. guys, it's a data fix tool that will run once in production, ever, and never be heard from again. of course i got pushback on this being the formal process, but it is their process and they pa
Post.aspx?Title=Small+Fix%2c+Giant+Process
07/10/2009 09:02 PM -
so apparently the blog's comment system was borked and nobody told me about it. however, due to my aggressive error handling, the errors were logged. howeverer, that's all it does -- logs them. therefore i wasn't notified. also, nobody told me they couldn't comment. so i fixed it. that is to say, if it can't understand a uri, it just deletes it and pretends it doesn't exist. the problem was in the commenting user's blog and website urls, so if they aren't valid they may go missing. so commenting works now. tested it myself. it was a bug in the blog's overzealous security measures, which i've implemented as a result of the massive amounts of comment spam the blog has historically gotten. the commenting system is still secure against bots though, as it requires the user log in through microsoft. more specifically, the bug was in two places where the blog parses uris: request url: http://zi255.com/post.aspx?title=windows+7+magnifier+-+now+with+scrollwheel! stack trace: at system.uri.createthis(string uri, boolean dontescape, urikind urikind) at system.uri..ctor(string uristring) at pagepost.detectcommentattacks() at pagepost.btnsubmit_click(object sender, eventargs e) at system.web.ui.webcontrols.button.onclick(eventargs e) at system.web.ui.webcontrols.button.raisepostbackevent(string eventargument) at system.web.ui.webcontrols.button.system.web.ui.ipostbackeventhandler.raisepostbackevent(string eventargument) at system.web.ui.page.raisepostbackevent(ipostbackeventhandler sourcecontrol, string eventargument) at system.web.ui.page.raisepostbackevent(namevaluecollection postdata) at system.web.ui.page.processrequestmain(boolean includestagesbeforeasyncpoint, boolean includestagesafterasyncpoint)
Post.aspx?Title=Comment+System+Unborked
07/08/2009 09:01 PM -
on 01/08/09, i provided a list of windows 7 keyboard shortcuts and pointed out that the magnifier should be mapped to win-scroll (windows key + mousewheel). that same day, i filed this connect bug against windows 7 to get it looked at. microsoft's response: digging deeper on this, it turns out the winkey + scrollwheel brings up the start menu. it becomes very difficult to get around that, apparently. [...] please let me know how that works-out. this has me curious as i was on the test team for magnifier for a short time recently. i voted and commented on this feature request with the windows 7 taskforce, for whatever good that might do. looks like 48 other people agree. of course, i'm a software developer, so i started looking into software solutions. unfortunately, since i'm a .net developer, i haven't had exposure to much of that low-level stuff like hardware listners. this stackoverflow thread 3 months ago yielded no results, but this one3 hours ago did make a difference. one responder linked me over to autohotkey and i resolved my complaint with this simple script: $#wheelup::send #{numpadadd} $#wheeldown::send #{numpadsub} so now i can freely zoom in and out in the windows 7 magnifier via the scrollwheel, without bothering with moving my right hand over to the +/- keys; although i can still use those.
Post.aspx?Title=Windows+7+Magnifier+-+Now+with+ScrollWheel!