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

Situation

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

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!

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)

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

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.

Software Development Mentor

I’ve created a page called Software Development Mentor.

I’ve learnt a bit over the last 20-odd years of creating software and programming (ironically, something I originally never particularly wanted to do) and that’s the page where you will hopefully find a few nuggets of wisdom.

I actually have a couple hundred nuggets scribbled down so I’ll be updating the page when I have time or need a short break from creating a product and building a company.

Rookie Mistakes

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

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");

Application window disappearing off edge of monitor (Windows 10)

In the last week I’ve had 2 instances of opening an application/program opening in Windows 10 and disappearing off the edge of one of my monitors.

My workstation is a HP OMEN gaming laptop with 2 attached monitors in a horizontal row. Unplugging monitors did not cause the hidden window to reappear.

 

The solution is reasonably simple.

1. Hold down the shift key and right-click on the application icon in the Windows task bar.

2. A context menu will appear. Select the “Move” option.

3. Immediately hold down the left mouse button. This will have the affect of selecting the title bar of the application and activating the ability to move that application’s window.

4. Still holding down your left mouse button (the primary button), move your mouse left and/or right and you should soon see your missing program window appear on the monitor.

(In both instances my application disappeared of the right side of my right-hand monitor. This may vary for different people.)