Friday, July 25, 2014

No Fluff Just Stuff - Lone Star Symposium Review

The NFJS conference (July 2014 in Austin) was a perfect fit for me. It markets to a Java audience, but there was plenty of other topics covered. For me there was the technical Java track (immediately relevant to my current work), a functional programming track (future focused), and a soft skills track, which I found to be a pleasant and perfect balance. I'm definitely going to go back!


I started out with Javascript Design Patterns by Pratik Patel. He was particularly found of underscore.js, not only for the features set that it offered, but it's use in the mixin pattern, which he asserts is easier to maintain than the decorator pattern. I personally liked his example of this command pattern, which I'm showing below.




Java memory by Ken Sipe was really deep, but it explained a whole lot of stuff that I never understood. Essentially the JVM segments the memory into 2 spaces, new and old. The idea being that for the most part, there are two types of objects occupying memory: the super short, like a message or request; and the incredibly long, like models which are needed for pretty much the whole time the server is up.

Given this idea, there is two main segments of memory, new and old. The new space is divided into Eden (brand new), SS0, and SS1, where SS* is a "survivor space" for not new, but not old objects. The old space is also divided into Old and PermSpace (Aha! that is what the JVM config -XXMaxPermSize goes). 

(BTW, -XX is an experimental flag, while -X is standardized)

The idea is that GC is misnamed, it is not garbage collector, but really a garbage avoider. It actually never touches the dead, but does promote the living to the next level (from Eden to SS*, then to Old, etc) 

There are two types of GC, major and minor. Minor happens only when Eden is full, which moves the living the the SS space, and resets Eden to write over the dead. Major GC affects all areas of memory and is slow and should be avoided if possible. The goal is a high morbidity rate in new space, and a very low morbidity in old space. 
After optimization
Before optimization

XX:NewSize = 256m

XX:MaxNewSize =256m

XX:SurvivorRatio = 8

XX:PermSize = 32m












Finally he gave a list of tool recommendations for Java tuning
  • JPS
  • JSTAT
  • JMAP
  • JHAT
  • VisualVM* (his favorite, open source all in one troubleshooting tool)
  • VisualGC
  • MAT

Functional JS by Pratik Patel was a great overview of the difference between functional and OO.  Basically if comes down to that OO in JS is messy for the things that we need to do, and functional is a "recipe for simplicity". Again he talks about underscore.js, but this time we go deeper into

  • composing
  • currying (special composition where first argument is the composed function
  • chaining
Transitivity is defined as "always getting the same result with the same input"
And in general OO talks about nouns, where FUN talks about verbs. 



Narcissistic Design by Stuart Halloway


Just as setting the context, Stuart is extremely passionate about Clojure and functional programming, so he generally exposes all of the evils of OO. And this talk is a humorous portrayal of that.  Although if you listen with an open mind, putting aside your OO education, there are some interesting points of view to consider.

The premise behind his talk is that by thinking only about "me", that you can add lots of complexity to the code base, all in the name of best practices. So here is a list of best practices that increases the complexity of the code base and makes it harder to share.

  1. Embrace setter methods :
    Setters undermine the two best parts of OO: constructors and interfaces
  2. Prefer APIs over data:
    data forces decoupling, while API couples by temporality, language, mutability, semantics, and esoteric features
  3. Start with DSLs (Domain Specific Languages)
  4. Always connect, never enqueue
  5. Create abstractions for information
  6. Use static typing across subsystem boundaries
  7. Put language semantics on the wire
  8. Write lots of unit tests
    He argues that once tests are passing, they tend to always pass
    He also argues that generative testing would test more options then a handful of pathways
  9. Update information in place
    This practices comes from assumptions that memory / storage is expensive and resources are dedicated
    It is not needed anymore and immutable data facilitates easy sharing, distribution, concurrency, access, and caching
  10. Leverage context
One of the neat ideas was to learn some of the data languages like you would a programming language:

  • avro
  • bson
  • csv
  • edn
  • fressian
  • hessian
  • java
  • json
  • kryo
  • protobuf
  • thrift
  • yaml
  • xml



Build your own technology radar by Neal Ford of Thoughtworks was by far the best / most inspiration session of NFJS.

This is basically a snapshot in time by opinionated technologists. It is not comprehensive nor strategic. It is not a technology lifecycle assessment tool. It is ultimately a tool to montior ("keep on the radar") technologies.

"You can't tell that the technology is stable or collapsing when you are on the inside"

The interactive version is at http://www.thoughtworks.com/radar/#/

The rings of the radar from outer to inner are

  • Hold - proceed with caution (notice there is no "avoid" category)
  • Assess - worth exploring with the goal of how it will affect you
  • Trial - worth pursuing on a low risk project. Get to know its strengths, limitations, and use cases
  • Adopt - finished a trial and found usage patterns
    • Mason Razor: "I'll make fun of you at the pub if you aren't doing this"
Neal strongly encouraged each developer to make their own radar. It is part of your knowledge portfolio, that needs to by managed. A simple API exsits for plotting one already at https://github.com/bdargan/techradar

As far as evaluating new technologies, here is the litmus tests that were recommended:
  • Testability
  • Integratability
  • Learnability
  • External references (books, blogs, conferences talking about it)
One of the best tactical / practical / immediately applicable comments was to write unit tests in a different language. For example write Java unit tests in Groovy. Given that tests are a form of overhead, there is a benefit to make it as efficient as possible. Besides you get to practice in a new language. 

That night, I sat in the lobby of the hotel and attempted to re-write one of our test classes to Groovy. I ended up with 4 people pairing with me and it was SUPER simple. Within an hour, I had nearly the whole class in Groovy, and that was GDD (Google driven design, given that this was my first exposure to the language. 

Neal also strongly recommends that COMPANYS create a technology radar as well. 
  • Gives you a platform for continual analysis
  • Unified message to non-technical but interested people
  • Excuse to get together to have an impassioned conversation

"The future is already here, it just is not evenly distributed" 

Research shows that your next job comes from your weak links in your social network, instead of your strong links, like friends and family.

The top pitfalls that lead to agile troubles by Andy Painter was just a wealth of nuggets for my scrum master position.

I enjoyed this presentation so much, that I even asked Andy to join me for lunch, so we could continue talking. I had several questions for him, and he provided great insight.



  • Agile vs waterfall
    •  Agile is like flying an airplane, you continually have to course correct for wind, weather, traffic etc. Waterfall is like riding a train, where the plan has already been laid down for you to follow. 
    • You can't say that Agile is faster than waterfall because they are not the same product. It is an apples to baseballs comparison. You can't assume that the finished agile project is anywhere near the same thing that would have been delivered via waterfall
  • Scrum master
    • Is about teaching
    • In order to teach, they need to be able to listen
    • Also needs to provide a safe place to fail, so that learning / improvements can happen
  • Product Owner
    • Available, knowledgeable, and empowered
    • PO as proxy should be a temporary position
  • Learning from Failures
    • True failure is not working through the challenges and giving up
    • "I welcome failure, not because I desire it as an ultimate end, but because I recognize that any true success must be born through some amount of failure. And because of this allowance, I expect my team to be better next year than they are today. 
  • Cargo Cult
    • I hadn't heard this term before, but it describe the condition of imitating actions expecting to produce the desired results. 
    • For example, if a team says "we have a backlog, daily standups, and demos; therefore we are Agile", without understanding the why or treating style over substance, might be an example of the cargo cult. 
  • Standup
    • If what you did yesterday, doesn't equal to what you committed to in yesterday's standup, that is an impediment
    • It isn't a status meeting, but at daily planning meeting
    • It is a layer PDCA cycle - Plan, Do, Check, Act
    • If "I'm working on it" for a couple of days, means that there isn't enough visibility.
  • Velocity
    • It is a PLANNING tool, not an accelerator
    • By definition it is a constant rate of motion
    • In retrospect, it should have been named "pace" instead, to take away the stigma that it can be throttled
    • Best stats is from the last EIGHT (8) sprints (3-4 months). This encompasses the average amount of stuff - vacations, sick days, life events. 



Javascript toolchains by Nathaniel Schutta
Here is their take on the JS toolchain

  • Node.js - Even if not for the server-ness, it is needed for the other essential tools
  • Grunt - build tool
  • Jasmine - testing
  • Mocha -testing with built in async and code coverage
  • Karma - automatic test execution
  • Phantom - Headless browser for CI
  • Sinon - spies, mocks, and stubs
  • Istanbul - code coverage
  • JSHint - static code analysis (more configurable then JSLint)
  • Plato - static code analysis with complexity reports & maintainability indexes
  • Angular - MVC large application management
  • Bootstrap - CSS framework
  • Require - dependency management
  • Uglify - JS compressor



For the rest of the sessions that I attended, while they were interesting, I'm not going to summarize them.

  • Leading Technical Change, while good to hear again, was all common sense. There was a good quote that came out it though. "Attention is our best resource, don't waste it." "Attention is a bit like real estate, in that they're not making any more of it. Unlike real estate, though, it keeps going up in value" 
  • Web Security was amazingly interesting, especially in the fact that we didn't just go over the obvious vectors, but we actually did the OWASP's web goat security demonstration application as a group lab. That was AWESOME!
  • Clojure in 10 big ideas was great at getting my head around a purely functional language. It would do no good to summarize or list the 10 points, because without the 15 supporting slides for each point, it is useless. 


Book Recommendations from the conference