Codemash 2013 – Testable Javascript

presenter James Kovac  JetBrains

4:50 PM 1/10/2013 Salon D

First reviewed the history of javascript.

  • First browser was lynx, all text no javascript
  • First browser with javascript was Netscape version .9.  Had it’s own javascript named livescript
  • Microsoft came out with it’s own version with DHTML to support Outlook web clients
There are now many complex javascript libraries and javascript code has been become very complex.  Because of this need to test just like we do with our server based code.  The tools he will review help bring Red-Green-Refactor motif to javascript.
Reviewed the following testing platforms
  • Qunit – built by jQuery to automate their testing
  • Jasmine
  • Mocha, with Chai
Jasmine with jQuery plug in very effective for testing jQuery.  Qunit very familiar for traditional TDD approach, Jasmine Mocha more BDD based.   Mocha is based on node.js therefore do not need a browser to run it, can run it through node.js.
Downside to all except Mocha is asynch testing.  Since Qunit and Jasmine rely on browser there is need for boiler plate code to write ansyced tests.  Mocha much better with asnyc since node.js based.
Synon.js is a mocking library for javascript.  Phantom.js is a headless browser for windows and perhaps could be used to automate tests for Qunit or Jasmine.

Codemash 2013 – Becoming a Software Strategist

presenter Bill Heitzig

11:00  AM 1/10/2013 Nile

Bill was a developer for a number of years and turned down the management path in the last few years.  The point of his presentation was that you should create a written ‘Strategy’ for what you are trying to accomplish with your group.  The strategy document should be a private document that you use to orient yourself and your actions.  It should be shared only with trusted colleagues with the purpose of garner feedback to improve your approach.

Bill believes that having this written strategy document is key to successful leadership.  He indicated that he believes leading means having a strategy and having it written down makes it clear it actually and concretely exists.  Writing down your strategy also assists you in perfecting communicating your strategy to others verbally.  It helps you practice defining your strategy to yourself so you can better communicate it to others.

A strategy is defined as a cohesive and rational vision for the future of your group.  The goal of a strategy is not to win, it is to make your project, aka your software, and your team successful.

A strategy should assist you in making decisions.  Decisions will be made, but a strategy helps you to actively chose to make decisions as opposed to letting them be made by circumstance.

A strategy should be objective, measurable and repeatable.  Bill mentioned Key Performance Indicators as a concept that can be useful in defining the metrics to use in strategy review.

The concept of sphere of concern and sphere of influence was brought up.  Bill recommended having your strategy focus on things in your sphere on influence, and to also try to increase your sphere of influence to give your strategy a higher chance of success.

The concept of technical debt was explored.  Technical debt increases because of looming deadlines and poor compromises.   This leads to downward spiral and your strategy should address shrinking your technical debt.  However, technical debt should not be tackled too quickly, it should be reduced over time.

You should invest in your software and your team through training and tools.  These investments will produce good roi and should be part of your strategy.

Your strategy should be separate from your implementation process.  Your strategy is not agile, agile is part of your strategy.

Your strategy should not strive to provide immediate value, but should focus on delivering value over time.  You should use your team on activities that are investment, not every activity can be for immediate gain or will increase to technical debt.  Investment items include training, documenting, researching, setting up environments.

Your strategy should include an approach to handling your customers.  You should strive to build trust with your customers.  You should go to your customers don’t make them come to you.  Do not over promise and share bad news with customers quickly.  Your strategy should be to try and become your customers trusted adviser.

Find ways to measure capabilities in your team.  Define how levels of competency in different areas can be measured and understand what level of competence your team has in different areas.

Build trust with your partners, aka QA and and Deployment.  Protect partners from you by helping them be better at what they do.  Inform your customers about your partners so they are aware of how you operate so can understand better how hard their requests are to complete.

Your strategy should state the problems you face clearly so you can more easily try and define solutions and approaches to mitigation.

Bill suggests that the higher up in an organization people are the less they read so effective written communication for upper management should be as short as possible.

 

Codemash 2013 – Understanding Prototypical Inheritance

presenter Guy Royse, Piller Technologies, pillartechnology.com.

9: 45 AM 1/10/2013 Salon D

This was a very solid overview of prototypical inheritance in Javascript.  The presentation was energetic and delivered exactly what it intended to delivery, a explanation and overview of prototypes in the Javascript language.

I was mystified initially as to how this worked, but it turns out to be fairly straightforward.  An object in Javascript is just a collection key value pairs.   Keys in this collection can refer to values that are functions to objects can have behavior.  Javascript is dynamic so when you call a method on an object you don’t know if it is there or not when you call it.  If the function exists on that object it will be called, if not the object as a prototypical parent, and it will pass the call to it to see if that parent has what you are looking for.  If the parent has what you are looking for it is returned, if not it looks to it’s parent.  The top of this prototypical chain is the Object.

Where it gets confusing is that objects have a constructor function and it is on this function that the prototype is stored.  When you create an object using hte new keyword in Javascript the constructor function executes and the object that exists in the .prototype property of the constructor function is set as the prototypical parent of the new object instance.  In this way every instance created of an object will have to same prototypical parent reference.

To set a parent on an object that is dynamically created you have to create a constructor function for the object, set it’s prototype to the parent the new object should have, and then execute the constructor through the new keyword to get an instance.

The above structure means you can add behavior to prototypes by acting on the prototype property of an objects constructor function.  This allows us to add behavior to any object in javascript.  For instance if I want to add a method to the string object to put append “Bob” to the end of any string I can add the method to the object set in the string’s constructor functions prototype property.  The ‘class’ in javascript is really the constructor function, so I just write String.prototype.AddBob(); and now all strings have the AddBob() function!

 

Codemash 2013 – Getting Started With SpecFlow( with some BDD and ATDD thrown in )

presenter James Bender, VP of Technology Improving Enterprises www.ImprovingEnterprises.com.

3:35  PM  1/10/2013 in Portia/Wisteria

James comes from a full on Agile shop, very into TDD.  Indicating testing very important for dynamic languages, like javascript!

Reviewed benefits of TDD: Quality, documentation in tests, more focused on what I’m doing since have to break down tasks into smaller tasks, reduces rust code.  Code doesn’t exist if no business test exists that uses it.  Less bugs.  Bugs won’t come back since test exists that proves its gone.

Behavior Driven Development(BDD)

Acceptance Test Driven Development(ATDD):   Get acceptance tests, write code to make them pass to implement.

Mentioned that he does not believe that there is right way to do this.  Just ignore people who say you should do it this way and do whatever works best for you.

Started doing actual BDD for Tic Tac Toe as excercise using SpecFlow as unit testing framework and taking a BDD approach.  Used nuGet to get Specflow using Nunit.  Create project called TicTacToe.Specs.  Need to go to SpecFlows website and install some software for processing BDD tests.

SpecFlow is basically a code generator that creates unit test code from SpecFlow Gerkin based Feature file.

Working With SpecFlow

  1. Add a Feature file.  This allows english language gerkin syntax driven tests.  Feature, Scenario, Given Then When syntax.  The feature file and gerkin syntax has no dependency on platform or language so can use it on any platform.  ( Can use Gerkin based Feature definition as your user story also if you want.  Then your user stories can become actual tests)
  2. Generate test files.   Specflow can goof up generating files, if this happens just use Run Custom Tool option to get it to regenerate.
  3. Create a step for each Gerkin statement.  Each Gerkin statement will become a unit test in generated tests.  Specflow wraps test attributes with its own Given and When attributes so abstracts from particular test framework.  Passing tests are marked ‘done’ when run tests in specFlow.

We as a group then went through the process of creating specFlow scenarios for the Feature GameWinner in a Tic Tac Toe game.  You can parameterize specFlow tests by using regular experssions.  This allows scenarios that are different only in value will be matched by steps that are defined with regular expressions.

In SpecFlow can write a given that visually defines  a table that then passes a Table to the unit test.  Table is collection of TableRows which are just keyvalue pairs where key is the table column name.

Quickly reviewed Mocking and Dependency Injection as concepts that underpin SpecFlow and BDD.

How do you get your management to buy into specFlow and TDD.  What do you tell them to convince them to do this.  Money and time.  They want to know how long will this take and how much will it cost.  Showed cost of fixing defect based on when it’s found chart.  Much more expensive to find defects later in process.  BDD and SpecFlow aid in finding bugs sooner and therefore save us money!  Showed a Defect Density and time to delivery chart.  Longer projects had much lower defect density, but not that much longer and had a lot fewer defects.  QA people should be aware this technology will not replace them but allow them to focus on things that only a human can do.

 

 

Codemash 2013 Keynote Neal Ford

After three years I’ve returned to Codemash! Just like three years ago I’m going to post my notes here so to help the learning sink in!

The keynote presentation started a little late, around 8:20 Am.  I was a little bleary eyed after my hour long drive out from Cleveland, and had a bit of a food coma going after a super quick breakfast.  All in all I was hoping to have an eye popping and life altering experience, or at least enough to keep me from passing out in my scrambled eggs.   I didn’t pass out, but I didn’t have any religious experiences either.

The keynote was given by Neal Ford.  See his website for the details but to summarize author and big wheel at ThoughtWorks.  Apparently has written a few books and has a new book out relating design patterns to creating presentations.

Neal’s presentation was based on a concept called ‘Geek Leaking’.  The basic concept was applying problem solving from disparate areas to each other to come up with unanticipated breakthroughs.    For example apply the scientific method to anything to break down walls.

The presentation began with definitions of the word “Geek’.  Apparently Geek is a verb as well as a noun,  ‘Geeking’ is spending inordinate amounts of time on disciplines that other people don’t find very exciting.

Richard Feynman worked at Los Alamos and had a deep physics background.  He was known for applying his problem solving skills to areas well outside of his specialty and achieving impressive results.

Forbes published an article about how all companies now have some software aspect to them.  In this regard all companies are in some way software companies and the ‘Geekness’ of software professionals is now leaking into normal businesses.

Next Neal’s book ‘Presentation Patterns’ was used as an example of how the ‘Geekness’ of software people is now leaking into presentations.  Neal gave some examples of some good and bad presentation formatting.  Anti patterns in presentations:  looking old even if using new technology, hiccup words, Alienating artifacts.  Good patterns in presentations: Context Keepers, Backtracking, Blank Slide to put focus on you when you want it.

Reviewed John McCarthy from Stanford in fifties, was creator of LISP language ran AI lab.  Neal put forth that many of personal computer researchers at that time were hippies, and that hippies were more visionary than normal people so the PC age was ushered in.   One problem, however, hippies are egalitarian so couldn’t forsee email being abused for spam.

Neal admitted to making  crank calls as a child.  He indicated he has stopped this now that caller id has come into use.  No fun making crank call when recipient knows where you live.  Not quite sure what the point here was, but it’s interesting.

Richard Feynman did work optimizing process at a Uranium Enrichment facility.  Part of this work laid the groundwork for parallel computing.  Feynman essentially created a human parallel computing process to help with large calculations he was needing to perform.

Neal next mentioned the book Power of Habit.  Habituation causes the brain to be able to do tasks with less effort.  Once a task is a habit brain can accomplish it with far less mental effort.

The presentation now spent a good amount of time detailing benefits of continuous integration and deployment.  Mentioned anecdote about Martin Fowler as a teenager in Birmingham UK visiting a software project that was bogged down in long ‘integration’ process of software that was written then ‘integrated’.  Used this as a reason to integrate every day to make integration less painful by doing it more often.  ‘Bring the pain forward’ to make the pain less.

Deming Cycle is really just scientific method and really is Geek Leakage from research and statistics into software.

Richard Feynman like pretending to be a safe cracker.  He knew many safe codes were birthdays so would sneak into people’s offices and spend time guessing their safe codes, then if front of them would pretend he could crack their safe.

Jeweler’s Hammer metaphor.

Use a jeweler’s hammer to break a large problem domain down into two or more more easily solved problem domains.  Neal used time as  a hammer to break down presentation problems, gave examples of Traveling Highlight and code Overlays as examples of how looking for how to save time lead to breakthroughs.  Also used clojure as an example of a jeweler’s hammer approach to solve variable threading problems in Java.

Evolutionary Architecture and Emergent Design.  Architecture is anything that is really hard to change.  Architecture should start small and evolve.  Design is for things that are flexible so it can emerge as a project moves forward since changing it has minor consequences as compared to architecture changes.

Continuous Integration for Components.  Can create systems that self update when a dependency changes all the way through deploying a production ready version.  Guarded dependency is build with an updated component that did not make it all the way to deployable code.  Trust is required to setup systems that automatically consume other component updates.  Mentioned Github and change in open source motif where there are now pullers who get source code and make changes and then submit them versus old school allowed collaborators on a project.

Richard Feynman played the bongos.

Downsides to Geek Leakage: overly complicated solutions.  Reference wired article about advanced math used on Wall street being reason for financial melt down.  I disagree, if banks were allowed to fail they would not use these tool irresponsibly, it is the lack of risk involved since banks are too big to fail that lets them run massive risks that then damage the economy.

Neal then reviewed his concerns regarding armed robots.  He wants to make sure that armed not so smart robots have rock solid code.  In this context Neal mentioned Asimov’s robot books and the robot laws as  a good idea.

Richard Feynman participated in reviewing the challenger disaster.  By using a simple approach was more effective than statisticians  He simply put o-ring material in cold water to show it was ridgid.

In short, embrace scientific method everywhere, use Jeweler’s hammers and only Geek Leak positively.