software development – Page 13 – Kev's Development Toolbox

January 2, 2019January 2, 2019

My software development blog posts from 2018: AWS, Twitter bots, Machine Learning, Docker, Kubernetes and more!

Looking back, I’ve investigated and played with a lot of interesting stuff this year, I was pretty busy 🙂 Early in the year I was doing a lot of experimenting with AWS as part of my prep for the AWS Solution Architect Associate exam, so a lot of my posts this year were AWS related, but I did some a some time working on some other projects too.

Here’s a look back at some of my favorite personal projects and blog posts during the year:

Mining Monereo in Docker containers running on Kubernetes: was it worth it? No, but it was a good exercise in learning some Kubernetes fundamentals.
Spring Boot microservices with Eureka
AWS Storage Gateway and EC2 spot instances with launch templates

Moving my WordPress (nginx, php5 and MySQL) to a new VPS host running in Docker containers (as of 12/31/12 where it’s still running right now)

Lessons learnt from migrating my blog to Docker: hereand here
Scheduled AWS Lambdas

Continuing my Android game development (Space Invaders remake)

Building an AWS Lambda based card game bot on Twitter (and updates here, here and here) – check it out here: https://twitter.com/BlackjackCard/with_replies

Using AWS Sagemaker to train Machine Learning models – here and here

mvmdvm and Pi-Star setup – multi digital voice Amateur Radio modes on a Raspberry Pi – here and here

Phew that’s quite a lot! I sincerely appreciate the feedback and comments I receive on my posts and hearing that at least some of my content is useful to others. I look forward to continuing to share my thoughts and write more content that hopefully will be continue to be useful in the coming year.

Happy New Year!

December 18, 2018December 18, 2018

InfoQ interview with Martin Fowler : 2nd Edition of his 1999 Classic, Refactoring, is now shipping!

Martin Fowler’s classic software development book, Refactoring, was first released in 1999. It’s been a staple on my bookshelf since I got a copy in 2000, something that I regularly refer back to for advice on how to improve the structure and maintainability of my code.

The 2nd edition of the book has now been released, updated for 2018, with all the code examples in the book which were previously in Java now replaced with equivalent examples in JavaScript. I have my copy on order with Amazon and should be receiving my copy before the end of the year.

InfoQ have a great podcast interview with Martin, discussing the motivations for releasing an updated edition for 2018, 19 years after the 1st edition was released. Check out the interview here.

November 29, 2018November 29, 2018

The best way to learn anything new in software development is to try it out yourself

You can read books, watch YouTubes and listen to as many podcast as you like, but the best way to learn anything new in software development is to try it out for yourself. Why? Because you’ll learn far more from the hands-on experimentation with a new tech/library/api when you try to use it that can ever be transferred as knowledge and experience from a single book/video/article/podcast. What you can learn from a single 1 hour podcast can give you a high level overview of a topic, but you can never learn as much as you will from trying it our yourself.

Part of the learning experience is working out how to solve the problems you run into. The ‘huh, it never said that in the manual’ experience. Once you’ve worked through the unexpected issues along the way, you’ll have built a much deeper understanding of what it actually takes to use a new technology. It’s where the rubber meets the road that counts.

June 20, 2017

Never assume you know how something works by only observing its external behavior

As a developer, you should never assume you understand how something works solely by observing what it does. This is especially true if you are trying to fix something and your only understanding of the issue is only the behavior that you can observe.

While you don’t have to understand how something works in order to use it, if you’re trying to fix something, especially software, it helps to understand how something works. The reason is what you observe externally as a problem is usually only a symptom of the problem; it’s rarely the actual problem itself.

Let me give you an extremely simplified example. Let’s say you have an electric car, but you’ve no idea how the electric motor drivetrain works, you just know you press the accelerator pedal and it goes. One morning you get in the car and press the pedal and nothing happens. In diagnosing the issue, the only thing you consider is the external symptoms that you can see: you press the pedal and it doesn’t go. An extremely naive conclusion you could make is that the accelerator pedal is broken (!). So you replace the pedal, but then you’re surprised to find that it still doesn’t work (ok, so this is a contrived example to make the point – if you know enough to be able to replace the accelerator pedal, you probably know enough about how the car works to not assume the pedal is broken!)

As a software developer or architect, as you diagnose issues you should always look under the covers and find out more about what’s actually going on. The problem you’re looking for is rarely the symptom that you can actually see (or what the user sees).