I have not hand coded an HTML file in a long long time. I use Word, Dreamweaver, or some other tool to create html files for me.


html is *not code*

html is simple markup.

... you do offer powerful and actionable advice (dangerous in the wrong hands?). ...


indeed, I worry about that sometimes. It is why I many times ask "why" first.

This advise applies to the person serving food in a restaurant, a manager, a programmer, a DBA, a school teacher, <any occupation pretty much goes here>

1) knowing a little html won't be a bad idea for htmldb but it is not a pre-requisite.

2) what about it (the future). HTMLDB is an application development tool, having knowledge of it, how it works, when to use it - won't hurt you.

3) I believe that you can learn a tiny bit of java, but you won't be marketable as a java developer really. J2EE is a 'career path', it'll take a while to get your arms around it.

I don't know, they haven't been invented yet.

some of mine so far have been

cobol
rpg
pl/i
sas (I was known as the "sas master" before I got into SQL ;)
jcl
tcl
rexx
exec
exec-2
pascal
lisp
prologue
C
C++
SQL (dialects for ingres, informix (various dialects, every database from them was a little different), sqlserver (sybase), sqlserver (ms), db2, sql/ds, oracle, sqlbase - at least, might be missing some)
PL/SQL
T-SQL
68000 assembler
too many shell's to remember
awk
java


probably others, don't remember them all anymore. Oh and the API's I've learned over time.


When I learned PL/I - some of those languages did not yet exist, some had existed for years.

guess the future? never with accuracy.

Arm you with a way to be able to work in the future? Sure, see the list above and remember that everything you know for sure today will change tomorrow and be lessons learned in the future.

Meaning - gasp - my parents were actually right when they said "you'll see..."

I've described in seminars that I think there are 4 kinds of people:

a) version 6 DBA's. They install software, they backup databases. Occasionally, they discover they can ever restore them - but many times not. They are not very helpful generally. I don't get along well with them. They will not survive much longer (they can be automated).

b) DBA/Developer - a person that is mostly DBA but can actually understand software development, the business, the needs. They are helpful, they've tested things. They can write some code in a pinch (hence they can automate stuff, help developers tune some SQL). They understand the physical schema and so on. They will survive for a long time - they are flexible, they get along well with others, they communicate, they make themselves useful.

c) Developer/DBA - a person that has taken the time to learn all of the tools they have available (their languages, their OS, their application server, their database). They use them all to their fullest. They do not like to write gobs of code, they pride themselves in being able to put together things that work quickly by taking what exists and using it to its fullest. They understand the bits they are pulling together.

d) Developer - code jockey. Loves their language, their language is the last language ever. I get along with them as well as a)


Unfortunately, too many teams are a) and d). Never works :(


But put an A/C team together or an B/D together - that is like "war"


B/C - perfect ;)

.... what technologies will
be "HOT" in near future in terms of Oracle DBA job /market value ? ...


All of them. And depending on your physical location on the planet - different technologies will be hotter than others on different places on the planet.

in Oracle 15 we might have perfected the flashforward query to go along with flashback queries. I cannot wait to hit the nasdaq tables with that one :)

I have that bookmarked already - my blog topic for tomorrow :)

It freaked me out how close the "gists" were. I am thinking of going to a java conference (believe it or not) just to see her talk once and meet her in person.