What... is your favourite colour?

Yesterday somebody called Pradeep posted a question in the OTN PL/SQL forum asking for careers advice. He is a VB programmer working in a Microsoft code factory (in India I would guess). He wanted to know what the Oracle job market was like, because he wanted thinking of training as an "oracle developer".

The reaction from some of the forum regulars was dismissive. Here is a sample:

"There are so many career/job opportunities in IT that to ask on a forum like this for career direction advice is just ... Well, just not a good idea.

But put yourself in Pradeep's position. (Note the following is an extrapolation: I don't really know his circumstances). A combination of the commoditization of IT and outsourcing has produced software sweatshops, where you, the developer equivalent of a sharecropper, churn out code chunks to be assembled into systems elsewhere. It's repetitive, stultifying and without much room for personal growth. Even if you do hear of a better job you know you are surrounded by dozens of other sharecroppers who stand just as much chance of getting it as you.

So Pradeep has thought to himself, Oracle is a famous company but he doesn't know anybody who works as an Oracle developer. That means he is going to face much less competition for any Oracle job which might arise. You might find this optimistic but it is thinking outside of the box. He then shows further initiative by posting a question about Oracle careers on the OTN forums. Because he thinks that the people who answer questions there will be helpful - which they are - and they will have the relevant knowledge - they all have careers in Oracle development.

What he hadn't anticipated was that quite so many people regard the PL/SQL forums as a suitable place for rehashing Monty Python jokes and discussing antiquated programming languages but not for offering careers advice. It's a funny old world.

Neologism corner: commando

Somebody who chooses to use a command line tool like sqlplus.exe over a GUI.

I coined this unthinkingly in a Forum thread about SQL editors which had descended into another "real programmers use vim" yawn fest. However, Brian Tkatch picked me up on it, so I had to retrofit a justification.

I chose the word because a commando is a member of an elite unit of toughnuts, which would seem to fit the self-image of soi disant real programmers. It was only afterwards that I noticed the resonance with "command line" itself. And it also brings fresh life to the phrase "going commando".

Update

The ever-reliable web-comic xkcd proffers a neat encapsulation of how these conversations tend to go.

My PL/SQL Coding Standards

As I mentioned recently a long-running trolling thread in the OTN forum has recently taken a new twist, by reviving the PL/SQL Coding Standards meme. Alas I was wrong in my prediction that the OTN moderators would soon kill the thread. Not only is it still going but the evil genius behind it is still going, and regularly changing their handle. Currently it is my turn to be impersonated.

In order to justify my assertion in that thread I have decided to publish my damn fine standards. So here they are.

---

APC's Damn Fine PL/SQL Coding Standards

1. Your code must implement the requirements correctly and completely.
   
2. Your code must have a suite of unit and integration tests (preferably automated) to prove it implements the requirements correctly and completely.
   
3. Your code must implement the requirements as efficiently and peformantly as possible.
   

---

Is that it?

These standards have much to recommend them. They are easy to read. They won't need revision whenever there's a new version of PL/SQL. And they focus on what is really important in code: correct functionality. Of course things such as layout and naming of variables are important, I'm not saying they're not. But a PL/SQL procedure can be neatly laid out, rigourously capitalised and thoroughly commented and yet be full of bugs. In my experience, most coding standards tend to document in tedious detail the things which are easy to standardise - use of upper and lower case, line indentation, etc - rather than the things which actually matter.

Also the strictures of codings standards are rarely revised. I still get handed coding standards which say things like "Always use explicit cursors". So either these standards were written ten years ago or the author has not coded any PL/SQL in the last ten years or the author should be shot. Whichever it is, if the standards document contains such canards, why should anybody pay it the slightest attention?

I intend to expand upon some of these points in future posts. If you want a more regular set of PL/SQL Coding Standards then you should check out the redoubtable William Robertson's site. Alternatively, invest in a copy of Oracle PL/SQL Best Practices by Steven Feuerstein (Whom God Preserve). I don't agree with everything that Steven writes but I firmly believe that if every PL/SQL coder in the world followed these guidelines the overall quality of the global PL/SQL codebase would increase by several orders of magnitude.

Update

The troll has now reverted to an anonymous userNNNNNN handle and restored the original text. Obviously even they have got tired of the joke. Or been stricken by conscience.

It's That Thread Again

There's a thread which has been running in PL/SQL for several months. It started off as a spoof on the URGENT PLZ HELP type threads we get from time to time. I blogged about it in June. After a long hiatus the OP has changed their handle to John Titor, Time Traveller and posted some more nonsense. I don't mind that. Some of the responses were quite entertaining, and the thing was mostly harmless.

The problem is, they are now masquerading as venerable lead-pipe swinger Billy Verreynne. They did this by the simple mechanism of replacing lower case Ls with capital is in their handle(curse those sans serif fonts!). Furthermore they have changed the subject matter and text of the original post to make it look as though Billy is offering Oracle's own internal PL/SQL coding standards. This is an homage to a notorious thread from the forum's history. This leads credence to the suggestion that the post is a mischievous forum regular with a sound knowledge of the other denizens. Unfortunately some of the less knowledgeable visitors are falling for this scam and are posting their e-mail addresses.

This is a thread which now, alas, has to die. Anybody got any zombie poison?

Post Scriptum

I haven't bothered putting a link in to this thread because I expect it to be pulled soon enough.

Interesting relational integrity bug

Over in the OTN forums, Wilhelm demonstrates a method for disabling foreign key constraints in such a way that we can delete the parent data and then re-enable the foreign key without throwing an ORA-02298 exception.

The proper syntax for disabling a constraint is this:

SQL> ALTER TABLE temp_child DISABLE CONSTRAINT what_the_fk;

Table altered.

SQL>  delete from temp_parent;

2 rows deleted.

SQL>  ALTER TABLE temp_child ENABLE VALIDATE CONSTRAINT what_the_fk;
 ALTER TABLE temp_child ENABLE VALIDATE CONSTRAINT what_the_fk
                                                   *
ERROR at line 1:
ORA-02298: cannot validate (APC.WHAT_THE_FK) - parent keys not found


SQL>

But if we include the mystical keyword VALIDATE in the disabling command we can corrupt our relational integrity quite nicely:

SQL> INSERT INTO temp_parent VALUES(1);

1 row created.

SQL> INSERT INTO temp_parent VALUES(2);

1 row created.

SQL> ALTER TABLE temp_child ENABLE CONSTRAINT what_the_fk;

Table altered.

SQL> ALTER TABLE temp_child DISABLE VALIDATE CONSTRAINT what_the_fk;

Table altered.

SQL> delete from temp_parent;

2 rows deleted.

SQL> ALTER TABLE temp_child ENABLE CONSTRAINT what_the_fk;

Table altered.

SQL> select * from temp_parent;

no rows selected

SQL> 

Worse than J2EE

There's an interesting thread on the OTN PL/SQL Forum about Real Time Database Design. At least that's how it started. It has now morphed into another pop at J2EE and .NET developers. Zlatko Sirotic has posted a nice satire of the average OO developer's approach to databases:

METHOD 4: sending XML files to OO2EE.Net;
super-fast and clean method that ensures database independence;
we need database independence - maybe one day we must replace our RDBMS with flat files

Which is almost too true to be funny.

I fear my latest contribution to the debate is likely to spoil my chances of getting a Director's tiara to go with my ACE of spades.

It is worth bearing in mind that it is not just OO developers who have a poor understanding of databases. This recent WTF story shows how a VB developer with just the wrong amount of knowledge can inflict a lot worse than J2EE on your system.

Night of the living spamtards

So are there any lessons to be learned from the spamtard ORACLE's adventures in the OTN forums yesterday? Not really. We all know little corners of the internet are vulnerable to individuals with the time and the motivation to be anti-social. This was one adolescent sitting in a Comp Sci class with too much time on their hands (I think in this case we can justly blame the teachers). ORACLE (and at least one other spamtard) posted a lot of silly comments in a number of active threads and started up many more threads of their own. So what? It's not like it was a bot-driven DoS assault. The DB General forum was still usable and none of the other important forums were hit at all. Frankly the forums being down for "routine maintenance" is a bigger pain.

"One monkey don't stop no show" -- Joe Tex

I am therefore surprised by the over-reaction of some of the forum regulars. I agree it would be nice if we could prevent such incidents but actually doing so would be quite difficult. If we trash ORACLE's account today they're back tomorrow with a different Hotmail address. Somebody suggested OTN could block their IP. Well, given that they seem to be posting from a school that might also block other more benignly-motivated students from asking questions. And it certainly won't prevent the spamtard from using some other place - such as an internet cafe - to continue the games.

In a recent article in the Guardian Cory Doctorow explained why effective DRM is impossible to achieve. All it does is punish those people who have actually paid for their digital media. Stopping low level trolls like ORACLE is basically the same case. OTN could put up loads of road blocks which would inconvenience us but won't stop the spamtards. Yes, OTN could appoint trustees to zap every post these gits make, but who wants to be on spam patrol for the whole afternoon? Not me. Much better just to let the spamtards have their fun and wait for the housekeeping bot to tidy up automagically. In the meantime, just ignore them. They'll get bored if nobody reacts to their jibes.

But above all, keep it in perspective. This is not poisoning the well, more like piddling in the paddling pool.

Trolling for laughs

Just recently we have had a troll visiting the OTN DB General forum. They call themselves ORACLE. They're annoying but harmless. Still every evening the Forum moderators eradicate their posts but the next day ORACLE is back. It's just like the Do Long bridge but with disposable e-mail addresses.

Here's an example from today (I won't bother posting the URL, it'll be gone by tomorrow):

Just got my new Oracle today

Oracle 12g, OMG it is so freaking cool.

I can write 9 queries in 5 seconds.

Then I laugh at all of you noobs.

^_^V 

I don't know about you but it reminds me of this recent posting from Dizwell....

Update

Since I posted this I have noticed that ORACLE is really blitzing the forum with postings. I guess they want to be considered more than just an annoying idiot. Still at the rate they're going they should have enough posts to qualify for ACE-hood by the end of the day.

Update 2

Well ORACLE now has control of the OTN forum. So undoubtedly something must be done. Rather helpfully, ORACLE has posted a list of actions which OTN ought to undertake to make life harder for trolls:

On the subject of spammers I suggest that you make so you have responsible oracle users able to ban and delete certain posts. For example, If you where honestly going to stop my spamming you should ban the account instead of just resetting all of the posts the spamming user makes and resetting the name, that is hardly dealing with the problem effectively.
Also, whoever the Forum administrator is. They should try giving more power to users they can trust such as
-N. Gasparatto
-Paul M
-Blushadow
-Hans Forbich (hes funny =P)
You should give them the position know as moderator (these are used on most forums). They should have a certain amount of control on who uses the forum. They should be able to ban (permently immoblilize the account, dont just reset the posts) and delete posts when necessary. Therefore you won't have to wait till your stupid oracle mod comes in and sweeps the place every 24 hours.

I'm slightly miffed that I'm not included in the list of trustees.

Final update of the day

Well the OTN forum housekeeper has woken up and cleared out all the messages posted by ORACLE. But it remains to be seen whether the troll will be back tomorrow.

How To Be A Good Guru

In her engaging UKOUG presentation on being a newbie Lisa Dobson devoted a large chunk of time to Being A Good Newbie. That is, how to post questions on Oracle-related lists in the manner most likely to elicit a helpful response. We might summarise this advice as don't poke the tigers.

Lisa didn't have the OTN Forums on her list of, er, lists but we get a lot of newbies posting questions there. Partly it's just location, location, location: the Oracle site is the obvious first port of call when you need help¹. Also, it is not a forum where the really big beasts - the Oak Table chaps - visit and the level of discussion hardly ever descends to hex dumps of block headers and other such esoterica. Hence newbies are perhaps less likely to feel embarassed about posting simple questions. This is obviously a good thing but it does impose a burden on us soi disant experts who volunteer to answer their questions. So, in homage to Eric Raymond's seminal guide to list etiquette for newbies I am modestly proposing some advice to would-be responders. And, yes, I know I still regularly break these guidelines.

How to Answer Questions the Smart Way

#1. Don't answer questions to which you don't know the answer

Obvious really, but it's very easy to think you know something about the database that is no longer true, or maybe never was. For instance it has been a long time since anybody asserted that explicit cursors performed better than implicit ones, but people still proferred this advice long after it had ceased to be true. Be sure that if you do post something factually incorrect your peers will gleefully expose your bloomer to the wider world. It is better to post the right solution second than be first with a wrong one.

It is perfectly okay to research an answer. Indeed, one of the benefits of answering questions on the forums is that we discover stuff we didn't know. Questions coming from out of leftfield can tell teach us interesting (and sometimes even useful) things about how the database works.

#2. Explain yourself

Eric Raymond advises newbies to approach technical gurus in a supplicatory fashion. They are supposed to treat lists as resources of last resort, to kowtow before the collective wisdom and then present a detailed description of their problem, including complete specifics of environment and configuration, plus all the things they've already tried and all the manuals, whitepapers, etc they've already read, before humbly beseeching us for the merest crumb of assistance. Of course the ungrateful wretches never do this but we should still respond graciously.

It's not enough to dash off the correct answer. Consider whether its correctness will be obvious to the questioner. If not, try to explain why it's the correct answer. That way there's less chance that the questioner will be posting an almost identical question next week. Whenever possible include a link to the relevant part of the manual. Linking to a specfic heading in a chapter is better than just linking to the Table of Contents, but the manual is not always tagged the way we would like. Similarly, if you need more information, explain what else you need to know and why you need to know it. If you want (say) an explain plan and you suspect they don't know what that is, link to the manual.

#3. Give as little assistance as necessary

The most effective form of learning is discovering things for ourselves. Teaching someone how to diagnose their own code (use SQL> SHOW ERROR, look up the error, check the syntax in the online documentation) is better than just rewriting their code for them. Not least because in rewriting the code we are likely to break some business rule we do not understand.

#4. Show your workings

When answering a SQL related post it is always best to include a worked through example. Take a tip out of Tom Kyte's practice: use cut'n'paste from SQL*Plus to demonstrate that what you have asserted is in fact the case. This is a corollary of #1.

If, for reasons of time or environment (for instance you do not access to a database) it is acceptable to post untested code, provided:

• you indicate it is such;
  
• you think an untested code sample is more helpful than no code sample at all;
  
• you think it is probably correct. Heh.
  

Nothing exposes a poseur faster than a piece of code that doesn't even compile, so make sure you cover yourself.

#5. Use humour judiciously

Many people using the forums do not have English as their first language. Humour does not always travel well between cultures. Some questioners will not be expecting humour in a work context². Furthermore, even amongst English speakers, humour can be difficult to spot without the non-verbal signifiers that accompany barroom banter. In particular irony is a tough one to pull off. Still, humour is a Good Thing and can liven up some dry reads so by all means be witty (if you can - lame jokes are, well, lame). It is helpful to use emoticons to signify that your preceding line was intended humourously, even if they are a debasement of the high standards of English literature. Jane Austen never posts on Oracle lists anyway :)

Oh, and sarcasm is right out (see #6).

#6. If you can't say something nice don't say anything at all

Just like your mother told you.

There are no stupid questions only stupid answers. If someone has posted a question you don't think is worthy of an answer then don't bother answering. Remember: you're a volunteer, there is no compulsion, you are choosing to answer the question. So, the person is not wasting your time by asking a stupid question, you are wasting your own time by typing a stupid (angry, sarcastic or belittling) answer. By all means explain what is wrong with the question, show how it could have been phrased better or request more details. If some newbie has posted "my code doesn't work", ask them to describe the observed behaviour, to explain the difference from expected behaviour and to paste in the error message and callstack (if appropriate).

If somebody seems to be particularly unreasonable - posting an URGENT!!! question on Saturday and then whinging in follow-ups that nobody has responded - feel free to explain to them that you are a volunteer, this is a free service and there is no SLA. In fact, if they want an answer within a set timeframe they should stop being so darned cheap and spring for a support contract. Also, if I suspect the poster is a student looking for me to do their homework I always ask for a course credit (Not being American I have no idea what this means).

#7. Avoid jargon, baffling acronyms and idiolects

Fnord. This is just another way of demonstrating your superiority over the OP. Of course, like wit, you can use such stuff if you think your audience will get it. Alternatively, embed a link to the Jargon Dictionary, although this rather undermines the point of using abbreviations. LOL.

#8. Never never never just respond with RTFM. Not ever.

Telling some newbie "RTFM" is an act of pure arrogance. It just feeds the respondent's ego without helping that questioner learn anything, except maybe not to ask for help in the forum again. Barbara Boehmer taught me this one. Keep in mind that the Oracle FM is huge; there are dozens of books and the search engine fronting the online version ain't that great. At the very least, post "RTFM" and a link to a relevant part of TFM. That way at least they will know where to go the next time they need to find out something.

STFW is at least as bad and arguably worse. Googling for information about Oracle problems takes a lot of skill, not just in filtering queries but in knowing which results can be trusted. There are plenty of snakeoil merchants out there. (You may think you know who I am talking about but there are others too).

#9. Meditate on eternity

Other people will read your posts in the future, because they will come up in search results. Obviously if these people are using the OTN Forum search engine they'll probably be after an answer to some completely different question but Google also indexes the OTN Forums. So try to make your answers suitable for a wider audience. Besides, as Jakob Nielsen observed in another context, your future boss may be reading.

#10. Keep your newbie mind

We were all newbies once. We are all still newbies in some dimension of the database, it's just too big for one mind to know everything. Even Tom Kyte occasionally farms out questions to Sean Dillon, Cameron O'Rourke et alia. So the next time you find yourself about to type a withering riposte to some "dumb" question just remember: one day, in some forum or other, you will ask a dumb question and an arrogant, big-brained geek is going to squash you like a fly.

---

^{1. Unfortunately this means people do assume their questions will be answered by Oracle employees and therefore there is some SLA we have to meet. In fact most OTN forums have little or no active Oracle participation (the HTMLDB, Developer and JDeveloper forums being honourable exceptions).}

2. Here is my favourite example (the words are approximate, this is from memory). The questioner ask a generically "stupid" question, "How can I improve the performance of my database?". A wag responded (using the UBB [code] markup so it looked authentic):

ALTER SYSTEM SET GO_FASTER='TRUE'
/

The original posted replied, "I tried this command but it failed due to illegal option". Which is funny but also rather cruel.