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
A few people have talked about the main thread. It’s not something we’ve had to worry about yet, as most of our heavy lifting is done with Python, and JavaScript is like, 99% UI. However, we have been doing some work on a search function, which could probably be a good test case for using a worker. We’ve also got a couple of calls to external APIs which could be farmed out. I doubt any of this would make a huge performance impact though, as most of our data is pretty static and managed in the back-end, but it’s worth thinking about what we can offload into a background process.
Typescript
Does anyone actually write JavaScript any more? There has been so much talk of TS around here that I’ve actually started looking at our code to see if we could switch over. There are certain people who dislike the casual nature of Python, so perhaps giving the option of a nice, statically typed version of JS might make things seem better!
Security
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
- AWS:
- Cloudtrail - see which user made what changes
- Cloudwatch - logging
- [GuardDuty) [https://aws.amazon.com/guardduty/) - identifies unusual activity
- Patches - just let AWS do it all, though this has backfired on us in the past
- 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.
- Scalability
- 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
- Testable
- Well obvs
Trivial Examples
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.
Top comments (0)