This article is part of my #100DaysOfCode and #100DaysOfBlogging challenge. R1D15

I have to say that I am surprised by the overall high-quality sessions. This is one of the best conferences I attended. Thanks to all the speakers and their effort and time they put into preparation. You rock!

Modern SQL: Evolution of a Dinosaur

By Markus Winand, “SQL renaissance ambassador”, independent author, trainer, and consultant on all things SQL

It was a bliss listening to Markus share his expertise on SQL. The session was absolutely interesting and informative.

He started off by asking the rhetorical question

Still Using Windows 3.1? So why stick to SQL-92?

During the next 45 minutes he spoke about the various standards, which features were introduced, and the current state of which databases are supporting said features. He made it more than clear, that if one is still using MySQL 5, it is time to update to MySQL 8.

I was able to take notes of only a fraction of the session. If you get a chance to attend one of his talks, make sure you don’t miss it!

SQL:1999

In 1999 recursive queries were added, which allows transitive closures like in child-parent-relations. GROUPING SETS

SQL:2003

An important function was added: Windows Function aka the over clause.

If you have SQL on you CV, but don’t know Window Function, you need to cross it out. But you can add it again in 10 min, because I will teach it now!

What a great guy. 😂

SQL:2011

If you’re using OFFSET for pagination, you’re doing it wrong. It gives you the wrong result and is slow.

Read more about it here.

SQL:2011 introduces System Versioning, basically time traveling for data storage. INSERT, UPDATE, DELETE are DESTRUCTIVE. Tables can be system versioned, application versioned or both.

System versioning

  • Keeps track of changes as these are learned (sets timestamp for when change is known).
  • Validation columns updated by system.

Application versioning

  • Keeps track of changes when they actually happened (actual timestamp of when the change occurred).
  • Validation columns updated by application.

SQL:2016

JSON_TABLE allows consumption of JSON strings in SQL and can serve as a bridge between NoSQL and relational databases.

Conclusion

SQL has evolved beyond the relational idea; SQL has broken out of the relational cage.

If you use SQL for CRUD operations only, you are doing it wrong.

SQL was not designed to be a simple data store (row-by-row processing). You should collect all the data on the database, transform it into a form which is more useful and return it.

Further reading

Introduction to Architectural Katas

By Frank Sons, a freelancing developer and consultant for agile software and code quality

Architectural Katas can bridge the gap between requirements and technical implementation.

The software architecture are those decisions, that are hard to change.

Martin Fowler

The greatest teacher, failure is

Since we can learn so much from failure, how could we fail more often.

A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each.

Codekata.com

Code kata are very simple problems, which can be solved in 20 minutes to 1 hour. It helps training to look at solutions from other perspective on each iteration.

Basic idea

  • Manageable in size and duration
  • Make mistakes, fail and gain experience
  • Get feedback in a group

You put yourself in a situation, where you need to be prepared to fail. And take failing as a learning experience.

Two scenarios

  • 3 to 5 people in group (optimal being 3, since all are involved and challenged, allowing a lot of discussion)
  • 4 to 10 groups vs max 3 groups (depending on available mentors)
  • Different Projects / Kata vs Same Project / Kata for each group (the latter allowing collaboration and discussion afterwards)

How does it work?

Introduction > Planning > Presentation > Feedback

Rules

The goal is not to come up with a concrete solution. The goal is to come up with a rough architectural vision of the project and defend questions about it. So, it is crucial to gain a common understanding of defined requirements. Assumptions about technologies have to be clearly defined and spelled out. You may not assume you have hiring/firing authority over the development team (sizing up the team to meet deadline) (what a bummer 😂). Any technology is fair game (but you must justify its use). Any other rules you may ask about.

If you ask a customer whether they want to a feature, the answer usually will be “Yes”. Your duty is to communicate the impact on the timeline and costs. The business decision is the customer’s responsible.

How do I get from unclear requirements to an architectural structure?

Instead of rewriting specs in own words, use a structured language. As a communication tool, UML is fantastic.

  • define user roles
  • define use cases
  • …

The first version won’t be good.

Plan to throw one away

Frederick P. Brooks - Mythical Man Month

Rapid Prototyping

What about iterating throwing away versions - throwing away the first three or four versions. Or iterate parts of the draft that don’t work.

Work on a whiteboard. It makes easy to wipe things away. Flipcharts is the perfect example of what happens when you implement code. Once implemented it is very hard to erase or change.

Container diagram or C4 Model.

UML can be very confusing, C4 only uses the most four important. Makes usage easy and lets you focus on designing.

Why you shouldn’t care about Security

By Ben Dechrai, Technologist, Presenter, Auth0 Developer Evangelist, Community Advocate

Ben’s sessions are always fun to attend. He is an experienced speaker who quickly informs about all necessary details and also shows a great live demo bridging the gap between theory and practical use (at least the sessions I attended so far).

Traditional authentication and authorization can become complex quickly, especially when scaling.

As we don’t implement our own payment service, but use a provider, we should not implement our own authentication mechanism, but use an identity provider for login process as user storage.

Live demo application of creating a PHP web application adding Auth0 as identity provider.

First impression: Very well documented, simple to implement, ready-to-go.

PHP to Hack, an incrementally typed Adventure at Slack

By Scott Sandler, a Senior Staff Engineer at Slack

Awesome talk with Slack’s journey on migrating from PHP to Hack. There was so much information, I could only take notes on a few thoughts. I definitely recommend viewing the slides.

  • We came to Hack for performance but stayed for type safety.
  • hh_client Type Checker
  • Hack will drop PHP support
  • Inferred Union Types
  • Generics: Array, Hack Arrays, Shapes
  • Shapes allow type definitions of arrays with mixed values - But why not use a class instead?
  • Type refinement knows that a key is present within an if condition where you check Shapes::keyExists
  • Hack standard library improves standard functions.
  • Hack Pipeline with HSL
  • Type Checked Regex
  • XHP: Type safe HTML.
  • Greatest task in migrations: Type safety
  • You lose vendor libraries (incompatible to composer (PHP) packages)!!
  • Instead of performance measures etc. internal survey on how developers feel about the code base. Large majority confirmed it improves, because type checks help understand what the code is doing.

Slides Twitter

Getting started with PHP on AWS Lambda

By Thomas Bley, Senior PHP Developer at Bringmeister

I’m new to AWS, so I tried following as much as I could. Thomas made a great and thorough job explaining each step to setup lambda functions on AWS. It looks very promising and interesting for the following use cases.

  • cronjobs (don’t pay for idle time)
  • websites with unknown traffic spikes (tv advertising)
  • event based workers (Kinesis, SQS, S3, etc.)
  • event based backend tasks (images resizing, creating PDFs, sending e-mails, etc.)
  • integration with database event, e.g. RDS Aurora

Slides

In fünf Jahren wird es keine Tester mehr geben

By Nils Langner, Founder and CTO of Leankoala // Rethink Web Testing

In five years, there will be no more testers.

I remember Nils from his successful blog phphatesme, which later became the web hates me. It used to be the most successful PHP blog in Germany. I liked it for the thought-provoking articles and excellent exchange among visitors.

Although the title is not meant (absolutely) seriously, again Nils delivers a message that encourages to reflect on common opinions and to exchange views on testing.

During his presentation he touched upon 10 reasons that could make testers (almost) obsolete. The following are just my notes and not necessarily a true representation of what Nils delivered.

  • It is a boring job. Fewer and fewer developers decide to become a tester.
  • There is a risk-based approach in which tests cover only the most important components. Not everything is equally important.
  • The team, not the individual is testing.
  • Explorative testing for large releases rather than testing each release. One way to accomplish this, could be crowd-testing (Testbirds, test.io, Applause, Testival)
  • Static code analysis and the use of software metrics. Give a piece of code a qualitive number value. Linting, check for syntactical correctness.
  • Error costs dropped. When shipping code on CD, bugs were fatal. For web applications a fix is done much quicker. Especially with the help of monitoring (New Relic, Appdynamics, Instana, Tideways).
  • Your project is nothing special. In the early days everyone was writing their own framework or CMS. It was 90 % own code and 10 % 3-rd-party code. Nowadays it turned, 10 % being own code, 90 % being 3-rd-party.
  • Your project will not succeed. 9 out of 10 start-ups fail during the first year of operation. According to experience this could be applied to features. So instead of doing things right, try doing the right thing.
  • Fully automated tests. Click-path testing tools like Selenium are time consuming and complicated. Property-based testing where it checks for the presence of business-relevant elements could provide the same quality for much less cost.

If all business-relevant elements of a website are present, it is statistically likely, that there are no critical errors.