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

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

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

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