From JS Conf Budapest with love
This year’s edition of JS Conf Budapest was hosted at Akvárium Klub. Located right in the center of the city, below an actual pool, filled with water!
Akvárium Klub is more than a simple bar: it is a culture center with a wide musical repertoire from mainstream to underground. There is always a good concert and a smashing exhibition, performance, or other event happening here, in a friendly scene, situated right in the city center.
JS Conf Budapest is hosted by the one and only Jake Archibald from Google. Day 2 started at 9 o’clock. Enough time to drink great coffee and enjoy the breakfast.
Day 2: Talks
- Suz Hinton: The Formulartic Spectrum
- Oliver Joseph Ash: Building an Offline Page for theguardian.com
- Nicolás Bevacqua: High Performance in the Critical Rendering Path
- Sam Bellen: Changing live audio with the web-audio-api
- Rob Kerr: Science in the Browser: Orchestrating and Visualising Neural Simulations
- Stefan Baumgartner: HTTP/2 is coming! Unbundle all the things?!?
- Claudia Hernández: Down the Rabbit Hole: JS in Wonderland
- Lena Reinhard: Works On My Machine, or the Problem is between Keyboard and Chair
Day 2: Morning
Suz Hinton: The Formulartic Spectrum
Suz is front-developer at Kickstarter. Member of the NodeJS hardware working group. Member of the Ember-A11y Project team.
You can find her on Twitter using the handle @noopkat. She blogs on meow.noopkat.com.
Why are we here
- Data & Art
- Make a mess
Warning, a lot of feelings
- Commodore 64 graphics book
- Wants to make art on computer
- The littlest artist
- Accidental programmer (Suz didn’t really want to become a programmer)
- Semicolon wars;; It doesn’t matter how you place your semicolon!
This story is inspired by the movie Contact by Carl Sagan and makes Suz wonder: what does sound look like?
Formulartic spectrum (made up word: art)
- Analysing PCM data (Pulse Code Modulation -> raw uncompressed data)
- Resulted in only 13-ish lines of code
Suz talked about programming and art. She spent a lot of time on the subway and was wondering if it would be possible to use the sounds of the subway to create art. So she started by taking the sound of the subway doors closing and analysing that part.
- Sampling the audio to pixels resulted in 300k pixels
- Make it smaller by converting to 16-beat song
- The top section: Stand clear of the closing doors, please.
- The mid section: white noise
- The bottom section: ding dong!
Suz created a visualisation of the sampled audio that resulted in cats sitting on an subway.
- Cats can sit on 16 seats in subway car, each seat representing a beat
- In total there were 308.728 samples which divided by 16 beats result in 19.295 samples per beat. Suz took the average of the sample values of each ‘beat’
- The seats have different colors that represent the drum beat and oscillator note
- When a cat is sitting on a chair, we get a guitar strum and note
The subway example is made using:
- SVG images
- CSS animations
Check out the working example!
But I’m better at hardware
So Suz created a subway card with built in speaker!
- Creative coding gets you out of your comfort zone and teaches you to use tools you use everyday in another context
- Art doesn’t care about your semicolons
- Code can be messy
- No one cares about semicolons, etc.
- Art doesn’t care about perfection
- Again, your code doesn’t really matter
Art is about what you learned
- Write messy code
- Make lots of mistakes
- You deserve a break from being judged
- Code like no one’s watching
- Don’t ‘git rebase -i’
- Show the history behind good code
- Code evolves from a first idea to a final solution.
- At first, code might not be perfect
- Don’t rebase to hide this fact
View the slides of Suz’s talk here!
Oliver Joseph Ash: Building an Offline Page for theguardian.com
Oliver is a software engineer working on the team behind theguardian.com. Being passionate about the open web, he aims to work on software that exploits the decentralised nature of the web to solve non-trivial, critical problems. With a strong background in arts as well as engineering, he approaches web development in its entirety: UX, performance, and functional programming are some of the things he enjoys most.
You can find him on Twitter using the handle @OliverJAsh.
You’re on a train to work and you open up the Guardian app on your phone. A tunnel surrounds you, but the app still works in very much the same way as it usually would, despite your lack of internet connection, you still get the full experience, only the content shown will be stale. If you tried the same for the Guardian website, however, it wouldn’t load at all. Native apps have long had the tools to deal with these situations, in order to deliver rich user experiences whatever the user’s situation may be. With service workers, the web is catching up. This talk will explain how Oliver used service workers to build an offline page for theguardian.com.
Oliver talked about the functionality they created with service workers on The Guardian. When offline on The Guardian, you’ll get a crossword puzzle (always the most recent) that you can play. We summarized the key parts of the talk for you.
Website vs native
- Content is cached
- offline: stale content remains
- server down: stale content remains
- poor connection: stale while revalidate
- good connection: stale while revalidate
- offline: nothing
- server down: nothing
- poor connection: white screen of death
- good connection: new content
How it works
- Prototype built in < 1 day
What is a service worker?
- A script that runs in the background
- Useful for features that don’t need user interaction, e.g.:
- Listen to push events, useful for pushing notifications
- Intercept and handle network requests
- Background sync
- Alarms (e.g. reminders)
- A progressive enhancement
- Trusted origins only (HTTPS only or localhost)
- Chrome, Opera and Firefox stable
For now The Guardian is not yet fully on HTTPS, but they are switching at this time of writing.
Some pages have service workers already enabled such as:
How did they do it?
1. Create and register the service worker
You can debug service workers in Chrome by selecting Service Workers under the Resources tab.
2. Prime the cache
- install event: get ready!
- Cache the assets needed later
- Version the cache. To check if a user has an old version so you can update with newer versions
3. Handle requests with fetch
- fetch events
- Default: just fetch
- Override default
- Intercept network requests to:
- Fetch from the network
- Read from the cache
- Construct your own response
It is possible to use custom responses when using Service Workers. E.g. Use templating to construct a HTML respose from JSON.
- Mutable (HTML)
- Network first, then cache
- Page -> service worker -> server or cache -> Page
- Immutable (assets: CSS, JS)
- Cache first, then network
- Page -> service worker -> cache or server -> Page
4. Updating the crossword
Check if the cache has been updated and if it’s not up to date, update it and delete old cache.
Why should we be building with offline first?
- Instantly respond with a “shell” of the page straight from cache when navigating a website
- It improves the experience for users with poor connections
- No more white screen of death
- Show stale content whilst fetching new content
Problems and caveats
- Browser bugs in both Chrome and Firefox
- Interleaving of versions in CDN cache
This can be fixed with a cache manifest.
Why? Is this valuable
- Insignificant usage due to HTTPS/browser support
- … but plant the seed and see what happens
- Iron out browser bugs, pushes the web forward
“If we only use features that work in IE8, we’re condemning ourselves to live in an IE8 world.” — Nolan Lawson
- Service workers allow us to progressively enhance the experience for
- Offline users
- Users with poor connections
- It’s easy to build an offline page
- A simple offline page is a good place to start
The slides of Oliver’s talk can be viewed on Speaker Deck.
Nicolás Bevacqua: High Performance in the Critical Rendering Path
You can find him on Twitter using the handle @nzgb and on the web under the name ponyfoo.com.
Measure what is going on and see what is going on!
Use the Chrome DevTools Audits.
- Per-resource advice
- Caching best practices
PageSpeed Insights (Google)
- Insights for mobile
- Insights for desktop
- Get a rough 1-100 score
- Best practices
- Practical advice
- Gives analytics and metrics where you can act on
- A lot of statistics
- PageSpeed Score
- Waterfall View: figure out how to parallelize your download to speed up loading
- Makes it easy to spot FOIT
- Calculates SpeedIndex: SpeedIndex takes the visual progress of the visible page loading and computes an overall score for how quickly the content painted
- Inspect every request
- Analyze TCP traffic
- Identify bottlenecks
- Visualize progress
But we can automate a lot!
Measure early. Measure often.
PageSpeed Insights is available as npm module.
Webpagetest is also available as npm module but is a bit slower.
YSlow is available for different platforms.
- Enforce a performance budget
- Track impact of every commit
- What should I track? More info about this on timkadlec.com/2014/11/performance-budget-metrics
- Milestone Timings: Load time, time to interact, “time to first tweet”
- SpeedIndex: Average time at which parts of a page are displayed
- Quantity based metrics: Request count, page weight, image weight …
- Rule based metrics: YSlow grade, PageSpeed score, etc.
Budgeting can also be automated using the grunt-perfbudget plugin.
What can we do beyond minification?
Minification is usually the first thing developers think of when talking about optimizing your code for speed. But what are the things we can do beyond minification?
A lot of best practices on optimizing performance in your app are described in the High Performance Browser Networking book written by Ilya Grigorik.
For all the detailed tips and tricks we suggest to view the slides for Nicolás’s talk on ponyfoo.com.
Anand is Senior Application Security Consultant at nVisium
You can find him on Twitter using the handle @brownhat57.
Break the web together!
They say the best offense is good defense. No. The best offense is offense.
Hands-on vulnerability exploitation of medcellar
Anand’s talk started by explaining the most common web application vulnerabilities that currently exist. We’re talking about SQL Injection, Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF). During the talk, Anand used an open source application that contains all of these vulnerabilities and which is available for you as a developer to fool around with. The application is called ‘MedCellar’ and you can find it on github.
XSS & CSRF
We saw how to perform XSS attacks and CSRF attacks on the MedCellar Application. These attacks weren’t extremely harmful at first but showed just how they could be exploited.
Using the Burp Suite’s proxy, we were able to inspect all requests/responses the application was performing to get more insights in how the app actually worked.
Burp Suite is an integrated platform for performing security testing of web applications.
- attacks users
- JS Injection
- Exploits can be bad, really bad
XSS is a serious vulnerability. It may not seem so for some people or clients but it really is!
- How do we exploit apps where users have direct control
- How do we attack web apps on a private network
- “Session Riding”
- Attacker sends malicious URL to submit a form to a third party domain
- Victim is tricked into interacting with the malicious link and performs undesirable actions
Using a third party domain you can create a form (you won 1 million dollars) to perform an action like this.
During the talk, Anand demonstrated how to perform XSS and CSRF attacks. However, it seemed like you were only able to hack yourself.
Things got serious though, when Anand demonstrated how you could exploit these vulnerabilities way more by using a special Linux distro called Kali Linux and BeEF (Browser Exploitation Framework).
Kali Linux is a linux distro designed specifically for Penetration Testing and Ethical Hacking.
BeEF is a Penetration Testing tool that focusses on the browser and possible vulnerabilities in it and the applications running in it.
Combining these two, Anand was able to do basically anything in the users browser and he demonstrated this by running some random audio in the users browser. Playing audio isn’t that harmful, but you could have installed a keyLogger instead and start tracking anything the user types on his computer. That seems to be a little bit worse than playing some audio!
When you enter a coffee shop and see someone using this, disconnect from the internet and run away as fast as you possibly can.” - Quote from Anand
Mitigate against these attacks
Implementation of a CSRF mitigation is Tough!
- Method Interchange
- Beware of CSRF Token replay
- Token must be tied to the user’s session on the server
- CSRF Token exposed as GET Param: Could potentially have logs or some other network traffic see the CSRF token and intercept it that way.
But, luckily for us, CSRF middleware which implements these mitigations has already been developed for us! You can find these libraries on github:
- App Sec vulnerabilities can be used in combination
- No state changing operations should be GET requests
- Make sure the CSRF token is cryptographically secure
- Random !== Cryptographically secure
- CSRF Middleware Saves Lives!!
- Cross Origin Resource sharing (CORS)
- Access-control-Allow-Origin: * IS BAD!
Day 2: afternoon
Sam Bellen: Changing live audio with the web-audio-api
Sam is developer at Made with love.
You can find him on Twitter using the handle @sambego.
As a guitar player, I usually use some effects pedals to change the sound of my guitar. I started wondering: “What if, it would be possible to recreate these pedals using the web-audio-api?”. Well, it turns out, it is entirely possible to do so. This talk takes you through the basics of the web-audio-api and explains some of the audio-nodes I’ve used to change the live sound of my guitar.
Presentation can be found here: https://github.com/Sambego/pedalboard-presentation
Get the sound in the browser
- Create new audio context.
- Get the audio input of your computer: navigator.getUserMedia()
- Create inputNode from the media stream we just fetched
- Connect the inputNode to the audiocontext.destination
Add effects to the sound
- Create a gainNode = audioContext.createGain();
- Value of gain is 0 tot 1
- So for now we have input -> gain -> output.
- Make the audio sound rough.
- Create a waveShaperNode = audioContext.createWaveShaper();
- Set a value
- So for now we have input -> Waveshaper -> output.
- delayNode = audioContext.createDelay();
- Set a value delayNode.delayTime.value = 1 (1 second)
- Some kind of echo on your sound
- convolverNode = audioContext.createConvolver()
- Load impulse-response-file and do some crazy stuff
How to create an oscilator
- oscilatorNode = audioContext.createOscilator()
- Set Hz value
- Request access and start doing things with it
Rob Kerr: Science in the Browser: Orchestrating and Visualising Neural Simulations
Rob works at IBM Research Australia.
You can find him on Twitter using the handle @robrkerr.
The topic for this talk was quite some heavy material. However, Rob managed to give us a quick, super high-level, introduction to neuroscience and more specifically an introduction to how neurons actually work.
Very High level, there are 3 parts in a neuron:
- Neuron body (Soma)
Neurons receive electrical signals through their dendrites, and transmit those to the neuron body, called the Soma. From the neuron body, new electrical signals travel to other neurons. Sending electrical current from one neuron to another is being done through its axons. So the axons actually send electrical signals to other neurons and those other neurons receive these signals trough their dendrites.
A better, more thorough explanation of neurons is being described on Wikipedia, but we needed a super simplified explanation of neurons and their main components to further explain what Rob showed us.
Science in the browser
Neurons and their main components can be ‘encoded’ in special files .swc files. These files contain multiple records with an ID, X, Y, Z, Radius and Parent-link. Using all the records and their properties allows you to visually represent the neurons.
There’s already an online repository containing these encoded neurons which you can find here.
Now, what does all of this have to do with the browser or JS or anything you would expect at JSConf? Well, while he was working on his Ph.D. thesis, he started playing around with JS and its related technologies. And he continued to do so since then, all in function of the neuroscience domain.
As we saw earlier, there’s already a webpage where you can upload swc files with neuron data to visually represent these, but these are rather static images. Instead, Rob decided to create a platform which can also simulate the behaviour of such a neuron when you trigger it with electrical current on its dendrites.
Rob used a combination of tools and technologies to build the platform. Together with his colleagues at IBM research Australia, they built an entire Cloud platform that could perform these complex simulations.
On their IBM Bluemix cloud they run Docker Containers running the algorithm that performs the neuron simulations. The algorithm is written in C and is based on mathematic formula which is shown in the below image.
Hodgkin-Huxley Model of the Squid Giant Axon
The web application used to render the neurons used a combination of tools, most importantly:
The tool in action
In the below video you can see what the tool looks and animations look like:
The tool enables researchers to replay a scenario where a certain spike is triggered in a branch of the neuron. This gives scientists a lot of knowledge and insights about how neurons behave.
Rob gave a really entertaining talk with some really cool visuals of neurons in action. He introduced us to just the right amount of neuroscience to be able to follow what he was actually doing and showing!
Stefan Baumgartner: HTTP/2 is coming! Unbundle all the things?!?
Stefan is a web developer/web lover based in Linz, Austria. Currently working at Ruxit, making the web a faster place. He is also a co-host at the German Workingdraft podcast.
You can find him on Twitter using the handle @ddprrt.
Unbundle all the things?
Everybody is saying to not bundle things, minify things, concatenate things, … when moving to HTTP/2.
Tools like Browserify, Webpack, etc. would all become obsolete. But why? We need to question this and see if this is actually the truth.
The best request is a request not being made
In HTTP version 1.1 we need to do as few requests possible. Pages like Giphy have 40 TCP connection at a single time!
HTTP/2 was made to prevent the bad parts of HTTP/1.1
HTTP/2 allows a connection to stay open and transfer multiple things over the same connection. No need for handshakes for each file that needs to be transferred from the server to the client.
Rule of thumb
A slow website on HTTP/1.1 will still be a slow website on HTTP/2. You need to perform optimisations no matter what.
Most important part: do not block the render path.
Only serve what you really need. Again, the best request is a request not being made.
So, unbundle all the things?
So in some way, yes unbundle all the things. Because you don’t want to transfer bytes you don’t need, but there is something more to it. This article about packaging will get you on the way: engineering.khanacademy.org/posts/js-packaging-http2.htm.
Create a lot of modules to update as flexible as possible and as small as possible. When using ES6 we can also use Treeshaking.
- Create independent, exchangeable components
- Create small, detachable bundles
- Think about long-lasting applications and frequently of change
Use tools, not rules!
Claudia Hernández: Down the Rabbit Hole: JS in Wonderland
Claudia is Mexican front-end developer.
You can find her on Twitter using the handle @koste4.
This talk by Claudia was so much fun! We didn’t write down anything because it was virtually impossible to do. You need to see this with your own eyes!
You can view the slides on Speaker Deck.
Lena Reinhard: Works On My Machine, or the Problem is between Keyboard and Chair
Lena is teamleader, consultant and photographer.
You can find her on Twitter using the handle @lrnrd.
In this talk we will look at the many facets that affect our decision making and interactions, and work out how we can change for the better. Together, we will take a look at the effects that our software has on the daily lives of the thousands of people who are using it. You’ll learn what you can do as an individual to support change into a positive direction, and how you can help debug this system and make a difference in the tech industry. You’ll leave knowing about practical things you can do in your daily life to make the tech industry a better, more inclusive and diverse environment that is a better place for everyone.
Debugging can be hard and it becomes harder when working with complex software.
Spaghetti code is difficult to read and maintain. It can be code that is not organised, has lots of dependencies and is difficult to debug.
The Tech Industry is bugged
A lot of people already contributed to the tech industry. It has grown very fast and has many flaws.
That’s why we need to have a look at it and try to fix the defects.
To be able to fix this we need to understand ourselves. Our flaws, limitations, …
We are privileged and need to understand that.
Privilege: The human version of “works on my machine”.
Privilege is sitting in your comfy home and not knowing a big thunderstorm is coming that could harm people.
Privilege is being able to stand up when attending a standup and not having to sit because you are disabled.
We are biased
We need to understand we are biased. More often we are being objective and often that is not OK.
We all have biases and we need to realise and understand.
We need to understand that we need to be empathetic. Empathy is the right direction.
Creativity is necessary to design and build good software.
And so is diversity and understanding each other.
Inclusion means all people in the group are respected for who they are. The lack of inclusion and diversity is a real problem in our industry.
The Tech Industry
Let’s look at some key points within our industry.
- Lack of diversity
- Lack of inclusion
- Lack of diversity
- Lack of inclusion
Software can help people
Our software can help people. A screenreader, accessibility, …
But can also ruin lives
Our software is racist. Our software (tools like Siri or Cortana or Snapchat) does not correctly recognise skin color, alters skin color and does not recognise harassment or racism. Animations in software can trigger panic attacks or epileptic attacks.
We have a collective responsibility and need to take that very seriously. Technology and our code is not neutral. Our work is political and has consequences on lives.
Debugging the system
Change starts with you, starts with all of us. What can we do to debug the system?
- Educate yourself, about systemic issues and oppression
- Practice empathy, because we need it to be good designers and developers
- Work on Humility, because none of us are Unicorns
- Understanding Privileges, and use them for good
- Address biases, and establish policies to address them
- Listen, and actively look for voices outside of your networks
- Amplify others’ voices, and speak less
- Work on diversity, because it’s our moral obligation
- Work on inclusion, to make spaces welcoming and safe
- Give, our knowledge, time, technical skills, money
- Work on being allies, constantly
Quite a talk on some serious matter to close the second day of JS Conf Budapest.
Have you experienced these things yourself in the tech industry?
Have you contributed to debugging the tech industry?
Day 2: Conclusion
Just like day 1, day 2 was one hell of a nice day packed full of great speakers and a superb atmosphere!
The talks by Rob Kerr and the one of Lena Reinhart surely got the most attention. Rob’s talk because it was impressive to see what they achieved over a course of 2 years to visualise neurons in the browser. Lena’s talk because we got slammed in the face about how faulty the tech industry is at the moment.
This year’s edition was, just like the one we attended last year a very good one! It is nice to see such a diverse community that cares about technology and people. This is something we should be very proud of.
A big thank you to the organisers and volunteers to make JS Conf Budapest what it is!
Find us on the family photo!
In 2017, JS Conf Budapest will be held on the 14th and 15th of September.
We will surely be present for what will be another great edition! See you next year!