The Economist, the culture that is Google
Least likely to happen though
Google bought out by Microsoft?
The Future: *Chinese outsourcing co.* outbids *Indian solutions provider* for large chunks of dev. work with *major search engine* company.
Fill in the Blanks! 🙂
My Bicycling future is doomed, the sun set at 5:00pm today. 🙂
Apart from moping about the inability to ride a man-powered contraption on two wheels with a rudimentary arrangement for illumination of direction.
I feel my commitment peaked today, ironically only a short period of time before I am about to lose it. The feeling of ownership of a REALLY long-term project alongwith a seasoned crew sailing alongside you. Hard work, aye, paid off? aye aye, mate!! Unfortunately, land has been sighted, I am to get off at the next port. Just when I felt it was my boat too. Arrr thats what we all live for mate, a sense of belonging.
Breathe In The Air Lyrics
The Dark Side Of The Moon
Breathe, breathe in the air.
Don’t be afraid to care.
Leave but don’t leave me.
Look around and choose your own ground.
Long you live and high you fly
And smiles you’ll give and tears you’ll cry
And all you touch and all you see
Is all your life will ever be.
Run, rabbit run.
Dig that hole, forget the sun,
And when at last the work is done
Don’t sit down it’s time to dig another one.
For long you live and high you fly
But only if you ride the tide
And balanced on the biggest wave
You race towards an early grave.
Not that this has not been noted before, assuming we design a cone-like system, where the tip is where we have logic to hinge sub-systems and drive the system, reusability is the lowest there at that tip. This of course is what a good design is aiming at. To move the 90%-99% of the work into sub-systems, keep 1-10% of the work at the tip. Eventually, that gives your code a label of 90%-99% reusable or atleast easily replaced.
Abstract that further, break the problem up into n parts. Going by the theory presented by Dijkstra, it is now that much easier to get each of the sub-parts of the problem right 100%. Now, apply our Cone system to each of the sub-parts.
Avoid the overhead of each division by confirming to specifications. You now have a system that is much larger and still obeys the cone-reuse rule above. The failure of design occurs in a case where you introduce coupling between divisions increasing the non-reusability of your system to > 10%? My argument is flawed iff reusability does no require each and every sub-component to be reusable (ie. I am arguing for finer granularity).
I think I have drifted into hybrid territory here (functional versus data driven architecture). This is since we now observe a tree like pattern forming all over again. This is usually seen in functional systems, but can the converse be true too?
Note that Dijkstra also warns that the probability of solving the problem approaches zero as the number of sub-divisions to the problem increases, he never stated that it will grow. In fact, the probability of solving the problem is 100% if you take the whole problem and you can guarantee that that monolith solution will work (which is the tough part in the first place).
Breadth is always better in any solution.
Soft References to cirumvent HashMap problems
Jack Shirazi’s page on Java Performance Tuning