I recently spent a week in hot, muggy Florida, visiting my mom both before and after Kscope15. Thanks, ODTUG, for organizing the event near my mom's home! Oh, and a BIG thanks for scheduling Kscope16 in Chicago. One less trip on an airplane! Hurray!
Kscope15 followed a predictable (and very pleasant) pattern:
We announced the brand-new Oracle Database Developer Choice Awards at the conference. These awards celebrate and recognize technical expertise and contributions in the Oracle Database community. As longtime and new users of Oracle Database move to the Cloud and take advantage of this exciting new architecture, community experts will play a critical role in helping them succeed.
Analytics, Model Clause, Edition-Based Redefinition, and Rethinking "Advanced"
I am, sadly, a very typical PL/SQL in one regard: I have not kept up with the latest regarding SQL. So at this Kscope, I decided to pay a bit more attention to the SQL side of things.
I started out by attending both of Tom Kyte's YesSQL sessions. I didn't follow well the most interesting SQL he presented, but was intrigued by his reminder that analytic functions have been in Oracle Database for a very long time. Yet, they are still tremendously underutilized. The model clause has also been available for years, but few people know of it or are comfortable using it.
Alex Nuijten's session SQL Model Clause: A gentle introduction helped me understand that feature better, but I am not still not sure how soon I will be using it.
I also attended a couple of talks on Edition-Based Redefinition (EBR), a feature introduced in 11.2 that allows us to hot-patch our applications. It is one of those amazing things we've baked into the database, but very few people know about use.
Like analytics and the model cause, EBR is perceived as "advanced" and "complicated" - and so most developers avoid it.
Which has me wondering: maybe we need to rethink what is advanced, and what we should project as advanced.
Perhaps when it comes to teaching SQL, we should include basic analytics from the very start. Perhaps the way that should happen is that instead of starting from: "Use ORDER BY to sort. Use WHERE to filter...." we should pose typical problems and then show SQL can solve them most easily. I expect that many common requirements naturally would lead to analytics.
In this way, we might be able to offer a more holistic view of SQL and how it helps you manage data.
As for EBR, it's just one feature (among many) that gets me reflecting on how Oracle builds a lot of great technology, but we don't do enough to make it easy for users to apply that technology.
Instead we too often find ourselves shaking our heads and wondering: "What is wrong with our users? How can they not be using LAG and LEAD after all this time? Why do we still have to remind them about bulk processing? Why don't they leverage compile-time warnings? Why don't they instrument their code? Why don't they do better error handling?" etc.
I have a friend who has had great trouble finding a satisfying job. In one position after another, things start out great, but then go sour over time. In as gentle a manner as I could manage, I asked: "What is a common element among all these bad experiences? You are. So maybe in addition to being irritated with co-workers and managers, you should ask yourself how your behavior might have contributed to the problems - or at least how you might want to change for your next job to improve the chances of success."
Hey, it's just a thought. Just trying to be logical. OK, fine, get mad at me.
But doing the same thing over and over again, when you see it's not quite working as well as it should....don't you feel an itch, a desire, to change that same thing? I do.
If our users persistently have trouble fully leveraging our products, and we see this over and over again, perhaps we shouldn't wonder what's wrong with our users, but instead wonder about what we need to be doing differently.
But definitely we should not wonder what's wrong with us. :-)
Thanks, ODTUG!
I've been attending ODTUG conferences for a loooong time, and they have uniformly been great experiences.
But there's a dangerously comfortable feeling I feel when at Kscopes: it's like a reunion of some of my very best tech friends from around the world. It's so easy to spend most (all?) of my time catching up with "my people" - and then afterwards realize that there were also attendees I'd never met and could have learned from.
So I am pleased to say that I did meet a number of "next generation" Oracle Database developers (meaning they are at least 10 years younger than me). I was excited by their energy and their smarts, their desire to learn and apply that knowledge to solve their company's problems. I hope to follow up with at least some of them, and help them become the next generation of gurus for tens of thousands of others.
So, thanks ODTUG for the experience and the opportunity and all the friends!
Kscope15 followed a predictable (and very pleasant) pattern:
- an extremely well-organized event (kudos to Executive Director Crystal Walton, Conference Manager Lauren Prezby and the rest of the the amazing Your Conference Connection staff, as well the ODTUG conference organizing committee and board)....
- gathering together many of the hottest and most engaged Oracle Database development talent....
- in a really nice location (resort hotel right on the beach).
Many attendees brought their families, so I had lots of kids to play with, including and most rewardingly, little two year old Kingston, who now calls me "Uncle Steven." I love extending my virtual family. :-)
Some highlights from Kscope15 (not meant to be a comprehensive review, but simply reflecting my experience) include:
Launched Oracle Database Developer Choice Awards
Some highlights from Kscope15 (not meant to be a comprehensive review, but simply reflecting my experience) include:
Launched Oracle Database Developer Choice Awards
We announced the brand-new Oracle Database Developer Choice Awards at the conference. These awards celebrate and recognize technical expertise and contributions in the Oracle Database community. As longtime and new users of Oracle Database move to the Cloud and take advantage of this exciting new architecture, community experts will play a critical role in helping them succeed.
For 2015, awards will be given out in the following technology areas:
- SQL
- PL/SQL
- Oracle REST Data Services
- Oracle Application Express
- Database Design
This awards program is different from the Oracle ACE program in a number of ways, the most important of which are:
Nominations come from the community (you).
Panels of ACEs decide on a set of finalists.
Winners are determined by popular vote (that is, by you).
In other words, as much as is possible for a program implemented by Oracle, Oracle will not be driving the process and selecting the winners. You will.
First-ever YesSQL Day at Kscope
Tom Kyte and I held the first ever YesSQL Day at a Kscope: we each had two sessions in which to explore the fundamental value propositions of both SQL and PL/SQL.
Tom Kyte and I held the first ever YesSQL Day at a Kscope: we each had two sessions in which to explore the fundamental value propositions of both SQL and PL/SQL.
Tom did his usual outstanding job of (a) offering context for understanding SQL's historical importance and (b) wowing us with what is now possible in the Oracle SQL language.
I must confess, though, that as I watched Tom's second hour, showcasing the wizardry of SQL, I found myself wondering: do attendees watch Tom and think "Exciting! I can't wait to get back to work to try it!" or something more like "Wow, Tom is brilliant. I don't think I could ever do that."
I sincerely hope the latter former. :-)
I then had two hours to talk about PL/SQL. The original title for my talk was "21st Century PL/SQL", but on Sunday, I asked the Kscope15 organizers to change it to:
That's because, well, I like to feel important, really important.
OK, so that's not all. My managers (at least three levels up the chain) agreed to allow me to build a whole team - the Oracle Developer Advocates - in order to make sure that developers (especially open source, scripting language programmers) understand the fundamental importance and value of the Oracle Database for application development.
But for me to do that, I not only needed to believe it (which I did, instinctively and self-servingly), but to understand why, to be able to step through the argument logically. It's the way I think, and the it's the way I write (which, I think, contributes to the readability of my books and articles).
So I've spent a fair amount of time thinking it through. At this same time (well, actually, starting before I rejoined Oracle last March), I had also been studying evolution, and what we now know about the way that organisms evolve, develop, survive and reproduce in the world. To my great surprise, these two seemingly disconnected trains of thought intersected a few weeks ago.
I then had two hours to talk about PL/SQL. The original title for my talk was "21st Century PL/SQL", but on Sunday, I asked the Kscope15 organizers to change it to:
PL/SQL Developers: The Most Important Programmers on Earth
That's because, well, I like to feel important, really important.
OK, so that's not all. My managers (at least three levels up the chain) agreed to allow me to build a whole team - the Oracle Developer Advocates - in order to make sure that developers (especially open source, scripting language programmers) understand the fundamental importance and value of the Oracle Database for application development.
But for me to do that, I not only needed to believe it (which I did, instinctively and self-servingly), but to understand why, to be able to step through the argument logically. It's the way I think, and the it's the way I write (which, I think, contributes to the readability of my books and articles).
So I've spent a fair amount of time thinking it through. At this same time (well, actually, starting before I rejoined Oracle last March), I had also been studying evolution, and what we now know about the way that organisms evolve, develop, survive and reproduce in the world. To my great surprise, these two seemingly disconnected trains of thought intersected a few weeks ago.
And PL/SQL Developers: The Most Important Programmers on Earth was the result. I've uploaded my presentation on OTN (it now has the title "Oracle Database Developers: the most important programmers on Earth") if you'd like to check it out. It makes the argument in a bare-bones, slide deck kind of way. I will be recording my thoughts on camera soon for publication on Practically Perfect PL/SQL.
Analytics, Model Clause, Edition-Based Redefinition, and Rethinking "Advanced"
I started out by attending both of Tom Kyte's YesSQL sessions. I didn't follow well the most interesting SQL he presented, but was intrigued by his reminder that analytic functions have been in Oracle Database for a very long time. Yet, they are still tremendously underutilized. The model clause has also been available for years, but few people know of it or are comfortable using it.
Alex Nuijten's session SQL Model Clause: A gentle introduction helped me understand that feature better, but I am not still not sure how soon I will be using it.
I also attended a couple of talks on Edition-Based Redefinition (EBR), a feature introduced in 11.2 that allows us to hot-patch our applications. It is one of those amazing things we've baked into the database, but very few people know about use.
Like analytics and the model cause, EBR is perceived as "advanced" and "complicated" - and so most developers avoid it.
Which has me wondering: maybe we need to rethink what is advanced, and what we should project as advanced.
Perhaps when it comes to teaching SQL, we should include basic analytics from the very start. Perhaps the way that should happen is that instead of starting from: "Use ORDER BY to sort. Use WHERE to filter...." we should pose typical problems and then show SQL can solve them most easily. I expect that many common requirements naturally would lead to analytics.
In this way, we might be able to offer a more holistic view of SQL and how it helps you manage data.
As for EBR, it's just one feature (among many) that gets me reflecting on how Oracle builds a lot of great technology, but we don't do enough to make it easy for users to apply that technology.
Instead we too often find ourselves shaking our heads and wondering: "What is wrong with our users? How can they not be using LAG and LEAD after all this time? Why do we still have to remind them about bulk processing? Why don't they leverage compile-time warnings? Why don't they instrument their code? Why don't they do better error handling?" etc.
I have a friend who has had great trouble finding a satisfying job. In one position after another, things start out great, but then go sour over time. In as gentle a manner as I could manage, I asked: "What is a common element among all these bad experiences? You are. So maybe in addition to being irritated with co-workers and managers, you should ask yourself how your behavior might have contributed to the problems - or at least how you might want to change for your next job to improve the chances of success."
Hey, it's just a thought. Just trying to be logical. OK, fine, get mad at me.
But doing the same thing over and over again, when you see it's not quite working as well as it should....don't you feel an itch, a desire, to change that same thing? I do.
If our users persistently have trouble fully leveraging our products, and we see this over and over again, perhaps we shouldn't wonder what's wrong with our users, but instead wonder about what we need to be doing differently.
But definitely we should not wonder what's wrong with us. :-)
Thanks, ODTUG!
I've been attending ODTUG conferences for a loooong time, and they have uniformly been great experiences.
But there's a dangerously comfortable feeling I feel when at Kscopes: it's like a reunion of some of my very best tech friends from around the world. It's so easy to spend most (all?) of my time catching up with "my people" - and then afterwards realize that there were also attendees I'd never met and could have learned from.
So I am pleased to say that I did meet a number of "next generation" Oracle Database developers (meaning they are at least 10 years younger than me). I was excited by their energy and their smarts, their desire to learn and apply that knowledge to solve their company's problems. I hope to follow up with at least some of them, and help them become the next generation of gurus for tens of thousands of others.
So, thanks ODTUG for the experience and the opportunity and all the friends!
Thanks for teaching me bulk processing last year, and it was a pleasure to see you again at Kscope15. Thanks for reflecting on the conference and providing insight from your point of view.
ReplyDeleteGreat seeing you at Kscope, Steven, and very very great to see you learn SQL ;-)
ReplyDeleteYes, you are right, much of the "supposedly advanced" stuff (both in SQL and PL/SQL) isn't really that advanced, but it's always been presented as such, so people may think "that's too advanced for me." Yes, we should include these themes more during the relatively "basic" training - good idea to pose problems and give solutions, that can be much easier to relate to for new developers. And that could present ways to teach analytics and bulk processing and so on earlier in the teaching process.
By the way, you write: "I sincerely hope the latter. :-)"
Do you *really* mean that you hope people think "I can never do that"? Or did I just miss the irony? ;-)
See you in Chicago. Fighting buckthorn for community service day? ;-)
That "latter" was not irony. It was a mistake. I have change it to "former." Thanks for pointing that out.
ReplyDeleteChicago and buckthorn: I hope so! We shall see...finding a group that can and wants to organize a half day volunteer program for 100 people, involving sharp tools might be tough.
But hey they managed in Seattle!
Hello All,
ReplyDeleteIn what concerns "the former" and "the latter", I think that both are true,
and, in fact, there is no real contradiction between them ...
I personally feel both of them, equally strongly !
The problem with the most advanced features is that they, like everything else,
do impose a learning curve, and, how to say it, a "learning for the sake and pleasure of learning per se", before having a real problem to solve.
Then, learning requires time, time, and again time ... and not all the managers
are so advanced in their way of thinking as to understand this aspect ...
let's face it, most of them are not, those who are, are rather the exception than the rule.
And, another aspect, except for really genius people, very few persons can really master each and every aspect even of *only* Oracle Development.
Being / becoming a super-specialist in one field, almost automatically makes you
to be "less perfect" in another field ... there are very few those who are indeed able
to equally master the highest levels of everything !
I can only be envious on those who already can make promisses to meet again
at the next KScope ... I wish I was able to plan so precisely just my next 24 hours ...
These confereneces are great learning opportunities, but, let's not forget, most developers in the world can only dream about being able to participate ...
Just as an example ... I was happy when I heared that one of Tom Kyte's sessions
would be available online, live ... and that same day, guess what happened ?
I discovered that our management has blocked all the video websites except for YouTube ... so, finally I found a remote server on which the site was accessible,
but I had to be content with the video only, without the sound.
That says much about how real life looks: everybody expects you "to just pull out every piece of knowledge, no matter how recent or how advanced, out of your sleeve" ... no learning, no trying, no attending conferences, and so on.
I would have been very happy indeed to meet you all there, especially after so many years of PL/SQL Challenging, these would have mean the whole world for me ... who knows if ever ...
Thanks a lot & Best Regards,
Iudith