DevTalkLA Does an About Face

DevTalkLA, that Geeky Book Club started a new one last night. Pictured above, we began discussing About Face. This is the new 4th edition of a "classic" which has been around for two decades. This latest release came on September 2nd, and includes mobile devices!

Mobile is crucial for user experience! So this promises to be a very important book.

TheHackerCIO doesn't specifically focus on User Experience (U/X) as a sole pursuit. But he has to wear every hat in the wardrobe, so adding in knowledge about U/X and IxD (Interactive Experience Design) is a welcome addition. It adds to the arsenal.

We had a lot of new blood at the Meetup. 24 people RSVPed, but of course only 12 showed, making for a 50% Unreliability Factor. It's always good to note how flaky, irresponsible, undependable and unreliable people are. It's an important index for life. In this case, 50% of respondents actually had the politeness and follow-through to keep their commitment. TheHackerCIO follows this principle, "Always call out bad behavior." You don't want that to go unremarked upon. Ideally you'd like to see it go away. Following through on your RSVP allows a Meetup organizer to get a room of the correct size. If all 24 had showed, we would have needed the larger room. It also allows the organizer to get food or refreshments for the Meetup. I mention this just to indicate that RSVPs have a *reason*. And it's only common courtesy to RSVP if you're going and stick to it.

With over 50% of attendees being first-timers, the Fearless Leader spent a good deal of time giving everyone an overview of DevTalkLA: how we've been continuously discussing technology books for 15 years or more, how we select the books (by vote), and the "bidding" system we use to determine who goes next on offering a comment/question/problem or issue to discuss.

As usual, the discussion was wonderful. I hope we see these newcomers return next week!

We began discussing the introductions, with the interesting point that designing behavior is a totally new concept. Products have been designed, but in a very static sense. The form of a product has been designed. Even the content has been designed. But with computer technology, we now have an additional element of behavior to consider and design.

We were greatly missing one of our old-timers for this book. He has to sit it out for personal reasons. He was always such a helpful addition to the group because he came it with Post-It-Tabs showing clearly every next comment he would raise, and in the absence of others having read the book, we could depend on him to drive the discussion. Since this book was a new release, I made sure that I did a similarly thorough job, so that we would have a very full and helpful discussion for the kick-off session.

On page xxii and following: I noted that there was some confusion. First they questioned whether an experience could be designed. So instead the book authors "have choosen Moggridges's term 'interaction design' to denote the kind of design this book describes." This statement in isolation isn't confusing, but the following paragraph stated that "we feel the term *user experience design* is most applicable." So the question is, WTF? Is this book going to use the term "interaction design" or "user experience design," or both? If they are using both, when will they be employed and why the need for both term? It's not crucially important, but it raised issues for me, and no-one else was able to offer any insight.

TheHackerCIO has lot's to say, but this is running too long already. So, I'll leave this ...

 To Be Continued ...

TheHackerCIO

A Good API is Hard to Find

API design was the GeekyBookClub topic last night atDev Talk LA. 

RESTful Web APIs is the current book, and we had a near overflow turnout for the discussion of chapters 2 and 3.

The book is turning out to be good. But it's the give-and-take of the group that really makes the club work!

Some members have worked ahead, which gives them a bit of an unfair advantage, but TheHackerCIO won't hold that against them. :-)

I particularly liked the fact that the author jumped right in with an actual API to take a look at. A Simple API (chapter 2), in fact, is a micro-blogging API that he uses to illustrate his points. He suggested using wget as a command-line tool to play with it.

I found that I don't have wget available on my MacbookProRetina.

As I mentioned to the group. When someone asks you how long something is going to take, always ask them, "Is this an estimate, or a commitment?" Because management needs to be reminded of this. A lot! Anyway, I curl-ed wget, but I couldn't get it to build because my Xcode was a version or two out, and that download/install seemed to be taking plenty of time. What should have been a 10 minute diversion threw me off for a half hour.

I switched over to simply using Advanced Rest Client, a Chrome extension I highly recommend! You can issue whatever RESTfull calls you wish, with any verb you please, graphically from within your browser, and you can even keep them organized in a file structure for reuse. A very handy tool.

There were too many take-aways from the discussion, but some of the biggest for me were:

1. Being Liberated by Constraints. As the author notes, constraining your REST design, for instance, by using his "personal standard," which requires the JSON to follow some structure, can indeed keep your developers from going wild.

2. I never knew about LINK and UNLINK, but they seem worthwhile. We talked for a while about how POST should be probably be used to create the resource, perhaps with an embedded link to whatever other resource is this resource-target. But then LINK can be used to create a further relationship, going the other direction, from target back to the dependent. (I may be missing something here, because the author tell's me he's going to fill me in on Chapter 11. )

3. PATCH -- looks like a performance enhancement. I'd say to avoid it until absolutely necessary, because it's not idempotent. You're only going to patch a portion of a representation, rather than replacing the whole thing.

4. OPTIONS -- we need to ALL be using this, and straight off the bat, to get the full "billboard" of what we can and should be able to do with our API. No one does. But that doesn't mean we shouldn't start!

5. Overloaded POST -- The author points out how on the web APIs we use POST is overloaded with anything and everything. As he put's it:

The HTTP specification says that POST can be used for:

 Providing a block of data, such as the result of submitting a form, to a data-handling process.

That 'data-handling process' can be anything. It's legal to send any data whatsoever as part of a POST request, for any purpose at all. The definition is so vague that a POST request really has no protocol semantics at all, POST doesn't really mean 'create a new resource'; it means, 'whatever.' [p. 41]

And "Whatever", is never a good thing to mean.

 So don't mean that.

And restrict your POST to creation of new resources with newly-created identifiers.

I Remain,

TheHackerCIO

Some REST for the Wicked

The wicked coders at Dev Talk LA started a REST book the night before last. Discussion was amazing. First we covered the paper on functional programming, which we didn't get to last week. This paper is a response to another paper, so you should read both. Then we did chapter 1 of the REST book.

One fellow geek brought his date to the Meetup -- this was his date night entertainment! I hate getting pushed off my UberGeek pedestal, but stuff happens! I look forward to seeing the happy couple at future Meetups.

I was kind of blindsided by one discussion, which mentioned "traits" with Java. I never heard of them. That's pretty weird for a java techno-maven such as myself, so I need to follow that up with him. And Google didn't help me out this morning, either. It seems "traits" might be another term for "mixins," which were found in some OO environments, but never in Java. Mixins were/are a kind of inheritance where multiple inheritance didn't quite fit the bill. I'm not sure if he's thinking of AOP and mixing the notion in with traits, but it's something to check up on. Or it could be some kind of a library that offers this kind of support in the java ecosystem.

Someone else mentioned GPars, a concurrency framework used in Groovy quite a bit. I don't know that much about Groovy, so this one  has to be put down on my "to be investigated list." I already spent a few minutes Googling it, and it appears to be an implementation of the "actors" abstraction from Scala and Erlang, but in the Groovy/Java world. I definitely need to spend some time playing with Groovy and taking advantage of it's type-inferencing, so I can avoid boilerplate code more. That just needs to happen. Because speed matters.

Another member highly recommended a concurrency talk by Doug Lea. From what he said, I believe that this is the talk.

Moving on to the REST book, the bid system got completely hijacked! Normally, everyone offers page "bids," and the lowest bid wins. But this time, one of our members just jumped in and pushed the last page of the chapter as the opening round!

The discussion focused on a Members key problem with REST for him in his work and in general., which was to get the human readable and machine readable representations integrated. For instance, he hates the whole embedding of versions into the URL for APIs. This is ugly and hard to support. Instead, if you traverse from the top of the hierarchy, and have clients parse a page of "billboard" information, which describes the kinds of additional services and methods available in the API (at that version), then you can completely avoid this.  You are basically building the API spec into the page returned, which the client reads, scrapes, and uses to invoke the various additional API calls.

The problem is, this scheme doesn't allow permalinks and the use of bookmarked pages in the browser. You have to start at the top of the hierarchy and traverse it, because the site might have been reorganized since the last time your client noted a permalink.

But it occurred to us that you could have a versionless permalink API, that mapped permalinks to whatever new, reorganized location they now properly dwelt in. And that would effectively take care of most of the whole issue.

We still need to get our heads wrapped around the right way to do all of this, but the book promises to help us immensely in that regards.

I Remain,

TheHackerCIO

Conceptual Integrity Part 1 ... or Why Committees Can't Do Doodly

Last night at DevTalk LA (that Geeky local book club), having finished our book, we read two articles. We do this in-between books, to allow members a little extra time to get the book in-hand. Next week, we'll start the eagerly anticipated RESTful Web APIs by Richardson & Amundsen.

Add caption

RESTful Web APIs

This book appears to be a complete rewrite of their earlier RESTFul Web Services (2007). It was, by universal acclamation of Dev Talk LA, one of the better books we've recently read, and advance opinion holds the re-write to take things on the next level and clear up all our questions.

The two articles can be (and should be!) read on-line here:

•  Design and Research by Paul Graham
•  Why Why Functional Programming Matters by Reg Braithwaite

We spent most of the time on Paul Graham's essay.

If you haven't read Paul Graham, you need to stop reading here and get on with it. Buy his book. Read his essays. Just do it. The short-version of why is this: Paul Graham is a twice-successful Startup enterpreneur who built his success upon technical excellence. He's a big proponent of the rapid development he found possible through the use of Lisp, of which his is an advocate and presently is designing/promoting Arc, a Lisp derivative of his own. But there are two additional factors that make him a compelling figure.

First, he's done something other than technology. He's also a painter. And the interplay of what he has learned from both shows clearly in his very insightful and reflective essays. Secondly, he understands, in a very no-nonsense way the value and importance of passion. From last nights essay, for instance, came this timeless quote:

To make something good, you have to be thinking, "wow, this is really great," not "what a piece of shit; those fools will love it." 

Which brings us to the point of today's essay.

Conceptual Integrity.

It's important.

Really important.

Paul Graham gets it, too.

As he puts it, (highlights mine)

Notice all this time I've been talking about "the designer." Design usually has to be under the control of a single person to be any good. And yet it seems to be possible for several people to collaborate on a research project. This seems to me one of the most interesting differences between research and design. 

There have been famous instances of collaboration in the arts, but most of them seem to have been cases of molecular bonding rather than nuclear fusion. In an opera it's common for one person to write the libretto and another to write the music. And during the Renaissance, journeymen from northern Europe were often employed to do the landscapes in the backgrounds of Italian paintings. But these aren't true collaborations. They're more like examples of Robert Frost's "good fences make good neighbors." You can stick instances of good design together, but within each individual project, one person has to be in control. 

I'm not saying that good design requires that one person think of everything. There's nothing more valuable than the advice of someone whose judgement you trust. But after the talking is done, the decision about what to do has to rest with one person.
Why is it that research can be done by collaborators and design can't? This is an interesting question. I don't know the answer. Perhaps, if design and research converge, the best research is also good design, and in fact can't be done by collaborators. A lot of the most famous scientists seem to have worked alone. [ed. note: see my "Never Hire The Greatest Scientist The World Has Ever Known"] But I don't know enough to say whether there is a pattern here. It could be simply that many famous scientists worked when collaboration was less common. 

Whatever the story is in the sciences, true collaboration seems to be vanishingly rare in the arts. Design by committee is a synonym for bad design. Why is that so? Is there some way to beat this limitation? 

I'm inclined to think there isn't-- that good design requires a dictator. One reason is that good design has to be all of a piece. Design is not just for humans, but for individual humans. If a design represents an idea that fits in one person's head, then the idea will fit in the user's head too.

I wanted to collect these ideas into one place and last night was a wonderful impetus to do so.  But this posting is already too long, so it looks like we have to kick off a series. And what a wonderful topic for a series! Conceptual Integrity. And, I'm very happy to have one of my heroes, Paul Graham, give as forceful and thoughtful a kickoff as could be imagined.

I Remain,

TheHackerCIO

The Tribulations of Developers

... more about the book our GeekyBookClub chose last time around. I'd have voted against it!

DevTalkLA at last Tuesday's meeting wrapped up the last chapter of Data & Reality, a supposed classic by William Kent. The book proved highly disappointing. It's a kind of skeptical look at data modeling. Skeptics are generally annoying. If data modeling can't be done (objectively), what kind of practical advice does he have to offer us for doing it? Why bother?

This, for example, is from his concluding chapter, entitled "Philosophy":

"So, at bottom, we come to this duality. In an absolute sense, there is no singular objective reality.  But we can share a common enough view of it for most of our working purposes, so that reality does appear to be objective and stable." [p. 149]

What rot! If there is no objective reality at the base, how the devil can anyone share a "common enough view" of such a non-existent-thing in order for it to magically appear to be a thing, let alone an objective and stable thing?

And if we operate on the (supposedly naive) view that there is an objective reality at the base of what we do, and we do this because we *have to*, then what is the point of removing the naiveté?

Anyway, luckily, this rubbish book is now behind the group. And, also, the side-bar conversations were stimulating as always.

In fact, the great lament of the book club was related to timing. One member noted that the next book, RESTFull Web APIs, which looks extremely promising, was wonderful, but he needed to have read it several months ago, when he encountered these issues!

And TheHackerCIO, also had similar experience, with the Java Performance Book. I came to know about the book through DevTalkLA, and when I got it I realized that the client I had been building a performance engineering environment for would have gotten an order of magnitude better job out of me, if only I had read the book at the time I began the project!

But, such lamentations, trials, and tribulations are part and parcel of the life of the Hacker. We can only know about what we know at the time we know it.

I Remain,

TheHackerCIO

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

Cucumber Sidebar Conversations

Last nights Geeky Book Club continued on with the Cucumber book. These chapters didn't elicit earth-shaking insights. However, the sidebar conversations were wonderful.

One of the special pleasures of having such a great group is that you get to find out about all kinds of things you've never heard of. It's almost an unofficial Technology Radar.

The big one I discovered last night was Liquibase. This is almost like a Git repo, but for your database. And these discussions led me on to mention to the group an idea that had been brewing in my mind for a while.

Relational databases are based around a few simple concepts:

• The concept of a table: rows & columns, almost like a spreadsheet.
• A few relational operations, with an underlying mathematical model.
• Set processing of all data.
• Metadata (the catalog) for discovery/documentation and enforced at creation automatically.

But an enormous complexity arises from these.  Maybe not with the canonical example from Date's book of the Employee and Department tables. But when you get up to ten tables with foreign key constraints, and then move up to hundreds or even thousands of tables (as in Peoplesoft), all with complex relationships -- the complexity is very hard to manage. It's also hard just to grasp.

This is fairly common. The idea in Finance of Options is very simple. Two types: calls & puts. Two sides to each type: long and short. But the complexity that results from this resulted in a Nobel Prize for Fisher Black! And I've read many a neuron-busting treatise about valuing such options, back when I consulted for Wall Street Derivatives traders: the gamma-neutral strategies, delta-neutral hedging, etc. etc. etc.

My idea is that just as we have tools like Cucumber to store our scenarios and link them to our code, so also we need such a tool that shows the database transformations that come from each step of our scenario.

This would be both a documentation tool, a tool for systematically collecting and creating test-data, and educational tool for new developers, or those who want to understand the system. In short, such a tool is most earnestly to be desired.

So all of this crystalized in my mind as I put it forth to my honorable colleagues, last night. And they agreed that such a system would be very useful.

If any of my readers want to help me work on it, TheHackerCIO is now set up on Github, and I think I'll begin hacking ...

Now if only I had a catchy name ...

I Remain,

TheHackerCIO

Wednesday Returns to Geek Book Club

The LAJUG Study Group, or Geek Book Club, as I prefer to call it has extended me an extraordinary honor, in light of my long-time attendance, and allowed me to dial-in remotely on Tuesday nights, to participate, even though I'm 2,000 miles away.

So, beginning next week, Wednesday will return to reporting on what came from the discussion the night before.

It means TheHackerCIO will have to be up from 10:30-12:00pm, rather than the more palatable 7:30-9:00 -- but hey, he's a night-owl anyway.

The next chapters of the Cucumber book will be discussed.

I Remain,

TheHackerCIO

Book Recommendation: Hackers & Painters by Paul Graham

Last Tuesday, the Geeky Book Club didn't meet. The night was "off," owing to the Holidays. So, in lieu of Cucumber, I thought I would take today's space to recommend one of the best "techie" reads to be had.

I speak of "Hackers & Painters," by Paul Graham.

Notice that I didn't say I would review it. I'm just recommending it. It's the best technology read around, and if you haven't, you need to get a copy and start reading it ex post haste.

If you want to get a taste, you can read most of the contents online here.

geeky Cucumber

Our GeekyBookClub is the best! Last night was a perfect illustration. TheHackerCIO came in totally unprepared. Unread Chapters. No time to read them. Too much client Hacking this week. Plus the Bus. Dev for the coming year!

Some would be intimidated by going to a book club, especially where the reputation of the club members is so high. I've heard that this is a "Guru's group."

TheHackerCIO is intrepid. Guru's don't intimidate.  Plus, we completely lack Prima-Donnas in the group anyway!

So, we had a wonderful time. Earl, as always, had performed the reading with his usual highlighting of every relevant passage and lots of sticky tabs along the edge to locate them the faster. Thank Deity for the "Earls" of the world.

The way we structure our club, members "bid" the page number of their next comment or question. The lowest bid wins. It makes everything flow along smoothly. We also allow backtracking to pages covered in prior meetings.  Which means that next week, when I get caught up on the reading, I'll be able to revisit everything that I just got a nice conversational and high-level introduction to at last nights Meetup.

In Chapter 5 we noted with interest the principle that:

 DAMP (Descriptive and Meaningful Statements)  

trumps DRY (Don't Repeat Yourself), 

when writing examples, because readability is paramount.

Someone remarked about the "bug magnet" -- that they had heard of a chick-magnet, but not a bug magnet. There was a general consensus that chick-magnets were preferable.

One member is moving away from a proprietary CMS to Magnolia, which came top of list, for:

•  working easily, 
• runs locally, 
• doesn’t have to be deployed on a dev environment.

Which puts it onto the radar for consideration, at least by me.

Our local Groovy bigot held forth about the wonders of that JVM language, in support of closures. He expressed his wonder and indignation at Java's implementation of lambda expressions versus the superior work in Groovy. TheHackerCIO needs to get more into Groovy to follow this, but for those geeks interested and not in-the-know, here is the difference between a Lambda and a Closure:

A Closure has access to the static variables.

That is to say:

1. a Closure:

x=5

y=7

Z = {a, b : (a+x * y +z)}

2. A Lambda is the same as above, but without access to the static x, y which are now out of scope.

Then they discussed "Gstring", which is apparently another Groovy idiom, and not a racy nightclub exhibit. It's some kind of a templating expression language that will fit into a string to replace items.

I asked for the best book/resource to learn Groovy, and was recommended this:

The Definitive Guide to Grails 2, by Greame Roche, which apparently covers Groovy in an appendix which should be read first. Going by what the reviewers say, anyway. 

Then we started discussing Clojure (yes, Clojure the functional language, not to be confused with closures, the functional programming idiom that, when called returns another function)

We talked a bit about how Clojure is so hard to follow/read, at least for us, mere mortals. I remarked about how nice it would be to work with the smart people who DO work in it, for instance the people at Factual. And we got this capper:

"Clojure is ok when the system is small enough to be retained entirely in the head. When it outgrows that, or a mere moral must deal with it, it collapses." A whole lot of wisdom is contained in that epigram.

And for that Wisdom I am Grateful to the GeekBookClub Members &

I Remain,

TheHackerCIO

Sickness & Taking Out The Garbage Scientifically

As the pills took hold of my internal (bodily) Garbage Collector and tuned it to more efficiently remove unneeded and unwanted objects, TheHackerCIO's thought naturally turned to his beloved JVM and it's own GC algorithms. For those more managerial, Garbage collection is part of the major advantage of Java over the old C and C++ environments. It allows the programmer to depend upon the environment to manage memory, rather than having to explicitly perform this in code.

There are two major advantages to using GCs. Memory management takes up a huge amount of development time, estimated by some at 40 to 60%! And secondly, if you mess up, it's easy to get a memory leak. Those are what cause your old windows box to hang on you, back in the day. The memory of your machine kept getting used up and never was released, so eventually there was no more memory left. So you were "hosed." That's a technical term. :-)

GC is an important issue in todays world, and I had been unsatisfied by the Java Performance book our Geeky Book Club read recently, most specifically by it's treatment of the GC algorithms. It seemed to be poorly organized from the standpoint of fundamental types of GC. Instead it plunged right in to the present state of GC available.

I was confirmed in this opinion by hearing a wonderful talk by Azul, who make a for-purchase JVM built around the idea of a "pauseless GC." In other words, in most GCs, when you collect the garbage, all work must stop. This is called "Stop the World," because all threads doing application work are stopped while the GC "pauses," collects the garbage, reclaims memory for new use, and then restarts the application. If the heap is big, a pause could be long. Maybe seconds. Maybe even 4-5 seconds? Now your talking availability problems!

Consequently, the GC needs to be understood. And tuned.

The talk by AzulSystems was far better organized. It cut through euphemism, defined and organized the presentation around fundamental GC types, then explored the currently available GCs and how they fit into those categories in terms of their performance characteristics. And the CTO mentioned that the bible for them was this book by Jones (image below), called The Garbage Collection Handbook:

So naturally, I ordered a copy.

The book is wonderful. I'm only on chapter two, but even if difficult/demanding, since it's well organized and doesn't leave dangling questions, it's a far better resource to read first, before attempting the Java Performance book, already reviewed here.

Plus, this is the absolute latest update on GC algorithms and technology! Further details will follow.

I Remain Thinking of Garbage,

lol,

TheHackerCIO

Quick Point on Cucumber

Quick point on Cucumber

Last night we covered the next two chapters of The Cucumber book. These were on Gherkin -- the syntax for specifying Scenarios. It's kind of amazing that the keywords are essentially meaningless! You can actually use an "*" in place of any keywords, with exactly the same results.

We also determined one reason why "the enemy" disliked it. There is no namespace capability within Cucumber. Consequently, it becomes cumbersome proportionally with the increase in Scenarios and Features. At least it throws an error if an ambiguous step definition is created. But as the number of scenarios increases, the time necessary to run also increases.  Which is to say, it doesn't scale well.

Next week -- on Tuesday,  will be the LAJUG main meeting & I hope to see everyone there!

Also next week -- on Monday, will be the Technology Radar Group & I hope to see everyone there as well. :-)

I Remain,

TheHackerCIO

Cucumber Word salad

Great attendance & surprises indeed last night at the GeekBookClub, more properly called the LAJUG Study Group.

We began the new book: The Cucumber Book, seen above.

It's a bit Ruby-esque, but applicable to Java via the download of cucumber-jvm, which I'll need to investigate.

So, I got my MacBookProRetina loaded up with Ruby as a prerequisite for the Cucumber install, and followed the appendix without serious issue to get a working cucumber installation up to try things out. And I entered the first bits of chapter two's "First Taste," and got the same results.

Apparently, the whole Cucumber/BDD -- or Behavior Driven Development -- is based around attempting to provide a communication tool that can involve business people as well as developers in producing executable specifications.

To begin with Cucumber is a command line tool.

That's cool, to the inner Hacker that constitutes TheHackerCIO, because GUIs are for those who can't Hack. Your mileage may vary.

:-)

There is a sort of word salad of technical terms in the cucumber suite, so here is a quick glossary ...

A feature is  a flat file that contains plain-text, ordinary language descriptions of one or more scenarios.

A scenario is a list of steps for Cucumber to work through. These scenarios must follow a particular syntax so that Cucumber can work through them.

Gherkin is the name for the syntactical rules required of the scenarios. Gherkin uses keywords such as Feature, Scenario, Given, When, and Then to provide the needed structure to the DSL.

The steps, or step-definitions are where Ruby programs actually get bound to the specification, thus making them executable.

The essential point of all this is to make it possible for business -- that it, non-technical -- people to get involved in writing acceptance tests. That seems like a good thing.

The big surprise in last nights discussion was in one new, first-time attendee. Newcomers are freely and warmly welcomed at our book club; at whatever level and from whatever technology background. And this newcomer was already very familiar with both Ruby and Cucumber!

So, instead of a discussion among people all eager to learn a new technology, we had an interaction with someone who already new and HATED the technology! That was a twist! This person was coming to try to see whether she could be convinced of the value of Cucumber from the Pragmatic Programmer book!

We spent quite a bit of time trying to understand what her issue was with the tool, and we all quite happily viewed a demo of how Cucumber works, which she whipped up for us on her Macbook and ran.

Seeing a live demo on the spot certainly made it a lot easier to grasp the whole essence of Cucumber. It's amazing how much superior a tutorial is to reading, no matter how much I like reading.

So, you'll have to stay tuned for future blog postings to see what we learn about Cucumber and whether it's useful or a pain! No matter what the verdict is, new technology needs to be learned about and evaluated. And so ...

I Remain, Ever Learning, and ...

TheHackerCIO

Geeky Book Club Had Neither Me nor a Book Last Night

TheHackerCIO is in crunch mode to meet deadlines for client delivery, so I had to miss my GeekBookClub (LAJUG study group) last night. So, the poor club remained wanting in two essential ways:

• an incredibly brilliant, scintillating commentator, such as TheHackerCIO.
• a book to discuss.

A book club without a book!

A geeky club without a geek! At least, without one normally in attendance.

What a situation.

The club has finished Java Performance and typically reads articles in-between books for a week or two. Next book up is The Pragmatic Programmer on Cucumber.

I'm very sorry I missed the discussion of the Paul Graham article, Hackers & Painters. If you haven't read Paul Graham's essay, you need to stop reading my blog now, go there, and read it. Then read it again. Then poke around reading his other essays.

I'll explain why in another post, or possibly, an essay of my own!

I remain, Hacking in Crunch Mode,

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

Cucumber Gets It's Day

Cucumber

So the next book to be read by all my co-Geeks is the Cucumber book pictured above, followed by the Data & Reality book.

These are choosen democratically by a vote of ATTENDING members. The vote took place last night, and Cucumber was the winner. I know very little about Cucumber, except that it purports to be a behavior-driven approach to testing and development.  I wasn't too happy to learn that I'm going to have to mess around with Javascript for the Cucumber book!

For those who don't know, Java is to Javascript as Ham is to Hamster. Javascript isn't type-safe. It's loosy-goosy typed, which means that data types can be created willy-nilly from whatever data they contain into whatever type you need for something else. That sounds nice, and might even speed up prototyping. But for writing a stable production system, the errors that get lost in the mix are very troubling. Especially when they bite you in production! Java, by contrast is strongly typed. All errors are gotten up front. For those of us who like strong-typing, we'd like all our errors caught up front, thank you very much. We'd just as soon not find them later, in production. At 9:30pm on a Saturday night. You get the picture.

The book is now on it's way to TheHackerCIO from Amazon and I'll be posting about it in the future. Most likely on  Wednesdays. And after Cucumber, the runner-up was Data & Reality, which will be the next book for Geeky discussion.

Actually, the other books looked pretty good as well, and so I bought the lot! That's the problem with loving technology! Seriously, they all looked good to me. The books that didn't make the grade were:

Behind Closed Doors, not to be confused with Behind Closed Doors, as I did on my first Amazon search!
Cryptography Engineering
Agile Database Techniques

  On the Java Performance book, the discussion of the day was rather light. One of the great things about this particular club is that the side discussions make up for the deficiencies of the books. We'll come back to that in a moment. Last nights' chapter was on Web Services performance.

Many comments were raised about exotic JVM options. You can disable explicit GC calls with a startup-option. That's kind of weird, since you can't depend on GC happening from an explicit call anyway, so this is a very exotic option! GC, BTW, stands for Garbage Collection. It's one of the cool features of Java. In the bad old days of C and C++,  you had to manage the memory you used in your programs yourself. Since everyone screwed this up, lot's of "leaks" of memory resulted. Consequently, when you run an application too long, and enough memory leaks, your whole system freezes up, or "hangs." Now you know why. Java helps in the regard, by simplifying memory management.

I wanted to know what a NUMA architecture was, referenced in the book. NUMA stands for Non Uniform Memory Architecture. I apparently wasn't the only one unfamiliar with it. When I said to the group I'd like to know what it was they referred me to Google! I'll forgive them for it. At least this time.

Next we discussed and reflected with surprise on the section where it was pointed out that XML processors are NOT thread-safe! "JAXP does not mandate that factory instances be thread safe." One of our participants told how he learned this the hard way, from getting a ConcurrentModificationException. He couldn't reproduce it, but synchronizing the method resolved the exception.

We all disagreed with the book about the importance of XML. As far as we're concerned it's deprecated, and well deservedly, along with SOAP. Everything from now on ought to be REST and JSON. By the way, I really, really would appreciate some colleagues visiting my LinkedIn profile, found here, and endorsing me for REST. I only have two endorsements, and it's so low on the list. Yet I did the whole book club discussion about REST. At least you guys should endorse me for it.

So, this blog posting is getting long, but the book club members primarily like todays posting.

The side-bar discussion that was really interesting and tantalizing was a teaser about Resource Oriented Computing and the company Netkernel. Apparently, this approach is a complete paradigm change, according to our participant. He's researching it, and planning to implement ESIs (Edge Server Includes) as a first step, which have something to do with optimization of the CDN (Content Delivery Network). With any luck, we'll get a presentation from Earl on this!

I Remain,

TheHackerCIO

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