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.