Month: January 2019

Upgade Cloud9 Workspace to PHP 7.2

Posted on | by Jason Snelders

Update: 05 May 2019

I’ve discovered a page at https://www.soupbowl.io/2018/04/using-php-7-on-ubuntu-14-04-with-codeanywhere/ as an alternate source for updating PHP to version 7.2. Look for the section “Updating PHP 5.4 to PHP 7”. I haven’t tried the process, but it looks pretty good.

 

Updated: 14 April 2019

According to this announcement, the old Cloud9 service (c9.io) is soon to be no more, with all functionality ending 30 June 2019, and complete shutdown 30 November 2019.
What is the future of C9? It will be 100% within Amazon Web Services as AWS Cloud9.
I – like many others – am not a fan of AWS. In fact, I think AWS is one of the worst development services I’ve used, and Cloud9 proves it. They took an incredibly powerful and easy to use service and… well, totally fucked it to be honest. To the point I spent an hour of my Sunday afternoon swearing while trying to setup a new AWS Cloud9 WordPress environment.

As such, I am unsure at this time if I will continue to work with AWS Cloud9 or find an alternate cloud IDE (I now use https://codeanywhere.com). I use IDEs in a professional capacity and I’m happy to pay for convenience and ease-of-development experience.

Anyway, I won’t be attempting any C9.io workspace upgrades in future. I will, however, create a new post when I decide which development environment to use.

 

Updated: 03 March 2019
After my original environment upgrade I started to see CPU maxing on page loads. I thought it was code changes, but it wasn’t. I run WordPress in my environment and even /wp-admin was causing a 5-20x increase in page load times with 100% CPU spikes.

I happened to find a copy of my environment that was still the original PHP 5.5.9 version and have been using that since a week after this original post. CPU has been fine.

Today I cloned my working environment, did some more searching, and tested a PHP upgrade again. The section “Updated Solution (03 March 2019)” below contains the results of that upgrade. So far, so good. The upgrade process is not that different to the original.

However, /phpmyadmin shows an error “The mbstring extension is missing. Please check your PHP configuration.” I’m not surprised because I my script excluded that (see notes within the 03 March section).
I will work on this next, but I wanted to publish updated results before that happens.

Updated Solution (03 March 2019)

Today’s results are modified from [and thanks to] https://www.joeferguson.me/install-and-configure-php-7-1-on-cloud-9-workspaces/.

Run the following commands, but note:

sudo add-apt-repository ppa:ondrej/php -y
sudo apt-get update -y

#sudo apt-get install php7.2-curl php7.2-cli php7.2-dev php7.2-gd php7.2-intl php7.2-mcrypt php7.2-json php7.2-mysql php7.2-opcache php7.2-bcmath php7.2-mbstring php7.2-soap php7.2-xml php7.2-zip -y
sudo apt-get install php7.2-curl php7.2-cli php7.2-dev php7.2-gd php7.2-intl php7.2-json php7.2-mysql php7.2-opcache php7.2-bcmath php7.2-mbstring php7.2-soap php7.2-xml php7.2-zip -y

sudo mv /etc/apache2/envvars /etc/apache2/envvars.bak
sudo apt-get remove libapache2-mod-php5 -y
sudo apt-get install libapache2-mod-php7.2 -y
sudo cp /etc/apache2/envvars.bak /etc/apache2/envvars

sudo a2dismod php5
sudo a2enmod php7.2

sudo service apache2 restart

 

 

 

 

Original Post Solution

Cloud9 is a great online IDE (or it was before the Amazon AWS team got their hands on it).

The problem is the default PHP version in my workspace was 5.6, well out of date and unsupported.

It turns out, upgrading PHP version’s isn’t a simple matter. After much search in found this solution on StackOverflow that worked for me:

https://stackoverflow.com/a/51028239/115704

sudo add-apt-repository ppa:ondrej/php -y
sudo apt-get update -y

sudo apt-get install php7.2 php-pear php7.2-curl php7.2-dev php7.2-gd php7.2-mbstring php7.2-zip php7.2-mysql php7.2-xml -y

sudo mv /etc/apache2/envvars /etc/apache2/envvars.bak
sudo apt-get remove libapache2-mod-php5 -y
sudo apt-get install libapache2-mod-php7.2 -y
sudo cp /etc/apache2/envvars.bak /etc/apache2/envvars

sudo a2dismod php5
sudo a2enmod php7.2

sudo service apache2
sudo service apache2 restart

Bad UX: Microsoft Films & TV

Posted on | by Jason Snelders

This is a UX failure I experienced.

My default media player in Windows 10 is Microsoft’s “Films & TV” app. So most .mp4 or .mkv files I have or produce I play through this app.

The problem is, if my focus is on the app and I press the backspace button (which can happen if I’m working and switching between multiple screens), I go from a playing video to the following:

So, where the UX fails and I become lost is: how do I get back to the file I was just playing?

There is nothing on the screen that indicates this possibility.
And exploring the few extra options (including a back arrow that only appears after moving between “Explore”, “Purchase” and “Personal”) yields nothing.
In the end I have to go back to Windows Explorer and re-execute the file.
(Now I think about it, the application doesn’t even have a typical “File” menu to find and open a file directly.

I call this a fail because I cannot simply “go back” to the file I was playing.
I would expect this from a default operating system application in 2019.

Git: branch commit is in the future

Posted on | by Jason Snelders

I was just checking some branch commits from one of my developers and noticed the commits where 22 hours in the future.

It turns out they’d changed their system time for testing and forgot to revert it before pushing.

It makes sense when I think about it.

Because git is a distributed system, it would use the local system time when committing.
Git doesn’t track track off a server time.
That means you can be totally disconnected from other systems and still make commits – in that case the only time it knows is the system time.

That doesn’t make it any less confusing or counter-intuitive in an age of servers, synchronisation and centralisation.

Visually hidden field with ‘required’ attribute causes error: “An invalid form control with name=’xxxxx’ is not focusable.”

Posted on | by Jason Snelders

Situation

Receive a JavaScript console error of An invalid form control with name='xxxxx' is not focusable when trying to submit the form.

I asked one of my developers to comment out a field in a web page as part of a requirements change (I prefer to comment out initially before deleting so we are sure everything works fine with the change).

The developer added a style="display: none" to a surrounding div to hide a <select> field.

However, this in turn caused a JavaScript console error of An invalid form control with name='xxxxx' is not focusable when trying to submit the form.

 

Solution

Remove the “required” attribute from the form element.

In helping my developer I did a Google search for “an invalid form control with name=” is not focusable” and one of the first results lead to https://stackoverflow.com/questions/22148080/an-invalid-form-control-with-name-is-not-focusable.

On that page I immediately saw “Adding a novalidate attribute to the form will help” and that made me to immediately remember there is a “required” attribute still on the field that was hidden.

Experience and instinct kicked in.

We removed the “required” attribute and the form submission worked.

My guess is when the form was submitted the native browser-based validation did not work correctly because the specified field is “visually” hidden so the native validation message could not be shown, and that triggered the error in the console.

Insanely hot!

Posted on | by Jason Snelders

It is currently 6pm in Melbourne, Australia.

All day the temperature has been rising.

Right now it is 4.4 degrees Celsius above the predicted maximum of 36 degrees.

Tomorrow’s temperature just went up by another degree.

And my electricity provider is sending out text messages asking people to reduce their power load this evening:

Software Development Estimation (and breaking through The Planning Fallacy)

Posted on | by Jason Snelders

Everyone involved in software development sucks at estimating the time to complete tasks.
Developers. Analysts. Even project managers.

I recently heard a very really simple solution for this problem on a podcast that was discussing The Planning Fallacy.
The solution:

Multiply your estimates by Pi (3.14)

I’ve tried this a few times over the last week and it actually works.
My estimates are finally starting to match reality. And this includes such simple things as writing and responding to emails.

There’s only one problem – that’s jot really a problem – is:

Managers and customers are not going to like hearing the truth

Estimates are going to sound long and expensive, and you will be pushed to reduce them again.

Don’t.
Don’t back down.
Stick to your guns.

The real problem with estimation is not that we suck at it.
The problem is we are forced to cut corners and revise to unrealistic numbers that “sound good” to the customer’s ears.
It never works, and always blow out, and then the shit hits the fan, and stress increases as projects run over time and developers are coerced into working stupid overtime.

If we just do the right thing in the first place and communicate what’s real, everyone knows where they stand and everyone will be happy in the long run.

A Git Strategy

Posted on | by Jason Snelders

Background

Over the years, I’ve worked on a number of different projects with different Git branching strategies. I’ve also wasted many hours sitting in meeting arguing over what should be a relative non-issue.

The beauty of being the bloke in charge is sometimes you get to skip all the bullshit and just dictate the approach.
Or to be correct in this case, sometimes the approach is dictated for you.

Working remotely with developers who were essentially new to Git and were already facing a lot of learning and change, I found their actions have driven my Git process decisions.
Which is good:

You want to make business and development processes as easy as possible for everyone.

After all, complexity is the enemy of productivity.

I started with GitFlow, which has worked well in the past, but ended up simplifying if further.

 

The Strategy

The Git “Pilot”

One person is designated responsible for reviewing and managing a repository.
All developers should be capable of doing this role – and the role may rotate between developers – but at any point in time one person is the designated “pilot” in control and responsible for the repository.

Workflow

Normal feature development

  • A working branch is created from develop.
  • When work is complete it is merged back into develop via a Pull Request.
  • A release is created.
    • A version number is generated an applied at the start of this process.
    • A new release branch named “release/release_{version}” is created from master.
    • develop is merged into the release branch.
  • The release goes through test environments.
    • Note: Only 1 feature release branch is tested at a time. This reduced management complexity.
    • If a fix is required:
      • A working branch is created from the release branch.
      • The working branch is PR merged back into the release branch.
    • If a production hotfix occurs during this process, develop is merged back into the release branch.
  • A release completes testing and is published to production.
    • Assuming any production hotfixes have already been merged into develop and the release branch.
    • The release branch is merged into master.
    • The release branch is merged into develop (to ensure any fixes are available for continued development).

Hotfixing production issues

  • A working branch is created from master.
  • When work is complete, a release branch is created from master (same versioning and naming process at normal feature development) and the feature branch is merged into the release branch.
  • The release goes through testing.
  • When testing is complete:
    • The release branch is merged back into master.
    • The release branch is merged into develop.
      develop then needs to be merged back into any working branches, and feature release branch currently in test.

Version Numbers

  • Use the format {yyyy}.{mm}.{dd}.{HHmm}
    • {yyyy}: The current 4-digit year at UTC.
    • {mm}: The current 2-digit month at UTC.
    • {dd}: The current 2-digit day at UTC.
    • {HHmm}: The current 24-hour hour and minute at UTC.
    • Example: 2018.02.22.2158
  • Version number is applied as soon as a release is generated.
  • I don’t care about identifying alpha’s, betas, fixes, or otherwise. A release is a release. Use release notes to document details of what is going into a release.

Core Branches

Required:

  • master: The current production code.
  • develop: The current code being developed and tested.
  • release: Each release starts in its own branch.

Optional:

  • feature: Optional node for developer to create working branches under.

Working Branches

Developers can optionally create working branches (known as “feature” branches in GitFlow) under a feature node (e.g. feature/jason_my_work), or directly off the root – at the same level as master, develop, and release.

This “either or” approach came about because my developers were forgetting to create working branches under feature.
In reality this is not a problem in any way and, if anything, made them easier to find and access, so I’m happy for them to stay there.
Good repository maintenance will handle any clutter issues.

Branch Maintenance

After merging working branches back into develop, keep the branch for a “period of time” – generally through testing – we’re happy all code is included and complete.
Periodically delete old working branches.

Release Notes

Each release should contain notes identifying:

  • The type of release – e.g. scheduled feature release, production hotfix, security patching, etc.
  • A summary of changes included in the release.
  • Identify any breaking changes.

Rookie Mistakes

Posted on | by Jason Snelders

I was listening to a security podcast and someone of considerable industry experience said (of something they just did):

“That’s a rookie mistake”.

No, it’s not.

It’s just a “mistake”.

To say it’s a “rookie” mistake is being disingenuous to rookies, particularly when the experienced person is still making that same mistake.

So, by virtual of a fact it is an easy mistake for someone of experience to make, that makes it just a plain old “easy” mistake.

RegEx: Find occurrences in code, except when commented

Posted on | by Jason Snelders

Background

I’ve created a debug helper function in my PHP/WordPress development called TraceIt($value, $type, $param1).
TraceIt does a bit more than just echo out a value. It will format echo out based on value type or specified type, can be environmentally switched to not echo, and can write to a log file.

It’s also easier to find where actual tracing is being used versus the legitimate echo output.

The problem is, sometimes I forget to comment a trace, which is no good, especially when trying to perform a redirect.
And while I usually include a string value in the output that I can search for, sometimes in the heat of the debugging moment I forget that.

 

Solution

The easiest [and some may argue “painful”] way to find occurrences of forgotten TraceIt calls is regex.

What I needed was a way to find all instances of “TraceIt” but not “//TraceIt” (already commented).

And here it is:

^(?!([ \t]*\/\/[ \t]*TraceIt)|[ \t]*\/\/).*((^TraceIt)|( TraceIt)|(\tTraceIt)|(;TraceIt))

You can see it in action, with an explanation of each component, at https://regexr.com/46nbq.

The only problem with this is it also picks up instances of TraceIt on a line that already has //TraceIt earlier in the line.  But I can live with those rare occurences for now.

Oh, and don’t forget to use the /gim flags (global, case insensitive and multi-line).

 

The regex will find occurrences like this:

coding is here; TraceIt("aaaa");
TraceIt("aaaa");
another line of code;
TraceIt('bbb'); more code
TraceIt('ccc');
TraceIt('bbb');
some more code; TraceIt("adsfadfa");

But not like this:

//TraceIt("aaaa");
//TraceIt("bbb"); TraceIt("ccc")
// TraceIt("ddd");
// TraceIt("ddd");
// TraceIt("eee");

another line of code;

some code; //TraceIt('fff');
    //     // TraceIt("gggg");