Comment Even a Geek Can Speak (Score 1) 153
Joey Asher also wrote "Even a Geek Can Speak" - a book I give to just about anyone starting out giving presentations. This book looks just as awesome - can't wait to pick it up!
Joey Asher also wrote "Even a Geek Can Speak" - a book I give to just about anyone starting out giving presentations. This book looks just as awesome - can't wait to pick it up!
This was my thought as well. The analysis was wrong ("They have weapons! He has an RPG! Several AK-47s!") and that's a mistake which shows the need for better analysis. I mean, the guy did appear to have an RPG to me before they opened fire, but it didn't look like he was pointing it at any of them.
Far worse was the decision not to evacuate the kids. I mean, the soldiers on the ground had a much better view of what was going on, and to deny that was a travesty. And the cover-up makes it all that much worse.
In general, I see this as bad intelligence leading to a unfortunate call by soldiers looking to keep themselves safe. That doesn't excuse what happened by the commanders by any means. But I can't image being in that pilot's seat. Or the ground soldier when they made the call not to evacuate the kids.
Besides, if you really wanted to block them, wouldn't one just block the Googlebot? Or nofollow the entire site? Or robots.txt the entire site?
What they really want is to be in the top of the search results without having to have the stuff out there. You can't have it both ways.
The point is that
Of course, they could just have him not have it some of the times, or put it in the motorcade when he isn't, etc, etc. I'd imagine that you could use some of the attacks mentioned in the article to foil the above scenario even without the president having a BB. For example, if you know which phones are SS phones, and suddenly 5 or 6 are *way* away from the "motorcade" you might suspect something is up.
For the US, I'd imagine it not being too big of an issue - but the point with him being in foreign countries is pretty important.
(Notice: I'm the reviewer)
iDang it. iI'm iSorry. iI iGot iToo iCaught iUp iIn iIing iEverything.
- iCory
Basically what I was thinking as well. I did it while I was on a conference call, and was disappointed to see that this was all there was to it. I figured at the very least that it was just a first-level and the real puzzle would be on the site. Oh well.
And the article is not by Jim Shore, who wrote the linked article at the bottom of the summary. TYPO TYPO TYPO
With the above list given in order of importance. Really this breaks out to "Runs all the Tests" and "Refactoring" or making the code better. Simple design is perhaps one of the harder things out there, and yet the most important. When you look at systems that highly scale, it's because they are made up of simply designed components which work very well together.
After the Emergent Design chapter there is suddenly a chapter on Concurrency. This was not something I expected to see, but was very glad to. Too many times books about patterns and design don't address problems like scaling and concurrency. But this chapter does a great job of introducing the necessary steps that need to be taken to deal with concurrency — while still keeping your code clean. The book also provides an appendix which goes even deeper into the concurrency topic which I found to be quite good. Both this chapter and the appendix provide some very valuable rules that I personally have used when writing concurrent systems — like "Get your nonthreaded code working first" and "Run with more threads than processors" to flush out problems.
Chapters 14-16 cover the cleaning up of three different sections of code — an argument processor, JUnit and SerialDate, which is part of the org.jfree package. These chapters really hold true to the warning in the introduction that we'd be going through some code. However, the refinements work very well, and I think that each of them show the value of how much cleaning up the code can improve the readability of even code that works well and seems clean.
The last chapter is a "Smells and Heuristics" chapter which I'm finding to be a handy reference guide for code smells I see. When something is bothering me with code I'm reading, I flip to this section first to see if they have it listed. And with things like "Replace Magic Numbers with Named Constants" you can be sure that all of the advice that should have been beaten into your head long ago is still there, and relevant.
All in all I think this is a very valuable book for any developer wanting to improve how they write code. For senior level people, some things may seem trivial, but if you really take the time to look at the structural changes being made and apply them, you will write better code. For functional developers — the authors believe in OO, but there are still valuable nuggets that are applicable outside of that (like "Use Copies of Data" in the concurrency section). And for any developer, the insights are really good, and you'll find yourself writing down little snippets to hang on the wall.
The challenges with the book are first that it is just as they said — hard work. This is not a flip-through-with-your-mind-shut-off type book. If you want the most out of it, you have to be willing to really work at it. The other challenges are that at times it gets way too Java-centric. All of the code examples being in Java is fine, but some of the chapters (most notably the Systems chapter) really go heavy into Java tools and the Java way which, to me, weren't always applicable across languages.
All in all, I'd highly recommend this book to anyone wanting to improve how they write code. You likely will find yourself violently disagreeing with parts, but the total sum more than makes up for it."
"Ninety percent of baseball is half mental." -- Yogi Berra