My experience is limited to personal projects with perfect world requirements. So, in the end, I consider myself as a beginner on unit testing.

Where to start? I can analyze — and have analyzed — projects with unit testing implemented but nothing replaces hands-on experience in real projects with users and it’s edge cases. Glorified “hello worlds” do not count.

Testing is like digital security. Whoever is responsible for this will always be in an ungrateful position to defend.

Going back a little, I understand the advantages of unit testing. I’ve seen projects with testing implemented and the benefits it’s bringing to the table, but it’s been impossible to convince management of its importance — and even other senior developers. Maybe I’m not good at communicating the pros and cons.

Finally, the other issue that unit testing brings. Testing is like digital security. Whoever is responsible for this will always be in an ungrateful position to defend. When everything is going well, that unit testing is doing its job properly and the devs reap the benefits someone will probably say — or at least think:

Why are we wasting time with unit testing if everything is going so well? Why am I paying you?

Or even when the inevitable bugs occur:

Why are we having problems? I thought we had unit testing. Why am I paying you?

This is aggravating.

One time I was meeting the teams on a new company that, eventually, I joined and I remember asking “Do you do unit testing?”. The happy answer was “of course”. I was happy that I would be joining a company where I could get experience with unit testing on real-world projects. Little did I know he was referring to end-user testing. There was a team dedicated to testing entire user processes, from start to finish, to make sure everything was according to the requirements. This was good to have, but it was not unit testing. I later found that this company had an annoying habit of using industry standard names that meant something completely different inside the company. Consultants? = Glorified salesmen.

Articulating the advantages seems hard when even seasoned devs don’t want or care about unit testing. In real life, we also have to take into account company policy, personal interests — I want this project done ASAP! — which usually means getting closer to that bonus.

What are the usual pros? Let’s list them.

• Finds bugs early — The sooner a bug is found, the less likely it appears on production.
• Improves code quality and readability — A big advantage for big projects.
• Facilitates changes giving greater confidence to the developer that his changes did not break existing functionality, therefore…
• … boosts developer productivity.

Sum all of the above and you have the biggest pro since it reduces costs in the medium to long-term.

I can analyze projects with unit testing implemented but nothing replaces hands-on experience in real projects with users and it’s edge cases. Glorified “hello worlds” do not count.

What are the downsides? Let’s take a look:

• Does not guarantee bug-free code. This is the obvious one, but somehow some people believe unit testing to be magical.
• Time-consuming. Same as saying it costs more. Can’t release the project on time, or the project must have features cut. Managers/Clients don’t like to hear that.
• Unit tests can/will have bugs. This one is down to the quality of the dev team. Have less discipline here and you will get in trouble.

It boils down to cost. A company culture that does not allow a developer to fail will not have unit testing. If you cannot count on your teammates to help, you will not have unit testing. If your company only sees you as a row on an excel spreadsheet, that means you will actually get burned with unit testing (cost) and then you will not have unit testing.

After reading much about unit testing the greatest advantage I see is that it makes us focus and reflect on the code written. If your code is too big or hard to read, you will most likely refactor it. In a team, this will lead to increased productivity with higher quality code bases. As a developer, I don’t need any more reasons to like unit testing.

No glorified hello worlds here was originally published in Nearsoft Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

“There’s nothing more permanent than a temporary hack.” — Kyle Simpson

Does this mean I have never done it? Of course I have, and all programmers have done it at some point in their career and, like me, will probably do it again.

So we do it on purpose, right? Well yes and no.

Yes because we are pressured by deadlines to deliver a product on time and on budget. A good developer that does this on purpose is aware of its problems, so it takes notes and/or creates an issue on the issue tracker to solve it a later time. The problem here is the “a later time”. If your teammates and management in your company don’t understand that it has to be done, this will, almost every time, come bite you in the ass at a later date.

How? The two most common scenarios.

1. Another hack will be made to compensate the shortcomings of the first one. This will pile on and a third, fourth, ad infinitum, hacks will be made to compensate the shortcomings of the previous one.
2. Since your name was on the commit and due to the shortcomings of said hack, you will take the blame for the time it takes to “fix” the hack — see scenario 1.

This eats away at the productivity of your team and causes a sunken cost. The reasons for this cost are not obvious. The only thing that is noticed, by management, is that more money has to be spent on the project.

If someone on your team does not take notes on the hacks, this is a sign of future pain and suffering for the entire team.

Every month or so — your mileage may vary — some time should be set aside to solve these issues or risk getting drowned in them.

No , because the developer is unaware of the problems due to having low experience on how the code affects the code base. This is either inexperience as a programmer or inexperience with the code base itself. These hacks work great in the short term and give the appearance that the programmer can work in any environment, but is only leading to technical debt.

And these debts will be paid with interest.

If you scale of perfection is 1 to 10, with 10 being perfect, then always aim to 10 even though you will never get there. You will reach, hopefully, an 8 or even 9, but if you aim to the 8, you will be content with a 6 — until the day you have to maintain that code.

So my new year’s resolution will be to avoid hacks whenever possible and make sure my teammates understand the consequences of technical debt. Use mentoring, use technical tools — code reviews — or anything that is required to make sure everyone is on board.

And these debts will be paid with interest was originally published in Nearsoft Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Hi there. I want to create a website where I can put pictures and videos about stuff for sale and at the bottom, I want to put my contacts. What do I need and how much does that cost? It’s simple, right?”

That’s all I have for requirements.

Of course, I eventually ask for more details, but the details provided were not really unexpected since I know this person. Base on that I reach the conclusion that I need to:

1. Buy a domain (email with that domain).
2. Host it somewhere.
3. Buy a design. A minimal design is preferable.
4. Pick a barebones open source CMS that is easily hackable (just in case).
5. Implement said design on chosen CMS.
6. Publish it all.

But wait!

Guess who will have to manage this later? Me! The one who just wants to get this over with, but also wants to make sure the client has everything it needs. I will provide basic help in the near future (the next month or so), but I can’t let this take over my time.

I actually dislike Wordpress, from a developer point of view

Enter Wordpress. I actually dislike Wordpress, from a developer point of view, but does make a lot of things simple. Short to medium term it gets the job done. It ticks all the boxes and there are dozens or more providers out there who can host and configure everything with just a few click.

My dislike for Wordpress has nothing to do with the language — PHP. It’s a nightmare if used in a context of full customization, but when the requirements are straightforward it’s actually a pretty good platform.

My dislike for Wordpress has nothing to do with the language — PHP

So, in the end, I decided to leave over-engineering behind and go for the simplest solution.Got a host that did everything I needed, paid for a full year. Wordpress installed using their interface and got the job done.

KISS: Keep It Simple Stupid applies like a glove.

After some digging around I ended up finding how to do it:

Remember your default username for WSL, then enter a admin command prompt on Windows (WIN+X then A), then run the following command to the default user to root so that you can login with no password:

lxrun /setdefaultuser root

Keep the admin command prompt open, then enter the WSL cli application and change the default user password by issuing the following command:

passwd default_username

After entering the new password for default_username exit the WSL cli and set the default user to the default_username:

lxrun /setdefaultuser default_username

Done. You can now enter the WSL cli application and get back to whatever you were doing.

Let’s start with the hardware:

• Macbook Pro 2017 (13“)
• 27" 4K Monitor (LG)
• Mouse Logitech MX Master

I mainly develop with PHP so that of course influences my current development stack on the software side:

• IDE: PHPStorm | Visual Studio Code | occasional use of Vim.
• For command line: iTerm2 with Oh My Zsh (https://gist.github.com/kevin-smets/8568070). MacOSX built in Terminal defaults are horrible and decided to pick something that would look better overall.
• Homebrew to manage packages on MacOSX.
• Environment based on Docker containers.
• Spectacle App for managing windows. MacOSX is pretty horrible in this regard.
• Browser: Google Chrome. Safari is used to house the Slack web app. Desktop Slack is horrible (for memory consumption).
• For DB management I use two different applications. MySQL Workbench for production environments and Sequel Pro for dev/local.

That’s the basics. There are a few more apps that are mostly there for experimentation.

Tools of the trade 2017 was originally published in Nearsoft Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

update: This also works fine in Laravel 5.5

Recently started working with Laravel (5.4) and so far it’s been a joy to work with.

The first roadblock I encountered was on how to organize views/templates.

Page templates

I went down the simplicity path, having the following rules:

1. Grab the controller name, exclude the Controller part of the name, put it to lowercase. With this we have a folder that will house the templates that are used by that controller. For example: HomeController > Home > home.
2. Let’s assume that we create a method inside HomeController whose job is to load a generic about us page. So we create the method aboutUs and call the relevant view. What’s the name of view? Just call it about-us, which means a path /resources/views/home/about-us.blade.php.
3. The default controller method has a special name, __invoke, and since I did not want to have a view called invoke.blade.php I decided to just use the same name of the controller. So for now we have a folder called home with a file called home.blade.php. Based on these rules we can immediately assume, with a high degree of certainty, that the view home.blade.php is called inside HomeController::__invoke.

What about partials?

Partials are blocks of code that are reused in more than one page/view, so I needed a set of rules for creating these, so that the location where they exists makes sense and gives an ideia of how it’s used. These rules assumed you are following the previously laid out rules.

1. When the partial is only used among the views of a single controller, create a folder called partials inside the controller view folder. Put your partials in these. Ex: /resources/views/home/partials/example-partial.blade.php.
2. When the partial is used by different controllers, then put them inside a partials folder inside the views folder, on the same level as the controller views folder. Ex: /resources/views/partials/example-partial.blade.php.

Layouts

I did not see a reason to change the location of layout files (/resources/views/layouts/master.blade.php).

I’m sure there will be edge cases in which these rules cannot be applied, but I hope that these rules minimize those cases, instead of having the mess of view files that makes it hard to pinpoint what are it’s intended uses.

Adventures in Laravel 5.4 land — view management was originally published in Nearsoft Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.