Quote of the day
“BUT WHO NEEDS SETTINGS WHEN YOU CAN EDIT THE SOURCE?”
Reason to serialVersionUID your serializable classes
Quoting Eclipse FAQ: “When classes compiled in Eclipse are written to an object stream, you may not be able to read them back in a program that was compiled elsewhere. Many people blame this on the Eclipse compiler, assuming that it is somehow not conforming properly to spec. In fact, this can be a problem between any two compilers or even two versions of a compiler provided by the same vendor. If you need object serialization, the only way to be safe is to explicitly define the serialVersionUID in your code! /…/ Bottom line: Always define the serialVersionUID explicitly in your source files.”
My question is: can there be an audit to automatically detect source files where you explicitly defined serialVersionUID that is out of date? A nice-to-have addition would be a quick-fix for repairing serialVersionUID. Current eclipse quick-fix supports only generating serialVersionUID from scratch.
Eclipse Summit Europe 2006
11-12 October, Esslingen, Germany
The Eclipse Foundation is pleased to announce Eclipse Summit Europe, the Foundation’s inaugural European conference for the Eclipse community. The purpose is
- to generate interest and deepen understanding in the consumer community
- to generate feedback and ideas for contributions to eclipse
- to promote opportunities within the Eclipse community for contributions in several forms: membership, collaboration, investment/sponsoring new projects
- to create opportunities for collaboration among industry, education and research and individuals
- to create synergies among the public program, council meetings and membership meetings
Cost of Full Conference Attendee is €270EUR or $350USD.
Call for papers is now open!
More info on Eclipse Summit Europe 2006
Code without automated tests is like using bricks without cement
Just today morning in Tallinn a whole wall of a brand-new building just fell down!
Update: The building was not new and it fell because there is a road reconstruction very nearby.
This made me think that automated unit-tests can save at least your soul.
As soon as there is a bit more complex code to be programmed it’s very tempting to get it first working without using the glue or cement to nail down the foundations of the code.
By cement I mean automated tests, of course.
The implementation you write is only a set of bricks. Which can be used to build a wall, of course.
To really keep them together and ensure that they STAY together, you need to write tests.
Phuuh!
Let the Sun Shine and Tests Run!
Your plan is worthless without The Impulse
I’ve never before experienced how important is impulse on any kind of plan execution. I might have a perfect plan and it’s like an engine. And that’s it!
Having an impulse to start something is like a starter that puts your engine running.
How many times have you thought that “this is the last time I’m going to tolerate this” or “next time it happens again then I’ll do this” or “now that’s it, I’ll do it”! You are always waiting for such impulses to execute your plans. Subconsciously you’re trying to find out your impulse instead of just doing whatever you planned at the first place. This kind of subconscious reasoning is often not working as it encourages you not to take action now but somewhere in future.
Any kind of calculated plan is useless until you find the impulse to unleash the power behind plan. What’s most surprising is that the impulse is not often tightly related to your plan. It just attacks you from an unexpected angle.
What I learnt from this is that whenever there is a plan to execute you can always try to find an impulse to give it a real kick.
You can always start your plans without impulse but then you’ll never have that much power and energy compared to having a real event that forces you to take action.
May the Force be with you!
UPDATE! This post is not motivated by having trouble with always postponing the plans :) Quite opposite but more details later!
