Burnout sucks. There are a number of signs to pick up on it before it fully manifests which this article talks about. Having gone through it in the past, it's not something you want to go through, and can have some severely lasting effects that are hard to come back from.

Tell Him is a really important post by Jameela Jamil - if you don't read this, I'm incredibly disappointed in you

This is an incredible read about a huge undertaking the Guardian took to migrate _two decades of content_ of migration with zero downtime - it's a great story and has a lot of great learnings in there

In every programming language, there is a linting tool that can help pick up on some common style issues. ShellCheck isn't one of those - it's so much more!

I've been using it for many years now, and since it came into my life it's honestly changed the way I use shell scripts. There have been so many pitfalls that I've avoided falling into since learning about them (and adding ShellCheck to my Vim linting setup.

This is a great read from Vidar, the ShellCheck author, about a case where it could've caught issues that caused the deletion of a production database!

Last week I replaced my OnePlus 3 with a Pixel 3A.

Both Anna (https://annadodson.co.uk) and I have been thinking about getting a new phone for a while, but as both our phones were doing fairly ok, and we didn't want any unnecessary expenses, we decided to keep an eye out but not yet get anything.

I'd originally heard about the Pixel 3A on the TechMeme Ride Home podcast (https://anchor.fm/techmeme-ride-home/episodes/Tue--0507---All-The-Headlines-From-Google-IO-e3v85p) which sounded really nice.

But then when I saw both Ed George (https://twitter.com/Sp4ghettiCode) and Graham Smith (https://twitter.com/whoisgraham) tweeting about the fact that they had just got one, I was very interested. As respected Android devs, I see them both as having done the research and know what they're doing - so it meant that I didn't have to do as much research, right??

I could've waited, in all fairness, but Google did a deal where you got a Nest Home Hub, too, so it meant the phone was effectively £280 instead of £400, and we all know I love a good deal. Unfortunately that it still in the box, as is the Google Home Mini I've got, but maybe one day they'll make their way out - we're an Alexa household currently, but are looking at being multi-platform.

So what are my opening thoughts, one week in?

- The migration tool was pretty cool, especially being able to just connect up another phone and have it sync, but for some reason my Google Play Store decided not to download anything so that didn't quite work as expected
- I had rooted my OnePlus 3 so I could get better privacy control over my device, but hadn't used much on the rooting side for a while, largely because Google are making it such a pain to do. I decided I wouldn't root this device quite yet, which means I'm able to use Google Pay - which so far I've done a couple of times and it's been pretty useful, but has just saved me getting my wallet out
- Battery is much better than my two year old OnePlus 3, and the second day I had it I was tethering + playing music almost all day without it even running out of charge the following morning. Pretty decent!
- I am however missing some of the convenience gestures I could use from the lock screen - turning the torch on quickly, and controlling my music
- I'm a fan of the always-on display, especially as it prompts me with the upcoming calendar event
- The fast charge seems to be on par with the OnePlus Dash Charge - again a big decided in whether I got it or not, as being able to quickly boost battery was very important
- It has a headphone jack, so I'm happy
- Booting is super speedy - not that I need to that often, but it's good to have!
- I'm liking Android Pie, although I'm sad I no longer have the multitasking button so can't toggle apps as quickly
- I bought an official case, which although a bit pricey was quite nice, and has a good feel to it
- The camera seems to be pretty decent, from the few shots I've taken of our black cat, Morph

Overall it seems to be going well - hopefully it'll last as long as my OnePlus 3!

EDIT: And something I forgot to mention was that the fingerprint sensor isn't in my location. I'm very used to it being where the home button is on my OnePlus 3, and combined with the placement of the headphone jack on top, it means I'll regularly unlock my phone as I'm taking it out of my pocket, which is quite annoying.

EDIT: I also found the way to easily swap between apps is by swiping on the soft touch buttons, left to right. And by holding it for longer I can skip between multiple apps - nice stuff!

I found this when listening to episode 194 of the Bike Shed podcast: My PGP Shame. I'd only added this episode to my playlist as it was an interesting title, but listening to it, it was even better than I thought.

There was some great stuff in there about Thoughtbot's application security guide, linked, which is a definite must-read.

My favourite quote of the episode, though, is the following exchange:

> I've got to be honest, how does anything work at all?
> Oh computers don't work

This is a really great post! I think it was Jess Rose's talk about it where I realised it was a thing and not just something I felt. Talking about it and making others aware of it is good, and I'm definitely going to steal some of her coping strategies

I'm super excited to announce that I'm joining the organising team for https://phpminds.org/ !

Trawling back through the Meetup.com group for PHPMiNDS, I found the earliest time I marked myself as attending was November 2016.

I've never been a PHP dev, although I've dabbled for years. But I've always seen it as a great community, and have been attending for most months since then.

Attending tech meetups has always been about bettering myself, and learning more, and the talks at PHPMiNDS can absolutely be applied to my work, despite it being a different tech stack.

Before https://www.jvt.me/posts/2019/04/11/phpminds-april/ Shaun had mentioned to me about looking for another pair of hands with organising PHPMiNDS, and after a little bit of time to mull it over I decided I would definitely be interested in getting involved.

I'm really excited to start to help out Adoni (https://pavlakis.uk) and Shaun (https://shaunhare.co.uk) with organising the meetup, and I hope continue making it as awesome for others as it has been to me.

Matteo kicked off the session by asking the audience some questions:

> who has an automated build pipeline?

> who quality control, that doesn't include manual steps?

> what does your pipeline look like?

To this last one I mentioned about how in my team we've got a fully automated build + deployment pipeline with a number of system tests, including various key regression tests. Which seemed like a shock to most of the room, as they had mostly manual testing everywhere.

But then we started talking about "what actually is quality". We talked about how it's not just whether you've got all the test cases passing, or what code coverage percentage you have, but it's about whether the code is maintainable, or whether it follows good patterns. It's not just the testing, but the practices.

And of course, we've all met people who say:

> my code is perfect, it doesn't have any bugs

To which we can say that "works != quality".

DevOps has been based upon the foundation of quality, ensuring that we can reduce cycle times and ship early and often, owning our products all the way to production. Automation is key to building the greatest value through maximum quality.

We need to be careful of what checks we do, as there is a difference between objective (i.e. cyclomatic complexity) and subjective (i.e. tabs/spaces) measures.

Matteo spoke about "two camps" of quality:

- industry standards i.e cyclomatic complexity, secure coding standards
- team standards i.e. code style, coverage, patterns

We need to make sure that we apply quality in terms of the processes and practices, otherwise we are just adding gates that no one believes in.

This is different to i.e. fulfilling the spec, as a specification isn't just what you want. For instance, do you want something with a warranty of 1 year, or that (feels like) it's built to last a lifetime?

Remember the quote:

> even the best craftspeople need a helping hand

Instead of thinking "I can do it all myself", realise that you're fallible, may have an off day, etc. Look to automating cruft and focussing on the important things.

We have a few ways to enable quality and raise the bar, with tools:

- automated build pipelines
- code quality gatherers
- security vulnerability scanners
  - Dynamic Application Security Testing (DAST i.e. Zapp) - at runtime
  - Static Application Security Testing (SAST) - without running it
- force your PRs to require a successful build before it can be accepted

Or with practices:

- peer review
- bug bashes
- Test Driven Development
- secure development lifecycle
- continuous integration (in the true sense of the term, not automated build pipelines)

It's very much recommended to embed quality checking with a tool like Sonarqube, as it provides all the goodness of linting and quality checking i.e. cyclomatic complexity. It's preferable to use SonarLint which means it is done client-side, instead of needing a connection to your server.

Useful too is licensing scanning, i.e. to determine whether you're in risk of violating business rules, or at risk of violating GPL.

You should also look at security scanning, i.e. Whitesource, to help pick up on security issues in dependencies.

In the Java world, you can use Checkstyle, PMD and FindBugs which achieve similar, in the comfort of your own build process.

With Azure there are a tonne of other services to help secure your applications, such as security scanning your Azure templates to find out if you're doing anything insecure. There are also a number of other secvices in Azure you can use for locking down your security.

Matteo's recommendation is:

- use circuit breakers as a great way to isolate problems if i.e. a service is unexpectedly broken
- add deployment gates, so you can only promote artefacts when they're ready
- define patterns, and embed the quality mindsets, instead of it being a checklist that people are forced to go through

Great post by Luke about how we should be more inclusive in events and whether alcohol-oriented is the nicest message for those wanting to get involved.

This was the inaugural meetup for Cyber Nottingham, hosted by Capital One (my employers), but as I've always had a strong interest in Cybersecurity I definitely wanted to go.

Graham Sutherland (https://twitter.com/gsuberland) took us through TLS 1.3, in terms of how we arrived here and what it brought to the table.

As a reviewer of crypto standards and an implementer of various crypto-related tools, Graham was a good person to talk through it.

Most of the talk was over my head, and full of a number of acronyms and names of security attacks, but fortunately Graham also shared that there were many that he couldn't remember.

Graham spoke about how in the past the community has decided that the solution for mitigating most attacks should be "add an extension to TLS to resolve this issue". This doesn't help because TLS is still the same overall version, and it makes it harder for others to implement libraries as they have a shifting target. Because this has mostly been tagged on, it means that there's a fair bit of tech debt associated with it that makes it much harder for maintainers.

The security community are moving to be much more forward thinking and preventative, rather playing "whack a mole".

Graham noted that to make others adopt a new version of a thing, it has to be easy to adopt! Making it difficult means fewer people will jump at doing it - citing the Python 2/3 upgrade issues.

TLS 1.3 has been planned to remove a lot of those issues; both accrued tech debt, unused features and unsafe / difficult to implement features. And as well as removing a lot of stuff, they also added more.

For instance, forward secrecy is now available for all, by default! This is because it makes key exchange ephemeral, which means that keys will be destroyed after each conversation, so unless you're _already_ actively MITMing traffic, you can't retroactively decrypt things.

We now have encrypted SNI and a few modes that will allow a Load Balancer to understand which virtual host a connection is being sent to, without having access to the underlying content of the message. In addition, certificate lookups are added, otherwise that could also leak which sites you're interacting with, even if using SNI.

Finally we spoke a little about TLS Intercept Appliances (TIA) and how they're effectively broken for TLS 1.3, due to pieces like forward secrecy, as they have to do more work to keep up with it (it is possible, just much more difficult).

Lots of banks got together in 2016 to petition TLS 1.3 to re-add the ability to not run with forward secrecy but it was denied.

Then, TIA vendors in 2018, but again got ignored, so they got together to create what they tried to call Enterprise TLS. This was blocked, so instead it is ETS, but so far has no adoption.

Just a note that there are places where you would expect this to happen, as it makes it possible to perform deep packet inspection and determine if someone is trying to exfiltrate data out of your network, but can be something dangerous if that were to be attacked, as well as has privacy implications.

This was an interesting talk, although because I'm not hugely involved in the Cyber community I was definitely lacking some of the background knowledge.



The next talk from David Lodge (https://twitter.com/tautology0) was all about how we have smart locks that have been developed with dumb security, quoting the common saying:

> there is no security if you have physical access

David spoke about how we should threat model, as with other kinds of security; a lock has a sensor i.e. fingerprint/bluetooth, a charging port, the casing and a motor/mechanism, all of which can be attacked.

We went through different examples of how we could attack these locks:

What material is it made of? Common lower-end smart locks are made of a material that has ~300 degrees melting temperature, whereas an average blowtorch burns at ~1500 degrees

Can you screw the casing open?
- can you push the locking mechanism back and unlock it?
- can you attach a battery to the motor to unlock it?
- are there any debug ports on the board for the device that you can attach to?

Is there an Android app that we can de-obfuscate to work out any more details about how it unlocks the device?

Is there an API that the lock talks to?
- are there any ways we can sniff the traffic to pick up any helpful data i.e. the lock's key (this was a real example where sending a MAC address to the API returned a JSON response with details about the lock, including its key!!)
- is the API suitably designed and protected i.e. with rate limiting

Is there a vulnerability with the Bluetooth comms?
- if you don't pair to the device, communications are in cleartext, so you can sniff someone else's comms
- otherwise can you find any common patterns in the communication and see if you can interact with the lock yourself

Could the charging port be attacked?

Can you just break it open?
- magnets
- bolt cutters
- washing machine vibrations

And while researching this, a gem that a company responded with:

> the lock is invincible  to the people who do not have a screw driver

This talk pretty much confirmed my suspicions that smart locks were going to be less secure, although David mentioned that there are some vendors that are better than others, and you have to pay for quality.