After some thought initially on a new laptop, I decided to spring for an iPad Pro 12.9". So far I am really glad I did, the computer comes with me everywhere. I bring it to work, to visit family, on trips and everywhere in between.

It’s the ultimate work computer in many ways, always with you, light enough and comfortable enough for real work™. The keyboard shortcuts in iOS have improved massively from iOS 8 to iOS 9 to the point of actually being useful and the split screen view is actually rather nice to use (I never “got” it on a Mac).

I recently read Remote: Office Not Required by David Heinemeier-Hansson (who created Ruby on Rails) and Jason Fried (who co-founded 37 Signals with Heinemeier-Hansson). This book is really a case study in why the future of work will be remote, of which the book did convince me (but I would say, I already believed).

The book is really structured to convince those who do not believe in the premise of the title. It talks about many successful companies who have transformed themselves to work remotely fully and large corporations who save lots of money on office space (IBM, being one example).

Early last year, I purchased two Code Keyboards (one for work and one for home). The Code Keyboards are designed by Jeff Atwood (who founded Stack Overflow). Mechanical keyboards are “old style” in that the switches are from an era where everything was mechanical, unlike today where everything is glass. So mechanical keyboards have ardent fans and people who don’t really care for them.

I did a lot of research before I purchased, talking to various people in work who are very knowledgeable about mechanical keyboards (The best community for advice, discussion and group buys is /r/mechanicalkeyboards on reddit.). The variety of hardware and opinions is positively mind melting. If you are doing your own research, you should definitely come across Cherry switches (a very established German brand). Switches are what sit between your key that you see (with the letter printed on top) and the electronic board that converts the key press to a signal the computer can understand.

I recently purchased Ulysses Mobile after a recommendation from Macstories. My first impression was how expensive it was priced and what really makes a premium writing application?

Needless to say, I’m not a huge writer. But I do have a real fondness for plain text (it will survive the apocalypse) and by extension, Markdown by John Gruber. The problem for Ulysses is this: there’s lots of really great Markdown applications for iOS, two of which I have written about: Editorial (my favourite) and Byword (not so keen on this app).

I backed the Roost laptop stand on Kickstarter, which already had a successful run in their first Kickstarter campaign. I’ve been delighted with the result so far, it lives up to the promises of being super light but yet durable and strong. Here’s a photo of it:

It came with a really nice case which holds the Roost underneath and has pockets for a portable keyboard (I use a Logitech K811) and mouse (I use a Logitech Marathon M705). It works great for a really comfortable and ergonomic desk wherever you may travel (or set up to work). Highly recommended!

I recently read O’Reilly Building Maintainable Software (Java Edition). It provides good insight as to what to look for to create maintainability in enterpise software systems.

10 suggestions the book provides:

1. Write shorter units
2. Write simpler units (measured in Cyclomatic Complexity)
3. Write code once only
4. Keep interfaces very small
5. Seperate code in to modules
6. Couple modules loosely
7. Keep modules evenly sized
8. Keep codebase small (and look for ways to right-size)
9. Automate development pipeline and your tests
10. Write clean code and refactor as you go

Overall I thought the book was very well laid out, easy to read and easy to understand. I’d recommend it to anyone new to software development, but most of the tips contained within the book should be very familiar to the seasoned developer.

In the last year and a half, I set up a Ruby based Dashing dashboard for my team and others in our product area. Here’s what a sample Dashing dashboard looks like:

It’s been a huge success, but it was tough to gain traction along the way. Here I’ll summarise what I’ve learned (in no particular order):

• Don’t do dashboards for managers, do them for teams
• Use big text, have the minimum information as required
• Use colours (preferably like the traffic light system) to focus attention
• Link in all critical systems to daily work
• Make it a one stop shop and faster then all other methods of getting this information
• Reuse the work of others (steal with pride)
• Don’t bother with graphs

Below I outline the reasons for each point:

Continuing the theme of automation, one of the most repetitive tasks if you work for a big company is timesheets. So I set out to rectify this by scripting it!

Start with you configuration, I named mine hours.ini:

[DEFAULT]
url = FILL_ME_IN
username = FILL_ME_IN
password = FILL_ME_IN

then we need the magic of Selenium to do the heavy lifting, so we install it:

$ pip3 install selenium

I called this script, unsurprisingly hours.py:

I love trying to automate the world, it just feels like magic some of the time! I also really enjoy information coming to me, instead of having to seek it. As we are still only in 2016, we have no world killing Artificial Intelligence (yet). So we have to start small, ease the first world problems! So I decided to make my workplaces’ restaurant menu come to me!

I decided to write it in Ruby and use push notifications, rather than email or SMS. It uses a web automation framework called Selenium, which is available in many languages, including Javascript, Python, Java and obviously Ruby!

I’m a huge fan of Docker ever since I started to use it, approximately a year after it was started. It’s one of those technologies where when you start to use it, you immediately know it’s going to be a sea change in how things are done in the industry. It’s definitely going to be more impactful then Virtual Machines.

We’ve used Docker to great effect where I work. We’re building a huge system called Ericsson Network Manager, which will manage the networks of the future. As such, it’s a hugely complex problem to compartmentalise parts of the product, to be able to just use the part that you work directly on.