Sebastian Golasch's Speaker Profile @ Sessionize

The dark ages of IoT

Abstract

Advertisements suggest that we are at the zenith of mankind's scientific knowledge and technological power, but when it comes to IoT and the so-called 'Smart Home', we are clearly not. In fact, we are in the middle of the dark age.
I'll explain the challenges that we're facing today (from an implementors perspective), what's 'wrong' with our current products & show you how a smart 'Smart Home' experience could look like in the near future.
Details

If people buy "Smart Home" systems today, disappointment isn't far off. In fact, I haven't met a single person who is satisfied with their Smart Home installations & gadgets. Most of the time it is because they aren't smart at all. The interaction with the user is terrible, the systems are flawed & pulling out your smartphone to adjust turn on your living room lights feels more like a step back.
Yet, there are reasons why vendors weren't been able to solve the problems of this fairly young technologies. And it´s not because vendors don't see the needs of the users (mostly). I´ll explain (with code, examples & hardware demos), where we are today, what problems are still waiting to be solved and how modern (so-called) artificial intelligence (don't like that term) used to solve the biggest problem of all: The human <-> computer interface.
Note: Code examples will be in JavaScript (NodeJS)
Pitch (Anything else you want us to know about you or your talk?)

I´ve been working in the field of IoT (to be precise in the field of Smart Home systems - see *1) for over 6 years now. The landscape changed a lot in those 6 years, but a lot of problems we encountered early on haven't been solved until today. Not from us. Not from other vendors. And there are reasons why they still persist, so I´ll explain those problems (mostly user interaction, a few technical difficulties as well), and how we´re (as in all implementors, not only the company I´m working for) trying to solve them with upcoming technologies.
Note: This will not be a product pitch of any sort, I´ll only use Open Source technologies to explain the system & will mention the product I´m working on max. 1 or 2 times to illustrate problems device vendors have to solve.
What will the audience learn from it

The problems implementors face today when building smart home systems
About the protocol madness & technical details of the most used smart home protocols (Plus learn how to implement/use them)
How the industry fails to provide UIs that enable users (and why)
Basic understanding of the data flow & building blocks of Smart Home systems
How AI (Cognitive Services) can enhance the Smart Home experience (in fact, just really enable it)
How those systems can not only be technical toys but of real help (f.e. for people suffering from depression)
How interaction with those systems will get more natural & what we can expect of it in the near future
Outline

The history of Seattle a perfect analogy for the evolution of Smart Home technologies so far
The gap between technical innovation & innovation of User Interfaces (based on studies about Europes most popular home automation systems)
What do we as developers think when we hear IoT? (Hint, hardware, devices, microcontrollers...)
What do we forget about? (Hint: Our users, the human beings who need to interact with the systems we build)
WTP (What the protocol) An overview of the most used smart home protocols & their key entities
Demo (+ Code): Use an Enocean based light switch to control an Arduino
Explanation of the complexity of a "modern" lightswitch (Which is not smart & not even automated)
What could an automated (still not smart) home look like (Example of a geofence, lightswitch scenario)
Quick overview of one of the crucial Automated Home parts, the rule engine
It all is still pretty technical & abstract
Modern UIs converse with the user in a way it´s "normal" for them (f.e. Chatbots)
What could a smart home look like
Use AI (Cognitive services) to enhance the UI, by normalizing the interaction with the user
What separates humans and computers most? Emotions!
Demo (+Code): How can we teach a computer to "calculate" our emotions
What´s this good for? Example: People who suffer from depression can benefit from surroundings that adapt to their state of mind
Summary: Technology should blend into the background & enable the user. Interaction needs to get more natural.
Who is this presentation for?

For everyone who wants to...
...understand why the current state of Smart Home systems is so displeasing.
...know what problems implementors face.
...how the future of those systems could look like & which technologies it´ll be driven by.

EME? CDM? DRM? CENC? IDK!

Abstract

Once there was the video tag, but content distributors decided it wasn't enough. They wanted more - more power, more protection, more control, more features. So, Encrypted Media Extensions were born & Digital Rights Management appeared in our browsers.
In this talk, we'll explore the technical details behind Encrypted Media Extension (EME), Content Decryption Modules (CDM) like Widevine, and the foundation of Web Digital Rights Management (DRM). How? By reverse engineering Netflix and building our own personal Netflix video player!
Details

We´ve all used Netflix, but most of us (developers included) do not know how to deliver or implement encrypted video to the browser ourselves.
I´d like to invite you to join me as I recap my journey into reverse engineering Netflix. I'll let you know how I came to understand the messy, monstrous world of DRMed videos on the web, how fragmented this ecosystem is, and who is in control of what.
It´s a depressing but fun journey full of WTFs and technical/legal constraints that I had no idea about when I first set sail watching Netflix on my Raspberry PI.
Pitch (Anything else you want us to know about you or your talk?)

Usage of web video behind a paywall (*1 Adobe Digital Index Q1 2016 Digital Video Benchmark Report) is rising constantly and every device with a display that is produced nowadays comes with some sort of web browser that should be able to play all videos (Hint: It´s not that easy). Cisco estimated that by the end of this year, 80 to 90 percent of all global internet traffic will come from video data (*2 Cisco estimation of growth of global Internet traffic over time).
Based on these unbelievably high stats, I believe that every web developer would benefit from a basic understanding of the mechanics behind "DRMed" videos on the web and the history behind them.
What will the audience learn from it

A super short history of web video
What the different meanings behind DRM for web videos are
What different DRM implementations/protocols are out there and when/why they're used
What a CDM (Content Decryption Module) is and how it's used to decrypt videos
Why hardware acceleration is mostly a no-go for web video
What EMEs (Encrypted Media Extensions) are and what implementations on the client look like
The flow of a browser requesting & playing encrypted video
What restrictions video platforms get from content providers
(Bonus: If there´s time - Netflix on Raspberry PI isn't a myth)
Outline

The real story of how a random web developer fell into this devil pit
A super-short history of web video (From Quicktime/Flash/Silverlight and the video tag to MPEG-DASH)
The media playback ecosystem (Stakeholders and their role)
Case study Netflix - Pure map of HTTP requests made to play a video
API flow for requesting encrypted video with EME
Different implementations for different browsers and operating systems (and their implications for implementors and users)
Sir Tim Berners-Lee approves
(Chrome+Firefox)/Widevine CDM architecture (and a peek at Playready & Fairplay)
The blurry outline of robustness requirements and their impact on Hardware/Software decoding
Manifest files & content negotiation formats in detail (MPEG-DASH)
Demo: Build your own Netflix player
Explanation of the code behind the self-implemented Netflix player
(Bonus: If there´s time - Netflix on Raspberry PI isn't a myth)
Who is this presentation for?

Web developers who would like to understand these cryptic terms (EME, CDM, DRM, etc...), and want to know how the client side implementation of video platforms is really done. I also believe it is of common interest for any user of web video behind a paywall because it allows a look into this media sandbox - its implications and drawbacks.

Your cyclomatic complexity is so 1.9,76

Abstract

In 1976 Thomas J. McCabe, Sr. developed metrics to determine the complexity of the code we write. One year later Maurice Howard Halstead formulated the so-called Halstead metric to achieve something similar. 30 years later, we still rely on those abstract numbers that describe the complexity of our code, but do these naked numbers really tell us the truth about our code? Do they really give us the best advice on how to manage our code over its lifetime?
I believe not. Thanks to our modern, sophisticated toolchain we have many metrics at hand that Mr. McCabe & Mr. Halstead could only dream of. In this talk, I´ll explain how the combination can give us much better & "more human" advice about the flaws of our codebase - not as abstract numbers, but as concrete pointers to the parts of our code that really need our love & attention.
Details

A common "How to" for measuring the complexity of your code looks like this (see *1): "Install it - Create the report - Watch the report - And now go try to make your code better!". This is not far from the famous "How to draw an owl" (see *2) & only slightly worse then trying to understand this complex topic from Wikipedia and the related formulas (see *3)
Aside from understanding these abstract numbers, we need to ask ourselves if looking at those metrics isolated is still the way to go more than 30 years after its invention. Our ecosystem has grown and so has the available data about our code.
Besides explaining the basics of the code complexity metrics, I´d like to evaluate & explore the questions:
Are those metrics still relevant today?
Is it really worth spending time looking at those numbers as isolated metrics?
Is this really the best way of signaling to a developer that something seems to be wrong with their code?
What other metrics can be included, to make them useful & tell us something about our code & coding behaviour?
As an example, you might have a very complex bit of code (for whatever reason) that the metrics are always pushing you to refactor. However, there was no other clear reason for needing to touch this code for ages - it runs without problems, there are tests for it, the developer who initially wrote it is still regularly committing to the project, etc.
Should this piece of code really be at the top of your list for refactoring? Seems not.
I´d like to explain how we can get a clearer picture of our codebase by identifying the parts that really need some love (hotspots), or are easy targets for refactoring (low hanging fruits). Further, I´d like to introduce an automated way to identify these, based on metrics like:
The git commit history (number of people working on that code)
Level of detail in commit messages
Number of bugs over time measured (with tools like Sentry or Bugsnag)
Code coverage metrics
Number of code & comments added to files over time
Linting errors introduced/solved over time
Sources

*1 https://coderwall.com/p/q3mtgg/reduce-code-complexity-for-javascript-using-plato
*2 http://knowyourmeme.com/memes/how-to-draw-an-owl
*3 https://en.wikipedia.org/wiki/Cyclomatic_complexity
Pitch (Anything else you want us to know about you or your talk?)

I was once a number fanatic - a developer that introduced each and every metric into the CI system I could get my hands on. I didn't always fully understand what the numbers meant, but I still drew (wrong) conclusions. I think many developers do the same - introducing code complexity metrics, but then lowering the bar of those so that they don't raise any more warnings. In other words, introducing tools just for the sake of producing metrics & more numbers.
I got rid of my number obsession. I reflected upon my behavior & wrong conclusions. And, I think that others can benefit from what I learned. There are new ways to explore how to look at your codebase. Helpful, practical ways - not ones full of abstract numbers & metrics.
What will the audience learn from it

History of code metrics
What these metrics are trying to tell us
How we often fail to use them
Why I believe we need to do better to get meaningful data out of metric tools
Evaluation of what data we actually have at hand (often without knowing about it)
How tools can & should be combined to give us concrete advice
How those tools should output their conclusions to provide meaningful advice
Outline

McCabe & Halstead, pioneers of code metrics
30 years after: Have we learned a thing?
Cyclomatic complexity - the programmers worst enemy explained with code
"The way to hell is paved with good intentions", or "How we fail to interpret our metrics"
What else is there? Metrics we have but don't know about
Making sense of it all: Combining metrics to change the way we look at our code's flaws
A better way to present the analysis to developers
Demo: How a prototype of such a tool might look
Who is this presentation for?

Web developers who are like I once was. Obsessed with numbers, obsessed with metrics, but without proper ways to interpret them. Web developers who need to work in teams and who need to maintain a large codebase over years.

The Intranet of Things

Ever backed an amazing smart home tech gadget on Kickstarter and ended up with a useless piece
of techno garbage 6 months later, because that amazing start up ran out of money and needed
to shut down the servers?
Welcome to the wonderful cloud centric world we call the "Internet of Things".
But does it always need to be that way? I say No!
Thanks to the wonders of WebRTC, Service Workers and Node, we can create a world
in where todays consumer IoT hardware can be controlled using a P2P model.
I´ll demo a WebRTC based Smart Home Hub concept that interacts with ZigBee lights (Philips Hue),
WiFi Cameras and locally available voice and face recognition systems, without sacrificing
the comfort, security & privacy.
No data will ever leave your most private space, your home.

The Universal Serial Web

## Abstract

As a web developer it´s easy to feel intimidated by the world of hardware hacking and the physical web, we have to leave our comfort zone
and need to get familiar with a completely new development environment. But not anymore, thanks to wonderful possibilities that the
WebUSB Api brings to our browsers.

In this talk I will give an intro to the endless wonders we can encounter in the hardware world through our browser windows.
Aside from leaerning the basics of USB and serial port communication, we´ll paint on USB displays, live tweet to receipt printers,
control an Arduino, steal data from Android phones and many more... The only limit is your imagination.

## What will the audience learn from it (Outline)

- Why WebUSB? What´s the use case?
- The (not so) boring bits: How does USB work?
- A 5 minute intro to the WebUSB API
- Paper is patient: Tweet to a receipe printer
- Extend you browser window to USB screens
- Instant Arduino, lets build an educational game for kids
- Control you home with your browser and only your browser
- Create your own public book library with WebUSB
- What about security? A simple example of a website stealing data from your phone.
- Isomorphic WebUSB - Reuse your code in Node.js

## Who is this presentation for?
Web developers who...
...feel intimidated by the world of hardware hacking
...like to understand the basics of USB
...just wanna have some fun

In Pale Moonlight

Humans are a funny species. We may have developed the most sophisticated tools and technologies on this planet,
but our brains mostly haven't changed in the past 195,000 years. "Fight or flight" might have been a fitting paradigm
for our ancestors, but the environment we´re in nowadays requires us to add more nuances to our behaviour.

In this talk I will try to give an insight into some aspects of our behaviour, especially how signals from the outside
world can influence our decisions without being noticed by ourselves.
Prepare yourself to learn about why finding a dime in a phone booth turns us into better teamplayers for a day,
how Chinese brainwashing techniques rooted in the Korean war can be used to improve our lives and why every
team should have an initiation ritual for new members.

Speaker

Sebastian Golasch

Actions

Links

Sessions