Getting Started with R

Install R from:

Download R Studio from:

Oracle R Enterprise (ORE):

Anaconda for Python & R:



Law of Demeter and Tell, Don’t Ask

Somehow last week, can’t remember the context, I came across the Law Of Demeter for the first time, me not having an OOP background.

I followed the rabbit down a few holes and came to appreciate that this is a commonly misunderstood guideline, not a law, and often misinterpreted in terms of counting dots.

The “law” states:

A method of an object should invoke only the methods of the following kinds of

  • itself
  • its parameters
  • any objects it creates / instantiates
  • its direct component objects

Other people have explained it pretty well as follows:

It seems to be just about avoiding dependencies and being tightly coupled – your object should not be dependent on another object’s dependencies.

The references above use the analogy of a paperboy who needs paying by you, the customer.

  • You don’t let the paperboy take the wallet (object) from the customer(object) and take payment (method/attribute manipulation on wallet).
  • The paperboy doesn’t need to know anything about the wallet.
  • All the paperboy cares about is his payment.
  • He doesn’t need to know anything about where the money comes from other than whether he gets his dosh or not.

This is a very artificial example, as the references above acknowledge.

The problem with oversimplistic and contrived examples is they can then raise many “buts” which take away from the point at heart.

Seems to me (but what do I know yet) that the Tell, Don’t Ask principle is aimed at a similar target to Demeter.


Ask Forgiveness Not Permission

This is a programming notion rather than the recipe for a long and happy marriage!

As I’ve been reading, I’m been coming across many references to the pythonic principle of Ask Forgiveness Not Permission.

It’s not difficult. You probably know it. You just didn’t know it had that name.

An example of asking permission would be:

if (i_can_do_it):

vs the ask forgiveness approach of:

except (i_cant_do_it):

There are a couple of main reasons behind the practice.

Firstly, in any concurrent system there is the potential for there to be a race condition between the evaluation of i_can_do_it and the action of do_it (see more from db code example below).

Secondly, the comprehensive list of things you need to check for permission may be lengthy and/or not be possible to either know or cover in their entirety so you end up having to cover the exceptions anyway.

So, going back to my roots, you often see this pattern in PLSQL and SQL with a SELECT check followed by a subsequent action if something exists:

      select ... from ....
      do something;
    when no_data_found then
         do something else

Apart from anything else, another session may have inserted or deleted a row in between the time in which you did the select and you then attempting the subsequent do_something.

Better to attempt the do_something and then react to the no_data_found exception or react to the attributes of SQL%ROWCOUNT/FOUND/NOTFOUND.

Beginnings of Flask, Conda, Pip

This week I am mostly getting to grips with Flask, initially using this tutorial.

This is a gentle introduction to using a virtual Python environment using Conda at work and pip at home and getting to grips with my initial IDE of choice, PyCharm.

I installed a bunch of packages, realised I had installed them globally – not just to my new virtual environment for my Flask tutorial – uninstalled globally, reinstalled locally and now back on track.

I haven’t done any of the wirings from Flask into the DB but, initially at least, so many of the concepts are very familiar from recent learnings with Angular – model, view, controllers, factories, routing, etc.

Simple stuff but all good reusable learnings which are relatively new to this particular dinosaur.

Pythonic Zen: Failures and Exceptions

From my initial learnings on  Python, I have been struck by the message that there is a very strong sense of things being Pythonic, i.e.there being a Python-way of doing things.

Here I’m going to talk about coding for failures.

There are two approaches dealing with program execution and an operation which might fail:

  • LBYL
  • EAFP

Look Before You Leap – Check that all possible failure conditions for a failure-prone operation are met in advance of attempting the operation.

It’s Easier to Ask Forgiveness than Permission – Hope for the best and deal with the consequences.

In a simple example, this might mean that rather than doing a whole bunch of type checking on an object passed before doing an action (LBYL), it is a preferred approach to try to do it and then catch the exceptions if it fails (EAFP).

Below is another example. Consider some noddy LBYP code which processes a file:

import os
p = '/mypath/myfile.txt'
if os.path.exists(p):
    ...some exception code...

Problems include:

  • if check clutters the “happy path” through the code
  • ‘exists’ is only one of quite a few conditions we might check
  • something might happen to our file between the check and the process such that the file would no longer pass the checks so we have to code for the exception anyway.

Compare and contrast the EAFP approach:

p = '/mypath/myfile.txt'
except OSError as e:
    ...some exception code...

EAFP in conjunction with Exceptions, rather than bespoke error/return codes, is considered to be the Pythonic way.

Further reading:

Python, Cloud, Big Data and Javascript frameworks

I have for nigh on twenty years had an Oracle RDBMS focus, particularly on Oracle performance and the development and tuning of SQL and PL/SQL.

There have been many ebbs and flows on the demand for Oracle work over the years and I haven’t been in an exclusive relationship.

Around the turn of the century, my expertise turned towards Content Management Systems – notably Vignette on top of Oracle. When Vignette turned away from TCL to Java, I started to lose interest and refocused on my Oracle expertise.

Now not only is there a massive cloud-based threat to the status-quo but also start-ups and tech companies are using different technology and I find having a mainly Oracle focus restrictive on a) what’s on my to-do list day-to-day and b) where my future lies.

With the cloud and with the desire for elasticity and a microservices’ architecture, a single monolithic Oracle database doesn’t seem to make much sense. Once you break up into microservices then you start to look more towards sharded data stores and, at best, to write-behind monoliths or consolidated warehouses.

So I want to branch out.

Java has always held limited appeal. It’s always seemed bloated.

Python has an a natural appeal in that it can be very simple to spin up something quickly. It appeals due to the simple nature of scripting languages, familiar from my TCL background. And at the same time, it is easy to implement OO.

Big Data is a natural progression from my data and database  background. I certainly need to do a whole bunch of work understanding Hadoop, Hive, Pig, etc and most importantly Spark. There is an interesting tie-in with Oracle and external tables to provide a hybrid RDBMS-BigData approach.

Learning on Javascript and Javascript frameworks are born out of necessity. I thought I had left that all behind at Sky. But there are some GUI screens at work which need to be built using Angular 2. Furthermore, there are a lot of startups and tech companies booming with JS, Node.js, etc. And the more I learn it, the more I expect to enjoy it.

Just Keep Swimming

I’m starting this blog to document some of my learnings in other languages and framworks away from my traditional safe haven of Oracle, Oracle performance, SQL and PL/SQL.

Over the years I have found my Oracle blog an invaluable learning assistant.

On the one hand, documenting and explaining an interesting issue or aspect requires more understanding and means that you tend to double and triple check that understanding and illustrate it with distilled test cases where possible.

Secondly, I have lost count of the number of times I have searched for some reason or explanation and found that I have already blogged about it and that I had forgotten, either completely or in part, something that I once knew.

So, in the same way, I hope this will re-enforce these new learning adventures.