Mac : Windows :: iOS : Android ?

In the late 70s and the early 80s Apple computers were the coolest devices around and everyone wanted to have one, and then Windows came along firstly with IBM PCs and then with IBM PC clones, i.e. Windows worked on hardware sold by most manufactures.

Now in 2010, iPhone is the coolest device out there and everyone wants to have one, but Android has come along which works on hardware sold by a number of manufactures.

Is history repeating itself?

The Executive Dashboard 2010

This is the Executive Dashboard as presented at IBM Rational Innovate 2010. This looks to be quite a bit more sophisticated than last year.

Printpoints : Debugging by writing to console

There are two ways of debugging

• Breakpoints - I typically use breakpoints when
• I do not have much idea of the code and need to inspect variables and expressions at a number of places to gain an understanding of what is happening.
• I am making some changes and want to see how these changes affect a particular variable/expression, also I am confident that one or two iterations of this change-test process will suffice

• Printpoints - There are scenarios when the breakpoints fail or are inefficient, in these cases I just use System.out.println(). This is typically when
• the breakpoint hits too often, for example keypress, focus, mouse events
• I want to see the order of thread execution
• I am making some changes and want to see how these changes affect a 'few' variables/expressions, also I am confident that it will take 'a number' of iterations of this change-test process to fix the bug. Printing everything to console in this case proves to be much more efficient than stepping through the code.
  

Most developers (including me till recently) insert the print statements in their code and the problem with that is that you have to take them out later. I know you can sometimes leave them in the source as tracing statements, but most of the time they have to be taken out. But there is a solution...

The conditional breakpoint editor in Eclipse can be 'tricked' to create what I like to call as Printpoint - and define as a 'point' in code where the debugger does not 'break' but only 'prints' to console. Essentially a Printpoint is a conditional breakpoint that never suspends execution but only prints to console. To set a printpoint, set a conditional breakpoint with Suspend when 'true' option and a condition which is always false. e.g.

Code templates are available in the condition editor, so you can create a template under 'Java statements' context and use it here. Bug 315404 has been filed to have this available in JDT by default.