Note that attendance to the sessions are optional. There will be 2 to 3 sessions going at a time depending on scheduling but feel free to hangout in the main hall and hack on your own thing or collaborate with others.
It seems inevitable. As we’ve moved to a more component-centric UI architecture, we’ve moved our JS and HTML and CSS closer and closer together. Surely they’ll eventually end up all in a single file, right?
Not long ago, this idea was unthinkable—our units of composition were too large and divided along language boundaries. But things are changing.
This is a talk about the dream of a unified development language for components, and the progress one library, Styled Components, has made towards that goal.
selecting hardware and developing circuits,
overview of some of the different options for developing programs to read from sensors and control actuators for robotics and IoT projects using JS,
connecting your device and getting it talking with other devices and services
The Generic Sensor API is a specification that provides browser vendors a framework for implementing APIs accessing hardware features. What does that mean for developers? For the first time, it's possible to play with a whole new range of sensors, such as the accelerometer, gyroscope and magnetometer. This talk will cover the current state of the Generic Sensor API, the APIs built on top of it, and how you can get started using sensors via the web!
💰Learn how to integrate the W3C’s new Payment Request API into a payment flow (shipping in Chrome, Edge, and soon Firefox).
💰Signal which payment instruments can be used (e.g., credit cards, Android Pay, etc.),
💰how to guide users to fix things when things go wrong.
The Internets, it’s serious business! 📈
Open science should be visible science. And what better way to make your research visible and accessible than putting it on the internet. But no one wants to read endless tables of data. We’d rather look at graphs, or, even better, have the possibility of interacting with the data. And we have probably all created some graphs. But in order to make them accessible to many people, we will have to move away from our specialized software to a more universal platform - the internet.
We want to display our data on a website to increase visibility and accessibility of our research. Our goal is to create a dynamic bubble plot (a prettier version of a scatter plot) and publish it on the internet.
In this talk we’ll go through some history before diving into how it all fits together and how you can start using it today.
Historically, we have developed web applications with the assumption that the end user is connected to the internet. With the ever increasing browser support of Service Workers, however, this assumption is quickly becoming outdated: developers now have the opportunity to create websites that can work offline, independent of network status, with great flexibility.
But let’s take a step back: what is the Service Worker API? How does it enable developers to develop web applications with offline capabilities? To help answer these questions, one should look to its predecessor: the Web Worker API. By understanding what the Web Worker API provides us (and what it doesn’t), we can better understand Service Workers and how to use them.
In the past few years, we’ve witnessed a massive increase in the amount of CSS experimentation, with ideas like CSS Modules and—most controversially—the rise of CSS-in-JS. But does mixing our styles and logic run counter to the original ideas of CSS? Does it break progressive enhancement?
In this talk, we’ll take an empathetic look at these new approaches, how they relate to the history of CSS, and why they might possibly hold the key to the future of CSS—all from the point-of-view of someone who has been writing CSS since 1999.
With the latest version of node and the latest browsers, lots of the cool parts of ESnext are available to use now. Modules? Yep! Async/await? Yep! Let’s see how they can a code base better and easier to develop with.
What do you think Electron can do? Atom text editor? Slack chat? Hyper Terminal? More than that.
In my talk, I will go from my experience for building a production ready commercial desktop application to useful command line tool to mind blow mad science p2p live video chat(not unlike PipeChat in Silicon Valley).
It will cover:
* basic feature of using Electron build user interface(alone with a native Golang binary file running inside the app)
* as a headless browser to build command line too
* hidden browser only feature that could be "abused" from a hardware device like Raspberry Pi
iflix is one of the largest SVOD services for developing countries in the world, going from 0 to 1 million users in less than six months, and adding on many more millions ever since. Unlike western and first-world countries, many users don’t have the luxury of a functioning broadband connection. So how do you get your service to users in Nigeria - when nobody has a computer, and mobile data is at an extreme premium? This talk will cover everything from using Lambda & S3 for serving content, to maintaining Kubernetes for realtime services, all the way to deploying our own mini-CDN across Asia, Africa and the Middle East.
Frontend: RiotJS + Webpack for ’static’ loading. Build different bundles for users in different countries to optimise languages etc
Lambda: great for tracking ’async’ reqs. Not good to use for realtime because of latency in these countries.
S3: Static EVERYTHING. Can be cached at edge nodes instead of having to travel back to nearest region w/ AWS DC
Physical infra: Deliver everything way faster than using traditional internet. Install servers in local internet hubs & in Telcos.
CDN: Akamai/CF. End user traffic only has to hit local edge node, which is then sent over the internet using CDN connection rather than users slow internet connection. Also caching.
Kubernetes: Helps us maintain massive scale, runs all our realtime services, dynamic autoscaling etc.
+ more (time permitting)?
If you're interested in Styled Components or CSS-in-JS in general Glen will be answering questions and demonstrating techniques to solve common problems. You're welcome to ask for feedback or advice on your own projects if you like, or simply listen to the discussion & follow along the examples.
Drop in and out. No fixed program.
I'll run through a range of tools and techniques used to handle asynchronous operations that occur in the real world, address some the pain points of each method, and try to present an enjoyable and productive solution.
An exploration into how a flexible approach to Event Sourcing combined with a few simple abstractions can dramatically simplify traditionally complex problems. Examples include a complete email marketing solution, and fully automated feature analysis and rollout.
It's lovely making things beautiful, styles are no exception. It's also great to make things beautiful in an elegant way.
Traditional styling patterns and frameworks require context switching when writing styles for components. They make it hard to share logic between your applications content/structure and styles. You are also required to setup build configuration or use client side parsers which add complexity and performance concerns to your codebase.
Glamorous has an elegant api that allows you to write style components that follow react patterns, are easy to test and don’t require extensive configuration or expensive parsers. It allows you to write your application styles in the same language, using the same patterns as the rest of your code base.
This talk covers the what and why of glamorous, how it helps you write beautiful code and elegantly structured applications and why it's a great css-in-js community to contribute to.
Lets face it, frameworks lead to lock in. Every project eventually reaches a point where the original requirements that drove you to chose that specific UI framework have now changed, and now your only option is to start again from scratch.
As a thought experiment, what if developing against UI frameworks didn't result in framework lock-in, what if the components that comprised your UI were agnostic to the framework that managed them, and what if adopting a new UI framework didn't result in a complete ground up rewrite? What would that mean for you as a developer? In this talk I'll explore UI components from the ground up, and what it means to develop truely portable UI components.
Spoiler: this isn't a WebComponents/CustomElements talk.
Having built an API server in NodeJs, and testing it using mocha+chai+sinon, we migrated the tests over to Jest. There were several hard-won lessons along the way, which requires one to change the way they approach writing tests. Some of the paradigms involved are:
1. Framework vs library
2. DRY vs DAMP
4. chained APIs
5. warping test time
Who this talk is for:
2. Jest is also the new kid on the block, with mocha and other test frameworks having been around for much longer. This talk is for those who are using one of these other test frameworks on their existing projects, and considering switching to Jest.
If you wish to go on an adventure, I offer an alternative where systems are easily composed using only the simple abstractions of functions and objects. i'll go over common higher-level abstractions and show alternatives to popular trends using only these minimal primitives. i'll also a share two personal stories about doing this in practice, one of great success and one of terrible failure. :)
Everyone loves to talk themselves up in conference presentations, regaling you with tales of their technical brilliance. Sure these talks can be filled with valuable information about the latest technologies, but have you ever stopped to consider how it makes you, the audience, feel? After you’ve spent the weekend hearing about reactively programmed event sourced games running in the cloud isn’t hard to go back to writing CRUD forms using ASP.NET WebForms 3.5 against an Access DB? Don’t you want someone to stand up and tell you all the ways they've screwed up so you can feel better about the code that awaits you on Monday?
This is that talk.
It’s taken Colin 17 years to learn these things through failures big and small. Now you can learn such classic mistakes as inappropriate layering, leaky abstractions, reimplementing perfectly valid frameworks because reasons, undervaluing the cost of development friction, and so much more. All this (probably, maybe) in just one session the length of which I did not bother to research. Yours to take away so you can laugh smugly at me when you fail to do so in your career*.
The last part will be about algabraic data types (ADT). What they are, how to use them and maybe most important, why to use them.
In an industry where common design patterns are widely understood, why is it that many teams fail at executing on these patterns at scale? Even when designers focus on building out comprehensive design systems, the challenges of maintaining them and enforcing them are real. Design tools aren't quite yet up to the task of handling versioned contributions from multiple team members and even harder can be to get the whole team to agree on what tool to use. Designs then cross over into engineering, where the problem of consistency multiplies.
I think it'll be the complete union of engineering and design as functions that ultimately solves these challenges - a sort of Experience Engineer. In this session I'll cover some of the methods and tools people are already using to bridge the gap and offer my thoughts on how I think we may continue to innovate in the space.
This presentation explains how to use the ESP8266 and ESP32 microcontollers, Mongoose OS, Amazon IoT and Amazon lambda to hook physical devices to your phone or to your slack channels.
Examples: voice control your lights. Send slack alerts on events like kettle boiled or toast ready. Make a visual "away board" that responds to slack status. Build "traffic light" status monitors for your CI.
I can still hear the voice of my year 8 english teacher: "if you want to improve your writing: write! Get a diary and write in it every day".
20 years later, I finally took that good advice. Now I consider journal-writing to be one of the most valuable habits a programmer can have. And where it is enriching for any developer at any stage of their career, it is an essential discipline for those who work remotely or as part of a distributed team.
In this talk I will share my experiences from the last few years of writing a developer journal and working in distributed teams. I'll cover some of the "why" questions and some of the reasons I find it so worthwhile. I'll also introduce some easy techniques, so that anyone in the audience who is keen can start right away. I'll wrap up with some exploration into how I see this fitting in with the past, present & future of the web.
IndexedDB is not new. It is supported in almost every browser. Without it the future of progressive web apps are in peril. But there is not a lot of love for it and that needs to change.
We'll investigate why we should love IndexedDB and the kind of apps you can create when you have the power of a database in the browser. Then we'll dive into how to use IndexedDB with a look at both the terrifying API and the friendly libraries that will help us along the way. Together we'll discover a new love for IndexedDB.
This is a talk about understanding complex terminal commands.
git diff --staged --diff-filter=dx --name-only HEAD | grep -E '.*\.(js|jsx)$' | grep -v ^public/ | xargs -I % sh -c 'prettier --single-quote --trailing-comma es5 --write %; git add %'
This talk is about understanding this command - and other such linux commands. We'll spend about 15m going through fundamental linux concepts:
- philosophy of small, composable commands
- everything is a file"
- The 3 "standard" streams - STDIN, STDOUT, STDERR
- Redirecting the 3 standard streams
- Joining commands with pipes
- Using xargs to convert standard input to arguments
- Using explainshell.com for quickly understanding commands you've found on the internet
We'll work through small, self-contained examples each step of the way.
At the end, armed with this knowledge of how linux commands work, we'll come back and tackle our original command. We'll spend ~ 10m breaking it down step by step, and explaining how it works, and which of the features listed above it's using.
After the talk, people will have the foundations necessary to start moving away from the "copy-paste-pray" approach to linux commands that is all too common amongst juniors and intermediates, and start understanding commands they find online, tweaking them for their own use, and even composing their own more complex commands.