I was reading through some of Tanel Poder's older blog posts and came across one he did entitled: Running SQL scripts from remote locations using HTTP. Wow! How many times could I have used this before now?
I've used SQL*Plus forever but just never realized that I could execute a script stored on my web server like this. I won't repeat Tanel's details here, but go take a look at this post to see a few examples.
This will be something I implement and am sure it will be really helpful. I love it when I learn something new! Thanks Tanel!
Pages
▼
Friday, May 30, 2008
Hats
I was just thinking about the analogy that is often used about someone wearing a lot of different hats. As far as actual hats go, it's kinda funny...I love hats, but I don't really wear them that often. I have quite a collection of different hats: baseball hats with lots of different logos, floppy sun hats, visors and I've even owned a cowboy hat or two in days gone by.
But, the idea of wearing hats as an indicator of the different roles a person fulfills is what I've been pondering. I wear a lot of hats. In my business life, I'm a teacher, a developer, a DBA, a consultant, a researcher, a speaker, a writer, a student, a designer, a teammate, a manager, and on and on. In my personal life, I'm a daughter, a grand-daughter, a sister, an aunt, a partner, a mother, a friend, and on and on. A lot of adjectives come to mind too that I suppose would be hats too: perfectionist, seeker, wanderer, peace-maker, and on and on.
So, like I said, I wear a lot of hats. Some days it seems all I do is switch hats. Sometimes it gets tiring. At the end of the day, I occasionally feel as if I haven't gotten much accomplished because it seems like I spent most of my time shifting gears ... and switching hats.
But, I think I really like having so many hats to wear. Imagine if you only had one hat, and you wore it all the time. It'd get dirty and worn and might not even fit so well after a time...but if it's your only hat, you'd have to keep wearing it.
So, even on days when it seems all I do is change hats, I think I'll look back at the end of the day and be glad for it. If variety is the spice of life, and I've got lots of hats, then my life should be quite interesting, and spicy, indeed. And speaking of interesting....
What kinds of hats do you wear?
But, the idea of wearing hats as an indicator of the different roles a person fulfills is what I've been pondering. I wear a lot of hats. In my business life, I'm a teacher, a developer, a DBA, a consultant, a researcher, a speaker, a writer, a student, a designer, a teammate, a manager, and on and on. In my personal life, I'm a daughter, a grand-daughter, a sister, an aunt, a partner, a mother, a friend, and on and on. A lot of adjectives come to mind too that I suppose would be hats too: perfectionist, seeker, wanderer, peace-maker, and on and on.
So, like I said, I wear a lot of hats. Some days it seems all I do is switch hats. Sometimes it gets tiring. At the end of the day, I occasionally feel as if I haven't gotten much accomplished because it seems like I spent most of my time shifting gears ... and switching hats.
But, I think I really like having so many hats to wear. Imagine if you only had one hat, and you wore it all the time. It'd get dirty and worn and might not even fit so well after a time...but if it's your only hat, you'd have to keep wearing it.
So, even on days when it seems all I do is change hats, I think I'll look back at the end of the day and be glad for it. If variety is the spice of life, and I've got lots of hats, then my life should be quite interesting, and spicy, indeed. And speaking of interesting....
What kinds of hats do you wear?
Thursday, May 29, 2008
"dual"-ing for resources
Oracle 9.2.0.6 on AIX
Application module running in 12 concurrent streams (12 CPU box)
Total response time (%R) = 18 minutes 55 seconds
Total executions of "SELECT ... FROM dual" = 1,087,770
Total logical I/O's = 3,263,033
Contribution to R = 32.9%
Actual code:
I believe this is the most inefficient way I've ever seen to determine the next business day (not counting holidays) when an account will become n days delinquent. Admittedly, this code gets better (performance wise) in v10 with the addition of FAST DUAL, but still... There's only one SELECT (on the holiday table, UTRHLDY) that appears to be needed at all. Why use DUAL to calculate and format dates? Ever hear of variable assignment?
I suppose you've gotta laugh, huh? This may be one for the Oracle WTF!
Application module running in 12 concurrent streams (12 CPU box)
Total response time (%R) = 18 minutes 55 seconds
Total executions of "SELECT ... FROM dual" = 1,087,770
Total logical I/O's = 3,263,033
Contribution to R = 32.9%
Actual code:
PROCEDURE next_delq_date
(DUE_DATE IN VARCHAR2,
DELQ_DAYS IN NUMBER,
ACTION_DATE IN OUT VARCHAR2)
IS
DAY_NUM NUMBER;
HOLIDAY_DATE VARCHAR2(11);
BEGIN
BEGIN
ACTION_DATE := DUE_DATE;
FOR DAYS_COUNT IN 1..DELQ_DAYS LOOP
SELECT TO_CHAR(TO_DATE
(ACTION_DATE,'DD-MON-YYYY')+1, 'DD-MON-YYYY')
INTO ACTION_DATE FROM DUAL;
SELECT TO_CHAR(TO_DATE
(ACTION_DATE,'DD-MON-YYYY'),'D')
INTO DAY_NUM
FROM DUAL;
IF DAY_NUM = 1 THEN
SELECT TO_CHAR(TO_DATE
(ACTION_DATE,'DD-MON-YYYY')+1, 'DD-MON-YYYY')
INTO ACTION_DATE FROM DUAL;
END IF;
IF DAY_NUM = 7 THEN
SELECT TO_CHAR(TO_DATE
(ACTION_DATE,'DD-MON-YYYY')+2, 'DD-MON-YYYY')
INTO ACTION_DATE FROM DUAL;
END IF;
LOOP
HOLIDAY_DATE := NULL;
BEGIN
SELECT TO_CHAR(UTRHLDY_DATE,'DD-MON-YYYY')
INTO HOLIDAY_DATE FROM UTRHLDY
WHERE UTRHLDY_DATE = to_date(ACTION_DATE,'DD-MON-YYYY')
AND ROWNUM < 2;
EXCEPTION WHEN NO_DATA_FOUND THEN
HOLIDAY_DATE := NULL;
END;
IF HOLIDAY_DATE IS NULL THEN
EXIT;
END IF;
IF HOLIDAY_DATE IS NOT NULL THEN
SELECT TO_CHAR(TO_DATE(ACTION_DATE,'DD-MON-YYYY')+1, 'DD-MON-YYYY')
INTO ACTION_DATE FROM DUAL;
SELECT TO_CHAR(TO_DATE(ACTION_DATE,'DD-MON-YYYY'),'D')
INTO DAY_NUM FROM DUAL;
IF DAY_NUM = 1 THEN
SELECT TO_CHAR(TO_DATE(ACTION_DATE,'DD-MON-YYYY')+1, 'DD-MON-YYYY')
INTO ACTION_DATE FROM DUAL;
END IF;
IF DAY_NUM = 7 THEN
SELECT TO_CHAR(TO_DATE(ACTION_DATE,'DD-MON-YYYY')+2, 'DD-MON-YYYY')
INTO ACTION_DATE FROM DUAL;
END IF;
END IF;
END LOOP;
END LOOP;
END;
END;
I believe this is the most inefficient way I've ever seen to determine the next business day (not counting holidays) when an account will become n days delinquent. Admittedly, this code gets better (performance wise) in v10 with the addition of FAST DUAL, but still... There's only one SELECT (on the holiday table, UTRHLDY) that appears to be needed at all. Why use DUAL to calculate and format dates? Ever hear of variable assignment?
I suppose you've gotta laugh, huh? This may be one for the Oracle WTF!
Wednesday, May 28, 2008
Mistakes
I've often learned more from my mistakes than my successes. And, I've also felt more pride in myself when I've persevered through several failed attempts when I finally got it right.
So many times I see people unwilling to try something outside their comfort zone (myself included), because they're afraid of failure. When I'm on customer site, I'll often see people afraid to try new things (code changes, adding an index, etc.) even when they have proof provided to them of how doing something different can/will improve things. They're afraid to try even when the odds look very much in their favor.
Why do we fear the attempt so much? Do we think we'll lose our jobs, our good reputation, or even our anonymity? Do we just want to fly under the radar and do enough to get by and not call attention to ourselves, neither good nor bad?
I'm not suggesting to run willy-nilly making unthinking mistakes when it counts over and over. Make mistakes when you test. Make mistakes as you invent. Make mistakes on the way to the finish line. Taking time to do it right the first time includes the time it takes to make mistakes. Mistakes now are less costly than mistakes that are found later. There may well be things that are "mistakes", like a performance problem with a piece of code that didn't show up until it got used under heavy load. But, if you've done your job upfront, you'll have included a way to diagnose those issues quickly if/when they do occur (i.e. code instrumentation). If you've done that, you've built in your safety net for "if" something does go wrong.
I was reminded by this quote that it's not bad to make a mistake. Mistakes help bridge the gap between inexperience and wisdom. I often feel like I'm on a v-e-r-y long bridge, but the journey, and the view, are certainly beautiful.
Tuesday, May 27, 2008
Meerkat Motto
Meerkat Motto
Respect the Elders,
Teach the Young,
Cooperate with the Family.
Play when you can,
Work when you should,
Rest In Between.
Share your Affection,
Voice your Feelings,
Leave your Mark.
Wise advise if you ask me.
Monday, May 26, 2008
Ticket to Ride
My neighbor got me hooked on a game called Ticket to Ride. It's a board game that also has an online version as well as a version you can play with just cards. Anyway, when I want to "not think", I play TTR. It is made by a company called Days of Wonder. Here's the description of the game from their site:
Ticket to Ride is a cross-country train adventure in which players collect and play matching train cards to claim railway routes connecting cities throughout North America. The longer the routes, the more points they earn. Additional points come to those who can fulfill their Destination Tickets by connecting two distant cities, and to the player who builds the longest continuous railway.
I don't know why, but I fell in love with this game. There is some strategy to it but it's not very complex. It's just simple, fairly mindless fun. I play online mostly because it's easier to find people to play with that way. Even at 2am here, I can find somebody logged in and ready to play from half-way around the globe where it's late afternoon. You gotta love how small the internet makes the world!
Anyway, here's my latest game board after I won:
I'm the green trains. I made it from Vancouver all the way across the country to New York, then down to Atlanta and finally Charleston.
Gee...if I'd flown all that way, it would've taken me the better part of today to get there. As it is, I just spent 20 minutes crossing the country and never left my chair in front of my trusty MacBook Pro.
Now, if somebody would just figure out how to make real travel that easy, I'd be really happy!
Sunday, May 25, 2008
Complex, simple, huh?
Which one is ON?
This?
Or this?
I know the second one is ON. But to tell the truth, I'm not really sure if the first one is ON or OFF. Anyone care to enlighten me?
Neither one is as simple as it should be. I think the second one is certainly more clear as to the object's state. But if you're going to simplify, why not just go all the way and put the word ON on the right?
This?
Or this?
I know the second one is ON. But to tell the truth, I'm not really sure if the first one is ON or OFF. Anyone care to enlighten me?
Neither one is as simple as it should be. I think the second one is certainly more clear as to the object's state. But if you're going to simplify, why not just go all the way and put the word ON on the right?
Saturday, May 24, 2008
Making the complicated simple
I love this. I believe it's true. At the heart of creativity is the ability to distill the most complex of subjects into something simple. Simplicity that motivates understanding in a way that pages of detailed descriptions can't convey. A complex idea can be wrapped up in a few words or a simple image.
Some things are not easy. Perhaps you need special skills or knowledge. But there are many things that are thought to be complex or difficult, that just don't have to be. Consultants in all fields are paid large sums of money to do things that are thought to be too difficult for the people hiring them to accomplish on their own. Are the consultants really that much smarter? In most cases, I don't think so. I think that often it's just easier (and less time-consuming) to pay someone to tell you something than to discover it for yourself. Successful consultants are successful because they can distill the complex into something simple.
As a consultant, I've often heard the people I'm working with say "well, that was easy." But, they said that after I pointed out the answer. I suppose you could say that everything is easy once you know how to do it, but the challenge is learning how to find the simple in the complex.
I think that's what good software does. It makes the complex, simple. Have you ever tried looking at raw trace data (Oracle event 10046 - extended SQL trace data)? Once you know what you're looking at, you can read it. But if you have to look at much of it, the volume becomes prohibitive to your being able to determine anything meaningful from it. That's why it's nice to have a software product that can make it simple. That's what our Profiler product does. I like that. It's cool to take a nearly 50 MB trace data file and within a few seconds have our Profiler turn it into this (click on the image to see a larger, readable image):
I was handed this profile last week. The event that consumed the most response time (41.9%) for the application being traced was CPU service, prepare calls. The code being traced executed 850,058 parse calls....ouch! I drilled down and saw this (again, click on the image for a larger view):
Do you see what I see? A boatload of single row DELETE statements. Again I say, ouch! This code was created to purge data. It was not performing optimally (duh!). It had been running poorly for months but nobody could see the simple answer. They were caught up in the complex requirements and their beliefs about how meeting those requirements had to be done. The answer was obvious. The answer was simple. But the answer had to be pointed out in a clear, unequivocal manner. The profile did that. Cool....
I like working for a company that wants to help people find the simple in the complex. As one customer said to me recently "it's like being given a flashlight in a pitch black cave."
Whether it's in your business or personal life, I think it's a good practice to follow. Work to make the complicated simple.
Friday, May 23, 2008
Followup: Presentation Zen
I found this presentation at SlideShare.net.
Description: Fighting death by PowerPoint... How to make a presentation and not to bore your audience to death.
Description: Fighting death by PowerPoint... How to make a presentation and not to bore your audience to death.
Thursday, May 22, 2008
Presentation Zen
We've all been there. You're sitting there in a PowerPoint nightmare while the presenter drones endlessly on. If the presenter isn't reading the slides directly, he is pretty close to doing so. You've tried to pay attention, to glean some nugget of useful information, and to prove your fortitude by just hanging on till the end without falling asleep in your chair. It's even worse when you know the speaker is brilliant. You've read their books or articles and couldn't wait to hear them impart their wisdom in person. You take your seat, focus your attention on the podium and spend the next minutes (or heaven help us...hours) wishing you were having your head waxed instead.
I recently found the book Presentation Zen by Garr Reynolds and also found the author's blog by the same name. His May 20th post had a YouTube video that cracked me up. Check 'em out. The book is great and his blog is always fresh and thought-provoking but the YouTube video speaks directly to the PowerPoint torture I was referring to above.
I use PowerPoint frequently and am constantly on the lookout for ways to improve my presentations both for content and for delivery. I know from personal experience that there isn't anything much worse than sitting through a boring presentation, so I try to be as interactive and dynamic as possible when I'm standing in front of a group.
When I'm in front of a group, it is primarily in a teaching capacity. One of the points Garr makes in his book has to do with allowing pictures to say things for you. This is a struggle for me when so much of the technical content is difficult, if not impossible, to conceptualize with pictures. Plus, people typically want the presentation materials to serve as a reference for after the presentation is over and pictures don't really work well for that. Pictures are certainly more engaging but how can someone who isn't trying to give a presentation to sell something, but to teach and inform, use pictures effectively?
I'm a fan of marketing guru Seth Godin. He wrote a little e-book called "Really Bad PowerPoint (and How to Avoid It)" and did an interview about it. In that interview he speaks to my question about selling vs teaching as follows:
"It seems to me that if you're not wasting your time and mine, you're here to get me to change my mind, to do something different. And that, my friend, is selling. If you're not trying to persuade, why are you here?"
That got me to thinking about what I do in front of a classroom. I am trying to persuade and to get the students to change their minds and/or do something different. I may not be selling them a product (a car, a widget or whatever), but I am selling them knowledge and information they can use to do their jobs more effectively. I've never thought of myself as a salesperson, but in light of Seth's comments, I believe I have to change my thinking. And, that may also mean I need to revisit my PowerPoint slides to find a mix of both pictures and text that works.
Hmmm...I've got some work to do....
Wednesday, May 21, 2008
Do what you like. Like what you do.
That's my motto. I borrowed it from a favorite t-shirt I got from the folks at Life is Good.
I'm really very fortunate. The thing I really love to do is the thing I get to do every day of my professional life. I work in a field that I fell in love with when I was in college. I originally started out as an Accounting major but was also taking pre-Law courses. I guess I thought I'd be some bigshot corporate lawyer or such. But during my 2nd year of core courses in my major, I was feeling pretty low about my choice. Frankly, I hated it. Unsure of what to do, I was taking a required course in, of all things, BASIC programming (that's Beginner's All-purpose Symbolic Instruction Code)...yes, I'm old. Anyway, we were given a project to develop a program of our own choosing and in working on that project, I realized I'd found my calling. I loved it. I loved the logic of it; the challenge of getting a computer to do what I wanted it to do.
What I have come to realize over the years is that getting a computer to do what you want it to do is just part of the fun. It's about getting the computer (i.e. your application, your database, your "system") to do it well and not only perform the functions desired, but to perform them quickly and efficiently.
That's really where my focus is today. My job is all about optimal performance. My company, Method R, has a tag-line that says we are "committed to genuinely satisfying software performance". How cool is that? Every day I get the opportunity to help people get the most out of their systems. I teach. I consult. I assist with product development. I just plain have fun.
This blog will be my space to document some of the things that interest me and to share my experiences doing what I really love to do. I thought it would be a good way to preserve some of my day-to-day goings on to help jog my memory as time passes. As much fun as experiencing something is, for me, it's almost as fun to relive the experience. What I journal here will help me do just that.
I hope you'll stop by and join in the fun. And, if you're doing what you love to do...yea! If you're not, I wish for you to find the thing you're passionate about...and do it!