For the first time in a number of years attending Hackference's awesome hackathon, I was able to make it to the conference portion of the event in October. I had an amazing first time and both learned a lot and also met a number of really awesome people.
This also happened to be the year that I was invited to speak - I was covering Chef: Infrastructure as Cake, a talk which I have given a couple of times internally at Capital One, but had not yet done it externally. Additionally, it was the first time that I'd been speaking to a group of ~50 people! It was a great experience, and I was very glad I took the plunge and was able to speak about something I'm passionate about.
I was truly humbled to be a part of the event as a speaker - there were some really distinguished names I was speaking with, and it was a real honour to be one of them!
There were some really awesome talks here! I've documented each of the talks I attended, in chronological order, and am looking at follow-up articles for a few of the talks that I had some extra content and thoughts for on top of.
So I heard you like engineering.. - Jonathan Kingsley
Jonathan spoke about the impending doom of the insecurity of tech everywhere, largely due to engineers not fully understanding security and its implications, especially on devices that may be unable to update often. He also took us through the (slightly redacted) process of hacking a drone in order to make it perform a flip when whisling.
Infrastructure as Cake - Testing Your Configuration Management in the Kitchen, with Sprinkles and Love - Jamie Tanna
My talk was about why Configuration Management should be used, and how using Chef can allow you to fully test it and build it in the correct way.
Although I'd done variations on this talk a couple of times previously at Capital One, this was the first time I had done the talk externally. I felt the talk went well, and gave a good taste for what Chef and Configuration Management can do for you.
I'd also had a few engagements post-talk regarding the best ways to use Chef, including how to build it into your pipelines, for which I was able to share some insight from my previous work with it.
Update 8 Feb: After reviewing my recorded talk, I'm overall pretty happy with how the talk was given. I've found a number of tweaks that can be applied for future iterations of the talk, for instance to make the Chef concepts and terminology more clear.
He showed us how you can control multiple USB cameras over wifi in less than a screen of code, using the Johnny Five framework.
Tim was a great speaker, and both his passion and knowledge came across really well.
Tim also discussed Resin, the company he works for, and their approach to make it easy to deploy applications to physical hardware, removing the need for burning SD cards and cross compiling code. The heavy work is taken by them, where they build and deploy the applications for you, using a custom Linux distribution that uses Docker to run applications.
How to build a website that will (eventually) work on Mars? - Slobodan Stojanović
Slobodan had an interesting (and fundamentally important) take on the move to our expansion to Mars - how are we going to deal with the high latency of Earth-Mars communication until AWS launches
There are some great points about how we need to optimise the way we work on poor network connectivity, which had me thinking about how trying to view internet in a rural setting is very painful, let alone when it could take 22 minutes for light to travel between the planets (remember that light is much faster than radio or microwaves, so we'd have even more latency there).
I'll cover this in a follow-up article, as there are a number of interesting points I'd quite like to cover in more depth.
Code is not only for computers, but also for humans - Parham Doustdar
Parham raised a number of important points about building software, all centred around the fact that software is a human-centric job.
Yes, the code we write is performed by a machine, but as the famous saying goes - code is read more times than it's written.
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
Along these lines, Parham started the talk off with how we would interact with someone who wrote the code that we've just found is poorly documented, and went through to discussing the ways in which we should be more empathetic.
I'll cover this in a follow-up article, as there were some great points Parham raised that I'd like to add some extra commentary to.
Building a Serverless Data Pipeline - Lorna Mitchell
Lorna took us through the process of creating a Serverless pipeline to help the team track questions on StackOverflow about IBM CloudAnt, and determine whether the team had replied. The idea behind the application was to have a dashboard that would have a list of questions about CloudAnt that appeared on StackOverflow and for the team to be able to self-organise and ensure that answers are provided, but also that there are not duplicate responses.
This was also my first introduction to IBM Cloud and was very interesting seeing that Cloud Functions, their Serverless offering, was running on the Apache OpenWhisk Open Source project. OpenWhisk boasted an easy way to get started and test out your functions, and seemed to have some good tooling.
I'll cover this in a follow-up article as it was a great showcase for Serverless and how it can be used in a really simple way, being one of the first real explanations I've had done well.
Privacy could be the next big thing - Stuart Langridge
Stuart's talk was concerned with reminding everyone of how much personal data we have, and how it's out there being shared and mined by many, many companies. To sum the talk up in tweets:
Privacy could be the next big thing: "This is the first century that erasing history became more important than makinging it" #hackference— Michiel Roos (@Michiel_R) 20 October 2017
Stuart's got a full transcript of his talk available.
Anna and I, who are currently working on the side as Web Developers at Spectat Designs, wanted to automate the process of helping other freelancers to only allow website changes to be pushed live once a client has made their payments in full, creating a project called Be Paid to Get Deployed.