Joy of GC

https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.p8ue0zumc

GWT 3.0 migration

A quick list to try and help me keep track of information about the move to GWT 3.0. Corrections/ideas are welcome.

• JSNI - GONE - replace the JsInterop.
• Widgets - GONE - somebody could port?
• GWT.create - GONE - use annotation based code generation etc.
• RequestFactory - ? depends on GWT.create
• Editor framework - ? depends on GWT.create
• UiBinder - ? depends on GWT.create and Widgets?
• GWT RPC - ?
• Permutations - GONE - use system properties (early enough for compiler/linker to cut out code)
• Standard Dev Mode - GONE - debug in "translated"/transpiled JavaScript.
• SafeHtml - ?
• JUnit (Java) - GONE?
• JUnit (transpiled) - ?
• Activities/Places - ?

Third party code:

• GIN - https://github.com/google/dagger/pull/119 ? - Depends on GWT.create

RedQueryBuilder 0.7.0 released

http://redquerybuilder.appspot.com/ version 0.7.0 is released today with support for Number data type, fixes for IE11 and a few bug fixes.

Bit of a boring release while we are working on a big feature to support more flexible error reporting and custom serialisation.

Maven versions and feature branches

It doesn't seem that maven really supports feature branches. The version should be number.number.number-qualifier. If you want to use SNAPSHOT then the qualifier has to be exactly that.

All our artifacts are for a single webapp so we don't need to share articfacts. Given that the simplest thing seems to be to just use the version of the branch that the feature branch is tracking. e.g. if tracking master, and master is 1.2.3-SNAPSHOT, then that would be the version of the feature branch. Apart from SNAPSHOT working correctly it means that merging is less hassle.

If sharing artifacts within an organisation then something more elaborate like https://github.com/gary-rowe/MultiBitMerchant/wiki/Branching-Strategy might be needed.

Pipeline for web app development projects

One way that seems to work is to have a pipeline constructed as:

1. Requirements team go out to the customer/organisation to try and get decisions on what problems actually need to be solved and any fixed requirements/specification.
2. Once the requirements are firmed up the QA and developer join. The QA to understand the nature of the problem and record how to test if the problem is solved. The developer to understand the problem and start thinking about possible solutions.
3. QA/Dev can raise questions to requirements team to clarify specification (if required).
4. Once QA/Dev understood the requirements, QA then will write final acceptance criteria (to test if the problem is solved)
5. The problem can only enter a sprint when the QA and developer agree that it is ready to start.
6. Within the sprint the developer and QA negotiate an acceptable solution. The customer must be kept informed of changes.

At all stages any agreements with the customer must be record in the bug database.

monit

Saw lots of posts about horrible little shell scripts or full blown enterprise solutions but: http://mmonit.com/monit/ seems to work nicely for one or two boxes.

The good from latest agile project

• Sprint retrospectives are great in time boxing ongoing discussions and a good time to stop and think (as the name suggests).
• Good to limit fiddling with the process to once per sprint.

Some warnings:

• Users/customer will sit happily in sprint review meetings nodding BUT come the release they will really start thinking. The review meeting is no replacement for user testing. Really need to make the users use the app.