This is just a rant post to get it off my mind. No names will be mentioned. So I recently discovered a tech company was relying solely on volunteers to develop part of their product and were unable to provide support The volunteers didn’t realise that tech support for the code was basically customer support. Everyone’s response was “this is OSS” as that excused a company having zero employees supporting a part of their product.

Several months ago, I decided that I wanted to generate some income from my own projects. I originally started on a SaaS bootstrap library. A part of my development work for that library would need to be demos to prove the project and that I would try and sell each demo. Since doing that, I learned nothing about starting a business, so I began to read books on the subject. I read over 10 books during December alone.

So last night I managed to get myself into a twitter fight that I think brings up an important aspect of software development and highlights two different mindsets within the software development world. So here I will try to explain my position and theirs in a better format than 280 characters and while it’s not 3am. Quick Breakdown of the Fight The Twitter fight was over the idea that there are some bugs found by QA in code that has been in production for years and has never happened to another person ever and these bugs aren’t worth fixing.

So it’s yet another ProductHunt release blog post. This time it’s not to get that sweet, sweet traffic to my project but just to actually reflect about it. There were some things I really didn’t expect to happen, and I read a bunch of these blog posts for some reason. So here is my breakdown of “launching” my CRM side project Easio. One major thing to do So I realised there is one major thing that everyone who is going to use product hunt to launch their next big thing.

Here I try to explain in nontechnical ways things that happen in IT departments which in my opinion are generally harmful to the company. The aim of this series is to help company founders who aren’t experienced in IT be able to judge the health of their IT department. The Product Team is there to decide which features are to built first and how the features are to work. They are one of the most crucial parts of the development processes since they choose the path for the project and help make sure that the project brings the most business value as possible.

Over the years of leading teams and working in various IT environments I’ve discovered, there are generally three types of tickets within the small to medium size companies. An Idea An Idea Request is where someone has an idea, and it would be nice to try it out and see if it works or not. An idea is not a request that is based on current business needs but on the possibility to improve something that is already working.

For the most part, sanity checks are put into the code to ensure there are no bugs. For this reason, guaranteeing sanity checks are done correctly becomes necessary. If you do not check to see if the data is valid, and it is invalid, then you’re going to allow invalid data to proceed. Here, I’m going to discuss how I think we should do sanity checking in PHP. Asserting Valid Data What I’ve seen a lot is people are asserting for invalid data when they’re doing their sanity check.

Single Responsibility Principle (SRP) is probably one of the most well-known principles from SOLID. At its core is a desire to prevent classes from becoming overwhelming and bloated. While enabling the ability to change how a single thing works by only changing a single class. So the benefits of SRP are that you have an easier codebase to maintain since classes are less complex and when you wish to change something you only have to change a single class. In this blog, I will go through some ways to try and help avoid breaching SRP while doing code review.

I’ve been using OVH’s dedicated server range recently. When ever I tried to use docker with the Ubuntu latest LTS I ended up with an error failed to register layer: devmapper:. The solution is rather simple, OVH dedicated servers use rather old and unsupported kernel versions. The solution is upgrade linux kernel.

Go’s dependency handling has been an area which has been needing unification, over the years. Multiple package managers have been created. The Go community has been working on creating a dependency manager recently, which they plan on getting added to the official toolchain. I’ve decided to jump on the bandwagon and start using this tool. Here’s how I’ve been using it in docker.