A Book Club Rebooted ?!?!

This month, my local "Geeky Book Club," rebooted.

I thought about calling it a facelift, but the club was never in need of a facelift. It really just needed a little bit more modernization. It's a long-running book club! About two decades, standing,  -- or, rather -- sitting, from what I can tell.

Officially, it used to be called the LAJUG Study Group.  The Web Page for this monicker still sits there -- for a while, at least. But now, the links on this page point to the newly rebooted:

DevTalk LA

It's not merely a name change, or a face lift. The group has shifted from being focused on Java to a broader range of technology interests. It was natural, almost imperceptible shift, which you can see for yourself by perusing the extensive list of  past books:

Past Books Covered Before I Joined:

• Design Patterns Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
• Refactoring by Martin Fowler
• Concurrent Programming in Java Design Principles and Patterns by Doug Lea
• Java 2 Performance and Idiom Guide by Craig Larman and Rhett Guthrie
• Agile Software Development by Alistair Cockburn
• Bitter Java by Bruce Tate
• Patterns of Enterprise Application Architecture by Martin Fowler 
• Problem Frames by Michael Jackson
• J2EE AntiPatterns by Bill Dudney, Scott W. Thomas, David Osborne, and Bob Kiel
• Documenting Software Architectures: Views and Beyond by Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith Stafford
• Pragmatic Programmer by Andrew Hunt and David Thomas 
• Refactoring to Patterns by Joshua Keriesky
• Expert One-on-One J2EE Development without EJB by Rod Johnson and Juergen Hoeller
• Domain Driven Design by Eric Evans
• Agile Software Development Ecosystems by Jim HighSmith
• Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity by Joel Spolsky
• Effective Java Programming Language Guide by Joshua Bloch
• Effective Enterprise Java by Ted Neward
• Aspect-Oriented Software Development by Robert E. Filman
• Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea
• Head First Design Patterns by Elisabeth & Eric Freeman, Bert Bates & Kathy Sierra
• Test Driven Development: By Example by Kent Beck
• Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps by Mike Clark
• Implementation Patterns by Kent Beck
• Java Generics and Collections by Maurice Naftalin and Philip Wadler
• Programming Groovy by Venkat Subramaniam
• Founders at Work by Jessica Livingston
• Effective Java, 2nd edition by Joshua Bloch
• Enterprise Integration Patterns by Gregor Hohpe
• Java Persistence with Hibernate by Christian Bauer and Gavin King 

I joined the group shortly after returning to my birthplace, here in Sunny Silicon Beach. That put me on the list at this point:

Books Covered During My Participation:

• Programming the Semantic Web by Toby Segaran, Colin Evans, and Jamie Taylor
• Coders at Work by Peter Seibel
• Advanced SQL Programming Forth Edition by Joe Celko 
• Seven Languages Seven Weeks by Bruce A Tate
• Pragmatic Thinking and Learning by Andy Hung
• Scrum and XP from the Trenches by Henrik Kniberg
• Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi
• Restful Web Services by Leonard Richardson, Sam Ruby and David Heinemeier Hansson
• Java Performance by Charlie Hunt & Binu John
• The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers) by Matt Wynne and Aslak Hellesoy
• Data and Reality: A Timeless Perspective on Perceiving and Managing Information in Our Imprecise World, 3rd Edition by William Kent and Steve Hoberman

Next Book Upcoming

• About Face 3: The Essentials of Interaction Design by Alan Cooper 

One can easily see that the focus shifted almost exactly when I arrived. We covered the Semantic Web, Coder Stories, SQL, 7 different languages, Thinking, XP, Psychology!!!, REST, Cucumber, and Database Modelling problems. Only one book, on Java Performance was directly about Java!!! 

So, the name change merely reflects the present-day reality ... the changes that have taken effect ... we now have a wonderful discussion-based book club for developers in the local Los Angeles area. Please come and join us ...

I Remain,

TheHackerCIO

Bookishness & Geekiness

Internally I think of it as "My Geeky Book Club." And so I refer to it with my wife. But, the official name is LAJUG Study Group,  and last night the remaining faithful few finished up the Performance Book:

 Java Performance by Charlie Hunt and Binu John

Now, our group will take a little break, and read a few articles, specifically: 

• Hackers & Painters: by Paul Graham
• The top 9+7 things every programmer or architect should know: by Brian Du Preez

Paul Graham is a Technologist everyone should know about. Read his essays, if you haven't already. The link above will give you a start. He's a successful entrepreneur and now runs Y-Combinator , which is the best incubator for tech startups to get into. Not so much for the money -- you won't get that much -- but for the in-house expertise on starting tech companies, which is incomparable, and invaluable. 

Invaluable, in that it can't be valued, because it's value is too high. That's one of those problem words that always bothers me, because there are other reasons I can think of why something might be invaluable. For instance, working at a multi-billion dollar enterprise is experience that is invaluable: it can't be valued, because it is worthless. They lied about their desire to transform their technology, or at any rate they have no serious desire to step outside of their comfort zone and really accomplish much of anything. So the time spent working there and the experience overall is invaluable. This is another word to put on my list of peculiar english expressions along with inflammable, which means flammable! But we don't want to get confused here and we need to get back to geekiness and books and articles!

After next weeks session on the two articles linked above, we'll move into BDD and Cucumber. My copy has arrived from Amazon, but I haven't imbibed yet. So comments will have to come later.

As to last nights discussion, none of us are too enamored with the Performance Book, so we ventured fairly wide in our chatting.

One early topic was a comparison of several books from the past, and what was learned from them.  I noted that the Azul presentation, in my view, was far superior to this book. I felt that the Azul presentation answered questions and raised my understanding about Java Performance and Garbage Collection. In contrast, while this book answered some questions and improved my understanding somewhat, for everything I learned, I became aware of ten more questions, issues, and conditioning factors, which were NOT explained. Thus I was left with the feeling that in some sense I knew less than what I started with. Yes, I had gained knowledge, but I had gained more awareness of how lacking that new knowledge was than I had gained in new knowledge. This is kind of a difficult point to explain succinctly, but the pattern is: to understand A, you must understand Q, R, S, T, U and V to enter into a proper comprehension of A and it's implications. And here is are a few more details about A. But in the meantime, if you want to know about Q, R, S, T, U, and V, please consult the references at the chapter end. That is the pattern of what I felt from reading through this Performance Book.

By contrast, with the Azul presentation, I learned basic principles, and then saw an analysis of existent JVMs in the context of those basic principles. That's an extraordinarily good structure for any presentation. And it didn't leave me with tons of unanswered nagging problems and issues.

Another member noted that with the Generics book, it had been confusing, and he concluded that the Java community should have "just said no" to Generics.  I've always found them confusing as well. And I prefer keeping a language simple. 

He also noted that with the Concurrency book, while many of the corner cases were disturbing, there were lots of tips and "don't go there" advice that was well worthwhile.

Then there was some discussion about NRU: Not Recently Used. That's kind of interesting, this this is distinguished from the LRU (Least Recently Used) algorithm with which we are all familiar. Apparently, NRU is less precise, but has less bookkeeping overhead. 

Everyone was kind of surprised to learn that with a Java start command (-XX LargePageSizeInBytes) you can alter the page size all the way up to a Gigabyte! Not sure when I'd want to do this, but it's quite interesting. Perhaps an application might be able to tune to page size. Have to think about that one.

On p. 549, we got hit with a countervailing opinion that "pessimistic locking may provide better performance." But the conventional Whiz-dumb has it that optimistic locking will provide better performance. We discussed this for some time and came to see that really it depends on what the statistical likelihood is of lock failure, in your particular environment. If you're likely to fail on a particular lock, then it actually improves performance if you pessimistically lock! But I don't think anyone ever notes this nearly obvious fact, or stops to consider what their particular environment likelihood of failure is. 

So, that wraps up a difficult, demanding, and marginally rewarding read. I'm still a better person for having worked through it. But I would really love to take the Azul presentation and compare it to the Book chapters on the JVM. Perhaps, if Azul provides us with their slides, I'll do that.

I Remain, Ever Reading, and Ever ...

TheHackerCIO

Blued; NOT Screwed!

Blued; NOT Screwed! Which is to say "Zinged"!

TheHackerCIO is fluent in Spanish. So Azul Systems is "Blue" to him. Last night at the LAJUG we were amazingly lucky enough to get a tremendous presentation on Java Garbage Collection from the CTO and Cofounder of Azul Systems,  Gil Tene.

Azul, for those who don't know, make a JVM which, while it costs money, resolves a lot of the performance problems commonly encountered in Java environments.


TheHackerCIO is never tempted to Lionize anyone, or write puff-pieces about any product. What set this presentation apart were the following:

• factual information about all available GCs was the main thrust of the talk.
• Zing (Azul's product) was only mentioned briefly at the end.
• Basic terms were defined, some in cleverly clear ways that made for greater retention
• Basic principles were developed.
• Principles of GC operation were then examined in the context of those basic terms and principles, so that everything was brought into a coherent whole.
• The focus was on understanding the Mechanism, not on explicating the JVM flags. As Gil put it "Once you understand how it works, you can use your brain" to figure out the flags. TheHackerCIO likes that. Always use your brain.
• A lot of misinformation and fallacies were debunked. Turns out, surprise, surprise, the Conventional Whiz-Dumb is wrong much of the time. 

The presentation was so superior to the Performance book, that in my mind it formed a perfect contrasting concrete. If only the Performance book we are studying had been written in this manner, we would have all been happy campers. 

I took pages of notes, and I suspect that I'm going to have to break them out over several days. But, you have to start somewhere. And what better place than his attention step?

He began by claiming that most of what people "know" about GC is wrong. Then he told a story

Early in Azul's history they encountered an application taking 18 second pauses. This was somewhat embarrassing for a pause-less JVM, so they investigated. What they found was that every class had a finalizer that set all instance variable references to null. 

Notice that this is the right discipline for a C++ environment. But it's dead wrong for Java. Dead objects cost nothing to collect! Except, when you put finalizers on them! This is a perfect example of how people fail to rethink new technology in the context of it's own spirit and intent and continue to use it in antiquated, outdated manner. But that is a major topic for yet another day's blog, and was not a topic of Gill's talk. 

So, despite the Conventional Whiz-Dumb:

• GC is extremely efficient. Much more so than malloc().
• Dead objects cost nothing to collect (Except when you put finalizers on them!)
• Those pauses you eliminated from your 20 minute test are not really gone. They just got pushed out to 30 minutes. Your times may vary, but the pause just got pushed out to a later time!
• There will be a 1s per live GB pause. This is not really tunable. The only way around it is Zing.
• No, GC doesn't mean that you can't have memory leaks.

Even I fell for some of these in times past. But this is getting long. 

I would say in conclusion that rarely have I been so impressed by a company's values. The talk we scored came from Azul honoring the commitment of a junior sales engineer to speak to us in October, but who had left the company. In the absence of anyone local to fill in, the Cofounder/CTO hopped on a plane to give us the promised presentation. TheHackerCIO deeply respects keeping commitments and  can't think of a more paradigmatic example. More on GC will follow. 

Geek Book Club: Java Performance

Java Performance Book

A Users Group is a bit low-tech, but still an excellent way to improve technical ability. This is re-demonstrated by the advent of agile techniques such as pair-programming, and Mob Programming. What is Mob-Programming, after all, but a sort of Users Group working on the same problem collaboratively, using only one keyboard! I have reservations about the value of  MBA-hole touted "teamwork," since it is often the last refuge of the incompetent; No better means of blame-shifting has ever been invented than the "teamwork" of a committee. But clearly there is a place for collaboration. And a Users-Group is a self-selected group of interested valuers of a particular technology.

I go regularly to a local Java Users group, which has a weekly Study Group, whose present book is on Java Performance. So, on Wednesdays, typically, I blog about the Tuesday night's book discussion. This week we're on Chapter 10, about performance on the Web.

Since I haven't blogged about the book at all until now, I'm going to generalize my impressions on the first ten chapters. This is not a book for the faint-hearted. It's very a very dense, tough read. I made it through about chapter 5 or 6 without serious problems, but got slogged down at that point, and only picked it up again here at Chapter 10. And what I learned was limited and somewhat frustrating. I can't entirely blame the book. Part of what limited my learning was the mere fact that an almost overwhelming number of tools are discussed in considerable detail. Now, if I had the time to use this as a tutorial, and work through those tools, my learning would have been much greater. For that, I'll take the blame. But the book raises a number of very tantalizing details which are not presented in sufficient detail to be really grasped or understood. On the positive side, I'm glad to know of the existence of all these tools. I'm also glad that I know where to turn to find all the tools and things-to-do to monitor a particular aspect of the performance of an environment. But, of course, this is a dwindling asset: as time passes, the list will logarithmically decay in terms of usefulness. The part that is frustrating is that many topics are referenced obliquely -- enough to raise them as a point of interest, but not enough to really grasp what is going on. I'll try to post an example of this next week -- in the interests of keeping this post manageable.  Back on the positive side, there are many tips and tidbits scattered through the text.

Last night, for instance, we read with considerable interest that enabling the Java Security Model resulted in a 33% performance degradation. That's much more overhead than I would have guessed. We also learned a cool trick for avoiding the 404 error associated with lack of a favicon. Provide a 1x1 pixel blank icon! Now that is way cool! And the whole group agreed.

My experience working through this book are shared by many other club members, by the way. One of them was posting to potential visitors not to judge the club by this book!

I Remain As Always,

TheHackerCIO

All Work and No Play Makes Jack a dull Hacker

Play is contagious. But that's not a problem, when the play is a Framework.

http://www.playframework.com/

Play works in both Scala and Java, but you have to be very careful to pick which one you want correctly without mixing/matching, or you'll get into errors. Monday, TheTechnology-Radar-Group had a presentation from Alexandros Bantis on Play with Scala.

Tuesday night, our local Java User's Group got another presentation from Alexandros on  Play with Java.

One question surfaced, which is still being discussed: Given that Grails can easily produce a CRUD application, using Active Record as in Ruby/Rails, is this time-saving capability available in Play, or are they orthogonal approaches? Stay tuned for details!

Two Play sessions, in succession! What a fun month for the Hacker side of ...

the one who remains faithfully,

TheHackerCIO