Wednesday, September 23, 2020

Beginner Level Material

 “We need more beginner-level material, more Basic-knowledge topics”

This was the cry from a conference routinier and organizer(m/f)

My replies to this remark are multiple:

  1. Agree: I see many app/dev/ops/archs make basic (known-)mistakes.
  2. Beginner-level topics are not sexy, the don't draw crowds.
  3. Basic topics don't promote/sell products.
  4. Beginners are not at conferences, they are on stack-overflow.
  5. I first want to Talk to their managers and “architects”.

And of course, in Covid-19 days, there are hardly any conferences anymore, just web-video-youtube-streaming-meetings. The remark comes from meeting ppl at POUG and from a weekly zoom call with some friends.

I will say that whatever goes wrong in IT (and a lot goes sub-optimal or plain wrong), it is not the fault of the "beginner" or even of the Dev.

The "root cause" of most wrongs is with the lead, the architect of said "Dev". 

Mistakes I seem to see are (in +/- random order)

 - No basic Design.

 - Chasing interesting technology, rather than building a useful system.

 - No database-design: you don't know what your data looks like!! 

 - Use of object-store (hierarchical datamodel) rather than a well-designed (table/relational) model.

 - No (data-)life-cycle, and unlimited growth.

 - Inefficient data-access (e.g. no indexes, or very poor datamodel)

 - Use of technology (RDBMS or any other) without much experience or knowledge.

 - No testing, no “verification” (despite good intention of automated "pipeline")

So, in all my "Senior Arrogance" I stated that, rather than "more beginner level material", we need some sort of "curriculum for IT-professionals". 

Currently I'm thinking of “how can I help on this ?” 

Expect a few blog-posts on t his topic soon. Probably starting with pointers to the likes of HeliH, ToonK, JeffS, TimH etc.. 

And we know: You can lead a horse to water, but it still needs to drink...

Suggestions welcome (in comments or on twitter…)

note: I find it better to put extensive ramblings on a blogpost rather than to string a set of tweets together. But reactions on Twitter tend to start better and more accessible discussions.

Saturday, September 05, 2020

How To... Meet for Coffee with a motorcycle rider.

 If we decide to meet for coffee during one of my (motorcycle)trips, here are some tips.

In Short: Keep it Simple. 

Meet at some easy-to-find place where we can talk and have coffee.

The more elaborate version...

The Goal:

To meet and to listen to eachother.

Hence we optimise "coffee time" and face-2-face time.

I don't want to have to search too much, or have to go through hoops to park the moto in some vague-underground-payable parking, nor do I want to walk for >1km in motorcycle-gear.

Requirements, in order of priority:

- A place to sit, quietly, to have coffee and a snack.

- Easy to get to for both of us: near your office/home, easy to find via GPS. 

- Ideally, a moto-parking where I can keep an eye on the bike. 80% of my life is loaded onto that motorcycle when I travel.

With the above, Simple, instructions, we should be able to arrange a good meeting.

Bad Examples, things to avoid...

1. Sightseeing and showoff are not a priority. 

You don't  need to Show-Off your landmarks and there is no urgent need to show me around your city. E.g. don't ask me to meet under the Eiffel tower or in front of Sagrada Familia. I already have those pictures, and getting there can be complicated for both of us during normal daytime hours. Talk-time is more important than sightseeing. (I might make an exception for Red Square and Kremlin, or for for the statue of Genghis Khan, I don't have selfies there yet... ).

2. No Offie. 

There is no need to "check me into your office". It is often easier to meet outside, much less hassle and less parking+security complications. I'll make an exception for I have really enjoyed working from their offices, occasionally, for about 6 years now.

3. Not too much food.  

Quality of Coffee + Snacks is not crucial. I don't eat much when travelling. Even MacD will do if not too busy with kids. Exchange of Ideas is the main aim, and that can be done almost anywhere.

4. No pages of instructions. 

Don't worry about "detailed directions". Just give me the GPS-coordinates or a clear address. My GPS, combined with google-maps, can find most places. Parking for a moto is not a problem in most cities (some French and Dutch cities have special regulations for motorcycles though).

Let me now if the above is too Pedantic... 

Friday, September 04, 2020


If you came here to find out who I am: read on, and then Google a bit more...

I work in IT, I help people with data and databases.

And I try (tried) to speak about my work in various places around Europa, places I can visit by motorcycle so as to combine work and fun.

In some earlier jobs, I did a lot of travel by air as well, but I got tired of that and switched to Motorcycle. I can recommend it!

Now that Covid-19 has reduced a lot of travel-opportunities, I feel a little confined. But life is not bad for me (as long as I have customers, I am ok...).

And I Did manage a few trips in 2020 already and a few more on the agenda for 2021. Dont give up Hope! 

Thursday, January 17, 2019

Ego document - videos - must sink to bottom quickly.

The buzz around RigaDevDays for 2019 made me realize that there are some videos of me out there.

Now, I am a bit camera shy: I dont look good on camera, or in video.
but I didnt want to loose the link, so here we go..

RDD, Smart-DB (2018)

RDD, Funxtion Result Cache (2017)

Tuesday, August 21, 2018

POUG and other plans.

September, October, November are just around the corner.

That means: Quickly sneak in some more motorcycle-riding before Winter sets in.

Early September I hope to ride this:

Edit: here is the link to the actual route:

Edit2: And Here is the link to the ppt from POUG18.

Current plan is to go speak at four conferences this autumn:

POUG (6-9 Sept, Sopot, Northern Poland - the map above)
MakeIT2018  by SIOUG (14-16 Oct, Portoroz,  on the Adriatic)
HROUG (17-20 Oct, Rovinj, only 90min from Portoroz..).
DOAG (19-23 Nov, Nuremberg)

Optionally: PG-Day Europe in Lisbon.
Just after HROUG - would mean 3 days of solid riding between Venice and Lisbon. That sounds more romantic than it is, but still a Very Good Ride (Link to map)

Optionally: UKOUG Conference in Liverpool.
Early December. Not practical on a motorcycle. But possibly a last occasion to visit england before the dreaded brexit kicks in.

*** Insert logos and links here ***

*** Insert the Proud "I am a Speaker" stuff here ***

*** Insert oracle ace-stuff... Nah. ***

The real reason to visit these events is of course to do the "Road Trip", and to meet some interesting folks from the Database-world.

Hope to see you at some conferece soon.

Monday, April 16, 2018

Spring Trip via RigaDevDays and BGOUG

It is that time of year: Conferences on the horizon.

Edit: yesss. you can follow it Live on, Right Here.
Or use Google, let me help..

My main items this spring are RigaDevDays (RDD link), Bulgaria Orace Usergroup Spring Conference (BgOUG link) and an evening at the Romanian RoOUG. Plus a few other planned visits of friends and places, meals and coffee on the way. I am kinda sorry to miss out on NL-OUG event and the Austrian OUG, but I will remember those for next year.

Here is the approximate map for this spring (I will probably avoid taking the same roads twice):

After this trip, later in the Summer and Autumn, I hope to do a few more trips if I can get papers accepted. I know that POUG (Poland, September) is near-certain, and I might re-visit Slovenia, Croatia and Germany if the schedule and the jury help a little.

Edit: As requested, I added the "Awesome Logos"...

Saturday, March 31, 2018

Docker and PDB discussion

This blog-entry will serve as my note-taking and explanation-texts for a Docker discussion that started on Twitter on 30Mar2018.

Topic: Docker and PDBs

Here are the key questions I want to ask "everybody", before we dive into discussion:
Q1: What kind of use-cases are developing out there for Oracle on Docker ?
Q2: What do you (all) want to do with OracleDB running from a Docker-container?
Q3: (Gerald?) What is the direction that Oracle wants to take with 18.x and PDBs on docker ?

More detailed questions tend to follow, but ... Later!

I am interested in your answers to Q1/Q2 before we start the detailed discussions, mainly to prevent my own "tunnel vision". I realise that Others have often very different views of products and possibilities. So let's hear it from you!

----- Space for Pause and Reflexion -------

Popssible agenda for discussion:
 - open for suggestions...
 - me: Use Docker to deploy Oracle-DB software, and plug various PDBs in/out.
(add your suggestions here...)

 - Simple to deploy, clone-able.
 - Runs nearly anywhere.
 - Disposable containers, e.g. Cattle, stateless.
(add your items/suggestions.... )

Databases, and PDBs:
 - Storage of data (ACID), e.g. Pet, Stateful.
 - Application code-base in PL/SQL or similar (#SmartDB).
 - PDBs: Easy (re)start of dev sandboxes (including app-code in PL/SQL).
 - PDBs: Clone from prod/acc/test/pristine environments.
(add your items/suggestions)

Wishlist for OracleDB on Docker:
 - A quick-deploy method to many platforms (that it is already!)
 - A guaranteed, known, software version (e.g. known version + patches)
 - Image as light (small) as possible.
 - Complicated: Patching, First on a "golden" image (per project?), then distributed.
 - Nice-to-have: when oracle18 is out: Read-Only OH.
 - Clear choice of data: "in" or "outside" of the container (mappable volumes).
(add your items here...)


Gerald Venzl (link) has provided and published Docker Images (link) that can run an Oracle Database. There are also a range of other Oracle-provided containers that allow "devs" to play with various oracle tools, and I'm sure everyone is discovering various ways to use Docker.

In another universe someone (link to jk) even complained that Containers were used for "production databases". I'm really curious to see how+where+when that works, notably if the data is stored persistently, ACIDly, and how the additional layer from container-to-storage is affecting the running and performance.

Storage, persistence: 
I can see two distinct cases, your choice will depend on circumstances:
 - Data inside the container, and disposable. You can lose the data at some (unexpected?) point.
 - Data on mapped volumes, and Persistent. You have more control over the data.

In my case:
 - Disposable "sandboxes : can be in the container. But any plug/in/out may have to be done over DB-links, cumbersome.
 - Persistent data: mappable (host-)Volumes. Easy to reach, similar to NFS concept with pros/cons.

Notable items for Docker, from my memory/history:
 - Avoid splitting the database over "container" and "volumes".
 - Keep the spfiles and orapwfiles with the data (linked into the dbconfig in 12.2, nice!)
 - Also map diag-directory, prevent container-storage from filling up (was easy)
 - Detail: add a "vi" to the container. I had to yum it in.
 - Make perl work correctly or use bash. (I like CreateDB, not just dbca...)
( - add your items here...)

My own agenda (if any) is to have the OracleDB software in an easy-deploy, run-anywhere container, with the option to keep the data "external" and to plug-in PDBs at will.

My "containers" resemble old-fashioned VMs. Not sure if that is "correct way"

My deployed-container will be my "processing unit" and my "service".
The docker-host will provide storage as mappable volumes.
The concept I would use would resemble a set of linux-servers with an NFS for filesystem.

Side-topics, optional, later:
 - Anything Oracle can do to concentrate all "output files" to a small number of mountpoints is welcome. I used to spend time putting spfile, ctlfiles, redo, data, archives, log/diag all in 1 subdir-tree to allow easy movement of databases between systems. Gerald has mentioned FSH already: that was a good concept on unix once. All output to a "/var" subdir.
 - Anything Oracle can do to make (un)plug of containers easier: Welcome. I would like a PDB to be even more simple transportable from 1 subdir, including all files needed (oracle is close!). In another DB, all you do is provide some name, or point 1 (one) environment variable $QHDATA to 1 (one) subdir, and the whole DB materializes under it... Neat! No messing with "file-name-convert" or GUID/random strings. Easy, Flexible!

Open for Discussion... (on twitter?)

Copies of Relevant links:
Gerald :
docker images :

The tweet that started it.


This is the footer...and this should be small text for disclaimers and the like. and some small stuff

Locations of visitors to this page And this text is placed next to the map. we could possibly hide some stuff here too for the benefit of the search-engines and if it is at color ffffff cam we put all sort of rubbish that we do not want readers to see. travel itinirary reservation ticket agent flight plane boarding attendant train connection rail ticket wait time booking flight boardingtime taxi ramp luggage suitcase trolley wheely laptop bagpack corpaorate wifi connection oracle. it will also be interesting to see what happens when this wrap around. or even if we put in spherus and worwood as additional word.