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.

GWT RequestFactory network retry project

I've just been allowed to make a module from my day job FOSS.

https://github.com/salk31/gwt-rf-queue

With any luck it will get picked up by the community.

Big bang replacement of existing business system

1. Don't.
2. Almost certainly underestimated the complexity of the system you want to replace.
3. The users have learnt to live with the existing system.
4. The existing system includes endless Excel and Access things the users have knocked up and love.
5. The existing system will improve while you work on the shiny new replacement.
6. Building a new system from the ground up is exhausting.
7. Near impossible to manage user and management expectations of the new shiny system.

SCRUM/Agile

Great article here:
http://agile.dzone.com/articles/7-agile-best-practices-you

I've not enjoyed doing SCRUM on a greenfield project with a large set of fixed minimum requirements... Seems very unsuitable.

One great thing from SCRUM has been the sprint reviews where we decide things to try. Geeks are particularly bad at worrying to much.

RedRobot 0.2.13 released

http://code.google.com/p/redrobot/ 0.2.13 just released. Upgraded to use WebDriver 2.30.0 and an experimental listener API.

Developer stereotypes

Young hacker - quickly and accurately writes huge swathes of code that works but nobody else can understand or fiddle with. Unit tests etc are an annoyance that just slow them down.

Puzzler - sees writing code as a series of puzzles to solve. How you solve them and what happens after that is not important. Once you have finished the "crossword" just move on.

Old hacker - slow and inaccurate but knows a lot of paths to ignore and needs unit tests to support the weight of their own code. Tendency to be grumpy as they have discussed X too many times already.

By the book - if it is not in a book then it is _wrong_! Don't bother trying to debate anything with them as only the book can explain it properly. Have you read the book!?

Tidy - doesn't really care what the code does or how it behaves but has a compulsion to re-write everything in a tidy way. Big danger is that they will happily spend months re-writing something just so it follows how they think it should be done.

Fiddle till it works - has no real clue what is going on but if they mess with something long enough it will eventually do roughly what is needed. Not worth trying to get them to tidy it up. It took them days to get it working and they are not prepared to mess with it again.

Demo of our SQL Query Builder widget

http://redquerybuilder.appspot.com/

Pure JavaScript and easy to connect to jQuery, GWT etc

Just feed it meta data and off it goes.

Brutally simple deployment has advantages

"one of the main reasons why operations stop and restart processes in applying a managed change – to be sure the process can indeed be restarted"

http://williamlouth.wordpress.com/2009/07/03/jazoon-%E2%80%9809-the-conference/

Eclipse CTRL+SHIFT+t

On a class name will show you which "file" that class is coming from. Thanks to Virender!

Common management diseases

Noticed these three recently:

• Incapacitated by worrying about long distant problems - this sort of manager when asked a question will fail to solve the simple problem we have now because of pondering how it would be solved if we were 100 times bigger than we are now. So when asked who should have the final word on certain issues the manager responds with a lecture on the problems of organisations like IBM and Google managing architectural decisions... There are only ten of us!?
• Bored by their real job - this manager will neglect the work they are meant to be getting on with and put huge amounts of energy into a daily series of fads.
• Blinded by glitter - a manager that doesn't real know what is going on is totally blinded by the buzzword compliant and the "bored by their real job" people. The plain speaking guy that is not constantly coming up with wiz bang projects is of no interest and the manager can't spot who is actually doing useful work.

Yep. I'm bitter.

Advantage to meta data not hanging off RDBMS meta data

Is still denormalisation but one big advantage of not just augmenting the database meta data is that you can describe types without needing actual database tables. It is still re-inventing the wheel but it is hard to sell having lots of tables in the database even though the database is very able to cope. Tooling may struggle opening 1000s of tables in the UI.

e.g. You want to describe a model and user interface but never want to collect the data in a table. So you want the model definition but no need for the actual table (if not using the meta data).

I think I'd still vote for using real tables but would need to test that all parts of the database and tooling can cope.

Project management notes to self

1. Panic early. Reduce features and complexity early, you can always add them later. Better than having to drop them at the last minute.
2. Clear roles and responsibilities - obvious but doesn't always happen. Who do I have to ask to get X approved...
3. Before you say no to an idea make sure you have an alternative to propose -
4. Don't fiddle with time estimates just because they are inconvenient.
5. Don't isolate yourself from critical voices.

Google Web Toolkit Blog: Look ma, no plugin!

Still not sure if a hoax.

Many months on I'm still not sure if GWT Quake is real. Looks like too much of a pig to get running to find out for real.Already my pointy haired boss has got the wrong end of the stick and thinks GWT is all about making a website look pretty.

Composition for happy ORM?

None of the polymorphic mapping strategies for ORM seem to work very well.

• Table per class hierarchy - Is too evil to mention.
• Table per class - Very similar to composition?
• Table per concrete class - Makes queries and FKs painful.

Composition seems to map nicely to relational databases. Also in the real world composition can model the world nicely.