Introduction to Open Data

Open Data is data available publicly accessible and shareable by anyone for any purpose AND is machine readable, usually - but not exclusively - provided by governments and other public agencies.

You may ask "So what?" Open Data is diverse - public transport, crime statistics, pollution levels, government lobbying - so it's a matter of finding interesting data and seeing what you can do with it. Open Data is the logical successor to Open Source Software but is not as well-known.

In this talk you'll learn the definition of Open Data, its importance, and how to search for and consume from available sources. We'll wrap it up with a live demo showing Open Data being retrieved, consumed, and visualized.

This is a re-work of a previous talk presented at JavaOne and DevoxxUK, this talk focused more on Open Data and less on the demos. Previously the demos were Java-/Neo4J-based but other technologies may be incorporated, depending on conference.

Personalizing Your Random Numbers

Random number generators (RNGs) generate "supposedly" random numbers for use in your application or solution. However, most RNGs are algorithmic, "pseudo", that anyone who deeply understands the algorithm may be able to regenerate the "random" numbers. Often this isn't too concerning: go ahead, recreate the shuffled songs played by Sonos.

But when it's important, it's REALLY important: cryptographic keys, digital signatures, authentication challenges, statistical analysis, gaming and gambling. Different algorithms have different entropy: higher entropy leading to better randomness - assuming, of course, no back doors were injected! That said, even strong algorithms displaying high entropy _may_ have faults to exploit. Should you be concerned?

In this session we'll dig into RNGs, pseduo-RNGs and, for the truly concerned or paranoid, learn to create custom true RNGs that are impossible to hack. Hope you can join us!

This talk is both theory and fun/geeky, defining random number generation - not going overly deep, differences between true and pseudo, possible ways to test, etc - and then creating hardware RNGs that are based on your personal environment and therefore very likely to be random AND unbreakable.

Code Scene Investigations: Whodunit

The objective of Cluedo is to deduce how, where, and by whom the victim was murdered based on clues gathered from the other players. Colonel Mustard, spanner, Conservatory? Mrs. White, candlestick, Lounge? Ask questions, gather facts, and deduce answers before anyone else to win.

An objective look at your code base finds many problems: lost architectural vision, questionable code structure, security through obscurity, undeleted dead code, inconsistent coding paradigms, copy-pasted code, and more! Instead of considering current state, let's look at the journey. Did a sleep-deprived engineer misunderstand Stack Overflow, did the Product Manger making unreasonable commitments, did a non-technical leader inflict her technical decision? Causes are distributed throughout the org with plenty of blame to share.

Join me for a fun discussion about what triggered a decline of your code quality and what actions you, as the engineer, can take to protect the code and yourself!

Data Modeling for Software Engineers

Really, data modeling? Is that even a thing any more?

The days of formal data modeling are definitely years in the rearview mirror, empowered teams define their data as they see fit, implement, and move on. Done. And we'll deal with short-comings down the road when they arise, that's Agile, let's keep moving forward (to data architects' frustration when trying to make sense of it all after the fact).

But "modeling data" extends beyond what is persisted in a database server: API Payloads, messages, configuration files, document metadata, Redis indexes are forms of data we define and work with regularly.

If I've got your attention, join me to discuss data modeling, this time from a software engineering perspective!

Demonolith the Monolith? Think Again!

Mature organizations often have that all-encompassing, business-critical app that represents person-decades of effort. likely starting as a very well-defined, well-implemented solution for business requirements which became a behemoth as functionality was added without considering overall impact.

Unsurprisingly, the solution has not aged well and even leadership admits there are problems:

* consistently increasing production bugs that require immediate attention;
* dramatic increase in time required to deliver new features;
reliance on key individuals to do critical work due to cognitive complexity;
* inability to successfully monitor application to understand its true state.

Legitimately, organizations are loathe to accept a rewrite, interpreted as engineering for engineering's sake. Leadership makes a call to action to find a less-costly and more timely solution. After much analysis, discussion, deliberations and hand-wringing, it's decided: Demonolith the Monolith!

presented at DevoxxUK, Devoxx Morocco, and BuildStuff, as well as non-public forums.

Customized Jakarta Bean Validators

Most of use use annotations from Jakarta Bean Validations to define acceptable values for properties and parameters: @NotNull, @NotBlank, @Min, @Mix, @Size. Less code, more consistency, fewer bugs. Wonderful!

However, what about less-than-trivial object validations, e.g., validation based on object state or multiple properties? More complex validations require implementing custom validations which, if not careful, may become spaghetti code. However, there are alternatives, such as creating DSL (domain-specific language) validators.

If this problem sounds familiar, join me and learn how to create customized bean validators and how a DSL customized validator eliminates code bloat, resulting in maintainable and self-documenting validations. Hopefully you walk away with new ideas and possible approaches for your current dilemma!

The DSL validator is a real-life solution created to solve the problem of a customized validator whose code was impossible to understand. I've written up a 4-part DZone article discussing the specifics: https://dzone.com/articles/dsl-validations-properties

The DSL is Kotlin-based and publicly available on GItHub. The talk itself will be Java-based.

Under the NIO Hood: Building a File System on Neo4J

How well do you understand Java NIO? I mean REALLY grok Java NIO? Yes, java.nio.file.Files is incredibly simple for basic file work, but dive any deeper? Nope, me neither ... until now!

Applications, SaaS apps in particular, often implement app-specific file management where local disk doesn't meet the requirements. A directory tree is stored in a database - too often SQL - and files are persisted externally (think Azure Blob or AWS S3). The functionality is via customized APIs and limited to basic CRUD operations: create directories, upload/download files, read/modify security attributes, delete files and directories, etc. A limitation that nothing is standard, everything is a one-off.

A second limitation I've discovered is how a directory tree is managed: for performance, files and directories entries are fully "inflated" with its fully-qualified pathname, inherited permissions, and whatever else stored with the entry. While this approach does reduce database calls when navigating, but certain tasks - moving a directory or changing its permissions - requires updating every moved entry. When thousands of files are involved, it's expensive and time-consuming.

This is where Java NIO and Neo4J rocks. Java NIO provides a File System API for implementing custom file systems that are used via standard JDK calls. A directory tree is a simple directed graph - no loops - and Neo4J excels in navigating an arbitrary graph distance. Now derived data can remain derived, not persisted. Looks like both limitations could be addressed!

Join me to learn of my Java NIO file system solution using Neo4J and how powerful Java NIO's design and implementation is. Yes, geeky but more fun than I've had in a while. I'd love to explain the architecture and design and show you it in action.

New talk for 2026. Combination presentation and live coding. Geeky buy deep Java.