Was there something special about OS/2 that suggested it would be the winner of this war or did WP and Lotus just make the same bad bet at the same time?
I'm not seeing a smoking gun here and the thread looks very reasonable. I see nothing related to "growth" so maybe link to something that actually backs up your assertion?
I'm not a huge fan of this question. I've been programming for 20 years (professionally for 13). Is the hardest problem some noddy maths i worked out at 15 to convert real coordinates to screen coordinates? Is it the first app i wrote out of college when i learned that servlets aren't thread safe? Is it what i worked on last year to design my current company's authentication/authorization system?
I find it very hard to interpolate between these examples. And none of them are "hard"! I haven't written an OS or a more efficient linked list. All I've done is plugged away at something until it works.
Anything less than O(n) obviously means not needing to look at every element of the input, i.e. it's already sorted or similar. For most other interview problems that seems like a reasonable lower bound in the absence of more detailed analysis. I guess the recruiter's advice to go practice on TopCoder wasn't just copy-paste.
So. Having just messed up an interview at a large tech company by having trouble deriving an O(n) solution on the whiteboard, anyone got any good tips on how to take algorithms / data structures to the next level and look good at this sort of thing?
I always thought the point was that he spots a ... tattoo? Of a snake? That reminds him of the club? Or the dancer... I'm going to have to watch it again aren't I?
This seems similar to michaelochurch's thinking about 'guilds' - which I guess is a precursor to formalised 'engineers' or master craftsmen, which is something Software 'Engineering' seems to be in dire need of.
Thanks, that was fun and not as tricky as the blank grid initially made it appear! And the implementation was nice (although a little twitchy if you rotate twice quickly).
I agree with the author that the Single Responsibility Principle is being violated with all these annotations, but I disagree that the resolution is to move the annotations into hbm.xml files (or similar).
I would, in the limited example given, prefer to have a 'storage' POJO (annotated with the hibernate annotations), and an 'API' POJO (annotated with the JSON and XML perhaps).
Then it seems to make sense that if you're changing the underlying storage you would update the storage POJO.
I very rarely want to return the exact object as stored in my database to the API layer - there's business logic and the like that needs to be applied, and transforming the object into something the next layer requires means you can generally implement tighter interfaces.