Skip to main content

Care to join "Team Feuerstein"?

So on March 17, 2014 I joined Oracle Corporation as an Architect.

Wow, do they have lots of things for me to do!

And I want to do my very best with all of it:
  • Publish articles, presentations, white papers that are accurate, are readable, and have no mistakes.
  • Share my PL/SQL utility and sample code (and make sure they are readable and have no mistakes).
  • Find - and notify developers - about useful blogs, code and anything else relating to PL/SQL.
It is quickly becoming clear to me that I can't do it all, all by myself. And everyone else at Oracle is just as busy as me.

So I have decided to create "Team Feuerstein" - a group of Oracle technologists who share, with me, a delight for PL/SQL and SQL, and a desire to help build our community.

While you will not be paid in hard currency for your efforts, I will be very grateful and you will get public credit for your contribution.

I plan in the future to provide a webpage where you can submit an application to join the team and list your specialties. But I've decided that there is no reason to wait until that is ready.

I can get started right away soliciting your help!

So if you are interested you can do one of two things:

(a) Send an email to steven.feuerstein@oracle.com asking for more information.

(b) Send an email to steven.feuerstein@oracle.com to volunteer as a team member and provide the following information:

  • Background on your Oracle experience: free form text, LinkedIn profile, etc.
  • Your technical strengths: for example, I can definitely use help with non-trivial SQL, regular expressions, XML, etc. Core PL/SQL knowledge is, of course, great, too!
  • Other skills of interest: I plan to record lots of videos and podcasts, so if you have experience with this (esp on a Macbook), I'd love to hear about it. Excellent English writing skills? That would be very useful.
  • How you would like to be identified publicly.
Many thanks in advance for considering this!
Steven Feuerstein



Comments

  1. Kim Berg HansenApril 24, 2014 at 12:48 PM

    Well, the bit about non-trivial SQL sounds much more interesting than trivial SQL ;-)
    Can you use a dane with no Macbook experience whatsoever?

    ReplyDelete

Post a Comment

Popular posts from this blog

Why DBMS_OUTPUT.PUT_LINE should not be in your application code

A database developer recently came across my  Bulletproof PL/SQL  presentation, which includes this slide. That first item in the list caught his attention: Never put calls to DBMS_OUTPUT.PUT_LINE in your application code. So he sent me an email asking why I would say that. Well, I suppose that is the problem with publishing slide decks. All the explanatory verbiage is missing. I suppose maybe I should do a video. :-) But in the meantime, allow me to explain. First, what does DBMS_OUTPUT.PUT_LINE do? It writes text out to a buffer, and when your current PL/SQL block terminates, the buffer is displayed on your screen. [Note: there can be more to it than that. For example, you could in your own code call DBMS_OUTPUT.GET_LINE(S) to get the contents of the buffer and do something with it, but I will keep things simple right now.] Second, if I am telling you not to use this built-in, how could text from your program be displayed on your screen? Not without a lot o...
4 comments
Read more

How to Pick the Limit for BULK COLLECT

This question rolled into my In Box today: In the case of using the LIMIT clause of BULK COLLECT, how do we decide what value to use for the limit? First I give the quick answer, then I provide support for that answer Quick Answer Start with 100. That's the default (and only) setting for cursor FOR loop optimizations. It offers a sweet spot of improved performance over row-by-row and not-too-much PGA memory consumption. Test to see if that's fast enough (likely will be for many cases). If not, try higher values until you reach the performance level you need - and you are not consuming too much PGA memory.  Don't hard-code the limit value: make it a parameter to your subprogram or a constant in a package specification. Don't put anything in the collection you don't need. [from Giulio Dottorini] Remember: each session that runs this code will use that amount of memory. Background When you use BULK COLLECT, you retrieve more than row with each fetch, ...
4 comments
Read more

PL/SQL 101: Three ways to get error message/stack in PL/SQL

The PL/SQL Challenge quiz for 10 September - 16 September 2016 explored the different ways you can obtain the error message / stack in PL/SQL. Note: an error stack is a sequence of multiple error messages that can occur when an exception is propagated and re-raised through several layers of nested blocks. The three ways are: SQLERRM - The original, traditional and (oddly enough) not currently recommended function to get the current error message. Not recommended because the next two options avoid a problem which you are unlikely  to run into: the error stack will be truncated at 512 bytes, and you might lose some error information. DBMS_UTILITY.FORMAT_ERROR_STACK - Returns the error message / stack, and will not truncate your string like SQLERRM will. UTL_CALL_STACK API - Added in Oracle Database 12c, the UTL_CALL_STACK package offers a comprehensive API into the execution call stack, the error stack and the error backtrace.  Note: check out this LiveSQL script if...
5 comments
Read more