I have been working on some Java coding kata’s lately.

One of the pain points was the getting the environment set up.

This is one thing that other environments get right:

C# – visual studio has templates for everything.

Elixir – “mix new projectname” does the trick

I have had a look at the Java equivalents:

If you have gradle installed:

gradle init –type java-library

or if you prefer groovy and spock:

gradle init –type groovy-application

If you have maven installed:

mvn archetype:generate –DgroupId=com.mycompany.app –DartifactId=my–app –DarchetypeArtifactId=maven–archetype–quickstart –DinteractiveMode=false

Personally I like the brevity of gradle, both of these should be run inside the directory that you have created.

Powershell is a very powerful language yet a lot of developers get frustrated by some of it’s little quibbles.
Learning a few little details make working with powershell much easier.

Items to consider are:

• Continue On Error
• Strict Options
• Comparison Operators
• Type System
• The Pipeline

Powershell commands are always formed Verb-Noun although they can have a more familiar alias.

The beauty of Powershell is how configurable and reflective it is.
If you don’t like the default behaviour then it can easily be adjusted.

For example to find the automatic variables you can use the simple command:

dir variable::*

This lists the variables defined in global scope, including the automatic variables.
Details of these can be found using:

get-help about_auto | more

For example you can change the continue on error by setting $ErrorActionPreference

If you don’t think that PowerShell is strict enough on checking the parameters and types you can use:

Set-StrictMode -Version Latest

This is the Implicit None from Fortran (or VB’s OPTION STRICT).
It means that you get warned if you try to use an uninitialised variable.

PowerShell uses the prefix [Type] to define a type.

So:

$a = [int]16

is valid.

This assumes a mature XP process is underway (this is almost 20 years old, so should not be a surprise to anyone).

If you are actively developing software there are only a limited category of bugs:

• The critical – stop development and fix
• The important – to be picked up as the next highest priority item
• Prioritised alongside other upcoming work items.
• Do not fix – record as unimportant

These days there should be no reason to keep an extensive bug backlog.

A bug is effectively a missing test (unit, integration or end-to-end).

With a sufficient test suit the QA should be getting bored. Hopefully they are spending the time working on acceptance criteria and acceptance tests for upcoming work.

This is a site that tries to spread the load on open source projects.

The idea is that you volunteer to help out triage the issues on projects allowing the maintainers to focus on adding new cool features.

https://www.codetriage.com/

Here is a useful reference for bash shortcuts:

https://www.skorks.com/2009/09/bash-shortcuts-for-maximum-productivity/