State of my toolchain 2018

Back in mid-2016, about two years ago, I did a run-down of my personal productivity stack – essentially a ‘State of my Toolchain’. After almost 2 years, it’s time to provide an update and see what’s changed.

Main laptop

My Asus N76 17.3″ laptop is still going strong as my main workhorse; but its days are numbered. I’ve had to rebuild a couple of times now after hard disk drive sectors have failed, so it’s a matter of time before it’s forced into retirement – but at nearly six years old, it’s had a good run.

So the question becomes – what replaces it? I’ve always been very happy with the ASUS gear I’ve had over the years, but the Zenbook range doesn’t seem to have that much in the way of high end GPU specs – which I need for both gaming and machine learning stuff. On the other had, the RoG range doesn’t seem to have good battery life; although that really isn’t a major consideration.

Enter System 76. I hadn’t heard of these guys until some of my linux.conf.au and Mycroft AI mates mentioned them, including this kick-ass video.

https://youtu.be/TcWVKqeF0MY

After doing some asking around, folks seem pretty happy with them, but the downside is that they’re costly; especially with the poor $AUD exchange rate – and then on top of that you have to pay import duty. Might have to see if the $AUD/$USD exchange rate improves.

Mobile laptop

My Asus Trio Transformer TX201LA is still going strong as a mobile laptop; the battery life isn’t great but having the Android & Linux combination on one device has come in very very handy. I’ll be hanging on to this until it dies – and then I’m very interested in one of the newer Transformer models.

Mobile phone

Two years ago I was using the LG Nexus 5X but unfortunately it was victim to the Bootloop issue. Now I have a Pixel, and it’s brilliant. Right size, great battery life, and great bluetooth and NFC support. And yes, I often use it with with headphones.

Wearables

With Pebble being acquired by Fitbit and subsequently sunsetted, I needed to find a new smartwatch. My Fitbit flex was also degrading, so it was a natural choice to go with the Fitbit Ionic – essentially combining two wearables – fitness and watch – into one. I’ve been incredibly happy with Ionic – I was skeptical at first, but the battery life is long – about 3-4 days and the reminders to move are useful. The range of applications is limited, but the key feature – of passing notifications from my phone to my watch – works well.

I’ve found that over time, my smartwatch is very definitely part of my toolchain – it’s no longer a nice-to-have extra – it’s a tool that I regularly check and rely on.

Quantified Self

My Fitbit records and stores a lot of data about how active I am, however I’m still using RescueTime and BeeMindr to help with day to day productivity and long term goals. RescueTime gave me a great deal on a premium upgrade (big ups, guys!) and I’m using the “focus” features a lot – which prevent you from using time-wasting websites like Facebook for a period of time. RescueTime also continues to deliver great visualisaitons that help to see where you’re spending your time.

rescuetime-usage-2017
My RescueTime logged time by category for 2017

Headphones

Plantronics Backbeat Go 2 Bluetooth headphones were great, but being an idiot I left them in a hotel room while travelling. I replaced them with the Jabra Rox – the magnetic earbuds are great for not losing them, however I’ve struggled to use the “wings” to get a good fit.

My Logitech H800 is still going strong. Great headphones.

I did splash out on some Plantronics Backbeat Pro bluetooth headphones that have noise cancellation for concentrated, focused work in noisy places – like co-work spaces. They’re great – 20-odd hour battery life, and they really do cancel out a lot of distracting background sound. My one niggle with them is that the ‘active off’ feature – which pauses music when you take them off – activates with movement, like walking around the house or getting up off a chair.

Streaming Media

With Pandora moving out of the Australian and New Zealand market, I needed to find another streaming music provider. Spotify was an easy choice because of their cross-device support – including a native Linux desktop app. On the plus side, Mycroft AI has a Spotify Skill that, due to API restrictions, is only available with Spotify Premium accounts.

Input devices

My keyboard, graphics tablet and presentation pointers haven’t changed in two years, but I did back Sensel Morph on Kickstarter, and have started using it, but because the Linux driver isn’t great (yet), it tends to work better under Windows. I’m hoping that the Linux support matures in the future.

Voice Assistant

Would I like an always-on spy listening device in my house? Hell no.

Would I like a useful voice assistant that doesn’t save what I say to sell me advertising and invade my privacy? Hell yes.

Which is one of the reasons I went to work for Mycroft AI. But I digress. As part of my role, I do a lot of testing and documenting for the Mark 1 hardware – and I have three of them around the house. They’re solid little units with microphones that are better than I expected for RPi-based devices.

One thing I did need to get for working with the Mycroft Mark 1 was a new set of torx hex keys – the ones I had didn’t have a long enough handle to disassemble the Mark 1.

We also have a build of Mycroft for Raspberry Pi – Picroft – that needs a microphone and speakers. For this I got  a Jabra 410 – it’s much better than I expected for a mid-range omni-directional USB microphone.

For Picroft I also need some Micro SD cards; my key learning here has been that cheap Micro SD cards will cause you pain and misery and suffering and segfaults. Don’t use cheap Micro SD cards. You’re better than that.

Internet of Things and Home Automation

My bevvy of LIFX light bulbs continues to grow; I really like the range. I did have an issue with their LIFX Z light strip; one of the three strips that was delivered didn’t work, but it was covered under warranty and they shipped me a replacement. One of my favourite integrations here is with Google Home; I can turn off my bedroom light using the power of my voice.

I’ve also been hacking around with some Ruuvi tags; I want to spend more time on these, they’re pretty cool as sensors.

Software

My software stack hasn’t really changed in two years – I’m still using LibreOffice, with Firefox and Thunderbird, and Atom Editor. In particular,  LibreOffice Draw is becoming my go-to tool for diagrams and process flows. Scribus, Inkscape and GIMP are still top in my toolbox too. The new version of GIMP is much smoother.

Gaps in my toolchain

Even with all these great tools, I’m still missing a few components from my overall stack.

  • Visual Git Editor – The range of visual editors for Git on Linux is limited. I tried GitKraken but didn’t like it much. GitHub for desktop doesn’t yet have an official Linux build; I tried to install the shiftkey fork, but couldn’t figure out how to install it.
  • Better internet – my internet is connected at about 6Mbps down, 1Mbps up. It’s slightly faster than two years ago. It’s usable, but very slow. If I have to download or upload a large image – which I often have to do for work – I have to plan ahead. Oh NBN. I simply don’t have the words.

 

Have I missed anything? What do you use?

Developer Experience as a fitness function for platform teams

Borrowing from several antecedent disciplines, developer experience is beginning to emerge as a distinct practice of its own. It borrows heavily from more general user experience techniques, as well as from developer relations and community management approaches. One of the pieces that I’ve felt was lacking in this space was a coherent framework – maturity model if you like – of how to approach the practice of developer experience.

Enter Thoughtworks and “Developer Experience as a fitness function for platform teams“. I’ve been a fan of Thoughtworks for a long time – not just their Tech Radar and their support of several tech community groups, and internet freedom events – but for their thought leadership – they challenge norms and aren’t afraid to be skeptical of the latest fad or industry ‘buzzword’. So when Andy Marks and Liauw Fendy were going to put on a session around Developer Experience I knew it would be worth a 3 hour round trip commute.

What is Developer Experience?

The session started off by defining Developer Experience – summarised as “user experience when the users are developers“, or more verbosely – building on the meaning of user experience itself;

“peoples perceptions and responses resulting from the use or anticipated use of a product, system or service”

We then explored what it means when we say ‘platform’ – and that most people have a very narrow view of what a platform is, but really, each platform has several components – it’s not just an API;

  • client libraries
  • test stubs
  • documenation
  • source code
  • tutorials
  • FAQ
  • quick start guide
  • community
  • evangelists
  • support processes
  • deploy pipeline
  • update and release strategy

The term “fitness function” itself is taken from Thoughtworks’ book ‘Building Evolutionary Architectures‘ – and is

“an objective integrity assessment of some architectural characteristics”

which can be used for continuous improvement purposes.

The discussion then turned to what is meant by good Developer Experience – both form and function. Using Aaron Waker’s Hierarchy of User Needs, we explored what it means for a Developer Experience to be

  • functional
  • reliable
  • usable
  • pleasurable

In the absence of a more formal maturity model, the hierarchy of user needs serves as a good starting point for understanding an organisation’s current level of Developer Experience and a way to prioritise improvement.

Drivers for investing in Developer Experience

We also discussed the drivers for investing in Developer Experience – which were generally very practical and focussed on reducing the cost of support;

  • If you build it, they won’t necessarily come; there are lots of development platforms available these days. If the development experience is poor then developers can easily switch to a different platform; developer experience is vital as an attractor for your platform, particularly if it’s commercially oriented.
  • If you don’t provide a strong developer experience, then developers who use your platform which build their own processes and approaches – essentially a shadow developer experience, which you can’t control. A robust developer experience gives you more control over the community.
  • Strong developer experience ‘frees up’ the platform team to be able to build more functionality and features, because support load reduces – developers are better able to ‘help themselves’, reducing interaction time on the platform team.
  • If you have strong developer experience, you will have more productive developers – able to build stronger, more featureful applications on top of your platform.

Measuring your Developer Experience

This was one of the most useful parts of the session – how to measure your Developer Experience, because if you can measure something, you can manage something.

  • Frequency of errors – what errors do your users get, and how frequent are they?
  • Documentation – which docs are used the most? Focus your effort here.
  • Repos – Issues created, PRs, repo stars and repo forks
  • Deployment processes – speed and ease of deployment, and continuous integration and continuous deployment processes.
  • Community – in bound requests and Net Promoter Score values.

When questioned about whether there was ‘one metric to rule them all’, the presenters offered;

“Mean time to first hello world”

which I found really interesting on several levels – getting something working quickly is more important now that teams have adopted Agile and minimum viable product approaches. On a psychological level, it also makes sense because if you can build something quickly, you’re going to be more motivated to expand your development.

I found all of these very informative for building a Developer Experience Metrics framework – even a cursory glance around the web shows that there isn’t a lot out there in this space – certainly not an industry-adopted ‘standard’ found in more established disciplines such as Service Desk Management or Incident Resolution.

Developer Experience lifecycle

Another key concept that was used to explain how maturity could be increased in Developer Experience was that of a ‘lifecycle’;

  • Find – Is there a platform? Here the developer is seeking a platform for their needs. How is your platform found? What are developer first impressions?
  • Learn – How do developers learn to use your platform? How good are the docs? The tutorials?
  • Build – How do your developers build? What do they get blocked on? What are their key obstacles or pain points?
  • Run – How do your developers operate the software? How quickly does it run?
  • Grow – How do you grow the number of consumers on your platform?

Together these stages form a ‘funnel’ – like a sales or marketing funnel, but with the aim of moving developers from ‘interested’ in your platform to active builders, and hopefully, advocates.

Parting thoughts

This was an excellent session – and the practice of Developer Experience is here to stay.

Image: Ember Code by Kovah on Flickr, CC-BY

linux.conf.au 2018 Sydney – A little bit of history repeating

This year, linux.conf.au 2018 headed back to Sydney, where it hasn’t been held since 2007. This year I skipped quite a few sessions due to having Linux Australia duties and tasks to do, and because the heat and humidity were exhausting. Thankfully, the videos by Next Day Video were released very quickly, so I’m spending “Week 2” of linux.conf.au catching up!

On reflection, several themes came through.

  • Volunteers, volunteering and volunteer labour – There are several free software and opensource organisations across the world, and they’re all vying for volunteer contributions. Moreover, the volunteer base itself is ageing; we’re getting older and having children and families and other family responsibilities – we simply don’t have the time to contribute that we once did. At the other end of the demographic curve, younger people don’t have the same passion and ‘fire in the belly’ for free and open source software. In one sense, that’s a product of the success of the free and open source software movement – because it’s been normalised; but on the other hand this leaves us with a gap in the ‘compelling-reasons-to-join-a-free-and-open-source-project’ list. As a concrete example, during the opening of linux.conf.au, no less than three organisations – Open Source Initiative, Free Software Foundation, and Code Club Australia – did a shoutout for volunteers. At the same time, Linux Australia – the auspicing body of the conference – had fewer nominations to its board than open vacancies. I want to be clear: The Organisers and Volunteers of linux.conf.au did a phenomenal job. They were dedicated, professional, resilient and awe-inspiring. As individuals, and as a conference team, amazing. Systemically though, open source has some major issues to address to avoid burnout, and worse, resentment.
  • Infrastructure-as-code continues to gain maturity – As more and more devices become internet-connected, and we’re managing more and more devices, we need better orchestration. We’re seeing this manifest in container-all-the-things, in MQTT for unified messaging and in our approach to IoT hardware and open hardware. Standards however remain a barrier to interoperability and greater maturity in code-based orchestration, as outlined brilliantly by Kathy Giori.
  • Open source touches many disciplines – the range of Miniconfs available this year sent a strong and undeniable message – free and open source software, hardware and practices are touching many disciplines. Art, genomics, games, galleries, libraries and museums (GLAM) – Linux and open source touch each of these in fundamental ways. Personally, I’m delighted to see this cross-pollination happening in our communities. Together, we do better.

On communities, volunteering and volunteer labour

“A division of labour in free software” – Molly de Blanc, Free Software Foundation

Molly’s talk used the results of different surveys of opensource communities to show visually that labour in free software is gendered, ageist, and that these schisms also apply to what is considered technical and non-technical work. The implications of these findings are that these patterns are repeated without intervening action, such as having quotas on leadership boards. Importantly, anecdotal data shows that we still value technical work over important non-technical work; people still justify their non-technical contributions to an opensource project by emphasising the technical contributions they do make.

This resonated strongly with me; as the leader of an organisation that turns over around $AUD 1 million a year – Linux Australia – there are a number of skills I need to have – budgeting, strategic communications, strategic and operational management – and of course, the ability to be an efficient administrator. None of these are technical skills; yet, as the leader of a technical organisation I am expected to have a strong grasp of technology issues. Even in a non-technical role, you’re not allowed to be non-technical.

https://youtu.be/6NDB2VFYlfg

“Dealing with Contributor Overload” – Holden Karau

Holden Karau is a core contributor to the Apache Spark project, and this war story and guidance was learned the hard way – when the project became so big that contributors were significantly overloaded. She provided a number of strong pieces of guidance for dealing with contributor overload, including:

  • Developing a contributor pipeline to allow users of the project to become contributors, and in time, core committers
  • Not ‘raising the bar’ for changes and requests because these have very unattractive downsides such as making the contribution pipeline harder and paradoxically increasing the contributor workload by increasing questions and requests for assistance.
  • The power of having clear roadmaps which make it clear what the core project is, and is not going to do, so that people can either start their own project, or plan around it. The Roadmap also helps guide contributions, and show how smaller tasks contribute to larger milestones.
  • Focussing on committer productivity – such as better tools to merge changes, making it easier to review changes, and more tests – can have significant long term dividends. Imagine what a 1% productivity increase would mean across say 10-20 committers? 50 committers? 100 committers?
  • Creating safe spaces to ask questions and contribute without being mocked – people who feel safe to fail are going to commit more.

https://youtu.be/BempWfBkvs8

 

“Burning Down the Castle” – Daniel Vetter, Intel (previous graphics kernel maintainer)

Daniel’s talk was an eye-opener. As a previous graphics kernel maintainer, Dan has seen a whole range of poor behaviours that contribute to maintainer burn-out, rage-quitting and other unproductive outcomes. His talk advocates for a kinder, gentler approach to maintaining a technically elite community.

 

https://www.youtube.com/watch?v=BB0luXmuo3g

 

“Mirror, mirror on the wall: testing Conway’s Law in open source communities” – Lindsay Holmwood

Lindsay provided an outline of Conway’s law of organisational communication patterns, and the concept of mirroring – the mapping between the organisational structure and the supporting technical structures for communication. Strong mirroring leads to strong ownership – you are led to the actors who own a system. Using an overview of the empirical literature on organisational development and he explained how organisations try to solve the problem of communication – using different structural strategies. But mirroring works poorly in unstable environments – those undergoing radical change and innovation. This has led to the rise of structures like guilds. These theories are then applied to open source to show that shifts away from the ‘core’ of an open source project can indicate a decline in the project itself. This necessitates a need to build a pipeline – again the pipeline – of people moving closer to the core in their contributions.

This talk was intense – but the key takeaway was that the way we design organisational structures has a significant impact on organisational outputs and long term organisation success. This is of particular importance for projects that are scaling up significantly; poor choices during scale up will lead to poor productivity later in the project’s lifecycle.

https://www.youtube.com/watch?v=xYkh1sAu0UM

 

Orchestrate all the things. With code.

“MQTT as a Unified Message Bus for Infrastructure Services” – Matthew Treinish

This was an excellent talk by Matt Treinish, who outlined the reasons behind the design of MQTT, which was originally designed for sensor telemetry. He goes on to show there are different levels of quality of service for the broker. An excellent introduction to how MQTT can be used as a unified messaging bus – as used in FireHose.

https://www.youtube.com/watch?v=y6xN6S407Xc

 

“What does the buyout of @arduino mean for #openhardware?” – Kathy Giori, IoT at Mozilla

I was truly disappointed not to be able to make it to Kathy’s presentation, as it came about partially because of a tweet I’d sent out to #lcapapers in mid-2017 – and which Kathy shouted out to me for. Thank you, and apologies for not being there in person.

Giori provided an overview of the corporate history of Arduino and how it’s now consolidated under one company; lamenting the drawn-out legal process that led to this point.

She continued to outline some of the challenges in licensing for open hardware and how manufacturers are being cheated by lower-quality knock-offs; with those same manufacturers then expecting the original author of open hardware / open software to provide ongoing support. This led to a discussion on the different levels of openness in open hardware, and the pros and cons of each.

Concluding the talk, Kathy provided an overview of the Mozilla Web of Things project, which is attempting to bring some standardisation and streamlining to the very fragmented IoT and open hardware space. There are competing standards, competing platforms, and the piece that I didn’t realise was that this is actually inflating costs for consumers. Because individual companies need to make hubs and supporting infrastructure for “their” range of IoT hardware, this means each endpoint device – light bulb, sensor, thermostat and so on – is quite expensive. Mozilla is seeking to have stronger interoperability in this space by creating the ‘Web of Things’:

“The “Web of Things” (WoT) is the idea of taking the lessons learned from the World Wide Web and applying them to IoT. It’s about creating a decentralized Internet of Things by giving Things URLs on the web to make them linkable and discoverable, and defining a standard data model and APIs to make them interoperable.”

If anyone can drive this, Mozilla can, but my personal feeling is that they’re going to come up against significant corporate interests in doing so – at a time when their own corporate mis-steps (Mr Robot, anyone) have significantly backfired. I live in hope.

https://www.youtube.com/watch?v=x2ltqoAqJbY

Cross-pollination, because together we do better

“The Future of Art” by J Rosenbaum

This was the mind-blowing talk of #lca2018 for me personally. Academic and artist J Rosenbaum took us through their research, which sits at the intersection of machine learning, neural networks and the production of art.

J’s talk started with an overview of machine learning projects, such as Botnik and Janelle Shae, and moved on to underscoring the collaboration between human and machine in generative art.

The future is not man versus machine  – the future of art is man with machine.

https://www.youtube.com/watch?v=lTT2mq692JQ

 

“The Knitting Printer” by Sarah Spencer

Again a brilliant intersectional talk by Melbourne-based hobbyist and knitter, Sarah Spencer, in which she provides an introduction to knitting machines, and provides a breakdown of how she reverse engineered a hack to a 32-bit knitting machine to be able to get images from her computer to the knitting machine.

Massive respect, @chixor.

https://www.youtube.com/watch?v=Y6k15pdFTsA

 

“Wearing access: a story about open collections, a sewing machine and the nation’s secrets” – Bonnie Wildie

Bonnie’s talk, from the OpenGLAM Miniconf, was very much a hidden gem of the conference. She talked about the concept of redaction art, created from files that have been redacted – and remixed. Bonnie even turned the redaction art into a dress, which opened up a conversation on the politics and power of what we wear. Dress and costume become media for subversion. Much awesome.

https://www.youtube.com/watch?v=XhTzE67HrhE