A few years ago, I worked myself into a leadership role at my job. Being one of the better Oracle Developers and one of the few that was willing to speak to people in a meeting, I was promoted to Oracle Development Lead. That was pretty ok. I had a great team and, for the most part, they knew what they were doing.
Then, my project got canned, but the contract didn't. Since I was now at a manager-level, I ended up writing PowerPoint presentations for the next year on how to make a massive behemoth of an organization into a more "Agile" massive behemoth. In addition to being massive, they are also underfunded, so progress was slow and highly resisted. I quit that job -- but they asked me to stay. I said I'd had it with PowerPoint presentations and they said they would work me back into the technical work.
Fast forward to now. I'm a Software Testing Lead. I've been bumbling through this job for about a year and I think I'm finally starting to get my feet under me. Rather than trying to figure out what development is up to and come up with some sort of testing schedule which will be messed up two weeks later, I'm going to flip that on its head. We are embedding our testers into the Scrum teams (that's more "true Agile" anyways) and then the Scrum teams can handle the scheduling and tasking. I'm now focused on the aspects that actually take a Senior resource -- test processes and test tools (Arquillian, Rational Functional Tester, Selenium, etc.). I'm going to be helping the teams move towards automation rather than assign it to my resources and hope they'll figure it out. I want to keep them moving forward and making progress in their projects while I spend time on some R&D. I also need to create a set of PowerPoint presentations on testing processes, etc. so that as testing resources become available, they can come up to speed quickly.
Wait, what?
Fair warning -- I'm not really sure what possessed me to post a blog posting today, but it could obviously be years before I post again.
Friday, October 14, 2016
Friday, April 20, 2012
Oracle Forms -- DML Returning Values
This is one of my most loved and hated properties in Oracle Forms.
If it is set to Yes, it makes it so that you automatically see not only user updates to a record, but any updates that may have happened on the database (ie, a trigger sets "Updated Date", etc.). Additionally, if this is set to Yes, you should not get the "record is locked by another user" message after you have committed, but attempt to edit the record again without re-querying.
So why in the world is it defaulted to No? Well, it's my understanding that this was done so that you don't break older code that may be running on a pre-Oracle 8 database.
The property works great, except when it doesn't. Occasionally, after a record update, you see a bunch of gobblydygook after it has committed. The extra junk isn't really there, and all you have to do is re-query the block to see that the records are fine, but it doesn't make my end-users happy.
And then today, I learned something that I didn't know before. If you set the "Query Only" to "yes" property on an item in a block with DML Returning Values set to Yes -- well, the item doesn't return the value -- it appears as if the DML Returning Values property is set. I guess that this is because the dml return is considered part of the update process and the query only items are ignored at that point (I wouldn't have guessed it before, but it's my theory).
So, there you have it. For the one stray person who may stumble upon this post, I hope it helped :).
If it is set to Yes, it makes it so that you automatically see not only user updates to a record, but any updates that may have happened on the database (ie, a trigger sets "Updated Date", etc.). Additionally, if this is set to Yes, you should not get the "record is locked by another user" message after you have committed, but attempt to edit the record again without re-querying.
So why in the world is it defaulted to No? Well, it's my understanding that this was done so that you don't break older code that may be running on a pre-Oracle 8 database.
The property works great, except when it doesn't. Occasionally, after a record update, you see a bunch of gobblydygook after it has committed. The extra junk isn't really there, and all you have to do is re-query the block to see that the records are fine, but it doesn't make my end-users happy.
And then today, I learned something that I didn't know before. If you set the "Query Only" to "yes" property on an item in a block with DML Returning Values set to Yes -- well, the item doesn't return the value -- it appears as if the DML Returning Values property is set. I guess that this is because the dml return is considered part of the update process and the query only items are ignored at that point (I wouldn't have guessed it before, but it's my theory).
So, there you have it. For the one stray person who may stumble upon this post, I hope it helped :).
Thursday, November 10, 2011
Password Tips/Recommendations
You Need a Strategy
A co-worker sent out an e-mail today about how he does his personal password strategy. It shocked me a bit that he was sharing as much information as we was -- especially the fact that he basically uses a fairly simple strategy and he uses one password for all of his accounts, and it got me thinking. This post was originally a reply to his e-mail, but I didn't actually send it, because it seemed like I was just saying "I'm right and you're wrong." However, I have some strong feelings about passwords, so I felt compelled to write it down somewhere, even if it is on my obscure, seldom-updated blog that is only read by myself. For the most part, I think people know better, but just get frustrated by all of the passwords that they have to manage, so they take shortcuts in order to make life less miserable for themselves. As a long-time IT Consultant, here are my recommendations on passwords. They are not original ideas, but the main point is that you need a well-thought out strategy to deal with your passwords.
Use a Tool for Password Management
I would suggest a password tracking utility (KeePass, Password Safe, etc.), which encrypts your file of passwords. Put the encrypted password file on an encrypted USB device so that you will have your passwords where you need them and when you need them (you should probably also load the software on your USB device so you can access the data from somewhere other than your computer, using something like PortableApps). Additionally, passwords stored this way are protected by at least 2 layers of encryption (one layer on the drive, one or more layers in the software). Pick one up at Staples or Office Depot today.
Almost everyone I've talked to about this has a fair amount of frustration built up from trying to remember all of their passwords. I'm sure that we are all aware of the dangers of written passwords, or passwords stored in the clear. However, we all at some point get overwhelmed at the task of remembering all of our passwords, so we resort to shortcuts that are much less secure than they should be. I've seen DBA's (yes, more than one) pull up a shortcut on their desktop that points to a text file of all of the system passwords, as well as their own personal passwords -- stored in the clear. When you really look, we've ALL (myself included) done something at least that insecure.
A strategy of using an encrypted password tracking tool helps alleviate the pain of tracking all of your passwords, but still does it in a secure manner.
Use Multiple Passwords/Password Schemes
I would recommend against using the same password for all of your accounts. It's a can of gas waiting for a lit match. We all have personal bank accounts, forums, social networking sites, etc. that we have passwords for. When I last looked, I have at least 30 passwords that I have to keep track of -- that's 30 systems that contain a password of mine. If you use the same password in all of your accounts, then your security is only as good as the weakest system that you use. I would submit that your personal e-mail address should be the STRONGEST password of all of them, as most systems use e-mail to trigger a password reset. You should also not use that password on ANY other accounts.
In coming up with a password strategy, I would suggest breaking down your accounts into different layers:
As an example, I used to have an account on lifehacker.com, one of the sites owned by Gawker Media. For their site, I used a weak, easy-to-remember password on it because everything in that account was public information with no need of protection -- "posts" to a forum. The only risk in someone getting that password was that they could have posted in my name. Possibly a reputation risk, but not a big risk. Well, Gawker Media was hacked this year. The hackers got my personal e-mail address and they got my Gawker password. Had I been using the same password on my personal email account, they could have gotten access to not only my email, but most likely, to every account I've ever had -- and they could have easily searched my email to see which bank I bank with, etc. If your personal email gets hacked, you're toast, as most online accounts use your email as part of their password reset procedure.
You Should Lie
OK, honesty is really the best policy, but consider this point. Social networking websites are a goldmine of personal information that can be used if you are launching a targeted attack of some sort -- or even as a tool in finding good targets. Interestingly, enough, social sites also frequently highlight information that could be used to hack a lot of people's accounts using "password reset" tools -- especially if you have access to their personal email account. For example, what are the security questions that you get asked when you have to reset a forgotten password?
In a Nutshell
I'm not trying to go all "Conspiracy Theory" on anyone or cause any panic. However, whether we realize it or not, each of us has enemies of some sort -- ex-spouses, a ticked off former co-worker, a building contractor that you made mad one day, the Cable Guy, a neighbor who doesn't like how you look, that kid that you "pantsed" in Junior High who just found you on Facebook, someone who you cut off in traffic and they wrote down your license number. I'm not sure if you can still do it, but with a simple phone call to the DMV, I once got a name and phone number, based on the license plate number of a car I wanted to buy -- imagine how surprised this person was when I called about the car (they didn't sell it to me, by the way...). Just by living, you have ticked off some people in life. In addition to these people, there are plenty of strangers out there, fishing (and phishing) for targets. These are your enemies when it comes to security.
If one of those enemies suddenly decides to cross the line and go all Hacker, they can make a mess of your life if you have one password everywhere and they get ahold of it. Given enough time and a specific target, a Hacker can get a long ways. The task here is much like locking your car doors or putting cable locks on a laptop -- it's nothing more than a deterrent -- it won't totally prevent a criminal from breaking in, but the harder you make it and the more time consuming it becomes, the higher the risk, and the more likely the criminal will be to move on to some other target. Your job is to make your passwords hard to crack, but accessible to yourself when you need them. Use a Tool to simplify password management, Use multiple layers of passwords/strategies, Lie -- use false information when the information is not needed by the system you are accessing. It's easier than you think.
I know that just in writing this, I've remembered several "chinks in the armor" of my own security strategy -- things that I've known I need to fix but have procrastinated. I will be making some changes, and I invite you to re-examine your security and make changes where they need to be made.
A co-worker sent out an e-mail today about how he does his personal password strategy. It shocked me a bit that he was sharing as much information as we was -- especially the fact that he basically uses a fairly simple strategy and he uses one password for all of his accounts, and it got me thinking. This post was originally a reply to his e-mail, but I didn't actually send it, because it seemed like I was just saying "I'm right and you're wrong." However, I have some strong feelings about passwords, so I felt compelled to write it down somewhere, even if it is on my obscure, seldom-updated blog that is only read by myself. For the most part, I think people know better, but just get frustrated by all of the passwords that they have to manage, so they take shortcuts in order to make life less miserable for themselves. As a long-time IT Consultant, here are my recommendations on passwords. They are not original ideas, but the main point is that you need a well-thought out strategy to deal with your passwords.
Use a Tool for Password Management
I would suggest a password tracking utility (KeePass, Password Safe, etc.), which encrypts your file of passwords. Put the encrypted password file on an encrypted USB device so that you will have your passwords where you need them and when you need them (you should probably also load the software on your USB device so you can access the data from somewhere other than your computer, using something like PortableApps). Additionally, passwords stored this way are protected by at least 2 layers of encryption (one layer on the drive, one or more layers in the software). Pick one up at Staples or Office Depot today.
Almost everyone I've talked to about this has a fair amount of frustration built up from trying to remember all of their passwords. I'm sure that we are all aware of the dangers of written passwords, or passwords stored in the clear. However, we all at some point get overwhelmed at the task of remembering all of our passwords, so we resort to shortcuts that are much less secure than they should be. I've seen DBA's (yes, more than one) pull up a shortcut on their desktop that points to a text file of all of the system passwords, as well as their own personal passwords -- stored in the clear. When you really look, we've ALL (myself included) done something at least that insecure.
A strategy of using an encrypted password tracking tool helps alleviate the pain of tracking all of your passwords, but still does it in a secure manner.
Use Multiple Passwords/Password Schemes
I would recommend against using the same password for all of your accounts. It's a can of gas waiting for a lit match. We all have personal bank accounts, forums, social networking sites, etc. that we have passwords for. When I last looked, I have at least 30 passwords that I have to keep track of -- that's 30 systems that contain a password of mine. If you use the same password in all of your accounts, then your security is only as good as the weakest system that you use. I would submit that your personal e-mail address should be the STRONGEST password of all of them, as most systems use e-mail to trigger a password reset. You should also not use that password on ANY other accounts.
In coming up with a password strategy, I would suggest breaking down your accounts into different layers:
- Accounts you use, but wouldn't care if they were compromised (your delicio.us account, car repair forums, etc) -- low risk accounts that pretty much contain information that is all public anyways.
- Accounts you care about, but contain semi-public ( less sensitive) information (Facebook, LinkedIn, RememberTheMilk etc.)
- Accounts that contain sensitive information (LAN/email accounts at work, accounts with your utility company, bank account, etc.)
- Your personal email account. This should have the most secure password, but people often use a weak one here, and leave it in place for years.
As an example, I used to have an account on lifehacker.com, one of the sites owned by Gawker Media. For their site, I used a weak, easy-to-remember password on it because everything in that account was public information with no need of protection -- "posts" to a forum. The only risk in someone getting that password was that they could have posted in my name. Possibly a reputation risk, but not a big risk. Well, Gawker Media was hacked this year. The hackers got my personal e-mail address and they got my Gawker password. Had I been using the same password on my personal email account, they could have gotten access to not only my email, but most likely, to every account I've ever had -- and they could have easily searched my email to see which bank I bank with, etc. If your personal email gets hacked, you're toast, as most online accounts use your email as part of their password reset procedure.
You Should Lie
OK, honesty is really the best policy, but consider this point. Social networking websites are a goldmine of personal information that can be used if you are launching a targeted attack of some sort -- or even as a tool in finding good targets. Interestingly, enough, social sites also frequently highlight information that could be used to hack a lot of people's accounts using "password reset" tools -- especially if you have access to their personal email account. For example, what are the security questions that you get asked when you have to reset a forgotten password?
- What is your mother's maiden name?
- What is your favorite color?
- Where were you born?
- Who was your best friend in High School?
- Where did you go to High School/College, etc?
- What year were you born?
- etc.
- "Do the people that I'm giving this information to really have a NEED to know it?"
- "What is that need, and does the need also benefit me?"
In a Nutshell
I'm not trying to go all "Conspiracy Theory" on anyone or cause any panic. However, whether we realize it or not, each of us has enemies of some sort -- ex-spouses, a ticked off former co-worker, a building contractor that you made mad one day, the Cable Guy, a neighbor who doesn't like how you look, that kid that you "pantsed" in Junior High who just found you on Facebook, someone who you cut off in traffic and they wrote down your license number. I'm not sure if you can still do it, but with a simple phone call to the DMV, I once got a name and phone number, based on the license plate number of a car I wanted to buy -- imagine how surprised this person was when I called about the car (they didn't sell it to me, by the way...). Just by living, you have ticked off some people in life. In addition to these people, there are plenty of strangers out there, fishing (and phishing) for targets. These are your enemies when it comes to security.
If one of those enemies suddenly decides to cross the line and go all Hacker, they can make a mess of your life if you have one password everywhere and they get ahold of it. Given enough time and a specific target, a Hacker can get a long ways. The task here is much like locking your car doors or putting cable locks on a laptop -- it's nothing more than a deterrent -- it won't totally prevent a criminal from breaking in, but the harder you make it and the more time consuming it becomes, the higher the risk, and the more likely the criminal will be to move on to some other target. Your job is to make your passwords hard to crack, but accessible to yourself when you need them. Use a Tool to simplify password management, Use multiple layers of passwords/strategies, Lie -- use false information when the information is not needed by the system you are accessing. It's easier than you think.
I know that just in writing this, I've remembered several "chinks in the armor" of my own security strategy -- things that I've known I need to fix but have procrastinated. I will be making some changes, and I invite you to re-examine your security and make changes where they need to be made.
Thursday, August 4, 2011
Keep Business Rules Legible in Your Code
I've just realized that this is one of my driving "code philosophies" though I've never really put it in words. It drives me to write code that separates the DML from the business related code. I understand that in some instances, this can lead to code that is slower than it could be.
Additionally, I strive to code one rule at a time, where possible. This allows you to test and debug a single rule, isolated from the rest of the mess.
However, I have seen that it leads to code that is reusable and more reliable than when you write code that contains everything in one SELECT statement. When you jumble multiple business rules together into one big SELECT statement, you have a mess to troubleshoot when one of the rules changes or when you discover that you have a bug.
Of course, when you are all done and it goes into a system with actual records, some processes perform so slowly that you have to go back and rewrite with performance as your primary goal.
Additionally, I strive to code one rule at a time, where possible. This allows you to test and debug a single rule, isolated from the rest of the mess.
However, I have seen that it leads to code that is reusable and more reliable than when you write code that contains everything in one SELECT statement. When you jumble multiple business rules together into one big SELECT statement, you have a mess to troubleshoot when one of the rules changes or when you discover that you have a bug.
Of course, when you are all done and it goes into a system with actual records, some processes perform so slowly that you have to go back and rewrite with performance as your primary goal.
Wednesday, October 7, 2009
SQL Developer 2.1 Early Adopter -- Still More Impressions
Holy Memory Leak, Batman. The good news is that although my memory usage on SQLDeveloper has crept up to 775MB this morning before getting slow enough to have to kill it, it did manage to save the file and somewhat interact at that point. It used to be that once it had crept up to about 600MB that it would just go blank and be useless. So, now it seems to tolerate the memory problems better, but still has a problem with memory consumption gradually creeping up to intolerable levels as time goes on.
So, what was I doing that cost all this memory?
I had 5 text files open (not huge files, mind you -- all less than 1000 lines), no database connections open, and I was editing one of the files (Search and Replace, Ctrl-G to go to a line, edit, save, copy paste -- just normal editing). That's it.
Looks like I will have to kill from the Task Manager, as it didn't shut itself down all the way.
SQL Developer has always done this to me. I'm a Developer, so I open the tool in the morning and keep it open. Originally, I had to kill around 2 in the afternoon. With version 1.5.5, I had to kill around 11 in the morning and 2 in the afternoon. With the new version, it looks like I still have to kill, but it manages to use even more memory before I have to kill it.
I've been trying to get my company to switch from TOAD to SQLDeveloper, but nobody else can stand all the bugs. TOAD is a hog, too, and I haven't used it seriously for a couple of years, but the TOAD guys aren't having to kill twice a day. One of the guys on the team really wants to use SQLDeveloper, but he's on Vista and SQLDev is absolutely unbearable on Vista.
Makes me wonder if I'm an idiot for continuing to be a SQLDeveloper junkie. I love the tool, but it's never been smooth, seamless, or reliable. Kinda like driving a DeLorean or something. Well, maybe more like a Yugo. No, it's way cooler and more useful than a Yugo, but certainly not as sleek or fast as a DeLorean. Hmmm.....how about an old Dodge 4x4 truck. Love it to death, it's powerful, cheap and useful, does way cool stuff, but it might die any minute. Maybe I like it because I have a Gambler streak in me and just want to see if I can beat the odds.
So, what was I doing that cost all this memory?
I had 5 text files open (not huge files, mind you -- all less than 1000 lines), no database connections open, and I was editing one of the files (Search and Replace, Ctrl-G to go to a line, edit, save, copy paste -- just normal editing). That's it.
Looks like I will have to kill from the Task Manager, as it didn't shut itself down all the way.
SQL Developer has always done this to me. I'm a Developer, so I open the tool in the morning and keep it open. Originally, I had to kill around 2 in the afternoon. With version 1.5.5, I had to kill around 11 in the morning and 2 in the afternoon. With the new version, it looks like I still have to kill, but it manages to use even more memory before I have to kill it.
I've been trying to get my company to switch from TOAD to SQLDeveloper, but nobody else can stand all the bugs. TOAD is a hog, too, and I haven't used it seriously for a couple of years, but the TOAD guys aren't having to kill twice a day. One of the guys on the team really wants to use SQLDeveloper, but he's on Vista and SQLDev is absolutely unbearable on Vista.
Makes me wonder if I'm an idiot for continuing to be a SQLDeveloper junkie. I love the tool, but it's never been smooth, seamless, or reliable. Kinda like driving a DeLorean or something. Well, maybe more like a Yugo. No, it's way cooler and more useful than a Yugo, but certainly not as sleek or fast as a DeLorean. Hmmm.....how about an old Dodge 4x4 truck. Love it to death, it's powerful, cheap and useful, does way cool stuff, but it might die any minute. Maybe I like it because I have a Gambler streak in me and just want to see if I can beat the odds.
Tuesday, October 6, 2009
SQL Developer 2.1 Early Adopter -- More Impressions
I like the new SQL Formatter changes. I really like the live previewer so that you can test a setting and see if it does what you think it's going to do. Very nice. My one complaint that I've always had with the SQL Formatter is that it seems to be less aware of PL/SQL. It handles SQL beautifully. Actually, this is a complaint I've had about Oracle products in general for years. SQL Developer has, in a lot of ways, been the answer to that void. However, the formatter still seems somewhat ignorant of PL/SQL. Interestingly, the formatter settings didn't migrate from the previous version very well until I went in and edited the settings, saved them as SQL and then restarted. The tabbing is weird. I have mine set at 4. Half of the tabbing works correctly at 4, but a bunch of other tabbing switches over to the default tab size of 2. Hope that gets fixed. If I use the "tabulator" (never have figured out what that means), then the indentation mostly disappears entirely -- one line works, then the rest move 4 spaces to the left of where they should be. There are a zillion options in the formatter. Tough to find documents, though. I really wish that the formatter would format DECODE statements correctly. Namely, that there be one value/translation pair per line.
Ctrl-Enter -- no longer runs a Select statement. Has to be F9 now. Also, a statement no longer runs with & as a prompted parameter, but if you run it as a script, it will. Using a ':' as the bind variable seems to work fine. Seriously, though, after all these years of making me learn to use Ctrl-Enter, we now switch to F9?
Case switching works a lot better with Ctrl-Quote now. It used to require clicking the mouse option first. And, there's a button now.
There's a button for an unshared worksheet now -- locking it into the current connection. That might be useful.
More later...
Ctrl-Enter -- no longer runs a Select statement. Has to be F9 now. Also, a statement no longer runs with & as a prompted parameter, but if you run it as a script, it will. Using a ':' as the bind variable seems to work fine. Seriously, though, after all these years of making me learn to use Ctrl-Enter, we now switch to F9?
Case switching works a lot better with Ctrl-Quote now. It used to require clicking the mouse option first. And, there's a button now.
There's a button for an unshared worksheet now -- locking it into the current connection. That might be useful.
More later...
SQLDeveloper 2.1 Early Adopter -- second impression
130 MB memory -- seems smaller. We'll see if it creeps up to 600MB and then hangs like it always has in the past.
It feels a lot faster. Maybe I'm just too excited.
One of the things I have to check is the Excel import/export. I also need to try out the Data Modeler viewer. However, I should probably do some work...
Ya know, it's kinda sad to see what kind of things get me excited. And, should I be on an Early Adopter version? Probably not for production work, but I just can't really help myself. :)
It feels a lot faster. Maybe I'm just too excited.
One of the things I have to check is the Excel import/export. I also need to try out the Data Modeler viewer. However, I should probably do some work...
Ya know, it's kinda sad to see what kind of things get me excited. And, should I be on an Early Adopter version? Probably not for production work, but I just can't really help myself. :)
Subscribe to:
Posts (Atom)