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.

Your Code Base as a Crime Scene

The objective of the board game Cluedo is to deduce how, where, and by whom the victim was murdered based on clues gathered from the other players. Was it Colonel Mustard with the spanner in the Conservatory? Or perhaps Mrs. White with the candlestick in the Lounge? Use your deductive powers to ask the right questions, gather the facts, and determine the answers before anyone else and win the game.

An objective look at your code base should find a multitude of problems: lost architectural vision, questionable code structure, security through obscurity, undeleted dead code, inconsistent coding paradigms, copy-pasted code updated inconsistently, and much more! Instead of looking at the current state, let's look at he journey. Was it the sleep-deprived engineer at home with an misunderstood Stack Overflow answer, the Product Manger making unreasonable commitments on-site, or the non-technical leader making a technical decision? Or all of the above? The reasons are distributed throughout the organization with plenty of blame to distribute.

Join me for a fun discussion about possible triggers that started the 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 application that represents person-decades of effort. It likely started as a very well-defined, well-implemented solution to original business requirements, but over time became a behemoth as functionality was added without considering the overall impact.

Unsurprisingly, the application has not aged well and eventually 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 that a rewrite is required; it's often interpreted as engineers wanting to do 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.