At the weekend I decided to embark on my first-ever ‘live’ coding experience. I was not bold enough to live stream it just yet in case it was an absolute disaster, so I opted to locally record it for now with a view of uploading it later. Essentially this was me sitting at a desk and working through a problem until I had successfully created a working proof of concept whilst recording myself and my screens. I like the mindset of trying to experiment quickly in a short period to understand what’s achievable, more often than not you’ll surprise yourself. Having taken part in many Hackathons in my time the pressure of a deadline and working quickly helps me to hyper-focus on delivering ‘something’ even if it is a little rough around the edges. This evening was simply an extension to a Hackathon, albeit with a camera constantly recording me… In total, I spent around two and a half hours trying to work on the problem and a large proportion of that was Googling, and fixing environmental issues and much less about the coding in some ways. This experience was, after all, going to document all of my struggles, and ‘wins’ just like any other working day, and in the end, I was left with something rough and ready, but ultimately I was happy with for a first iteration.
I did no prep other than set up a Git repo, and arrange my laptops on my dining room table, which is something I now regret. My daughter was upstairs sleeping and I wanted to limit any noise given it was late 22:00! – a bad time to do a coding project, especially a live recorded one as my brain started to wind down for the evening. This became rather evident towards the end where I forgot I wasn’t recording part of my screen, and I started to mumble… I also settled on a number of tools prior to the recording such as using Sublime as the code editor, and mmhmm to record the video.
So what was the project I had chosen? My goal was to write a system that allows remote peers to control a hosts slide deck. I intended to use a Python based around a ‘host’ and ‘client’ setup with sockets to allow ‘guest’ presenters to take control of my keyboard remotely – but more importantly transparently. Due to the pandemic and more remote working, I’ve been involved in presenting with several other co-presenters as of late and it becomes awfully difficult to handover keyboard control which restricts remote peers from easily autonomously navigating around the slide deck. Existing solutions are either to simply shout ‘Next slide, or previous slide’ to the host, or for the host to continually grant, and revoke controls to each presenter which seems clunky. My goal was to improve this experience. Having the ability to just handover to the next presenter without any of this complexity would determine whether this project would be a success or not.
My thought process in building the proof of concept centred around:
- Firstly to ensure Python could programmatically press a key.
- Find a code example for non blocking multiple socket server and adapt to my needs – there’s some assumed knowledge here, having experimented with a lot of network related projects in the past; like my clone of seblee’s Nyan cat game here’s my version and my remote firework launcher I knew that I needed this to support being able to accommodate multiple connected peers.
- Find a client example and tweak as needed to send the relevant key commands over to the host for processing.
- Use a tunnelling application to remove the network complexity so clients can easily connect to the host, I opted for ngrok as it allows you easily to expose a local application to the world.
So did it work? Since developing the application I’ve been able to try it out in the real world. Myself and three work colleagues used Microsoft PowerPoint together with Microsoft Teams. When it came to their section in the PowerPoint they simply pressed their left and right keys, sending the corresponding command to my machine, effectively mirroring their input allowing them to advance or rollback. They experience was pretty seamless. The only thing they had to do was connect with some basic instructions before the meeting starting.
Overall it worked well, I’m tempted to take it further, with a few more features and more resiliency, along with shipping it with all its dependencies so it’ll work with just a click of a button. The project relies on ngrok which despite being great on the free tier has its limits which can interrupt service, there are free alternatives but for a quick and dirty proof of concept, ngrok satisfies my needs.
- First time using mmhmm it crashed every 40 minutes, thankfully it kept the recording – it’s still only just out of beta but overall it’s a great little tool and very easy to use.
- Don’t live record late circa 21:00-22:00 hours my brain started to shut off.
- I progressively start to mumble – not great for explaining what’s going on.
- Lack of main monitor with this setup makes it hard to see exactly what’s being recorded – I missed sharing some of my terminals at the end, noticeable by the no image.. image.
- Invest in a higher quality second camera.
- No need to run krisp for real time noise reduction because iMovie can easily apply noise cancelling at the edit stage and it does a very decent job (also 120 free minutes with krisp goes quickly).
- Potentially invest a green screen next time.
There is a certain vulnerability that comes with recording yourself like this that most will find off-putting. The reality is solving problems is all about reaching some sort of end goal, and with most problems, there are normally many ways to reach that goal. Sometimes it’s researching and googling, or asking peers. I encourage everyone to jump in and try to build something outside their comfort zone to stretch one’s learning and self-development.