Thankfully, not much of the stuff at the conference was new to me - I would be worried for my career if I’d not at least heard about most of this! - but I’ve been working in Python for so long now I’ve not given much brain time over to JS for quite a while, so it’s a nice refresher. A brief overview of things I learnt/found interesting below.
The Main Thread
In a small team it is important to embed security into the development process so you don’t have to think about it. This would definitely be my preferred approach to this stuff, because I know bugger all about it and care even less.
Some tools to consider:
- Probely - auto security scanner, kind of like a pentest
- Build Kite - a Jenkins alternative, because here’s an interesting fact: Jenkins is number 2 on the list of ‘highest number of bug bounty payouts’. Now I’ve had a google and I can’t find a source for this, but the guy said it in his talk so must be true?
- Ghost Inspector - cloud based Selenium alternative?
- Sentry - Error logging
- Terraform - infrastructure as code, meaning you can easily roll back to last good configuration if you break stuff
- Dependabot - automatically keeps your dependencies up to date
- Scout Suite - cloud security scanner
- Bandit - Python OWASP security checked
- Synk Docker… stuff - monitors Docker image security considerations
Good Component Design
I was expecting this talk to be super React-heavy, like actually designing React components, but actually she was talking about a more general way of designing software which mirrors exactly what I have been banging on about, but more eloquantly.
Guiding principles of good (component or otherwise) design:
- Accessibility, aka “developer ergonomics”
- Here we mean the developer experience not the user experience, that’s a topic all of it’s own. Your could should be arranged and name logically and sensibly so people can work on it easily.
- Again, developer experience, not scaling the code/server/whatever.
- Single Responsibility
- Makes your code easier to test. Use naming sensibly to help identify which components go together
- Well obvs
This is an issue I have with most conferences, not just this one. Yes, real time autotune in the browser is cool, but it’s not really useful. I either want a deep-dive into the how, what, why etc of the silly thing you made (see (Remy Sharp’s Spectrum](https://talks.zx.isthe.link/#1] for a good example) or I want a real world use case. I know it’s hard, especially when speakers have limited time but it gets a little old after a while.
Other interesting bits
ITP: if your site is only ever rendered in an iframe browsers are starting to block them from reading cookies.