I recently read 'What Just Happened', by James Gleick. I'm a big fan of his--I read 'Chaos' years ago. This book covered the history of chaos theory; I was engrossed by the fluid writing and deft handling of such a tough subject.
'What Just Happened' is not such a book--rather than a coherent look at recent history, this book is a collection of stories spanning that time (from 1992 to 2001). From spam to bugs to online pornography to passwords to email forwards, Mr Gleick covers a number of issues that are still relevant for us today. I will say that the number of forwards I've gotten since I left college has fallen dramatically, but the amount of spam has not. The internet still 'makes it all too easy to fling random illiterate drivel across the planet'.
There are also a number of neat historic references. There is a five page article about Y2K, written in Jan of 1999, where Mr Gleick was already saying that we had nothing to worry about come 1/1/2000. Another suggests ways to 'make Microsoft for capitalism', written just around the release of Windows 95. Remember when we thought we could count on the US government to deal with monopolists?
On a personal note, I have to link to Zia Consulting, because one of their principals was mentioned in this book; you could apparently page Bindu Wavell over the Internet in December 1995.
The format of this book makes it a nice bus read. None of the articles are longer than forty pages and many are a good deal shorter. Whether you nod your head in agreement with some of the issues covered that are still present, or are wistfully transported back to the days when you were still interested in checking the status of a Coke machine over the Internet, this book has its moments. If you enjoy pop tech at all, or if you've been caught up in the wave the Internet has created over the past 15 years, chances are you'll enjoy this book.
I just discovered wikibooks. They look pretty cool, will be interesting to see if they succeed like Wikipedia or fall by the wayside like many other wikis (Bruce Eckel has some comments on this phenomenon). Of particular interest to me is the J2ME wikibook.
Here's a very interesting interview with one of the authors of "The Enthusiastic Employee".
If you've seen 'Meet the Fockers,' you probably remember the scene where Greg's parents have constructed a shrine to him, full of 8th place medals and the odd 10th place ribbon. Greg apparently didn't do too well in competition, but his parents loved him anyway. Not everyone is so forgiving, and most people had competition. To rephrase that, most people hate losing at competition--winning is just fine, thank you very much. In a free market system as well, most firms and people don't like competition--it forces firms to respond to customers and people to work harder. However, the overall benefits to society are larger in a system where everything is competitive.
Saving Capitalism from the Capitalists, by Rashuram Rajan and Luigi Zingales, examines competition from an academic perspective, choosing to focus on financial markets. As you'd expect from two economics professors, they argue that markets are the most powerful economic invention of all time, and the solution to many problems facing us today is to make them more prevalent. However, the central thesis of their book is that markets depend on governments for vital infrastructure (rule of law, contracts, etc) and thus depend on politics. Because of the nature of politics the interests of a focused few can outweigh the interests of a diffuse many. This means that government regulation of markets can be easily hijacked by those with disliking competition to smother it.
The authors examine many cases where this hijacking occurred, from developed and developing countries and many different time periods. They focus on finance because free flow of capital has a magnifying effect on competition since upstart produces of goods often need capital. The focus is on incumbent firms, who are usually the party with the will and ability to influence the government to put the needs of the few over the needs of the many.
Other issues they tackle include the emergence of financial markets, whether finance benefits the rich disproportinately, and how the free markets of the early 20th century were rolled back in the 1930s and what replaced them.
Well written, if dense, this book would have been average had the last chapter, which proposes solutions to the political vulnerabilty of markets, been omitted. However, with their proposed solutions, which build on the foundation that they laid out in previous chapters, I feel that this book is a useful read for anyone interested in knowing how the world works and might work better. In addition, I think it's wise and brave of them to trumpet that current markets aren't really free but instead are usually hijacked by powerful incumbent firms. This is something that you don't hear economists acknowledge often enough.
I just finished The Beast In the Garden: A Modern Parable of Man and Nature by David Baron. This non-fiction book is a quick read and outlines the comeback of the mountain lion, or cougar, along the Front Range, during the late 1980s to early 1990s. The cougar had been nearly wiped out by government bounties in the early part of the twentieth century, but the explosion of deer along the Front Range, along with revocation of that bounty, led to a comeback. In parts of the Denver metro area, mountain lions came to co-exist with human beings. This was especially true in Boulder, where the nature loving Boulderites assured a plentiful meat supply when they wouldn't cull deer herds. The mountain lions grow familiar with human habits, learn that humans don't mean danger, and end up mauling a high school student.
I really enjoyed the way the events were outlined, and Baron does a good job of making sure the science and character development are well balanced. He follows a few of the key players for the entire time, while bringing in other interesting characters, like the cougar hunter, as they appear. The science seems reasonable to me, though I haven't taken a biology class since high school: large animals don't have a natural aversion to humanity. Rather, this is a learned trait passed from generation to generation. Remove the killing that caused the aversion, and the animals will become more and more comfortable around humanity, to the point of considering humans a food source.
In the larger sense, though, this book is about managing wilderness, and realizing that as soon as you put a house up in a forest, you've changed the stakes. Humans love being around nature, but bleat for help as soon as nature threatens. In some ways, we want a Disneyland version of the forest--all of the beauty with none of the danger. You see this all the time with folks who build around national forest; as soon as fires season comes, they need to be protected. This is a thorny problem, and answers aren't simple. The Beast In the Garden really is a parable, and I'm not sure we've learned the lessons.
There's a a fascinating chapter of Java Programming with Oracle JDBC available online. What I find most interesting is that (as of 2001), the thin driver is good enough to use everywhere--in fact, in most cases outlined above, it outperforms the OCI (type 2) driver. In addition, typically it takes 10s of repeated calls to a given PreparedStatement to make using the PreparedStatement faster than a regular Statement.
I'm always on the lookout for interesting content on the internet. I just stumbled across Free as in Freedom, an account of Richard Stallman, which is published under the umbrella of the Open Books Project.
If you have a chance to read Dancing With Cats by Burton Silver and Heather Busch, don't bother. However, pick it up and glance through the photos. For it's in the pictures, of cats and humans cavorting, of almost impossibly resonant images, that this book shines. (Visit the Museum of Non Primate Art for more.) The text is a bit much, using words like 'aura' and negative energy, and apparently meaning it. But, if you like cats and have a sense of the absurd, oh the pictures--check it on Amazon.com. I chuckled and chortled through the entire book.
Deadly feasts: tracking the secrets of a terrifying new plague, by Richard Rhodes, is one scary book. It tracks the discovery of prions, the mishapen proteins responsible for mad cow disease, scrapie, and Creutzfeldt Jacob disease. Following human cannibals in the jungles of New Guinea in the fifties, bovine cannibals of the British Isles in the eighties, and the bizarre history of sheep scrapie from the 17th century on, Rhodes does a great job of presenting the history and discovery of this bizarre group of diseases. I especially enjoyed the characterizations of the scientists, from the Noble Laureate who so enjoyed the New Guinea that he often regretted rejoining civiliziation, yet brought thirty natives back to the USA and helped them through school, to the hyper-competitive scientist who named the molecules even though he wasn't quite certain what they were.
But this isn't just a story of scientific discovery. As the foreboding subtitle blares, Rhodes explores some of the scarier aspects of prions. These include spontaneous formation, responsible for the known early cases of Creutzfeldt Jacob disease, trans-species infection, including mad cow disease and scrapie, the long long incubation period and lack of immune system response, and hardiness of the disease. One scary factoid: a scientist took a sample of scrapie, froze it, baked it for an hour at 360 degrees (celsius), and was able to re-infect other animals from this sample.
For all the uneasiness this book inspires, it certainly doesn't offer any answers. A condemnation of industrial agriculture, a warning that it's unknown whether vegetarians are even safe, and a caution against using bone meal for your flower garden do not make a recipe for handling this issue. To be fair, it was printed in 1997--perhaps things are under control now.
Since many financial institutions have standardized on it, I hear Java is the new COBOL. Whether or not this is true, if Java is to become the business language of choice, transaction support is crucial. (By 'transaction,' I mean 'allowing two or more decisions to me made under ACID constraints: atomically, consistently, (as) in isolation and durably'.) Over the last five ears, the Java platform has grown by leaps and bounds, not least in this area.
Java Transaction Processing by Mark Little, Jon Maron and Greg Pavlik, explores transactions and their relationship with the Java language and libraries. Starting with basic concepts of transactions, both local and distributed, including the roles of participant and coordinator, and the idea of transaction context, the book covers much old but useful ground. Then, by covering the Java Transaction API (JTA) as well as OTS, the OMG's transaction API which is JTA's foundation, this book provides a solid understanding of the complexities of transactions for Java programmers who haven't dealt with anything more complex than a single RDBMS. I'd say these complexities could be summed up simply: failures happen; how can you deal with them reliably and quickly?
The book then goes on to examine transactions and the part they play in major J2EE APIs: Java Database Connectivity (JDBC), Java Message Service (JMS), Enterprise Java Beans (EJB) and J2EE Connector Architecture (JCA). These chapters were interesting overviews of these technologies, and would be sufficient to begin programming in them. However, they are complex, and a single chapter certainly can't do justice to any of the APIs. If you're new to them, expect to buy another book.
In the last section, the authors discuss the future of transactions, especially long running activities (the Java Activity Service) and web services. This was the most interesting section to me, but also is the most likely to age poorly. These technologies are all still under development; the basic concepts, however, seem likely to remain useful for some time. And, if you need to decide on a web service transaction API yesterday, don't build your own, read chapter 10.
There were some things I didn't like about Java Transaction Processing. Some of the editing was sloppy—periods or words missing. This wasn't too big a problem for me, since the publisher provided me a free copy for review, but if I were paying list price ($50) I'd be a bit miffed. A larger annoyance was incorrect UML and Java code snippets. Again, the meaning can be figured out from the text, but it's a bit frustrating. Finally, while the authors raise some very valid points about trusting, or not, the transaction system software provider, I felt the constant trumpeting of HP and Arjuna technologies was a bit tedious. Perhaps these companies are on the forefront of Java transactions (possible); perhaps the authors are most familiar with the products of these companies (looking at the biographies, this is likely). The warnings—find out who is writing the transaction software, which is probably at the heart of your business, and how often they've written such software before—were useful, if a bit repetitive.
That said, this book was still a good read, if a bit long (~360 pages). I think that Java Transaction Processing would be especially useful for an enterprise architect looking to leverage existing (expensive) transactional systems with more modern technology, and trying to see how Java and its myriad APIs fit into the mix. (This is what I imagine, because I'm not an enterprise architect.) I also think this book would be useful to DBAs; knowing about the Java APIs and how they deal with transactions would definitely help a DBA discuss software issues with a typical Java developer.
To me, an average Java developer, the first section of the book was the most useful. While transactions are fairly simple to explain (consider the canonical bank account example), this section illuminated complexities I'd not even thought of—optimizations, heuristic outcomes, failure recovery. These issues occur even in fairly simple setups—I'm working at a client who wants to update two databases with different views of the same information, but make sure that both are updated or neither; this seems to be a typical distributed transaction. The easiest way to deal with this is to pretend that such updates will always be successful, and then accept small discrepancies. That's fine with click-throughs—money is a different matter.
However, if you are a typical web developer, I'm not sure this book is worth the price. I would borrow it from your company's enterprise architect, as reading it will make you a better programmer (as well as giving you a sense of history—transactions have been around for a long time). But, after digesting fundamental distributed transaction concepts, I won't be referencing this book anytime soon, since the scenarios simply don't happen that often (and when they do, they're often ignored, as outlined above).
Divorce Your Car, by Katie Alvord, is thought provoking. In the United States of America, an automobile is many things to many people: transportation, status symbol, hobby, money pit. Alvord takes apart the place of the car in modern society (the focus of the book is on North America, though she does refer to Europe and the Third World in places) and roundly condemns our dependence.
Her book is split into three parts--the first covers the history of the automobile and other forms of transport. She legitimizes what I'd often heard and dismissed as a myth--the car industry bought up the transit systems of cities in the US early in the 20th century and replaced them with buses. The second is a laundry list of the negative effects of the car (which, I must confess, I didn't finish--too depressed after the first thirty pages). The final section covers alternatives, including walking, biking, mass transit, non-gasoline cars, and telecommuting.
I found the book to be quite good in outlining the problem and highlighting solutions. The dependence of modern life on the car is a dependence on convenience. But, to some extent, it's a matter of inertia. Automobiles are so prevalent and easy that many of us never try the alternatives, let alone use them in preference to our car. A strong point is that she realizes that car-free living isn't for anyone, and makes a point that going car-lite can have a positive effect as well. She also touches on the far reaching implications that technology decisions have had on our society, our cities and our lives--from subsidies to the development of advertising. It would have been interesting to read more about that, but what she did say was definitely thought provoking.
However, I do have three quibbles. Alvord cites sources extensively, but her arguments would be more compelling were the sources less biased (as you can tell by titles like Asphalt Nation) and more first hand. She ignores two factors that would affect my divorce. Giving up your car, or at the very least being aware of alternatives, makes drunk driving less likely--a good thing! On the other hand, if you don't have a car, you suddenly have a dearth of available camping and hiking activities. But these concerns aren't everyone's, to be sure.
Overall, a book well worth reading, especially if you commute a lot. Too bad they don't sell it as a book on tape!
How to Lie with Statistics, by Darrel Huff, should be required reading for everyone. The cachet of numbers are used all the time in modern society. Usually to end arguments--after all, who can argue with "facts"? Huff shows how the same set of numbers can be tweaked to show three different outcomes, depending on where you start and what you use. The fundamental lesson I learned from this book is that mathematical calculation involves a whole set of conditions, and any number derived from such a calculation is meaningless without understanding those conditions.
He also mentions that colleagues have told him that the flurry of meaningless statistics is due to incompetence--he dispatches this argument with a simple query: "Why, then, do the numbers almost always favor the person quoting them?" Huff also provides five questions (not unlike the five d's of dodgeball) for readers to ask, when confronted with a statistic:
1. Who says so?
2. How does he know?
3. What's missing?
4. Did somebody change the subject?
5. Does it make sense?
All this is wrapped up in a book with simple examples (no math beyond arithmetic, really) and quaint 1950s prose. In addition humor runs from the beginning (the dedication is "To my wife with good reason") to the end (on page 135, Huff says "Almost anybody can claim to be first in something if he is not too particular what it is"). This book is well worth a couple hours of your time.
The Great Divide, by Stephen Pern, explores one man's trip from Mexico to Canada along the Continental Divide. Now, this book explores the backbone of the USA, but the author is definitely (perhaps defiantly) English--and in many ways, from his frequent stops for tea to his sardonic wit to his idioms (biro, peg), it adds to the charm of the book. From New Mexico to Montana, Pern relates the obstacles, emotional, physical and personal, which confront him during his journey. Typically tongue-in-cheek in his prose, he also strikes true notes, especially when commenting on life in America. He lays out a succinct contrast between the New World and the Old: when confronting the lack of historic artifacts on his jounry, he muses "Life [in America] was first established, then lived. Back home [in Europe], it was the other way around."
The logistics of supplying his 2500 mile journey were worth the read alone--his description of peanut butter rationing chimes with anyone who has backpacked with luxury foods. He also includes an appendix with much information, including suggested maps, useful equipment and obstacles encountered. should you wish to follow in his footsteps. In 1986, when he wrote the book, there was no Continental Divide Trail, although it looks like Congess designated a (still incomplete) route in 1978. Pern is also very clear when he diverges from the Divide, providing maps with small comments and textual explanations of his detours. Many of these are for good reasons--bad terrain, a hot shower, a resupply mission.
But the most interesting sections of this book was not the physical exertion nor the beauty that he described (though a picture section would have been a fantastic addition). No, in the tradition of Least Heat Moon's 'Blue Highways' and Bryson's 'In A Sunburned Country,' it is his interactions that really lend depth and meaning to his book. Whether it's the innumerable breakfasts fixed for him, a surly shopkeeper in Montana, or a Navajo shepherd who can't speak English and doesn't understand the lifestyle of her grandchildren, Pern takes each encounter and uses it to reflect a bit of the American psyche.
All in all, this book was inspiring and well worth a read.
I just finished reading The Social Life of Information, by John Seeley Brown and Paul Duguid. This was not the quickest read; it's a business book with the obtuseness of vocabulary that implies. However, if you're a computer person with any desire to see your work in a larger context, this is a book you should read. In it, they examine eight separate areas in which computers, and the internet in particular, have supposedly changed our lives (this is typically called 'hype', though the authors don't use the word) in the latter years of the 20th century. (This book is copyright 2000.) You probably remember some of these claims: the death of the corporation, of the university, of paper documents, of the corporate office. In each chapter, they review one claim, show how the claim's proponents over-simplify the issue, and look at the (new and old) responses of people and institutions to the problem that the claim was trying to solve. They also examine, in detail, the ways in which humans process information, and how the software that is often touted as a replacement simply isn't.
I really enjoy 'ah-ha' moments; these are times where I look back at my experiences in a new light, thanks to a theory that justifies or explains something that I didn't understand. For example, I remember when I started my first professional job, right out of college, I thought the whole point of work was to, well, work. So I sat in my cube and worked 8 solid hours a day. After a few months, when I still didn't know anyone at the office, but had to ask someone how to modify a script I was working on, I learned the value of social interaction at the office. (Actually, I was so clueless, I had to ask someone to find the appropriate someone to ask.) While examining the concept of the home office, the authors state "[t]he office social system plays a major part in keeping tools (and people) up and running." It's not just work that happens at the office--there's collaboration and informal learning.
I've worked remotely in the past year for the first time, and anyone who's worked remotely has experienced a moment of frustration when trying to explain something and wished they were just "there," to show rather than tell--the authors refer to this process as 'huddling.' When someone is changing a software configuration that I'm not intimately familiar, it's much easier to judge correct options and settings if I'm there. The authors explain that "[huddling] is often a way of getting things done through collaboration. At home with frail and fickle technologies and unlimited configurations, people paradoxically may need to huddle even more, but can't." This collaboration is even more important between peers.
Reading about the home office and its lack of informal networks (which do occur around the corporate office) really drove home the social nature of work. After a few years at my company, I had cross-departmental relationships (often struck up over beer Friday) that truly eased some of my pain. Often, knowing who to ask a question is more important than knowing the answer to the question. It's not impossible to build those relationships when you're working remotely, but it's much more difficult.
Another enjoyable moment of clarity arose when the authors discussed the nature of documents. I think of a document as a Word file, or perhaps a set of printed out pages. The explicit information (words, diagrams, etc) that I can get from the document is the focus (and this is certainly the case in document management systems sales pitches). But there's a lot more to a document. How do I know how much to trust the information? Well, if it's on a website somewhere, that's a fair bit sketchier than if it's in the newspaper, which is in turn less trustworthy than if I've experienced the information myself. Documents validate information--we've all picked up a book, hefted it, examined it, and judged it based on its cover. The authors say "readers look beyond the information in documents. ... The investment evident in a document's material content is often a good indicator of the investment in its informational content." Just as if someone says "trust me" you should probably run the other way, information alone can't attest to its own veracity. The authors also look at aspects to documents (like history, like feel, like layout) that simply aren't captured when you treat them as streams of bits.
And there are many other examples of 'hype' that are deflated in this book, and a few other 'ah-ha' moments as well. As I stated above, this is a great read for anyone who thinks there is a technical answer to any problem (or even most problems). By taking apart various claims, and examining the truth and untruth of those claims in a real world context, these two authors give technology credit where it's due, while at the same time explaining why some of the older institutions and important factors in our lives will remain around. Reading this book was hard work, but understanding what the authors say gives me yet another way to relate to non-technical people, as well as fend off the zealots who claim, in a knee-jerk fashion, that more software solves problems. I majored in physics, in college, but minored in politics. It always seemed that the people problems, though more squishy, were more interesting. This book is confirmation of that fact.
Your Money or Your Life by Joe Dominguez and Vicki Robin, is a collection of simple, common sense observations about money. Perhaps because money is so fundamental to our lives, or because we associate it with work, often we don't examine these simple truths. But the first step to making sound decisions, about money as about every other topic, is to gather all the facts so you can make a knowledgeable and concious decision. This book helps you do that.
The book takes you through 9 steps to Financial Independence, from cataloging all the money you've ever made to keeping a budget to their solution for non wage income. The lessons are told in a easy, simple manner, with 'real life' stories interspersed throughout. Some of their most profound ideas aren't about money, but about work--what human beings look for in work that they used to look for in community and family.
I'm a single guy, and I felt this book was aimed at big spenders with families, mortgages and boats, but I still felt there were lessons to take away. Their end solution is something I'm still up in the air about, but the steps along the way were fabulous--every one simple enough to understand, yet powerful enough to change the way you thought about the concepts discussed. I liked this book and would recommend it.
How much do you know about recent Chinese history? I knew a bit, but reading Legacies, A Chinese Mosaic, by Betty Bao Lord, really brought the recent human tragedies of modern China home.
Bao Lord intertwines two main themes: the story of her experiences as an American citizen who emigrated from China as a youngster and is returning as the wife of a American diplomat, and the stories of Chinese friends and acquaintances, often given to her on audio tape, and recounting the sordid and tragic tale of the last 50 years of China. She does all this against the backdrop of the mid to late 1980s and the Tiananmen Square protests by college students.
This book derives much of its power from the simple stories Bao Lord relates. Whether it's the man who stays alive locked in his office (for years) because his son flys a kite to reminds his father of his presence, or the stories of the real life excesses of the Red Guards, burning any of the "Four Olds," these stories are touching and real. Even her own family story has a certain pathos, as we learn about her grandfather dying three years before she was able to visit, her aunt calmly dying of cancer, and a sister who only learned that she was adopted by happenstance.
The Great Leap Forward, the Cultural Revolution and the other major events of modern Chinese history are only touched on as they affect the people in the stories told, but even that was enough to shock me with what this nation endured. In fact, it's even more shocking than it was when I read about it in the history books, because the folks in the stories are real people.
I referred to Project Gutenberg obliquely here, but browsing their site I found that they've implemented distributed proofreading. This is a very good thing. I did one book, Hiram, the Young Farmer, for PG a few years ago, when I was in college and time wasn't so precious. The OCR went quickly, but the proofreading was slow going and error prone; the story wasn't exactly riveting, but it was in the public domain. (In fact, I just took a look at Hiram and found at least two mistakes. Doh!)
But Distributed Proofreaders solves the proofreading problem by making both the scanned image and the OCRed text available to me in a web browser. Now I can proofread one page at a time, easily take a break, and even switch between books if I'd like. Also, they've implemented a two phase review, much like Mozilla's review and super review process. Hopefully this will prevent mistakes from being made, since these are going to be the authoritative electronic versions of these documents for some time. Linus' law probably holds for text conversion even more than for software development.
Now, it wasn't apparent to me from the website, but I certainly hope the creators of this project have licensed it out to businesses--I can see this application being a huge help for medical transcriptions (work from home!) and any other kind of paper to electronic form conversion.
Update:
It looks like there is a bit of a distributed.net type competition among the PGDP proofreaders.
Hackers, by Steven Levy, should be required reading for anyone who programs computers for a living. Starting from the late 1950s, when the first hackers wrote code for the TX-0 and every instruction counted, to the early 1980s, when computers fully entered the consumer mainstream, and it was marketing rather than hacking which mattered. Levy divides this time into three eras: that of the 'True Hackers,' who lived in the AI lab at MIT and spent most of their time on the PDP series, the 'Hardware Hackers,' mostly situated in Silicon Valley and responsible for enhancing the Altair and creating the Apple, and the 'Game Hackers,' who were also centered in California; expert at getting the most out of computer hardware, they were also the first to make gobs and gobs of money hacking.
The reason everyone who codes should read this book is to gain a sense of history. Because the field changes so quickly, it's easy to forget that there is a history, and, as Santayana said, "Those who do not remember the past are doomed to repeat it." It's also very humbling, at least for me, to see what kind of shenanigans were undertaken to get the last bit of performance from a piece of hardware that was amazing for its time, but now would be junked without a thought. And a third takeaway was the transformation that the game industry went through in the early 80s: first you needed technical brilliance, because the hardware was slow and new techniques needed to be discovered. However, at some point, the hard work was all done, and the business types took over. To me, this corresponds to the 1997-2001 time period, with the web rather than games being the focus.
That's one of my beefs--the version I read was written in 1983, and republished, with a new afterword in 1993. So, there's no mention of the new '4th generation' of hackers, who didn't have the close knit communities of the Homebrew Computer Club or the AI lab, but did have a far flung, global fellowship via email and newsgroups. It would be a fascinating read.
Beyond the dated nature of the book, Levy omits several developments that I think were fundamental to the development of the hacker mindset. There's only one mention of Unix in the entire book, and no mention of C. In fact, the only languages he mentions are lisp, basic and assembly. No smalltalk, and no C. I also feel that he overemphasizes 'hacking' as a way that folks viewed and interacted with the world, without defining it. For instance, he talks about Ken Williams, founder of Sierra Online, 'hacking' the company, when it looked to me like it was simple mismanagement.
For all that, it was a fantastic read. The more you identify with the geeky, single males who were in tune with the computer, the easier and more fun a read it will be, but I still think that everyone who uses a computer could benefit from reading Hackers, because of the increased understanding of the folks that we all depend on to create great software.
If you thought Halliburton abusing the tax payers was something new and different, think again. Hear That Lonesome Whistle Blow, by Dee Brown, is a history of the building of the transcontinental railroads. It starts in 1854 and proceeds in detail until the 1890s, then hurriedly summarizes until the 1970s. (The book was written in 1977.) And Brown shows, repeatedly and at length, how the railroad builders screwed the American public time and again.
In fact, reading this book made me very very angry. It's the same old story: a bunch of rich men want to get richer, and figure out ways to use the public purse to make money. In this case, there were three main ways that wealth was moved from the taxpayer to the wealthy: scams building the railroads, land grants, and high railroad rates. Brown examines all of these in some detail, and sometimes the disgust just made me squirm. He also, towards the end of the book, examines some of the political reaction to the railroads: the Grangers and the Populist Party. And he covers at least some of what the railroads did to the Native Americans.
However, he also intermingles first person accounts in this story of perfidy. Whether it is stories from the immigrants, the first riders of the transcontinetnal railroad, the railroad workers, or the Congressmen who authorized the land grants, he quotes extensively from letters and speeches. In fact, he might go overboard in the quoting department; I would have appreciated more analysis of some of the statements.
Brown does include some very choice, precient statements though. In chapter 11, talking about Pullman's improvements, a French traveller said "...unless the Americans invent a style of dwelling that can be moved from one place to another (and they will come to this, no doubt, in time)...". In chapter 12, a fellow was travelling on an immigrant train and was happy to be separated in the mens' car because he "escaped that most intolerable nuisance of miscellaneous travelling, crying babies."
I learned a lot from this book, both about American history and the railroads. In large part, the railroads made the modern west--I 80 follows the path of the Union Pacific, and Colorado Springs was founded because a railroad magnate owned chunks of land around the area. It's also always illuminating to see that, in politics as in everything else, there's nothing new under the sun.
I go to Java Users Groups (yes, I'm struggling to get in touch with my inner geek) once every two or three months. Sometimes there's an engaging speaker, but most of the time the fellow up front looks like he's just swallowed a hot pepper, speaks like he has a permanent stutter, and answers questions like I'm speaking Greek. (I'm not making fun; I had a hard time when I was in front of a JUG too.) Regardless of the quality of the speaker, I gain something just by watching the presentation--he points out interesting technologies and usually has a list of resources at the end that I can use for further research.
I think Michael Yuan would be a great speaker at a JUG, as he seems to have a masterful understanding of Java 2 Platform, Micro Edition (J2ME). However, the true value of his book, Enterprise J2ME, was in its introduction of new ideas and concepts, and the extensive resource listings. This book is a survey of the current state of the art in mobile java technology. Whatever your topic is, except for gaming development, you'll find some coverage here. Securing information on the device or network, XML parsing strategies, messaging architectures, and data synchronization issues are all some of the topics that Yuan covers.
My favorite chapter was Chapter 7, 'End to End Best Practices.' Here, Yuan covers some of the things he's learned in developing his own enterprise applications, and offers some solutions to five issues that differ between the J2ME world and the worlds familiar to most Java developers: J2EE and J2SE. He offers capsule solutions to the issues of "limited device hardware, slow unreliable networks, pervasive devices, ubiquitous integration [and] the impatient user." Later in the book, he explores various architectures to expand on some of these capsules.
However, the strength of this book, exposing the reader to a number of different mobile technologies, is also its weakness. JUG speakers very rarely dive into a technology to the point that I feel comfortable using it without additional research; I usually have to go home, download whatever package was presented, and play with it a bit to get a real feel for its usefulness. This book was much the same. Some of the chapters, like chapters 12 and 13, where issues with databases on mobile devices (CDC devices, not CLDC devices) weren't applicable to my kind of development, but you can hardly fault Yuan for that. Some of the later chapters felt like a series of 'hello world' applications for various vendors. This is especially true of chapter 12, and also of chapter 20, which is a collection of recipes for encryption on the device.
Additionally, I feel like some of the points he raised in Chapter 7 are never fully dealt with. An example of this is section 7.3.3, "Optimize for many devices." The project I'm on is struggling with this right now, but I had trouble finding any further advice on this important topic beyond this one paragraph section. However, these small issues don't take away from the overall usefulness of the book--if you are developing enterprise software, you'll learn enough from this book to make its purchase worthwhile.
However, I wouldn't buy the book if you're trying to learn J2ME. Yuan gives a small tutorial on basic J2ME development in Appendix A, but you really need an entire book to learn the various packages, processes and UI concerns of J2ME, whether or not you have previously programmed in Java. Additionally, if you're trying to program a standalone game, this book isn't going to have a lot to offer you, since Yuan doesn't spend a lot of time focused on UI concerns and phone compatibility issues. Some of the best practices about limited hardware may be worth reading, and if it's a networked game, however, you may gain from his discussions in Chapter 6, "Advanced HTTP Techniques." In general though, I'm not sure there's enough to make it worth a game developer's while.
I bought this book because I'm working on a networked J2ME application, and it stands alone in its discussion of the complex architectural issues that such applications face. It covers more than that, and isn't perfect, but it is well worth the money, should you be facing the kind of problems I am. Indeed, I wish I had had this book months ago, as I'm sure it would have improved the my current application.
If you're looking for an introduction to Robert A. Heinlein's vast corpus of fantastic science fiction, don't read Sixth Column, read The Moon is a Harsh Mistress. If you're a Heinlein junkie who's read all his other stuff and you want a quick, fun read covering the typical Heinlein themes (the able man, war, gee whiz technology, "long live democracy"), then you'll definitely want to pick up this book.
The basic premise is: the USA has been invaded by "PanAsians," and the government effectively destroyed. Having subjugated India, the "PanAsians" know how to tie down the USA--lots of labor camps, citizen registration and public executions as punishment for any rebellion. But they also have learned not to interfere with their subjects' religion(s). One small military base, a research laboratory, has escaped destruction; luckily the plucky soldiers have an able commander and lots of technology the invaders simply can't match.
From there, it's just a matter of time. The reader gets to watch how these men build a movement, screw with the "PanAsian" leadership, and eventually free the USA. Of course the technology is hokey and the dialog can be a bit offensive, but it's realistic (yeah, I think slurs are allowable if they're marching your family off to the labor camps). This book was written in 1949 and reflects some of the paranoia that Heinlein later gave voice to in Expanded Universe.
But, it's a fun, quick read and if you like Heinlein, you'll probably like it. It's no classic, but not every book can be.
Well, I've figured out how Bill Bryson writes his hugely amusing tomes. Yup, I sussed out the formula:
1. pick a topic of interest that folks don't know much about
2. research it well, finding both fundamental facts and interesting tidbits
3. present the research in a conversational manner, dropping witticisms left and right.
Let's see how this applies to the latest Bryson book I've read: The Mother Tongue: English and How It Got That Way.
Point 1: Not many folks, least of all in America, know much about our language. This is kind of astonishing, given that it's our primary means of communicating (trust me, I spent several weeks in small Swiss towns, and I can tell you from experience that language is the main method of communicating. Charades isn't as fun when you want something to eat). But, other than the most common word (the) and letter (e), and the fact that English doesn't have gendered words, I didn't know much about English.
Point 2: This book shines here. Did you know that the word tits hasn'tchanged since the 10th century (page 215)? Or that Japan buys as many copies of the Oxford English Dictionary as the USA, and more than Britain (page 195)? Or that one sound (yi) in the Pekinese dialect of Mandarin stands for 215 words (page 86)? To support these sometimes absurd sounding claims, we get some footnotes and an eight page bibliography.
Point 3: As always, Bryson is prepared to take a pot shot at any ludicrous statement or proposition, and the English language provides plenty of those. Some of my favorites:
1. "...It is difficult to escape the conclusion that the British have such distinctive place-names not because they just accidentally evolved, but rather because the British secretly like living in places with names like Lower Slaughter and Great Snoring" (page 205).
2. Quoth a congressman, "If English was good enough for Jesus Christ, it's good enough for me" (page 195). Bryson doesn't even bother to comment on this, letting the absurdity scream for itself.
3. When examining the dictionary of Samuel Johnson, Bryson points out that Johnson defines "oats as a grain that sustained horses in England and people in Scotland" (page 153). He lets several of Johnson's tart remarks speak for themselves, but he also examines why this English dictionary (which wasn't the first) had such an impact.
Just the names of the chapters gives you and idea of the scope of this book. From "The World's Language" to "Spelling" to "Names" to "Swearing," Bryson leaves little out. Even the discussion of cross word puzzles and palindromes (hardly exciting stuff), in the "Wordplay" chapter, doesn't bore.
Sure, it's a formulaic book, but a damn good one.
This book, by Paulo Coelho, is, like all fables, written on many levels. Ostensibly the story of a shepard in Spain who, unlike so many people, follows his dreams. He does get a little help from the supernatural, but many of the stories most interesting thoughts come from his musings on nature. His travels take him across the Mediteranean into Africa, where he meets several archetypal characters (the Man Afraid of Change, the Waiting Woman, the Wise Shaman, the Warrior Chief, the Cynical Fool), learns about himself and his dreams, and finds his destiny.
An interesting way to look at this story is to ask the question: who is the title character? Alchemy is such a potent idea--the changing of one element into another has had a grasp on the human mind for as long as we have known about elements. But, of course, alchemy has secondary meanings--an alchemist transforms. Is the boy an alchemist, for transforming himself and the lives of those around him? Is God the alchemist, for transforming the destinies of humanity? Is the reader the alchemist, for taking the fable and transforming its words into something personally meaningful?
My favorite part about this book was its gritty reality. I like epics, but there were no sweeping vistas and no ubermensch heros in this book. Everything the boy does (and we never learn his name) is something you and I could do. I guess that's the point of the book.
Update: As ihath commented you do learn the boy's name. It's revealed on the first page. But, as I remember, it's not used much throughout the book, maintaining the everyman nature of the story.
Douglas Adams is amazingly whimsical. If the Hitchhiker's Guide to The Galaxy didn't convince you of that, the Dirk Gently novels will. Gently is a detective, but no Sherlock Holmes. No, rather than ruling out the impossible to leave only the improbable, Gently prefers to believe the impossible, because it makes so much more sense than the improbable. He solves his case through ingenuity, luck, and a belief in the interconnectedness of all things.
A highlight for me is Dirk's method of finding directions. He just follows someone who looks like they know where they are going. This, he says, doesn't always get him to where he wanted to go, but almost always gets him to where he needs to be. If only we all had such faith!
This book is the second of two about the private eye. I don't want to give away too much of the story, as it is definitely a mystery, but it covers some of the same ground as American Gods in a much less sinister manner. Everything has a reason and a rhyme in this book, even if at first encounter, an event makes no sense, neither to the characters nor the reader. While the ending is a bit abrupt for my taste, if you like whimsy, you'll get an ample helping with this book.
Afghanistan: A Short History of Its People and Politics, by Martin Ewans, is a fantastic book. This fascinating account of this plucky country was chock full of facts that have immediate relevance. Covering from ancient times to 2002, this book provides a traditional history--no stories of the working classes or women. But it covers the byzantine regime changes of Afghanistan very well. It als does a fine job of explaining how the Afghanistan state was in constant tension between the local tribal powers and the more modern central authority of the king. The foreign situation was also an exercise in balance, with the Afghans depending on money, guns and expertise from British India to fend off the Russian Empire. However, the relationship with the Brits wasn't entirely golden, as the three Anglo-Afghan wars suggest.
While the history was intensely interesting, the last chapters of the book, which cover the politics and battles of the last two decades which have left Afghanistan such a mess, were the most relevant for me. If you want to know how mcuh the CIA spent supporting the Taliban, it's in there. If you want to know which external nations supported which of the warring factions, it's in there. If you want to know why Afghanistan grows the majority of the world's opium, it's in there.
I won't say this book was easy to get through. The writing is quite dense. The frequent re-appearance of characters was at times confusing, but I fear that is more a feature of Afghan history than a shortcoming of the book. For a concise political history of a nation that we're becoming more and more involved with, check it out.
I remember way back when, in 2000, when EJBs were first hot. Everyone wanted to use EJBs in projects, mostly for the resume value. But there was also a fair bit of justified curiosity in this new technology that was being hyped so much. What did they do? Why were they cool? How did they help you?
I did some reading, and some research, and even implemented one or two toy EJBs. I remember talking to a more experienced colleague, saying "Well, all EJBs provide you is life-cycle assistance--just automatic pooling of objects, a set of services you can access, transaction support, and maybe SQL code generation." Now, I'm young and inexperienced enough to never have had the joy of doing a CORBA application, but my colleague, who I believe had had the joy of doing one or three of those, must have been rolling her eyes when I said this. 'Just' life-cycle assistance, eh?
I just looked at Amazon's web services, and I'm beginning to understand how she felt. Sure, all web services provides you is easy, (relatively) standardized access to the resources and data available in a web application. Sure, I could get the same information by screen-scraping (and many an application has done just that). But, just as EJB containers made life easier by taking care of grimy infrastructure, so do web services make life easier by exposing the information of a web application in a logical format, rather than one dependent on markup.
Using perl and XSLT (and borrowing heavily from the Developer Kit, I built an application using Amazon's web services (the XML over HTTP API, not the full SOAP API). I was amazed at how easy it was to put together. This was partly due to the toy-like nature of the application, and how much it leveraged what Amazon already provided, but it was also due to the high level of abstraction I was able to use. Basically, Amazon exported their data model to me, and I was able to make small manipulations of that model. It took me the better part of three hours to put together an application which allows you to search on a keyword or ISBN and gives all the related books that Amazon has for that book. You know, the 'Customers who bought this book also bought' section.
I've always felt that that was the most useful bit of Amazon, and a key differentiator. This feature, as far as I can tell, leverages software to replace the knowledgeable bookstore employee. It does this by correlating book purchases. This software lends itself to some interesting uses. (I wanted to have a link to an app I found a while ago, where you entered two different artists/authors and it found the linkage between the two. But I can't find it!)
I like this feature, but it also sucks. The aforementioned bookstore employee is much better than Amazon. Buying a book doesn't mean that I'll enjoy it--there are many books I've purchased that I wonder why I did so, even one hour after leaving the store--so that linkage isn't surefire. In addition, purchase is a high barrier, and will probably cause me to not branch out as much as I should--rather than waste my money picking a random book, I'll pick a book from an area I know. The book store employee, if good, can overcome both of these faults, because the process is more interactive, and the suggester has intelligence. But he doesn't scale nearly as well as cheaply, nor does he have the breadth of Amazon's database. (And he hates staying up all night responding to HTTP requests.)
I just finished 'A Farce to Be Reckoned With' by Roger Zelazny and Robert Sheckley. I've read a fair bit of Zelazny--the Amber novels and Lord Of Light and some others. This book looked more light hearted, but I figured I'd give it a try.
I was sorely disappointed. There's no plot. Or, rather, there is a plot, but it makes no sense. Plot turns are introduced (like the Greek gods getting free) and then dropped, willy nilly. There's a character called Peter Westfall who gets Pandora's Box at the beginning, but we never hear from him again. And at the end, we have a fight scene that is a total deus ex machina--the end of the book comes with no explanations.
Normally, you expect characters to have reasons for things they do. They can do weird things, but they should justify it to themselves, and have the actions be a natural outgrowth of their past. This is called characterization. Characters in this book have one sentence justifications for absurd actions. We have a nun who decides to deal with the devil, and an angel who is ordered to spy. There's a set of religious pilgrims headed toward Venice during the Middle Ages. A demon joins them, proves himself to be a demon, and they don't even run from him.
The dialog is wretched. Everyone converses in a stilted manner. The description is campy; the authors apparently decided to focus on the clothing of women--there are attractive wimples and red low cut blouses galore.
It feels like this book has been subjected to random editing. Or perhaps worse than random, as I feel that there may have been malicious intent at confusing the reader. Characters pop up, disappear for a while, then pop up again with no explanation (an example is the young lady named Priscilla [or Puss]).
But you know what? All of the above flaws could have been forgiven if there had been any scene, any scene at all, that was funny. I wanted to forgive the flaws--I wanted to laugh--I read the entire book, didn't I? But I didn't even crack a smile the entire book. There were times I put it down and thought to myself, 'Why are you wasting your time?' I will admit, I finished the book (I think for the same reasons that folks slow down to look at a wreck on the highway).
Don't buy this book. If you want some funny fantasy, read 'A Night in the Lonesome October' (which is great!) or anything by Blaylock. Don't buy this book.
I recently re-read The Worthing Saga by Orson Scott Card. This book really matters to me, on a number of different levels. It's not his most touching novel and by no means does it have the best characters. But it examines the nature of morality in a direct, simple manner that I've not found in too many other books.
The premise is that, due to genetics, a race of super beings exists, and they've saved humankind from all pain--they watch over everyone else. No more physical injuries--if you cut off your hand, they can heal it from afar. No more mental anguish--if your parent dies, they make it seem as though it was a year ago. No more social problems--bastards are prevented in the womb, and similar actions have no consequences.
And that's the fundamental issue. What does it mean to be an adult human being when actions have no consequences? Without choice, what is morality? These are issues that religions and philosophers have struggled with for thousands and thousands of years, but I like Card's answer.
In addition to the main novella, the book also contains a set of short stories that 'back up' the main one. Just as the Silmarillion, while not a fantastic read, enhances your appreciation of Middle Earth, these backing stories add depth to the Worthing universe. It's not often that you get a chance to read this underlying material, and that's another thing that makes this book unique.
It's also fantastic to see Orson Scott Card evolve as a writer. He was able to pick and choose the best of these short stories, but even so, you can still see him pay homage to the writers he read (as he mentions in the preface) as well as develop ideas of his own.
It's a great book, and I highly recommend it.
I used "A Programmer's Guide to Java Certification" as a study guide for achieving my Java Certified Programmer (JCP) status two years ago, so when I had the chance to review the second edition, I jumped at it (full disclosure: the publisher sent me the second edition to review). As I expected, I was again aghast and delighted at the level of detail, the exercises and the arrangement of this fine book.
Mughal and Rasmussen do a good job of covering all the nitty gritty details that the JCP requires one to know. Whether the length in bits of an int, the difference between overloading and overriding, or the order in which initializer expressions get executed, this book gives one enough detail to overwhelm the novice Java programmer, as well as cause those more experienced to scratch their heads and perhaps write a small program to verify what was read was valid. While this book lacks the discussion of I/O and the GUI of the previous edition (due to changes in the JCP test), it has a fine set of chapters on some of the fundamental libraries and classes. My two favorite explications are the chapter on Threads (Chapter 9), where that complicated subject is treated well enough to motivate more learning while not overwhelming the reader with detail, and the String and StringBuffer section of Chapter 10. So much of the Java programming I've done has been dealing with Strings, so this section, which covers the String class method by method and deals with issues of memory and performance as well as normal use, is very welcome.
The exercises were crucial to my passing the JCP, and they remain useful in this book. Grouped at the end of logical sections of chapters, they break up the text and re-iterate the lessons learned in the previous sections. The answers to these exercises are in the back of the book. Also, a full mock exam is included at the back, as well as an annotated version of the JCP exam requirements which serves as a study guide (both for the full JCP 1.4 and for the upgrade exam). Reading over the mock exam definitely let me know what areas I'd need to study if I was taking the JCP again. In short, the didactic nature of this book has not been lost.
The arrangement of this book is also useful. A fine index and the logical progression through the features of the Java language eases the onslaught of detailed information mentioned above. The extensive use of UML diagrams (especially class and sequence diagrams) was helpful as well. If one reads the book sequentially, one learns about how object references are declared (Chapter 4), then the various control structures available in Java (Chapter 5), then the basics of Object Orientation (Chapter 6), then the object life cycle (Chapter 8), in a very linear fashion. Additionally, there is extensive cross-referencing. This may not be useful to the novice programmer, but to anyone using this book as a reference, it's invaluable, because it allows Mughal and Rasmussen to provide yet more logical linking of disparate topics.
However, this book is not for everyone. I wouldn't buy it if I wanted to learn to program. While there are a few chapters that have general value (Chapter 1, Chapter 6), the emphasis on mastering idiomatic Java, not general programming concepts. Also, as they state in the preface, this is not a complete reference book for Java. It covers only what is needed for the JCP. Finally, if one wants to know how to use Java in the real world, don't buy this book. While most of the java programming I've done has benefited from the understanding I gained from this book, it has not resembled the coding I did for the exercises at all. This makes sense--this book is teaching the fundamentals, and does not pretend to cover any of the higher level APIs and concepts that are used in everyday programming.
Database Nation, by Simson Garfinkel, is a fantastic book. I admit that I'm a fan of what I like to call 'Chicken Little' books (I like William Greider and I even remember thinking that Revelations was the best book in the Bible as a child). My friends tell me that one of my typical greetings is 'Have you read XXX? You should!' I like books that challenge me and confront me with realities that I haven't considered before.
Database Nation definitely challenges. The author approaches the burgeoning issue of personal privacy, and the coming lack thereof, in several different ways. Whether it is biometric identification, the possibility of protecting privacy via property rights, or a chapter of possible solutions, he treats the topic in a manner befitting its fundamental nature. I found his historical emphasis, where he compares the current situation to the one created in the early 1950s by the newly forming credit reporting agencies, to be especially useful. There's nothing new under the sun, as they say. And the problems we've faced with privacy before have dealt with. The sky has fallen before, but it's possible to pin it back up.
Privacy has been on my mind for a while now. I work in technology, and one of the things that is allowing this current invasion of privacy is the ability to collect, store and mine vast amounts of information. As an example of just how far it has gone, I can access 12 million business records (and 120 million US households) via my library's
website--they've bought access to a database called referenceUSA. Search on business size, focus, years advertising in the Yellow Pages, location, etc. Slice and dice as you wish. As part of the usage agreement, you can't use the database for unsolicited commercial mail, but, having found the names in Reference USA, you could look up the business in the Yellow Pageseasily enough.
While such data aggregation has been possible for years and years (ask the insurance companies), computing power and disk space have become so cheap that it's much less work than it used to be--and collecting such information is only getting easier. See Cringely's column for a suggested solution. I'm not sure how I feel about it, but it's one idea for keeping the sky from falling.
I watched Enemy of the State again recently. While I enjoyed watching Will Smith and Gene Hackman avoided the satellite images and bugs of the NSA, I have no idea how much the movie made up and how much it nailed on the head (the Economist had this to say about satellite imagery in 2000). Still, this movie displays in a fundamental way what loss of privacy can mean. When folks say 'hey, I don't have anything to hide' I don't think they realize just what it means to have no privacy. There are shades and shades of 'hiding'; there are things that I would tell my parents that I wouldn't tell an acquaintance. Likewise, there are items I'd tell a new friend that I would rather not be published in
the daily paper. Discretion is something that all humans need--you do have things to hide since no one is perfect at all times! Having something to hide doesn't necessarily mean that you are doing something illegal--perhaps it's just embarrassing (or would be if exposed to certain people).
Another aspect is the federal 'do not call' list and all the hullabaloo surrounding it. Telemarketers feel they aren't going to be able to survive--everyone else feels they don't want to be called unless they opt in. Even Dave Barry has chimed
in. This is an issue that resonates with everyone and calls into dramatic perspective the tension between making your contact information publicly available and wanting to control what someone else does with that information. Imagine what it would be like if everything were public?
Expectation of reasonable privacy is something fundamental. I'd hate to lose it.