What did I learn today? There's always something you miss when rebuilding a system....
After about a year, my corp issued laptop was dog slow. Though I'm sure a large part of it was the anti-virus performance vampire, (we use Mcafee Enterprise) the system was due for a rebuild.
I've done this a few times. In the past I've usually either done a straight filesystem dump or (if I'm feeling paranoid) imaged the system with something like Ghost before starting over.
This time I didn't. I was backing up across a 100mbit network link with limited space on the destination, and so tried to pick and choose. And, of course, I missed something.
Mydocs? Check.
Everything checked into subversion (so I don't have to copy the working copy)? check.
desktop junk culled and saved? Yup.
Itunes? Pod synced up.
Download directory? copied.
Bookmarks? Heh...I use google's browser sync for firefox...so all my bookmarks are backed up and synced between all my machines, all the time.
Putty settings? Had to remember where it stores them (super-secret registry location), but check.
Winscp settings...winscp settings?!! Awww...crud.
Ah well. If I had to pick something to miss, that'd probably have been it.
Tuesday, October 30, 2007
Perfectionism:1, Aaron:0
Ok, so I wanted to fire off an entry every day for 10 days.
Didn't make it.
Crud.
So we try again.
I think it had something to do with the fact that my designated timeframe was a whopping 15 minutes (yes, I really am that naive sometimes) at the end of the day. Logically, it made sense because I'd be able to reflect on what I'd learned for the day. Practically, it meant that either my brain was fried or I was in a groove and didn't want to get out.
Well, that or I'd start on a post (I have one half completed) that'd go on. And on. And on. And I'd realize that for it to be a high quality post I'd have to put more time into researching my wild generalizations and casual proclamations.
Hmm.
Maybe a shorter, more doable goal. Instead of subtly thinking I'm going to deliver a highly polished .net 2.0 tutorial on whatever-the-heck-I-found-out that day, perhaps just two paragraphs. Just...two.
And if I only do one, so be it.
So what have I learned the last week?
Storing hierarchical data in a sql database isn't straightforward. I started off with what's called an "adjacency list" model. (I found that out when it blew up) That's essentially where each row of the relationship table stores the childID and the parentID (and the child name, in my case).
There is an extremely elegant way to parse this. Unfortunately, it's recursive. With ~ 100 rows it returned lickety split. With about 500 rows it ran the sql server's (unlimited) connection pool out of connections.
Ow.
Err.
Yeah.
So back to the drawing board. There's one called "modified tree order traversal". After drawing it out on paper, I think I got my head around it. But it's a little bit more work (?!!) when inserting and deleting nodes.
Not sure what to do at this point. I want a quick and easy solution (don't we all!) I'm not dealing with millions of rows of data (more like about 3-4000). So I think I'll need to do some more thinking.
Didn't make it.
Crud.
So we try again.
I think it had something to do with the fact that my designated timeframe was a whopping 15 minutes (yes, I really am that naive sometimes) at the end of the day. Logically, it made sense because I'd be able to reflect on what I'd learned for the day. Practically, it meant that either my brain was fried or I was in a groove and didn't want to get out.
Well, that or I'd start on a post (I have one half completed) that'd go on. And on. And on. And I'd realize that for it to be a high quality post I'd have to put more time into researching my wild generalizations and casual proclamations.
Hmm.
Maybe a shorter, more doable goal. Instead of subtly thinking I'm going to deliver a highly polished .net 2.0 tutorial on whatever-the-heck-I-found-out that day, perhaps just two paragraphs. Just...two.
And if I only do one, so be it.
So what have I learned the last week?
Storing hierarchical data in a sql database isn't straightforward. I started off with what's called an "adjacency list" model. (I found that out when it blew up) That's essentially where each row of the relationship table stores the childID and the parentID (and the child name, in my case).
There is an extremely elegant way to parse this. Unfortunately, it's recursive. With ~ 100 rows it returned lickety split. With about 500 rows it ran the sql server's (unlimited) connection pool out of connections.
Ow.
Err.
Yeah.
So back to the drawing board. There's one called "modified tree order traversal". After drawing it out on paper, I think I got my head around it. But it's a little bit more work (?!!) when inserting and deleting nodes.
Not sure what to do at this point. I want a quick and easy solution (don't we all!) I'm not dealing with millions of rows of data (more like about 3-4000). So I think I'll need to do some more thinking.
Wednesday, October 17, 2007
From the "I can't believe I did that" dept...
.net is a wonderful thing.
The Visual Studio 2005 IDE is a wonderful thing.
All those easily settable properties, intellisense...all are (repeat after me) Very Good Things.
Of course, they still don't always save the occasional bonehead miss.
So I've been trying to get (for a day and a half) a footer to display in an asp.net gridview.
You know the drill...gridviews don't allow you to create (insert) records by default. Given that this is a pretty common theme, there are quite a few tutorials out there on how to do it.
Ok, now get this. In the app I'm working on? I already had done this for a different gridview. (a week or two ago.) Worked great.
Followed the same steps. Compile. Run.
No footer.
Records show up. Paging numbers. All that good stuff.
No footer.
Hmm...maybe I need to change ALL the columns to template fields.
Nope.
Umm...put in a text field bound to the identity and make it hidden?
Uh-uh.
Oh yeah...I need to embed a formview in the footer, bind it to the same data source and...uh...
No.
Crap. What the confounded tarnation of all that is good and ... oh. Wait.
Maybe you just need to set the "showfooter" property of the gridview to "true".
Yeah. That'll do it.
[blushes furiously]
On the plus side, the odds of me EVER repeating this mistake (and the attendant pounding of the head on formica) is now pretty minuscule. Pain. It's a wonderful teacher.
The Visual Studio 2005 IDE is a wonderful thing.
All those easily settable properties, intellisense...all are (repeat after me) Very Good Things.
Of course, they still don't always save the occasional bonehead miss.
So I've been trying to get (for a day and a half) a footer to display in an asp.net gridview.
You know the drill...gridviews don't allow you to create (insert) records by default. Given that this is a pretty common theme, there are quite a few tutorials out there on how to do it.
Ok, now get this. In the app I'm working on? I already had done this for a different gridview. (a week or two ago.) Worked great.
Followed the same steps. Compile. Run.
No footer.
Records show up. Paging numbers. All that good stuff.
No footer.
Hmm...maybe I need to change ALL the columns to template fields.
Nope.
Umm...put in a text field bound to the identity and make it hidden?
Uh-uh.
Oh yeah...I need to embed a formview in the footer, bind it to the same data source and...uh...
No.
Crap. What the confounded tarnation of all that is good and ... oh. Wait.
Maybe you just need to set the "showfooter" property of the gridview to "true".
Yeah. That'll do it.
[blushes furiously]
On the plus side, the odds of me EVER repeating this mistake (and the attendant pounding of the head on formica) is now pretty minuscule. Pain. It's a wonderful teacher.
Friday, October 12, 2007
Pivot tableness is next to godliness
Today was a metrics day. A couple of years ago I did a bunch of work pulling data from our OpenView service desk application at the request of my hiring manager. (the schema - or lack thereof - would have been enough to scare me off otherwise)
Anyway. I managed to puzzle out a rough idea of what I was after using a data dictionary and after much weeping, wailing, and gnashing of teeth pulled some very unique data. (unique as in "they couldn't get it anywhere else", not as in "hmm..that's a...unique...data set. No relation to reality but definately unique.")
I've done a few small commando jobs for my current manager. So back into the fray I go. Fortunately, past experience and a hefty library of already-configured DTS jobs (to pull from the oracle back end) made it the work of only one day.
Pop the saved data out to a .csv. Load up excel. Create the pivot table.
Curse at the few odd lines that don't have valid dates and therefore muck with the grouping functionality.
Fix the description fields that have embedded carriage returns and therefore totally muck up the text export.
**the following perlscript snippit from the DTS transform does a marvelous job fixing the above issue, by the way:
Original line (referencing the field in question with the embedded returns)
$DTSDestination->Item("SER_DESCRIPTION")->{Value} = $DTSSource->Item("SER_DESCRIPTION")->Value;
Modified perl transformation script line:
$temp = $DTSSource->Item("SER_DESCRIPTION")->Value;
$temp =~ s/\n//g;
$temp =~ s/\r//g;
$DTSDestination->Item("SER_DESCRIPTION")->{Value} = $temp;
Simple. Nifty. Works.
Where was I? Oh yeah. Finally get the raw data into a pivot table and within 5 minutes the data is singing. (what, I don't know) Want to know how many raw tickets we processed, broken down by month, with a 12 month moving average?
BOOM! POOF! ALAKAZAAAAAMMMM!! (well, about six clicks, actually)
Average time to resolve tickets over the same period, broken out by Tier 1, 2, and 3 groups?
FHAWOOMPUS! (three clicks)
No, I'm not showing my work. You'll just have to trust me on this one.
Come to think of it, I actually happen to have a pivot table tutorial (disguised as instructions on how to pull VSS metrics) that might be helpful. I'll have to get on that...
Anyway. I managed to puzzle out a rough idea of what I was after using a data dictionary and after much weeping, wailing, and gnashing of teeth pulled some very unique data. (unique as in "they couldn't get it anywhere else", not as in "hmm..that's a...unique...data set. No relation to reality but definately unique.")
I've done a few small commando jobs for my current manager. So back into the fray I go. Fortunately, past experience and a hefty library of already-configured DTS jobs (to pull from the oracle back end) made it the work of only one day.
Pop the saved data out to a .csv. Load up excel. Create the pivot table.
Curse at the few odd lines that don't have valid dates and therefore muck with the grouping functionality.
Fix the description fields that have embedded carriage returns and therefore totally muck up the text export.
**the following perlscript snippit from the DTS transform does a marvelous job fixing the above issue, by the way:
Original line (referencing the field in question with the embedded returns)
$DTSDestination->Item("SER_DESCRIPTION")->{Value} = $DTSSource->Item("SER_DESCRIPTION")->Value;
Modified perl transformation script line:
$temp = $DTSSource->Item("SER_DESCRIPTION")->Value;
$temp =~ s/\n//g;
$temp =~ s/\r//g;
$DTSDestination->Item("SER_DESCRIPTION")->{Value} = $temp;
Simple. Nifty. Works.
Where was I? Oh yeah. Finally get the raw data into a pivot table and within 5 minutes the data is singing. (what, I don't know) Want to know how many raw tickets we processed, broken down by month, with a 12 month moving average?
BOOM! POOF! ALAKAZAAAAAMMMM!! (well, about six clicks, actually)
Average time to resolve tickets over the same period, broken out by Tier 1, 2, and 3 groups?
FHAWOOMPUS! (three clicks)
No, I'm not showing my work. You'll just have to trust me on this one.
Come to think of it, I actually happen to have a pivot table tutorial (disguised as instructions on how to pull VSS metrics) that might be helpful. I'll have to get on that...
Thursday, October 11, 2007
What did I learn today?
I'd like to say that today I picked up some new ultra-snazzy techno skill. I successfully refactored the web app I'm doing to use LINQ. Or NunitAsp. Maybe got the back end to multi-thread successfully.
Alas. No luck. Today was much more pedestrian. Requirements and test data.
Requirements:
Shadow IT development is a kick. In the pants. (The trick is for it not to be a kick in YOUR pants.) I'm guessing a fair number of developers got their start in shade tree IT development. (Hey, that's my foot in the door too, so please don't slam it!)
I want to do the best job I can. And I'm blessed (no, really) with both the perspective of a few years of QA ("is it testable? did you build it to spec?!") as well as systems administration. ("Whaddaya mean there's no support?! Who do I call when this breaks? Where's the documentation on how it's supposed to work? No...1/4 page of fragmented english and a screenshot of a dos command window doesn't cut it..")
And I realized today that, while I've been functioning well enough with some 10,000 foot fuzzy requirements for the proof of concept it's time for some more detailed stuff.
(also because I'm floundering like a beached carp wondering what to do next.)
Should I tackle
Yeah. What's most important?
What do I do _now_? (analysis paralysis, anyone?)
So I started augmenting and cleaning up the schedule I started several weeks ago. And as my fingers wandered aimlessly across the keyboard, I actually managed to see patterns of responsibility and logical progression.
And the logjam in my head started to free. Imagine.
On to testing.
Ahhh....test data. We hardly knew ye.
Well, actually we know ye too d### well.
My current assignment is a web app to help folks manage permissions in our corporate reports distribution tool. We use this for everything from Oracle Financials data to Peoplesoft reports to...well, a lot of stuff.
Anyway. When store managers move around (I work for a large retail organization) or their mgrs, etc, it's not uncommon for it to be weeks or longer before they can get their financials for their newly assigned post.
This is a Bad Thing.
The process by which the tool is updated evolved (you guessed it) in a rather organic fashion. As these things do. Folks did the best with what they knew and had. So we have a process by which emails are forwarded between 3-5 people, in no standard format, and get processed in a batch when there's time.
Where was I? Test data. Oh yeah.
I'm getting to the bit where I actually make the (7-10) changes necessary when someone moves, and I realize I have no data.
None. Nada. Zip. Zilch. Zeeero.
And developing a solution against a "test" database that's populated with 10 records...well...it's just not where I want to go.
So today was spent exporting a copy of (safe!) data from our production server and getting it imported into my little-ol test server.
What did I learn? I (re)learned just how valuable my "keep everthing INCLUDING the kitchen sink in subversion!" habit can be. Instead of being a multi-day process, I just hitched on over there, looked in a few previous project directories (I've worked with this app before) and before you know it, I had found scripts I'd written long (1.5 years or so) ago. Specifically to pull data from this app and load it into another system.
It still took a little tinkering, but in the end it was a couple hours vs. a couple days.
Life is good.
Alas. No luck. Today was much more pedestrian. Requirements and test data.
Requirements:
Shadow IT development is a kick. In the pants. (The trick is for it not to be a kick in YOUR pants.) I'm guessing a fair number of developers got their start in shade tree IT development. (Hey, that's my foot in the door too, so please don't slam it!)
I want to do the best job I can. And I'm blessed (no, really) with both the perspective of a few years of QA ("is it testable? did you build it to spec?!") as well as systems administration. ("Whaddaya mean there's no support?! Who do I call when this breaks? Where's the documentation on how it's supposed to work? No...1/4 page of fragmented english and a screenshot of a dos command window doesn't cut it..")
And I realized today that, while I've been functioning well enough with some 10,000 foot fuzzy requirements for the proof of concept it's time for some more detailed stuff.
(also because I'm floundering like a beached carp wondering what to do next.)
Should I tackle
- The parser for the peoplesoft-generated text file containing user location data?
- The multi-threading back end so the .exe called by the web app (on the web server) doesn't hog response time.
- Ooohhh...or the user authentication piece. Gotta get that in.
- What about a command-creation factory?
- Umm...logging functionality to record what the users did?
- Oh yeah, and I need to make sure I get some sort of reconciliation doohicky to pull data from VistaPlus (the reports distribution tool), parse it, and compare it to the (several) other "sources of truth" we have available.
Yeah. What's most important?
What do I do _now_? (analysis paralysis, anyone?)
So I started augmenting and cleaning up the schedule I started several weeks ago. And as my fingers wandered aimlessly across the keyboard, I actually managed to see patterns of responsibility and logical progression.
And the logjam in my head started to free. Imagine.
On to testing.
Ahhh....test data. We hardly knew ye.
Well, actually we know ye too d### well.
My current assignment is a web app to help folks manage permissions in our corporate reports distribution tool. We use this for everything from Oracle Financials data to Peoplesoft reports to...well, a lot of stuff.
Anyway. When store managers move around (I work for a large retail organization) or their mgrs, etc, it's not uncommon for it to be weeks or longer before they can get their financials for their newly assigned post.
This is a Bad Thing.
The process by which the tool is updated evolved (you guessed it) in a rather organic fashion. As these things do. Folks did the best with what they knew and had. So we have a process by which emails are forwarded between 3-5 people, in no standard format, and get processed in a batch when there's time.
Where was I? Test data. Oh yeah.
I'm getting to the bit where I actually make the (7-10) changes necessary when someone moves, and I realize I have no data.
None. Nada. Zip. Zilch. Zeeero.
And developing a solution against a "test" database that's populated with 10 records...well...it's just not where I want to go.
So today was spent exporting a copy of (safe!) data from our production server and getting it imported into my little-ol test server.
What did I learn? I (re)learned just how valuable my "keep everthing INCLUDING the kitchen sink in subversion!" habit can be. Instead of being a multi-day process, I just hitched on over there, looked in a few previous project directories (I've worked with this app before) and before you know it, I had found scripts I'd written long (1.5 years or so) ago. Specifically to pull data from this app and load it into another system.
It still took a little tinkering, but in the end it was a couple hours vs. a couple days.
Life is good.
Wednesday, October 10, 2007
What did I learn today?
Ever have one of those days? Days that ... well ... you struggle to find motivation to do much beyond reading the Onion?
I do. So in the spirit of keeping my brain kickstarted and engaged, I thought I'd try to do a "what did I learn today?" post. For about a week and a half. We'll see how it goes.
today..
Yesterday while searching for a canned logging solution that's more robust than my liberal system.diagnostics.debug.writeline's....I came across a couple of things. log4net was developed by the apache group. Big. Robust. Configurable n^n different ways. I'd run across it before and, frankly, run screaming the other way. (at that point my problem was a fly and log4net a howitzer)
Enter NLog. Short. Sweet. To the point. It "Just Works". Add a reference, define your targets in a (blessedly simple) .config file, and you good to go baby! No fuss, no muss, no reinventing the wheel.
Today's learning:
A word to the not-so-wise. (ie, others like me) If you're following along the tutorial (very straightforward and well done, btw), and you decide to create a windows form app instead of a console app. (because. You know. You're not really thinking..) And then you wonder why the "log to console" bit of the tutorial just isn't working...
Yeah. You got it. Console output doesn't just magically pop up in a windows forms app.
(bonus question: why not? Three minutes of googling didn't find me the answer, so I'll table it for now..)
I do. So in the spirit of keeping my brain kickstarted and engaged, I thought I'd try to do a "what did I learn today?" post. For about a week and a half. We'll see how it goes.
today..
Yesterday while searching for a canned logging solution that's more robust than my liberal system.diagnostics.debug.writeline's....I came across a couple of things. log4net was developed by the apache group. Big. Robust. Configurable n^n different ways. I'd run across it before and, frankly, run screaming the other way. (at that point my problem was a fly and log4net a howitzer)
Enter NLog. Short. Sweet. To the point. It "Just Works". Add a reference, define your targets in a (blessedly simple) .config file, and you good to go baby! No fuss, no muss, no reinventing the wheel.
Today's learning:
A word to the not-so-wise. (ie, others like me) If you're following along the tutorial (very straightforward and well done, btw), and you decide to create a windows form app instead of a console app. (because. You know. You're not really thinking..) And then you wonder why the "log to console" bit of the tutorial just isn't working...
Yeah. You got it. Console output doesn't just magically pop up in a windows forms app.
(bonus question: why not? Three minutes of googling didn't find me the answer, so I'll table it for now..)
Subscribe to:
Posts (Atom)
