Tag Archives: ADF

Hey JAVA-developer, why don’t you love your database


Why this post?

Partly, this blogpost is a result of a promise to Lukas Eder. Basically my vision adheres quite nicely to the “Thick Database” driven by Bryn Llewellyn and Toon Koppelaars who, understandibly, drive this from an Oracle perspective.
It –more than of course- also nicely fits EnterpriseDB or even vanilla PostgreSQL database landscapes.

There is apparently still so much confusion in the world on the how, why and what of good application development and architecture that I decided to chip in my bit. I think I have a bit of an idea on how this aught to work and I also think it is not a half bad idea, plus a couple of people whom I highly regard, seem to agree with it. So here goes…

Traditionally

Traditionally there is no big love between application developers and their persistence-store. I don’t really know why because I never found the opportunity to do a real inquiry, but I think I have a reasonable understanding.

Basically there is constantly the enormous pressure of delivering new features and functionality. So much even that the basic development work, the more “boring” and “time consuming” things -why pay now, if you can also pay later- get postponed. Things like peer-reviews, (integration) testing, technical design… Basically, more people means more features.
If even these things get too little attention, why would something like an overpriced library-box get more attention? Not to mention these DBA’s you need to pass to even get close(r) to this library-box…

Here are my four reasons why I think
it should deserve a chance!

1. Easier

Plain and simple. It is easier. If you take a structured query language like PL/(pg)SQL, it is basically easy. Founded on the programming language ADA, it is easy to understand and one can quite easily build a number of routines, procedures, packages, functions to let the database chop and glue data and just deliver the results for your application to consume.
It saves you the time of having to (re)write some of this more complex stuff in your application or perhaps even over a several applications.

2. Quicker

As said under the first point: build once, use many times. By creating mechanisms in the database, you get the opportunity to think about the separating data manipulation mechanisms from data representation mechanisms and where you want to put which specific function. Of course, this decision process takes a little extra time in the beginning, but will repay many times over as your projects grows and gains meaningful complexity (is there something like “meaningful complexity”, well, yes…).

Quicker also is in operational response times. Querying a stored procedure will bring agility to your application in a sense that this stored procedure will be much quicker in getting you the answer than if you do this in a distributed (middle-ware) environment. These stored procedures can be accessed through REST-endpoints, giving flexibility and the possibile desired disconnect between the database and the application layer.

3. Cheaper

Powerful, because you are and you remain close to the data. No data transportation overhead, no latency. These kinds of slimming down, mean less requirements to infrastructure and distributed capacities (either hardware or (virtual) “cloud infrastructure”. This slimming down frees up budget which can then be spend on the more meaningful bits and pieces of your application.

4. More consistent

Finally, I think this approach brings more consistency. As you do things near the data it lives on, near the processing power you depend on, you also get single access paths to specific bits of your data, to specific constructs that drive the value of the application you are building. Through this, it does not matter from where you call this service, REST-endpoint, stored procedure, or whatever you call it, you always get the same answer, driving a consistent decision process based on that application.

And if ever something changes, there is also just one place for you to ensure these new requirements are added. Voila, consistency throughout your application landscape, as all that depends on this data-set gets this uniquely updated information.

The magic of working together

There is a lot of misunderstanding between DBA’s and Developers. I have been in both roles at some point and I have seen this happen first hand. One of the things, though, in that force field, I have learned, is the power, the joy and, through this, the magic of working together.
In the end, we all have the same goal, which is furthering our business by being the best at what we do. This means, for a developer, meeting feature request, short development cycles, quick delivery and as much as possible, get it right in one go. For a DBA this means making sure the database stays consistent, performant and available. And, in extension of that, for operations it means that the final product must be easily and quickly deployable to enter into an uneventful and dependable life-cycle.

Bringing together these seemingly conflicting disciplines is fun! By investing a little time in exploring the other disciplines, you will find common drivers, in a sense that everyone want the same thing. By getting over nearly religious initial differences, you will find magic in the combination. You will reach your goals earlier with the bonus that your co-workers will also reach their goals earlier and have a better end result than you dreamt possible.

True JAVA-Champion

Coming from another world, I do not know the requirements for becoming a JAVA-Champion. I imagine it to be not too much different from other recognition programs out there… But…
If you create more features and functions and you are able to run your application with greater concurrency on (way) less platform-power. Thus increasing the RIO on your application, this makes you a true Champion of JAVA and your business!! If you are able to combine this with some magic in your cooperation’s…
Believe me, it is more fun in the end too!


#DBADev (Ops), who knows what is going on…

I have been considering writing this article for quite some time now.
APEX Connect 2016 in Germany’s capital Berlin and the DOAG Database days have finally persuaded me to talk more about #DBADev, let me explain why…

Whenever in the stone age…

During my career as DBA, I was always working closely together with Oracle Forms & Reports developers. In retrospect, the cooperation in that time was remarkable.
These Forms & Reports developers had always been used to working on a host-based platform.

For those of you who actually remember Oracle Forms & Reports and wonder…
Was there ever Forms & Reports host based?
Yes there was, but it is creepily long ago!!

Because of the nature of Forms & Reports, there always was a lot of consideration about where to place application code. This especially became true when PL/SQL was introduced and the migration to Oracle Forms & Reports 6.5 came about.
This brought the transition to client/server based computing and introduced physical distance between the database and the “front-end”.
Front-end between quotation marks, as in today’s world we don’t actually know “front-end” anymore in this same qualification. The “Frond-end” was always more elegantly and fittingly described as a “fat-client”, because of the sheer size of the software and utilities that were required on the end-users workstation.

The physical separation and distance between the presentation entity and the data manipulation engine required and inspired a lot of thought and debate on where the bulk of data processing had to be done.
You can imagine the impact of having a specific data manipulation done inside an Oracle Form that lived on a desktop on the other end of the network. Especially when the required data set is large. Having 1,000 records being fetched, where 2 where manipulated and then send back in bulk, repeated 100 times, 4 times a minute on a 10 Mbps network. OK, clear, that needs to be done smarter.
The solution: work with small data sets and do database side manipulation to limit client/server communication. And actually, that worked quite well!!

All good and fine… But how does this tie in to #DBADev? This already sounds so harmonious. And how could APEX Connect 2016 have inspired this article?

Well… Let’s see

Later on, I found that this cooperation appeared to be not so normal.
If you step out of the world of client-server computing and move on to “todays world”, that started more or less in the nineties with web based computing – or cloud-computing “avant la lettre“ or “my stuff on your computer” or however you describe it – you find a world that consists of “strange things”.
I find these things “strange things” because I believe they are suboptimal, and luckily I find myself not alone in this corner.
Suboptimal in a way that data manipulation solutions (lets call them applications for now) should be considered to be database agnostic. This independence dictates that you use the database as just a data store or even more accurately, as a persistency store. Blane Carter 2 minute TechTip

In another scenario these applications are designed and build by developers who are very good at creating intuitive and sharp looking user interfaces. Unfortunately often with a lesser developed understanding of the mechanics involved in dishing up and serving data to this newly established middle tier.

With the continuing professionalization of IT over the past 20 years, we have seen the creation of a wide variety of disciplines. These range from those who think about IT (architects, managers, designers) to those who build IT (programmers, engineers) to those who run IT (system administrators, operators) and the majority of these disciplines today are self-contained groups of professionals and specialists who excel at their own game. Basically that is good as the profession is wide and complex enough to support this.
The problem is that there is no longer anyone who has the whole picture.

Bring it on / together!

apex-logoAPEX Connect 2016, to me personally, was the first time I really saw #DBADev in practice. With the following two examples I want to illustrate my inspiration.

The first talk of this genre was @alexnuijten with his confessions, and subsequent smart tips and best practices in “Structuring an APEX application”.
As a pure database developer like Alex, you are automatically more prone to thinking about “DBA-stuff”. A lot of these best practices, although they are very database centric, like using a view for each application screen, are obviously primarily there to help the developer. And, don’t get me wrong, that is a very good thing! Alex inspires to try and combine the best of both worlds, which helps getting the most out of your application, your database, and therewith frankly, out of your total investment.

The second example was the information-packed presentation by Dietmar Aust @daust_de, called “Oracle APEX Scripting – die Kommandozeile ist Dein Freund“ (the command line is your friend).
Much more than “just about developing”, this presentation bridged gaps in more than one way. Perhaps it is even #DBADevOps if you think about it.

The recent DOAG Database days held a few additional surprises with the presence of @cczarski and @nielsdb. A very will pitched presentation by Bruno Cirone really sparked the growing interest in the topic!!

It is funny how an idea that was initiated some 18 months ago, conceived together with Sabine Heimsath @flederbine has grown and evolved out of natural demand. For me, this is one other aspect of the industry, where APEX is setting new frontiers.
With a growing awareness and more people recognizing the gap, the deficits it is bringing and the benefits cooperation brings, I have good hopes.

APEX is not only the technology that enables you to create web-based apps super quickly, it is also the technology that brings developers and DBA’s truly closer to each other, ensuring a maximum bang for the buck when it comes to utilizing your database infrastructure investments!
I am not saying we are there, but this is definitely a first step in the right direction!

Why GUI sucks…

Of course we all know GUI stands for Graphical User Interface, just as CLI stands for Command Line Interface, right!
Or, rather, a GUI is this nice, flashy screen where you can easily roam with your mouse, comparable to a multiple choice quiz, where the right answer is there for the picking.
A CLI on the other hand is this dark, mysterious blinking cursor… Nothing happens unless you know more or less what you are doing. Comparable to an open questions quiz.

Sparked by a recent Twitter discussion, I decided I should probably write the umpth blog post about this to make my contribution to this lasting dispute.

Disclaimer:
This post discusses GUI in relation to system administration, not necessarily in relation to data-entry or data manipulation applications that are used in front offices all over the world. I guess CLI has no place in a world like that…

bad gui

Why GUI sucks?
I have done my fair share of installing, scripting, ad-hoc fiddling, testing and trying. And, I have found myself in the situation where I worked with younger computer geeks or even in situations where nobody had the time to figure anything out – stuff just had to be made to work.

Probably in the few lines above, we could already have the basics for this discussion!

But, why then does GUI suck?

GIU’s suck because they are limiting, labor (or rather RSI) intense and require you, the operator, to be there, physically clicking away on your computer.

Limiting
They are limiting, or at least most of the time they are, because it is often quite hard to get a visual representation of each and every function of a device / program / system etc. If you consider, for instance, a networking device and then try to imagine having to create a GUI that lets the operator configure and define each and every parameter of a specific VLAN or VPN. And then also bear in mind that the GUI has to stay crisp, clean and intuitive.
For this reason, I have seen many vendors who have created a GUI for basic setup only, relying on the professionals to find their way in the CLI. They GUI can then stay intuitive enough to at least get the basics done.

GUI’s that aim not to be limiting, of which there also are a few out there too, need to sacrifice a lot of the things that a good GUI should stand for:

  • Short click paths (3 clicks from anywhere to get where you want to be)
  • Intuitive (don’t have to guess or read a manual to use a GUI)

So, what you end up with, then, is a maze of riddles, where you can easily spend a good day setting up some new functionality. Somehow I believe this is not what the designers had set out for nor is it a valid solution for most tasks at hand.

Labor intense
I personally find GUI’s often, quite labor intense. Not just for the absence of the ability to automate tasks, though. Especially if there is a lot of specific configuration that needs to be done, you often end up left and right clicking until your hands start hurting.
And, in the end, you always end up with the eerie feeling that you missed out on that one specific setting that would really put the icing on your configuration.

Operator presence
Last, but not least… For a GUI to work, you need to be at your workstation. Period.
Anybody who has ever worked on automated testing of applications that rely on a GUI, knows about the hideous crime of having to script test-cases, either working with hidden button-labels, screen coordinates, etc. Where these scripts fail every other day because a developer moved a window to a better spot or used a new button-label. You end up coding your application just to make it testable.
No, GUI requires operator presence, making it useless for automation or scaling.

good_cliThe bliss of CLI
Okay, middle Ages… or Stone Age…
Nothing really fancy, just a black (or, if you are feeling frivoled, you may choose some nice color) square on your screen with a blinking underscore – most often. And then you say; GUI sucks?

One of the challenges in this hyper fast moving world full of smart phones, tablet PC’s and what have you, loaded with intuitive and fast apps, is to realize that actually “hard core IT” is hard core.
You need to learn your stuff first, know what you do and know about the consequences of choices you make. You will have to learn to be able to walk the walk and to talk the talk. Once you have mastered that, this blinking underscore is no longer a roadblock but a invitation! Just like after mastering a foreign language, you will know what to say and do to open up the potential at your fingertips.

And now, reality
Of course, the above is ranting is just one side of the story.
It is even just one side of the story in hard core IT!

As already stated above, sometimes there is no time to really dive into stuff and get to know the tools you need to get to work for you. I am pretty sure we all have been in a place where we needed to get a project done or some functionality realized, where we just did not have the right devices.

What are your options at such a moment?
Get a hardcore IT specialist who does “talk the talk”?
Probably it will not be cheap and probably it will be a very thorough configuration, but just not exactly as you need it to be… Though still a valid option, even in a number of cases it’s a no-go.
This… is where a good GUI comes in handy.
It will allow you, yourself, to organize that which needs organizing in an orderly fashion. Okay, the GUI will have to be accurate and well thought through, but I that goes for all interfacing, that is also true for the CLI.

Seeing this story unfold… I guess I still think GUI sucks. (sorry!)
But GUI has a place, a very well earned place in a super-fast and highly demanding world. Still I am convinced that if you are working in a highly professional environment, having to do intricate stuff on ever live environments, I would say a good script for a CLI is the only way you can create some assurance that whatever change you need to execute will actually have a predictable result.

And putting in the effort of learning how to use any CLI? Well, I guess that’s why it is called “professional IT”.

Complex UI’s versus Simple UI’s

A few days ago I attended the AMIS UX & UI event.

During this interesting event, Niels Mansveld from AMIS presented about UX Frameworks. And he started off his presentation with an illustration about how user interfaces can create an “experience”, so to say. This illustration was a movie clip by Pixar, taken from the movie “Lifted”. It was so funny and, if you would watch it, you immediately know what Niels meant!

lifted uiThe day after I thought to show this movie at home and I found the YouTube link (https://www.youtube.com/watch?v=pY1_HrhwaXU). When I watched the clip, I realized that there was a second part to the preview, which Niels had left out, probably because of time concerns.
What struck me is actually the following…

I have seen quite a few views on user interfaces lately… Most of them talk about having clean and intuitive layouts and that it is important to think thoroughly about this. Shakeeb Rahman and Ultan O’broin are names that pop into my mind when thinking about this, and these gentleman are very clear about this!
Clean, intuitive UI’s make the Enterprise thrive!

Okay, but, as said, the clip went on for a little bit!TOAD saves

The second half tells the story of the Toad saving the situation, by using this same ultra intricate interface! By knowing what knob did which function, he was super-quick in saving the day!
Now, what would that mean?

Having a clean and intuitive layout may not be the ultimate solution in any situation, regardless! Having an application with a learning curve (not immediately judging the steepness of this learning curve is not always bad. If this interface helps the professional do his/her job in just a fraction of the time, because he/she knows what button to push, I think it’s a good thing.
I have to admit, there were one or two remarks about this in the flashing demo by Paco van der Linden… Bit I guess it is too little emphasized.

cockpitThere are several applications where these, more complicated interfaces do a superb job in helping the task at hand. And, as with anything, don’t blindly follow “best practices”, also in designing user interfaces!
Step back and think what would work best in your situation!

Hope this helps!

Visiting User Experience Event 18|3|2014

Today I had the privilege to visit the Oracle UX team from the USA. This special event was hosted by Amis Services (@AMIS_Services) and my visit was with Michel Koolwaaij, my esteemed colleague from VIR e-Care Solutions.

The event was super-well attended by a lot of enthusiastic people, comprised of students, novel developers and experienced seniors alike. I also got to meet a whole bunch of super interesting people (again) like:

  • Ultan Ó Broin (@ultan)
  • Patrick Barel (@patch72)
  • Noel Portugal (@noelportugal)
  • Lucas Jellema (@lucasjellema)
  • Lonneke Dikmans (@lonnekedikmans)
  • Mark Vilrokx (@mvilrokx)
  • Aylin Uysal

Through this post I would like to share some of what I picked up from the presentations and demos I went to and key learning points I figured out for myself.

Demo of Oracle voice (by Mark Vilrokx)
Oracle voice is a solutions based on Siri powered by Nuance which in fact now comprises a super lightweight front-end interface for voice-controlling Oracle Fusion Apps. The actual voice recognition and lexicon integration is done on the Nuance back-end.
A personal fun thing to find out is that actually the technology is again based on the work of the Belgian speech-specialists of Lernout & Hauspie, which I got to meet over 10 years ago!

Demo of Oracle mobilitics
Basically this is a demonstration of one of my key-take-aways for today.
These days you, as a classical developer, are challenged to step back, forget “grabbing data and throwing it into a grid or master-detail” and think about how you would “interact” with the data you have in your system.
If you think about it, you would not really want to scroll through master-detail… You want to visualize your data, so it becomes something more tangible and give you an overview with the ability to drill down or zoom in.
The “Designing for Mobility & Simplicity” talk of Aylin Uysal dove deeper into this.

Presentation UX directions with HTML5 by Mark Vilrokx
For me this was somewhat of a confirmation, strangely enough. Basically HTML5 is used as a rapid application development framework for Oracle ADF applications. In effect meaning that an Oracle APEX development environment supersedes Oracle ADF in both speed and diversity of application development (J) End of sentence

Presentation Designing for simplicity by Aylin Uysal
Stressing that person to person collaboration is still super important also (and perhaps even especially) for UX design. Organize several sesison consisting of different stakeholder groups, since UI design differs by user (or stakeholder) category.
Information abundance in classical UIs is to be replaced by minimal data UI design. Having less data, better (more visually represented) strongly increases UX!

Presentation Wireframing 101 by Ultan Ó Broin
Wireframing, in this context was new to me. Create a low fidelity “sketch” of what you want, don’t prototype anything yet! Create difference wireframes of applications and application flows to prevent “Squeak and poop” behavior of management or customers when presenting UX designs in wireframe format. A wireframe is no nicely worked out app, making it difficult to judge for outsiders.
A nice example of such rapid prototyping is the way Google Glasses is developed.
A good tool for digital wireframing (but also just for that) is Balsamiq which is used by the Oracle UX team as the preferred wireframing tool.

Presentation One picture worth a thousand words by Lucas Jellema
In this presentation of more pictures that words, Lucas gave some very cool examples of how pictures are able to, indeed, transfer much more information that words. An inspiration to use when you are UX-ing.

Visit to the Chamber of Secrets
I am so sorry, I had to sign quite an NDA before being let in… Please visit your local Oracle UX-session!

So, what are the key learning points:

  • Step back, and think free-flow how you would consume information. Unthink current UI design and… step back!
  • Less is more, also in UI design. A user experience is about getting to what the NEED as quickly as possible.
  • APEX is a viable development tool, in any situation!
  • User Interface design is becoming a serious trade, a trade to take into account.
  • Watch out for those InfoTiles!

A special “Thank you” to Wieteke Gaykema from AMIS who worked like crazy and still got me in at the Chamer of Secerts, even though I was shamefully late with my NDA!