I've officially appointed my cohort in contracting, Ryan, to be my Blogger Muse, Level I. It seems that every time I feel the need to update this blog and the proverbial well is dry, Ryan somehow seems to bring something out. Thanks, Ryan!
However, this post is a totally new, un-Ryan inspired post. It actually goes back to the week before last week, when Jennifer and I were making the final preparations for her visit with her parents. She and I had gone over everything weeks in advance, on-and-off, in preparation for this. She had explained some of her daily tasks, and shown me the ones I needed to do. Most of this was fairly low-level stuff, as she had a laptop and internet access, but I needed to do it to make her visit less stressful.
When all was said and done, and she was back home, I graded the boys' and my stewardship of the Secret Underground Lair with an approximate 85%+; her grade was closer to 70%, I think. The difference in the grades is not surprising: we got an immediate 10 point deduction for a rules violation. After that, I think the pluses and minuses came close to giving us the relative percentages previously mentioned.
However, this brings me back to the title. I've occasionally thought about chores, and have come to the conclusion that most folks think chores are those uncompensated jobs performed by under-18 year-old minions. I've refined my definition of chores a bit over the years, as I have come to realize that chores are the bits of housework that make a household function- in fact, they do not even require a family. They simply require execution. Part of my attitude about chores goes back to my childhood, particularly my preteen ("tween"... ugh- that's such a goofy word) and teen years. My Mom died just after my fifth birthday, so my Dad and I moved in with his parents. I had "chores" to do, but I think I was okay with doing them because they weren't called chores- they were just things which needed to be done. I always dried the dishes, and when I was old enough, I cut the grass. I also shoveled the snow. I eventually graduated to washing the dishes and doing the laundry, as my grandfather was horrible with both of these tasks. I guess that's why I don't mind doing these things today.
Which leads me to think they should be executed to the best of one's ability. They should also be done by the person who does them best... I started washing clothes after my grandfather washed a pair of my fairly new blue jeans in hot water, totally ruining them in the process. These days, I cut the grass. But in the winter, Jennifer operates the snow blower (I shovel). Jennifer normally does the bills and budget stuff. She and I both do the dishes, but she does almost all of the cooking and meal preparation. I do all of the computer, printer and network stuff. There are other things, but we avoid a lot of tension by working things the way we do.
Database stuff: Data entry is the focus for the moment. The queries need to be rebuilt, but there's no rush. I have 125 new entries (spread through three tables) from the last time I counted (Aug 9- yes, there's a spreadsheet for this... after all, I do write about data analysis AND management), which isn't a huge amount, but it's progress.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Monday, August 19, 2013
Saturday, August 17, 2013
Peace, Love & TQM
After a couple straight database-laden posts, I thought I'd go back to the somewhat more familiar format I've been following- that is, the larger part of the post being about life in the Secret Underground Lair, followed with a bit of database news. That's a polite way of saying: until I get back to rebuilding my queries, it's pretty much going to be data entry for a while!
My cohort in contracting has said on several occasions that to force writing is to end up with forced writing. Well, something along those lines. As I was leaving the office this morning, I said to him in parting, "Peace, Love and TQM!" It's such an odd phrase, coined by yours truly in Germany, in the halcyon days of The Drawdown following the end of Desert Storm. And this is the crux of today's musings.
In any environment where the same folks gather on a regular basis- whether it be professional, social or casual, a common vocabulary will emerge as these individuals get to know each other and become comfortable and maybe friendly. Beyond lingo, jargon or truisms, a certain "groupspeak" will emerge. Groupspeak, according to wiktionary.com, is "The jargon used by a particular group." They go on to define jargon as,
There are a few different ways in which we announce that we are leaving for the day. "I don't know about you all, ..." is Adrian's phrase; Jimmy Z's is, "I gotta get out of here" and mine is, "I've had enough fun for one day".
A great deal of what we do at night and overnight is quality control, which sometimes requires us to engage with folks from different departments or even facilities in different parts of the country. One evening, we were checking some work for a job we were doing for another facility, and we had to call the Customer Service Representative (CSR) for advice on this particular job (this particular CSR has long since left the company). First we asked about some counts, and the CSR said, "Is that really important?" Uh, yes, it is. Next, there was another issue and the response was," Do you think they'll notice?" Uh, yes. The last question was answered with, "Does it really matter?" These legendary, epic responses have become a regular part of our groupspeak and are invoked whenever something that obviously needs to be fixed shows up.
There are many others, of course, but one final group is the ones which just don't really mean anything- things like "Where do I sign?" (where something should be done, but the speaker indicates that another person has thoroughly checked something out), "He's off my Christmas card list", which indicates someone has done something particularly inane. And then there's the Jimmy Z all-time classic, "It's a setup!" in cases where something has gone horribly wrong, or where someone else has started a job, and then goes on vacation, leaving all sorts of potential disaster on the table (as well as all of the responsibility).
That's it for today. As mentioned, I'm pretty much to data entry mode, so no database news today.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
My cohort in contracting has said on several occasions that to force writing is to end up with forced writing. Well, something along those lines. As I was leaving the office this morning, I said to him in parting, "Peace, Love and TQM!" It's such an odd phrase, coined by yours truly in Germany, in the halcyon days of The Drawdown following the end of Desert Storm. And this is the crux of today's musings.
In any environment where the same folks gather on a regular basis- whether it be professional, social or casual, a common vocabulary will emerge as these individuals get to know each other and become comfortable and maybe friendly. Beyond lingo, jargon or truisms, a certain "groupspeak" will emerge. Groupspeak, according to wiktionary.com, is "The jargon used by a particular group." They go on to define jargon as,
- (uncountable) A technical terminology unique to a particular subject.
- (countable) Language characteristic of a particular group.
- (uncountable) Speech or language that is incomprehensible or unintelligible; gibberish.
There are a few different ways in which we announce that we are leaving for the day. "I don't know about you all, ..." is Adrian's phrase; Jimmy Z's is, "I gotta get out of here" and mine is, "I've had enough fun for one day".
A great deal of what we do at night and overnight is quality control, which sometimes requires us to engage with folks from different departments or even facilities in different parts of the country. One evening, we were checking some work for a job we were doing for another facility, and we had to call the Customer Service Representative (CSR) for advice on this particular job (this particular CSR has long since left the company). First we asked about some counts, and the CSR said, "Is that really important?" Uh, yes, it is. Next, there was another issue and the response was," Do you think they'll notice?" Uh, yes. The last question was answered with, "Does it really matter?" These legendary, epic responses have become a regular part of our groupspeak and are invoked whenever something that obviously needs to be fixed shows up.
There are many others, of course, but one final group is the ones which just don't really mean anything- things like "Where do I sign?" (where something should be done, but the speaker indicates that another person has thoroughly checked something out), "He's off my Christmas card list", which indicates someone has done something particularly inane. And then there's the Jimmy Z all-time classic, "It's a setup!" in cases where something has gone horribly wrong, or where someone else has started a job, and then goes on vacation, leaving all sorts of potential disaster on the table (as well as all of the responsibility).
That's it for today. As mentioned, I'm pretty much to data entry mode, so no database news today.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Monday, August 12, 2013
#notsobigdata Query fail
As Mel the cook on (the television show) Alice is purported to have said, "The best D fence is a good O fence". If true, that Mel was a man wise beyond his years. I'll bet he also moonlighted as a data analyst when he wasn't flipping greasy burgers.
Once again, I've lead off with a comment that is seemingly unconnected to anything- but when it comes to relational databases in which most everything is related to nearly everything in some way, shape or form, as the administrator, manager or designer one needs to be constantly aware of what is going on with the Precious. Er, I mean, the data.
A few days ago I had the opportunity to do a little bit of Show and Tell with a buddy and my database. As the database started out as a catalog of our audio and video collections, it's still very heavy with those sorts of records. My buddy was fairly amazed at the amount of movies we have (I'm not sure I've mentioned this before, but I coined the term "videot" with our son Daniel in mind, as he's constantly spurting out factoids and sundry other movie trivia... if I didn't know better, I'd think the "D" in IMDB.com stood for "Daniel" rather than "Data"). I've tried very hard from the onset to make the database accessible (no pun intended) and logical, and judging by my buddy's reaction, I think I succeeded. We were looking at all sorts of records and I was explaining as we went along some of the features and why it had been set up in the way that it was. Then he said, "Wouldn't it be pretty easy and useful to add another column in here that tells where each item is stored?" That, gentle readers, was an epiphany: in a instant he went from one who had never seen a database before and barely knowing what it could do, to making a suggestion to make it more powerful and useful. I told him, "Yes, thanks- I'd been planning on doing that, but it will take one or two more tables to do it properly."
Here's where planning and design come into play. I could add a column, and have a drop-down list for my locations... IF the number of locations was immutable and fairly small. I've done this in other databases where the dataset itself was finite and would not ever shrink or grow. In my situation, our organization is sometimes quite good, and at other times nonexistent. Additionally, we're always looking for ways (well, I am, at least) of improving storage... it does not always work as planned. In fact, a thought just occurred to me that involves the P-Touch. The more I think about this particular idea, the more I feel the need to utilize Visio and Excel- I have a rudimentary asset tag system, but it needs a bit of tweaking....
STOP! Find a happy data place, find a happy data place, find a happy data place.
This week's goal is to continue with data entry and to work on the physical area around Jennifer's PC, as I have some stacks of paper that need to go to a better place. Also, ALL of the queries need to be rebuilt. Although I do use ad hoc queries fairly often, I rely quite heavily on permanent queries for many things, such as deduping and making lists to output to Excel for analysis and counting. And yes, I am aware that in the #notsobigdata world, these tasks could be done in Access, but my little black book of best software practices says that one should use the best tool for the job. The reason for all that? I was going to show my buddy how queries worked, but I had broken all of them when I added a new lookup table to the primary table, so now they are all gone and need to be reconstructed. Vigilance is the price one must pay for clean data.
And now, it's time to wrap this up. I'm checking out of the Inn at the Stream of Consciousness and getting back to work. And, ...
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Postscript- Every so often, I will feature some older posts- here are today's group.
Once again, I've lead off with a comment that is seemingly unconnected to anything- but when it comes to relational databases in which most everything is related to nearly everything in some way, shape or form, as the administrator, manager or designer one needs to be constantly aware of what is going on with the Precious. Er, I mean, the data.
A few days ago I had the opportunity to do a little bit of Show and Tell with a buddy and my database. As the database started out as a catalog of our audio and video collections, it's still very heavy with those sorts of records. My buddy was fairly amazed at the amount of movies we have (I'm not sure I've mentioned this before, but I coined the term "videot" with our son Daniel in mind, as he's constantly spurting out factoids and sundry other movie trivia... if I didn't know better, I'd think the "D" in IMDB.com stood for "Daniel" rather than "Data"). I've tried very hard from the onset to make the database accessible (no pun intended) and logical, and judging by my buddy's reaction, I think I succeeded. We were looking at all sorts of records and I was explaining as we went along some of the features and why it had been set up in the way that it was. Then he said, "Wouldn't it be pretty easy and useful to add another column in here that tells where each item is stored?" That, gentle readers, was an epiphany: in a instant he went from one who had never seen a database before and barely knowing what it could do, to making a suggestion to make it more powerful and useful. I told him, "Yes, thanks- I'd been planning on doing that, but it will take one or two more tables to do it properly."
Here's where planning and design come into play. I could add a column, and have a drop-down list for my locations... IF the number of locations was immutable and fairly small. I've done this in other databases where the dataset itself was finite and would not ever shrink or grow. In my situation, our organization is sometimes quite good, and at other times nonexistent. Additionally, we're always looking for ways (well, I am, at least) of improving storage... it does not always work as planned. In fact, a thought just occurred to me that involves the P-Touch. The more I think about this particular idea, the more I feel the need to utilize Visio and Excel- I have a rudimentary asset tag system, but it needs a bit of tweaking....
STOP! Find a happy data place, find a happy data place, find a happy data place.
This week's goal is to continue with data entry and to work on the physical area around Jennifer's PC, as I have some stacks of paper that need to go to a better place. Also, ALL of the queries need to be rebuilt. Although I do use ad hoc queries fairly often, I rely quite heavily on permanent queries for many things, such as deduping and making lists to output to Excel for analysis and counting. And yes, I am aware that in the #notsobigdata world, these tasks could be done in Access, but my little black book of best software practices says that one should use the best tool for the job. The reason for all that? I was going to show my buddy how queries worked, but I had broken all of them when I added a new lookup table to the primary table, so now they are all gone and need to be reconstructed. Vigilance is the price one must pay for clean data.
And now, it's time to wrap this up. I'm checking out of the Inn at the Stream of Consciousness and getting back to work. And, ...
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Postscript- Every so often, I will feature some older posts- here are today's group.
Saturday, August 10, 2013
#notsobigdata
Yes, I did create the twitter hashtag #notsobigdata in the wee hours of Wednesday, August 7. It is for my Not-so-big-data theme. And even though I realize that Big Data is the future, Not-so-big-data is the here, and the now, ... and the foreseeable future.
Not-so-big-data can still be a lot of data. For example, I once worked as a data analyst for a Wal Mart vendor. This was back in the Excel 2000 days, when Excel had a limitation of 65,536 rows. Even though I reported on only six to eight SKUs on each weekly report, there were weeks where the data exceeded Excel's capabilities, and I had to grab the data in Access, and then slice and dice it into chunks that the Excel of the day could handle. It was also at this time that I became familiar with what is seriously the best mouse ever devised- the Logitech Trackman Marble. I had never had to select 60,000+ rows of Excel data before, but this mouse made that task easy. We own four of them.
Getting back to not-so-big-data...
Not-so-big-data is what we deal with on a daily or weekly or monthly basis. Some of it is eclectic and ad hoc, often never gracing a ledger or spreadsheet... data like fuel economy or utility usage, but maybe bits and pieces of the family or organizational budget. The bottom line is that these dollars and cents (or whatever one's local currency happens to be) are important, at least for the day or week or other short period of time in question. Jennifer is a perfect example of a not-so-big-data consumer.
And not only is she a perfect example of the not-so big-data consumer, she's also an expert not-so-big-data manager and analyst. As an example, our has meters for gas, water and electricity. Even though these utilities employ meter readers, we send in our readings every month, because when the utilities don't read the meters, they estimate usage. And sometimes, the meter readers just plain make mistakes. We were on the wrong end of a meter reading error once- a 100 USD mistake. Jennifer caught this, and the mistake was corrected.
Along a similar line of thought, I was doing some data entry in one of my Access tables on Thursday before going in to work, and I ran into some duplicate records, or "dupes" for short. There were at least six sets of dupes. Egad! I was not happy to find them, as I am typically pretty vigilant about my rules. This particular table ("Names") currently only has two columns- the autonumber and the name. Right now, the only purpose the table serves is to force normalization in the current primary ("Media") table. The Names table is the sole source of data for the Artist/Author column in the media table- I do not allow free data entry into areas that are prone to seeing repetitive data. As I was working with some books, I glanced over at the bookshelf and replaced the dupes with authors which had not yet been entered into this table. Adding insult to injury, I know exactly when and how the errors occurred.
I had been entering the data of some compilation music cassettes a few weeks ago, and as each cassette has a number of artists, I got a bit careless and just entered several- instead of checking to see if there already was a record. And so for a moment's complacence, I had to spend time fixing rather than creating. I hope to eliminate this from ever happening again by double-checking to see that there are no more dupes in the table, and then setting the duplicates property of the field to == no duplicates.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Not-so-big-data can still be a lot of data. For example, I once worked as a data analyst for a Wal Mart vendor. This was back in the Excel 2000 days, when Excel had a limitation of 65,536 rows. Even though I reported on only six to eight SKUs on each weekly report, there were weeks where the data exceeded Excel's capabilities, and I had to grab the data in Access, and then slice and dice it into chunks that the Excel of the day could handle. It was also at this time that I became familiar with what is seriously the best mouse ever devised- the Logitech Trackman Marble. I had never had to select 60,000+ rows of Excel data before, but this mouse made that task easy. We own four of them.
Getting back to not-so-big-data...
Not-so-big-data is what we deal with on a daily or weekly or monthly basis. Some of it is eclectic and ad hoc, often never gracing a ledger or spreadsheet... data like fuel economy or utility usage, but maybe bits and pieces of the family or organizational budget. The bottom line is that these dollars and cents (or whatever one's local currency happens to be) are important, at least for the day or week or other short period of time in question. Jennifer is a perfect example of a not-so-big-data consumer.
And not only is she a perfect example of the not-so big-data consumer, she's also an expert not-so-big-data manager and analyst. As an example, our has meters for gas, water and electricity. Even though these utilities employ meter readers, we send in our readings every month, because when the utilities don't read the meters, they estimate usage. And sometimes, the meter readers just plain make mistakes. We were on the wrong end of a meter reading error once- a 100 USD mistake. Jennifer caught this, and the mistake was corrected.
Along a similar line of thought, I was doing some data entry in one of my Access tables on Thursday before going in to work, and I ran into some duplicate records, or "dupes" for short. There were at least six sets of dupes. Egad! I was not happy to find them, as I am typically pretty vigilant about my rules. This particular table ("Names") currently only has two columns- the autonumber and the name. Right now, the only purpose the table serves is to force normalization in the current primary ("Media") table. The Names table is the sole source of data for the Artist/Author column in the media table- I do not allow free data entry into areas that are prone to seeing repetitive data. As I was working with some books, I glanced over at the bookshelf and replaced the dupes with authors which had not yet been entered into this table. Adding insult to injury, I know exactly when and how the errors occurred.
I had been entering the data of some compilation music cassettes a few weeks ago, and as each cassette has a number of artists, I got a bit careless and just entered several- instead of checking to see if there already was a record. And so for a moment's complacence, I had to spend time fixing rather than creating. I hope to eliminate this from ever happening again by double-checking to see that there are no more dupes in the table, and then setting the duplicates property of the field to == no duplicates.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Sunday, August 4, 2013
Driver's Seat
A discussion occurred at work a few days ago, and true to form, it was not linear. It started out well enough. A coworker- actually a fellow contractor- was relating a story to me about a chance encounter a friend of his had with a celebrity. Both his friend and the celebrity were in the green room of a radio station getting ready to tape interviews with a nationally syndicated talk show host which I'm guessing neither one liked. However, there is a saying that goes something like, "No publicity is bad publicity".
The celebrity in question was big in the Eighties for a while, and had put out some music which I like, and this was still on my mind as I left work a short time later. I loaded my gear in truck, fired up the engine and headed home. A song was playing on the radio, and I thought to myself, "That song just isn't appropriate to drive to." I don't remember the song, but it was around 0400, and at that time of the morning not all songs really strike a chord. The two songs after that were Stevie Nicks' Edge of Seventeen and Little River Band's The Night Owls. Both of these I regard as being excellent nighttime driving songs. Another great one, of course, is the title of this post, Driver's Seat by Sniff 'n' The Tears. Don Henley's Boys of Summer and even Donna Summer's Hot Stuff fit into the category of driving songs, as well as selections from Johnny Cash, George Thorogood, The Cars and a host of others.
Of course, whether one is going out or coming back also weighs heavily on the music selection. Don Felder's Heavy Metal (Takin' A Ride) and John Fogerty's Centerfield are both great going out songs, but for the return trip, something a bit more mellow and introspective is often appropriate- and this is where it gets a bit complicated. Barry Manilow is almost never driving music, but Neil Diamond might be. Similarly, the Eagles did a lot of great driving music, but great care must be taken in choosing their music. Just for starters, James Dean and Already Gone are definitely outbound songs, but Ol '55 is definitely a return trip song, as is New Kid In Town. Otis Redding's Sittin' By The Dock Of The Bay also fits in the return trip category.
And then there are the songs that just will play well whether the sun is just going down, or the birds are just starting to chirp. The Blues Brothers' Sweet Home Chicago and most of the collected works of Abba and Shania Twain fit here.
Database news: I've done a bit of light data entry recently, but nothing worth updating any statistics as of yet. I'm kicking around some ideas for a new table, but as it will include computers (and their innards, software and peripherals) I need to actually spend a bit of time and thought on this, and actually design it before building the table. In the interim, I'll be adding names to the Publisher/Manufacturer table.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Of course, whether one is going out or coming back also weighs heavily on the music selection. Don Felder's Heavy Metal (Takin' A Ride) and John Fogerty's Centerfield are both great going out songs, but for the return trip, something a bit more mellow and introspective is often appropriate- and this is where it gets a bit complicated. Barry Manilow is almost never driving music, but Neil Diamond might be. Similarly, the Eagles did a lot of great driving music, but great care must be taken in choosing their music. Just for starters, James Dean and Already Gone are definitely outbound songs, but Ol '55 is definitely a return trip song, as is New Kid In Town. Otis Redding's Sittin' By The Dock Of The Bay also fits in the return trip category.
And then there are the songs that just will play well whether the sun is just going down, or the birds are just starting to chirp. The Blues Brothers' Sweet Home Chicago and most of the collected works of Abba and Shania Twain fit here.
Database news: I've done a bit of light data entry recently, but nothing worth updating any statistics as of yet. I'm kicking around some ideas for a new table, but as it will include computers (and their innards, software and peripherals) I need to actually spend a bit of time and thought on this, and actually design it before building the table. In the interim, I'll be adding names to the Publisher/Manufacturer table.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Monday, July 29, 2013
Where the streets have no names
As with many other places, roadways in this part of the world more often than not have names. Some in particular - notably State Routes, U.S. Highways and Interstate Highways- are generally identified by numerals. In our little corner though, we often have roads that change names as one travels from town to town, or suburb to suburb. What's interesting about the particular road the title refers to is that while their names may change, their numbers do not.
To illustrate, I had interviews at a pair of staffing agencies this past week, one to the south and one to the northwest. The one to the south (and slightly west) was ~15.2 miles (33.4 km) according to Google Maps, and the one to the northwest was about 16.6 miles (36.5 km), also according to Google Maps. What makes these trips related are the purposes and the streets involved. On Tuesday, I used Higgins Road (Illinois Route 83), traveling south to Butterfield Road (Illinois Route 56), which I took to my destination near the intersection of Butterfield and 22nd St (which is also known both as Illinois Route 38 and Cermak Road). On Wednesday, I took Higgins north all the way to my destination.
What I find most fascinating about all of this is the relatively illogical naming conventions of roadways. Here is where Jennifer and I often have discussions about Chicago, where I grew up. These discussions generally end up with her saying something to the effect of, "Streets in Chicago don't make any sense." Which I don't really understand... then again, she didn't grow up in a big city. The thing that makes it all so interesting is that neither of us gets what the other one doesn't get... and we've been married for over twenty-five years!
I was going to wax eloquently and at great length here about the Chicago grid system, but in truth the information I found would be boring- even by my standards. So, I'll just leave it alone, save for this explanation: to tell someone ( a fellow Chicagoan) where I used to live in Chicago would have taken (at most) seven words: twenty-five hundred north and fifty-six hundred west. Where I currently live, a short paragraph would work... IF you knew the neighborhood. 'Nuff said.
I started writing this several days ago, and have been trying to publish it all week. I think I've mentioned before that my sporadic work hours can be bursty at times- this week, I had an unexpected Tuesday night, followed by consecutive ten hour nights when I came home at 0500 on Wednesday, and 0600 on Thursday (*actually 0500 Thursday and 0600 Friday morning!)
I've been looking for a foundational database design book, and the one pictured I found at our library. It's ancient as far as I.T. books go (copyright 1987). I'm fairly certain that I will not finish it: even though it has some pretty good design information, the terminology is not up to current standards (the author seemed to like the term "enterprise", but it does not seem to mean what "enterprise" means in the twenty-first century.
I need to wrap this up- it's nearly a week past due, even by my lax standards. I took a picture of our roses of sharon in our yard this past week... they're a poor substitute for data, but they look nice.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
To illustrate, I had interviews at a pair of staffing agencies this past week, one to the south and one to the northwest. The one to the south (and slightly west) was ~15.2 miles (33.4 km) according to Google Maps, and the one to the northwest was about 16.6 miles (36.5 km), also according to Google Maps. What makes these trips related are the purposes and the streets involved. On Tuesday, I used Higgins Road (Illinois Route 83), traveling south to Butterfield Road (Illinois Route 56), which I took to my destination near the intersection of Butterfield and 22nd St (which is also known both as Illinois Route 38 and Cermak Road). On Wednesday, I took Higgins north all the way to my destination.
What I find most fascinating about all of this is the relatively illogical naming conventions of roadways. Here is where Jennifer and I often have discussions about Chicago, where I grew up. These discussions generally end up with her saying something to the effect of, "Streets in Chicago don't make any sense." Which I don't really understand... then again, she didn't grow up in a big city. The thing that makes it all so interesting is that neither of us gets what the other one doesn't get... and we've been married for over twenty-five years!
I was going to wax eloquently and at great length here about the Chicago grid system, but in truth the information I found would be boring- even by my standards. So, I'll just leave it alone, save for this explanation: to tell someone ( a fellow Chicagoan) where I used to live in Chicago would have taken (at most) seven words: twenty-five hundred north and fifty-six hundred west. Where I currently live, a short paragraph would work... IF you knew the neighborhood. 'Nuff said.
I've been looking for a foundational database design book, and the one pictured I found at our library. It's ancient as far as I.T. books go (copyright 1987). I'm fairly certain that I will not finish it: even though it has some pretty good design information, the terminology is not up to current standards (the author seemed to like the term "enterprise", but it does not seem to mean what "enterprise" means in the twenty-first century.
I need to wrap this up- it's nearly a week past due, even by my lax standards. I took a picture of our roses of sharon in our yard this past week... they're a poor substitute for data, but they look nice.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Wednesday, July 24, 2013
A word, in any language...
I had this thought the other day. It's a thought one only really has after having studied another language for some time. Even having said that, I think I need to back up just a bit.
I'm not sure how things work in the rest of the world, but here in the United States of America, foreign language instruction can be somewhat challenging. For example, in most parts of Western Europe, English is taught- mainly because of business requirements... I believe this is also true of Japan. In the U.S.A., Spanish is more likely to be taught than any other language, primarily because of cultural reasons (and, because of the perceived ease of learning Spanish).
When I was in high school (gymnasium), I elected to take four years of German. This was slightly odd, but pretty much fit in with my character. Prior to that, I had a couple years of Polish in grade school. In college, I was exposed to Russian and French. Courtesy of the United States Air Force, I met Czech, Jennifer and Slovak. I have studied a few other languages more casually, as well as working on some computer languages.
So, today I'm writing this- not so much as a polyglot, but as someone who has studied a number of languages and survived.
My original thought was "words in another language" that were memorable. I have a short list of these, and they make me laugh- not because of their definitions, but just because of the way they sound to this particular English speaker.
My very favorite German word is "zusammengestossen". Like many German words, its a compound and pretty long. "Stau" is another great German word- it essentially means "a freakishly long traffic jam involving multiple wrecks". You won't find that definition in the dictionary, but that's pretty much what it is. Also, another long-time favorite German word is "ausgezeichnet". One word almost got me in trouble in Germany, and I can laugh about it now. I had to find an apartment "on the economy" before Jennifer could join me in Europe, so one of the guys in the squadron who was married to a German woman took me to a German realtor. His knowledge of colloquial German was pretty good, but I had studied it in high school, so my German knowledge was a little different than his. We were talking to the realtor, and my new friend was trying to explain the paperwork process back at the base. There are a good number of words that are cognates in the two languages, but in this instance he picked a false cognate, saying "der Prozess" for "the process". Before the realtor had the opportunity to inquire further, I quickly interjected, "Kein Prozess! Kein Prozess!", because, of course, anyone who has taken more than a few years of German would immediately remember that "Der Prozess" is the title of one of Franz Kafka's most famous works, which in English is "The Trial"- as in, a trial in a court of law!
"Merde" is my favorite French word. It's so portable, and quite down-to-earth. (I really can't think of "Bill and Ted's Excellent Adventure" without the scene of Napoleon in the bowling alley popping up!). "Roi" and "Rue" are also favorites. They're a few of the first words I encountered that were used to instruct the correct pronounciation of the French "r".
пожалуйста is my favorite Russian word (yes, I took a semester of Russian!) It's quite a complicated word to a native English speaker, but it embodies Russian-ness. нравиться is another favorite. I should make note here why these particular words are favorites: in Russian, these words are fairly complex sounding to the ear accustomed to English sounds. And, their English equivalents are fairly simple in comparison.
Lastly, there's a Czech word that brings back fond memories- "potřebovat". It's a very basic word, and not particularly funny, except I had this one classmate who absolutely could not pronounce this word, and every time he tried it sounded like some lost in love wildebeest howling in bewilderment after eating a jar of pickled hot peppers. He would turn red, and everyone would laugh!
So that's a short version of some of my language experiences.
Not much to report on the database front, but I had something of an epiphany at an employment agency today which is data related. During the interview, I was asked what sort of position I was seeking. I replied, "I'm more of a generalist than a specialist," and proceeded to explain some of my job background. As I was doing this, I suddenly realized that I had more data analysis experience than I had given myself credit for.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
I'm not sure how things work in the rest of the world, but here in the United States of America, foreign language instruction can be somewhat challenging. For example, in most parts of Western Europe, English is taught- mainly because of business requirements... I believe this is also true of Japan. In the U.S.A., Spanish is more likely to be taught than any other language, primarily because of cultural reasons (and, because of the perceived ease of learning Spanish).
When I was in high school (gymnasium), I elected to take four years of German. This was slightly odd, but pretty much fit in with my character. Prior to that, I had a couple years of Polish in grade school. In college, I was exposed to Russian and French. Courtesy of the United States Air Force, I met Czech, Jennifer and Slovak. I have studied a few other languages more casually, as well as working on some computer languages.
So, today I'm writing this- not so much as a polyglot, but as someone who has studied a number of languages and survived.
My original thought was "words in another language" that were memorable. I have a short list of these, and they make me laugh- not because of their definitions, but just because of the way they sound to this particular English speaker.
My very favorite German word is "zusammengestossen". Like many German words, its a compound and pretty long. "Stau" is another great German word- it essentially means "a freakishly long traffic jam involving multiple wrecks". You won't find that definition in the dictionary, but that's pretty much what it is. Also, another long-time favorite German word is "ausgezeichnet". One word almost got me in trouble in Germany, and I can laugh about it now. I had to find an apartment "on the economy" before Jennifer could join me in Europe, so one of the guys in the squadron who was married to a German woman took me to a German realtor. His knowledge of colloquial German was pretty good, but I had studied it in high school, so my German knowledge was a little different than his. We were talking to the realtor, and my new friend was trying to explain the paperwork process back at the base. There are a good number of words that are cognates in the two languages, but in this instance he picked a false cognate, saying "der Prozess" for "the process". Before the realtor had the opportunity to inquire further, I quickly interjected, "Kein Prozess! Kein Prozess!", because, of course, anyone who has taken more than a few years of German would immediately remember that "Der Prozess" is the title of one of Franz Kafka's most famous works, which in English is "The Trial"- as in, a trial in a court of law!
"Merde" is my favorite French word. It's so portable, and quite down-to-earth. (I really can't think of "Bill and Ted's Excellent Adventure" without the scene of Napoleon in the bowling alley popping up!). "Roi" and "Rue" are also favorites. They're a few of the first words I encountered that were used to instruct the correct pronounciation of the French "r".
пожалуйста is my favorite Russian word (yes, I took a semester of Russian!) It's quite a complicated word to a native English speaker, but it embodies Russian-ness. нравиться is another favorite. I should make note here why these particular words are favorites: in Russian, these words are fairly complex sounding to the ear accustomed to English sounds. And, their English equivalents are fairly simple in comparison.
Lastly, there's a Czech word that brings back fond memories- "potřebovat". It's a very basic word, and not particularly funny, except I had this one classmate who absolutely could not pronounce this word, and every time he tried it sounded like some lost in love wildebeest howling in bewilderment after eating a jar of pickled hot peppers. He would turn red, and everyone would laugh!
So that's a short version of some of my language experiences.
Not much to report on the database front, but I had something of an epiphany at an employment agency today which is data related. During the interview, I was asked what sort of position I was seeking. I replied, "I'm more of a generalist than a specialist," and proceeded to explain some of my job background. As I was doing this, I suddenly realized that I had more data analysis experience than I had given myself credit for.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
Subscribe to:
Posts (Atom)