Followership & Leadership : An Agile Perspective from Ballroom Dancing

 Here is the followership presentation that I just gave to Agile Leadership Network. 

TL;DR. The the core elements to Followership are

• Vulnerable trust
• Commitment to Engage
• Responsiveness. 

Followership.pdf (ALN 6/2024)

Going Solar

So, we just installed solar panels on our house and I have some info to share.  We purchased it ourselves and did not go through a co-op.  

TL;DR:

• When you are talking to the different sales people (and do talk to several of them) the company mostly likely does 1 of 4 things and subcontracts the rest.  Choose based on what you are most concerned about.
• They make the panels or equipment
• They do the installation
• They manage the financing
• They provide or manage the electricity
  
  
• The loan is different than other loans you are familiar with. As of 2022, there is a 26% government rebate (hopefully it will be extended), that the loans incorporate. The loan is recalculated after 18 months, because they expect that you pay the entire rebate into the loan when you get it, if not, then you monthly amount will go up for the remainder of the loan term (20 years). If you frequently owe federal taxes, you need to take that into consideration, as part of the rebate would reduce the amount you owe, but then if you don't pay that full rebate into the loan, the monthly payments will go up. 
  
  
• The amount of wall real estate around the electric meter is significant. Be sure to take that into consideration.  (See photos at the bottom)
• Given our real estate AND the base flood elevation, it was really tricky on how to arrange the 3 additional panels around the meter. 
  
  
• Of the many reasons to get solar, if you are trying to account for power outages, you will be paying the most. If you can deal with a tiny (hopefully) number of days without power even when the sun is out, or can solve that in another way, you can pay a lot less. 
  
• We opted for a portable duel fuel gas generator. It is manual, and will power the fridge and maybe a few outlets with the propane tanks that we normally keep on hand for the grill. 
• In short, if there is a power outage and full sun, we are getting limited power from a small generator, not the panels. 
  
  
• Unless you buy a battery, your solar panels will be tied to the grid. If the grid loses power, so do you. Batteries are really pricey ($13K) at the moment. As far as I know, there is no way around this, as the excess energy needs a place to go. 
  
  
• Once the panels are installed, expect several delays before you get fully operational.  
• First, Centerpoint needs to grant Permission to Operate (PTO), which is when you can actually literally flip the switch to enable the panels. This takes a few weeks to a month. 
• Then after that, Centerpoint needs to acknowledge that you are producing excess energy. We are still in this phase. I've heard it takes about 2 months. But so far my utility bill only reflects what I'm consuming (at night), not what I've produced, so my utility bill for the first 2-3 months will not be zero (even though I should be overproducing). 
• I don't know yet if when Centerpoint does acknowledge the credits, if it is retroactive or starts at zero. In other words, since we turned on the system in March, I don't know if in May (hopefully) when this happens, if we get credit for all of the sunny non-AC days of March and April, or if May is day 0. 
  
  
• Pay close attention to how your utility company handles net metering. You will likely need to switch to a new company. Green Mountain, for example, which I'd been with forever and thought would be really good, only will buy from you what you buy from them per month. This means that you can't build up credits in the spring for the summer. I'm now with Rhythm. 
  
  
• I would recommend Rising Sun Solar (recently renamed to Astrawatt) or Sunpro. 
  
  
• According to HCAD, the panels raise the price of the house, but DO NOT raise your taxes. 
  
  

Safari Low Power Mode

 Let's talk about the unclear documentation  of Safari's Low Power Mode. 

Here are some steps to get started: 

1. Log in to developer.apple.com
2. Go to https://developer.apple.com/download/more/
3. Download "Additional Tools for Xcode12"
4. Open "Quartz Debug" in the Graphics folder.
5. In the menu bar, click Tools -> Enable Quartz Debug. Then, Tools -> Show detached regions.
6. Your screen should now be tinted red. If your screen becomes normal color, it means low power mode is working.
7. In Safari, start playing a video (it should be red tinted)
8. Go to full screen and wait for the controls to decay. If there is nothing else on the screen other than the video it should be back to normal colors indicating that Safari is successfully playing in low power mode. 
   
   (This might seem backwards, but low power mode is basically the idea that nothing on the screen is rendering other than the video. The the red overlay is rendering, then that is the indication that other non-video things are rendering as well.)

Things you need to know if you are going to test or implement this: 

1. You can't have multiple monitors connected.
2. It only works when the video is playing. If the video is paused, it will not be in low power mode. 
3. The full screen element needs to have a `background-color: transparent`. Even though it is the default, it needs to be explicitly declared. The documentation says it needs to be `black`. This is wrong. 
4. Parent nodes of  the video node, up to the full screen element need to have no background-color defined or defined as transparent.
5. Other html elements that exist within the full screen element and on top of the video element need to have a display:none. Empty nodes will cause it to NOT go into low power mode. 
6. It will fail to go into low power mode if the page has a warning or error that displays over the window, not in the console, even if this error is not seen in full screen mode.  For example, "This webpage is using a significant amount of memory, closing it may improve performance". 

Incorporating an Agile Mindset as an Individual

The Other Way to Scale Agile: How you as an individual can incorporate an Agile mindset even if you org chart nodes disagree. 

Much of Agile focuses on the “team”, but Agile is a mindset and a mindset starts with a single person. Whether you are on a fully agile team, transitioning, or agile is not even an option, there are a number of personal practices that can help you become an Agile Practitioner no matter what your environment might be.

You will first understand what are some good personal and background practices that are foundational as an Agile Practitioner. Then you will gather techniques for acquiring and understanding feedback both from your users as well as your team. Finally you will learn some practices for being a catalyst for collaboration and commitment

Slides and videos

• Virtual Agile Shift Conference (6/18/2020)
• https://www.youtube.com/watch?v=mYcMXVPL7pU&feature=youtu.be
• Houston Tech Fest (Virtual) (9/18/2020)
• https://www.youtube.com/watch?v=7Y1ba37B_3Y&feature=youtu.be
  
• Unicom TestExpo and Agile and Devops Expo 2020 (Virtual) (10/16/2020)
• Agile Leadership Network - Hosuton (4/17/2025)

Agile in 160 Billion Gallons: When Agile Principles Occur During A Disaster

While the Agile concepts may sometimes be easy, the why's and how's are a little trickier to wrap your head around.   I’ve unfortunately participated in three recent rising flood water events in Houston over the last three years. Employing my agile skills has had a profound impact on the "success of the project".  

Their are some agile principles that are naturally occurring during a disaster. The "product" is protecting your home by saving your possessions.  The backlog is all of your possessions and it is prioritized by how you plan on attacking it. Some examples might be most expensive to least, or from the floor to the counters.

Some agile principals, like self organized teams or iterations are partially present. And some principals are rarely applied at all.

The  demo, retro, and sprint planning, tend to fall away during a crisis, but I assert that those are most important for a successful product, as they are core to the agile principles of transparency, inspection, and adaptation.

Here are the full slide decks.
* Houston Tech Fest ( 10/14/2017 )
* Agile Leadership Network Conference ( 04/21/2018 )
* Houston Tech Fest - Spring (05/05/2018)
* Project Manager's Institute - Houston Conference (06/05/2018)
* Houston Tech Fest - Fall 2018 (9/30/2018)
* Houston Scrum Masters Alliance (1/28/2019)
* Agile Shift Conference (04/12/2019)
* Houston Agile Leadership Network (7/18/19)
* Houston Tech Fest (9/14/19)
* Houston PMI October Meeting (10/9/19)

* Houston PMI August Meeting (08/19/20)

* Vivit-Worldwide Virtual Community Days - Agile, DevOps, and Testing Conference (12/2/20)


Video recording:
http://usergroup.tv/videos/agile-in-160-billion-gallons-when-agile-principles-occur-during-a-disaster

Creating our Flood Plan

So having flooded three times, and being an Agile-ist, I'm always trying to improve.  This is the summary of my flood plan.

After my first flood, I spent some time (almost all of my time) thinking through the choices I made "in the moment" and how I could improve. So I came up with a flood plan, in case I ever flooded again. 13 months later, I had a chance to implement the plan. The plan worked very well. I spent some more time thinking about it and have developed the following.

Before diving into the plan, I need to set the context. When I'm talking about flooding, I'm talking about a rising water event. This is where there is a lot of rain and after some length of time (maybe several hours) that rain isn't able to drain away any more and starts coming into the house. This plan does NOT apply to storm surges or dam releases where the water rises into the house within minutes.

First lets start with the objective: "Save my stuff"

Saving my stuff is quite broad. Saving all of my stuff is not realistic. This is where I failed during my first flood. I tried to save everything, but only that didn't happen - much was missed. And the things that I did save, were not the most important. Clearly I needed to prioritize. Here are the ways that I can think of to prioritize the things to save in my house.

• Irreplaceable -> Common
• Expensive -> Cheap
• Useful -> Unnecessary
• Floors -> Counters
• Front of House -> Back of House
• Nearest (to me) -> Farthest away

For me, after the first flood, ending up in a barren apartment with nothing to sleep on, nowhere to sit, and a pile of boxes that I was unsure of what was even inside them. I choose Useful -> Unnecessary would be our prioritization. This means I will save the beds, sofas and chairs first and the stuffed animals and Pokemon cards that litter the floor, would be last. 

Step 1: Determine the prioritization

Now that I have my priority set, how do I go about saving my household. Beds, sofas, chairs and tables take up a lot of floor space. How do I get them off the ground and how high do I have to put them?

Step 2: Determine the minimum and maximum height

For us, we have a 1 ft flood plan, it worked quite well during the second flood, where we only had 13", but would have failed massively during Hurricane Harvey where we would have had 51".  If I had actually looked at and understood my elevation, I would have seen that my BFE was 4' and I should have planned for that all along.

(I say would have had, because we elevated our house the day before Harvey hit. We had been in the process of elevating since the 2nd flood, and were scheduled to lift 1 week later, so we were able to accelerate the actual date when Harvey was developing in the Gulf of Mexico.)

Just listing out our beds, chairs, and sofas, I quickly realized that we didn't have enough "up-space". And if we used all of our countertops for those items, where were we going to put the second and third tier of stuff. We needed to create more "up-space".

The sofa is long and more things can be stored on top of it, so lets start there. For us, the sofa can perfectly span the kitchen counter to the island. This takes up minimal countertop space and the bridge that it creates can hold more things.

We also reasoned that we could bring in the outside chairs, which are waterproof, and then create additional "tables" using our doors. We took the doors off their hinges, using the chairs as the supports, and created bunches more up-space for our inside fabric chairs.

The king size bed was tricky. It is too big and heavy (temperpedic mattress) to try to move to a counter top. We just have to lift the whole bed. We have a collection of cinderblocks that now live under the bed. We remove the mattress and boxspring, position the blocks next to the legs of the bed, then lift the frame on to the blocks, then replace the boxspring and mattress. Then the kids twin beds can fit on top of the king.

After wading around thigh deep during the first flood, a friend asked me what I would have done if the water kept rising. At this time, I honestly hadn't thought about it. I didn't have a maximum water height in mind. Which in retrospect, is kinda terrifying.  We now have an inflatable boat (with a power AND hand pump). We have also talked to our high neighbors and have arranged refuge in their house should we need it.

Step 3: Define your constraints, then brainstorm around them

The plan is coming together well, but to lift the furniture every time it rains is a non-starter. We needed a plan that including timings that dealt with the fact that most of the rain events wouldn't actually flood our house. We want to avoid throwing out our backs if the water is not actually going to come into the house.

Plan Requirements: Save the things based on our priority, yet be mindful of the saving effort and probability of actually flooding. 

So our plan is broken down into phases to account for the Plan requirements.

Phase 1: Clean up the counters. 

Timing: Anytime the forecast calls for heavy rain / storms

Phase 1 involves cleaning the house. Clean off all of the counters and tables. Put away all of the stuff. No dishes in the sink,  no homework on the table, no unfinished project laying about, no laundry in the hamper, no clothes / stuffies on the floor.

Put away everything to where it is supposed to be. Clean and put away the dishes, do laundry, clean up all of the toys, put away all of the art supplies.

The purpose of this phase is to prepare the house in case it floods. We found that during our first flood, we were trying to save things, but there was stuff everywhere on the counters and it made it difficult to clean as well as lift. We also discovered that when we did salvage what wasn't damaged by water, that similar things ended up being boxed separately. (For example all of the things that were in the dishwasher, ended up being boxed and stored totally separate from the rest of the dishes).

If it doesn't flood, which is the most likely scenario, we have a clean house -WIN. If it does flood, we have created space to put things and have returned everything to its home so that it can be kept together.

Phase 2: Prepare to lift

Timing: Expected flooding event about to start OR water over the curb

Phase 2 is preparing to lift everything, but not actually doing any "saving" yet. For us, this means that we gather the outside furniture under the awnings around the house and near the doors. They are still outside at this point, but they are moved from their normal homes to a point where we can dry them off and prepare them to come inside.

We also gather the saw horses from the garage and the pile of cinderblocks and bring them inside.
We pay close attention to the forecasts / data (weather.com, weatherunderground.com, bayou level monitors) to determine how far Phase 2 goes.

We might determine that preparation is done at this phase, or we might determine that it is worthwhile to go ahead and get farther in the lifting prep work.

Going farther would mean that we would first move the cinderblocks to the areas that they would be used. We would start stacking the cinderblocks near the furniture in about the same size or related to the feet or footprint of the item. The idea being when we go to lift (phase 3) that we could pick up the item and put it down on the blocks fairly easily.  We are not actually lifting furniture at this point though (though moving cinderblocks is not exactly light work either).

We would stop and check the data again. If it is likely that flooding will not happen, we stop here. Sure there is effort to move the blocks, but we haven't rearranged the house yet. It is easy to undo.
If the data still indicates that flooding is possible, or our worry or PTSD is too high, we continue to build the platforms.

Platforms consist of saw horses and outdoor furniture with doors spanning them. We will take the doors off the hinges and create spans between anything that makes sense. This could mean we span the saw horses, kitchen counter and island, dining room table and buffet, etc.

Not only does this create a lot of up-space, but it could also save the doors if it does flood.

Phase 3: Lift

Timing: Flooding potential unknown / water past sidewalks

I'd be remiss, if I didn't include my favorite sound engineer joke (it might be the *only* sound engineer joke). Why do sound engineers say "Check 1...2...    Check 1....2...."? Because on "3" you lift. :)

Start lifting, but follow your priority. We lift our beds and sofas first, then the chairs, then the rest of the furniture. After that we start pulling out lower drawers, things still on the floor,  then lower shelves.

I have strong spacial packing skills (I'm always in charge of the dishwasher and the ornament box :)). I make sure that I'm maximizing our up-space.

NOTE: Anything wood will float! Free standing book shelfs are not safe place to put things, unless the bottom is weighted (also another good use for cinderblocks)

At this point, if it doesn't flood, we feel good that we practiced our plan. I find that working the plan helps me tremendously with the PTSD. I might grumble (alot) about un-lifting the furniture, but I (and my wife) appreciate having had actions counteract the worry.

The kids might or might not be able to help lift during this phase. If they are not able to lift furniture, have them take pictures..... lots and lots of pictures. I told my kids I want at least 50 pictures per room. Take 3 pictures from every corner into the room, then 3 more from every doorway. Take pictures of every shelf. Open up every drawer and take pictures. Take pictures of the art on the walls.
Please note, you might have to coach them that they should be clear pictures, and not hold down the button as they literally run around the room creating 50 house tinted blurs.

Phase 4: Water in the house

We found that phase 4 is an odd emotional time, as water is actually in the house. At this point we continue to lift the things that we have missed. Maybe we tackle the second or third shelves based on what the predictions are.

We had left one leaf of the dining room table for the kids to hang out in where they are safe and dry. There they are on devices to their hearts content.

This is also the point we, the adults, start taking pictures and notifying social media of our status. Inside the house, we would notice and record the areas that the water is entering as potential places to address in the future. This is also the time that we would call the insurance company, figure out our new temporary housing options, and connect with the contractor.

I told the kids that I was going to teach them a bad word. FUUUUUUUUU...... they said they already knew it. I said, well now is the right time to use it.... and you have to hold onto the U and really draw it out. And don't say it in school.

We discovered that during phase 4, we needed to lock our doors. During the 2nd flood, the water pressure forced an unlocked door open. For what it is worth, doors and walls act as a really amazing filter. The water, for the most part, is a lot cleaner if it has to work its way in, versus coming through an opening.

We also discovered that phase 4 might involve slashing the carpets. During the second flood, all of our furniture was secured in an up-space, but some of those spaces were on carpets. As the water rose, air got trapped under the carpet. Then when we would walk through the room, that air bubble would travel to our cinderblocks and platforms. So we took boxcutters and slashed holes in the carpets so we wouldn't cause our furniture to fall.

Finally depending on the data, we would start planning our abort procedure. We have not actually got that point yet during any of the floods, so I can only assume that we would blow up the boat and contact our neighbors.

Phase 0: When we are not flooding

So for all of the normal times that we are not flooding, here is some of the things that we have done to prepare for the next flood event.

• Take inventory pictures of the house every 6 months and store them in the cloud
• Bought a 5 person inflatable boat for the 4 of us and the dog
• Bought a portable pump to be used to help empty out water from the house. We use it to help move pooling water around in our backyard as well
• Bought a dehumidifier so that we would have one in case it flooded
• Scanned all of our photos and photo albums and stored them in the cloud
• Converted all of our VHS tapes to DVD and digital copies. Also stored in the cloud
• Everything stored below 2 feet is in a plastic bin
• Everything stored below 2 feet is not important to us or decently water resiliant
• We have some waterproof kayaking bags should we need to keep things dry during an evacuation
• Hired a plumber and made sure all of our area drains were clean and in full working order
• Don't keep any extension cords or power strips on the floor any more
• We have sealed up the places that we noticed the water coming through
• We have 2 sets of waders so it is easier (drier) to walk around during the flood

Collected ideas from others: 

Here is a list of ideas that other people have talked about

• Make sure that (at least some)  toliet paper is stored up high
• Get life vests for the whole family (and pets). Rescue boats often don't have them and/or if you have to make your way to a neighbors house.
• Move cars to higher ground, Uber home
• Valet park at the airport (making your car their responsibility), rent a car with full insurance coverage
• Empty buckets for make shift toliets

Fluent Conference 2017 - Personal Recap

Fluent Conference 2017 -- Personal Recap

The following is my summary and experience of my time at O’reilly’s Fluent Conference on 6/21 – 6/23 in San Jose, CA. This is not intended to be coverage of any of the sessions I went to, only an account of the relevant, interesting, and/or curious bits that I got from each interaction

---

Ignite Talks:

I enjoyed attending the ignite talks, especially since I was a runner up for presenting. The presenters were well rehearsed and did a great job in the rapid format that is ignite. I was able to take some notes on what I can do next RFP rounds to potentially get farther. 

One of the talks, which was particularly interesting was about communication and expectation settings

Good questions to ask: 

“What happens after I say yes?” 

“What happens if something goes wrong” 

Most of life is setting expectations and these questions help manage that

---

Lockdown: A security primer

I always enjoy attending security sessions, It is always good to refresh your personal paranoia. Most of this isn't new, but there are some new attack vectors that I hadn't heard of before. For example the SSLStrip was new to me, as well as some of the easy client side attacks that are available now. 

Apps are more complex, yet our security knowledge has remained relatively constant
“Security is like insurance: You only know how good it is after there is an incident”
Attacks are escalating in severity and the barriers to staging an attack are lower than ever]

• Man in the Middle Attacks 
• Defenses: everything needs to be https, specifically TLS not SSL 
• For man in the middle with SSLStrip, defense is Strict Transport Security (including subdomains) 
• Client Side Attacks 
• NEVER TRUST ANY USER INPUT 
• This includes styles 
• Opt in to software / libraries that do most of the user validation for you
• Be very careful about your browser plugins 
• Embedded malware 
• Limit attachment types (and do more validation than just extensions) 
• Optimize and re-process all images (especially dumping non-visual info)
•  Do not permit arbitrary HTML input 
• Whitelist content 
• Cross Site Request Forgery 
• Defense: CSRF Token with non-predictablity and per request configuration 
• Click Jacking 
• Defense: X-Frame-Options

---

Async in Js

This was a fantastic review of the pros and cons about the different methods of async in JS. I did not know about Async/Await or Generators. 

• Callbacks 
• Cons: 
• Pyramid of doom 
• difficult to decode
• inversion of control 
• (Note: Chrome has an async button in dev tools for debugging )
• Promises 
• Cons: 
• No cancellation 
• Lots of nesting 
• Inside of thennable is still complicated, 
• Too many libraries 
• Async / Await 
• Built into JS 
• Looks synchronous but non blocking 
• Still not cancelable 
• Generators 
• Uses yield and next keywords 
• Easy to read – looks synchronous 
• Pause and cancellable

---

Keynotes

 The keynote format had 5-8 mini sessions inside the keynote. The theme of the conference was "Build a Better Web" and obviously most of the keynotes focused on that. 

• Are we really taking advantage of the technology? 
• “Whether we are CSS or JS we are united by our users” 
• On a screen, we are processing in the visual cortext, which means it drives out all other brain activity 
• Apple ear buds are more than headphones, it is the start of implantable computers 
• Could we interact without a screen? 
• Could an always listening device (like Responsive Voice.js) give us a summary of the conversations of our day? 
• Or help give insight into our mood? 
• Could it make us better humans? 
• Building a culture of collaboration in devops 
• Things I need to look into more:
• Atlassian Dev Ops Playbook 
• Team Help Monitor 
• Glitch.com is a focus on tools and the community, it allows for remixing projects for API and community 
• The unsexy pillars of the web:
•  Security, Accessibility, And Performance 
• “You can’t fix what you can’t measure” 
• We live in a web bubble of privilege of speed, access, and availability. 
• “Data changes irreversibly into information can can not be extracted from the information”. It would be like asking “what were the dimensions of this melted ice cube” or “how much milk was used to make this cake” 
• Accessibility is about software quality

---

Functional JS Data Structures

Excellent description of how functional JS works, especially with immutable arrays. The presenter was super passionate about functional JS and was a joy to listen to.  Most of the talk was defining fuctional data structures vocabulary

• Perstistant data structures 
• Path Copying & Structual Sharing 
• Trie => retrieval tree 
• Bitmapped Vector Trie (32 bit branches are ideal) 
• Hash Array Mapped Trie 
• Libraries
• Immutable.js (sort of OOP) 
• Mori.is (more purely functional and based on clojure)

---

14 ways to bounce a ball (through code)

I had higher hopes for this session. Having taught Flash based animations for nearly a decade, and having left that scene a couple of years ago, I was hoping to get some intel on the tools that people are using to animate. Overall it was nothing more than a list of code based tools to animate. The presenter started out with a client created animation in Adobe Edge Animate, which of course has terrible, not maintainable output. So the presenter went on a quest to discover a better way to animate with maintainability.  Ultimately despite the research, could not create the richness of a visual animation tool, and used the Edge Animate output with all of its inline unmaintainable ugliness. 

But for reference here is the list that he talked about. 

• Browser 
• Vanilla JS 
• Css Animations 
• SMIL – deprecated 
• Web animations API 
• HTML5 video tag 
• Animated Gifs 
• Tools 
• Greensock 
• Velocity 
• Jo.js 
• Anime.js 
• Other 
• Jquery Animations 
• P5.js 
• D3.js 
• Matter.js 
• Animations Paradigms 
• Math (equations)
• Physics 
• Flipbook 
• Keyframes

---

CSS WTF

Being a CSS novice, this was a great session to learn some of the less used features of CSS. I especially liked the alternative (better) option than important. 

• CSS supports counting, and could be used for counting errors 
• UI selectors that are not common 
• placeholder-shown 
• user-error 
• indeterminate (checkbox w/ slash) 
• read-only 
• read-write 
• Smell: use of important 
• Instead of important, use multiple class decorations 
• .disabled.disabled is stronger than .disabled 
• #theirWidget#theirWidget doubles the weight of the selection 
• CSS supports blendmodes
• CSS supports shapes 
• Clip-path (shape or SVG) 
• Shape-outside is the HTML container shape for word wrapping 
• CSS supports masking 
• CSS “Material Design Icons” 
•  Font-family: “Material Icons” 
• Transforms words as icons 
• CSS as a modernizer with @supports

---

Schema First Development with GraphQL

I have heard around the office about our GraphQL, I didn't know much about it, so this was an excellent primer. 

• GraphQL provides an intermediary interface contract between the front and backends 
• Better then REST because it reduces round trips and simplifies maintenance and provides only the data the client needs 
• It is a specification not an implementation 
• Schema with strong types 
• Query schema 
• Results 
• Requirements 
• Hierarchical 
• Product centric 
• Strong types 
• Client specified queries 
• Introspective 
• “Prioritize the developer experience”

---

Keynote Day 2

• Diversity and Inclusion Post mortem 
• 10 years and $500M invested and virtually no improvement 
• What went wrong 
• We have not defined good outcomes 
• We have not created any methods of accountability 
• Not measuring inclusion, retention, promotion, or equity 
• Not monitoring all intersections 
• Too much reliance on Unconcious Bias Training 
• Not responding well to reports of harassment 
• No safe methods to speak up 
• You can’t get comfortable on the web 
•  Best photo on slide of whole conference =>
  
• You don’t need to know everything, but make sure you know your foundations well
• why-learing-to-code-is-so-hard:

•  On Community and Dev 
• For humans communication is everything 
• Technology isn’t neutral 
• Commuinities break from lack of ability to deal with conflict 
• Commuity is the thing shared with the person you like least 
• Community is a group organized for mutual survival of their ideas 
• Frustrations 
• We are repeating the same ideas that were had at the dawn of the computer age, we have better implementations and new names, but the ideas are the same 
• “Don’t frustrate your users” 
• “Never underestimate mobile” 
• Embrace good ideas 
• Don’t take tech as a goal – tech is tool 
• Progressive Web Apps 
• This is the new buzzword, means app like experience in a mobile browser 
• Note: Lighthouse is a chrome canary option in dev-tools

---

Accessibiltiy testing:

There was a heavy Accessibility (a11y) theme. It is nice to know that there are many automated testing tools for it. 

• You can automate 30-50% of a11y issues
•  Npm install axe-core for unit testing a11y in interaction / focus API, text alternatives, and ARIA states

---

Source Maps demystified

This was a deep dive into source maps. It was interesting discovering how they work. 

• “JS is the assembly language of the web” 
• To keep maps secure, you can change the domain (last line) of a source map to vpn or localhost

Agile simulations - lego game

I teach an introductory class at University of Houston. This semester I did half technical and half soft skills (like Agile). 

Given that I have a 3 hour class, I had the ability to try out the Agile simulation using legos ( http://www.lego4scrum.com/ )

I had introduced agile to my class, but didn't go into any depth about Scrum or any of the other flavors. We basically had a conversation about if you were going to spend a lot of money on something that you were unsure about the final result (like a full sleeve tattoo), what steps would you go through to ensure that it matched your expectations. 

All of this saying, they were not familiar with actually implementing agile or scrum. 

I brought in a huge tub of my kids legos and set them in the middle of the class. I also brought 8 smaller storage containers that would allow the students to take scoops of legos back to their desks / work area. 

I introduced the project explaining that we were going to be building a lego city, my lego city, and that I recommend that they break into small groups of 3-5 people (class of 25, although about 50% decided to not show up), and rearrange the furniture as they saw fit to prepare to build the city. 

While they moved a couple of desks to sit on the floor, they generally used this time to come scoop up containers full of legos to take back to their spots. Meanwhile I covered the "land" with paper.  I informed them that this paper was were the city was to be built and that for certain things, like roads, it was okay to draw them on the paper rather than make them out of legos. 

Then I introduced the things that I wanted in my city. I had, in my head, organized them by potential teams, but I never mentioned that to the class.  I also intentionally didn't mention the acceptance criteria unless asked. 

• Living: 
• 4 x 1 story homes 
• Must have a window 
• 2 x 2 story homes 
• Twice the size of a 1 story home 
• Apartment 
• 3 stories, outside stairs 
• Recreation 
• Park 
• Trees 
• Playground 
• Stadium 
• Open roof 
• Zoo 
• One animal and enclosure 
• Business 
• TV station 
• Satellite dish or Broadcast tower 
• Retail shops 
• 4 doors, each shop a different color 
• Hospital 
• Has a red plus on it 
• Education 
• Elementary school 
• Has a fence 
• University 
• Looking down on the top of the univeristy it should look like UH 
• Worship 
• Religious symbol on it 
• Infrastructure 
• Power station 
• Wind turbine (ie propeller) 
• Waste water treatment 
• Visible Pipes 
• City Hall 
• Dome on top 
• Transportation 
• Mass transit 
• 8” and 6+ wheels 
• Dedicated bike lanes 
• Barrier from cars 
• Roads 
• Drawn + 1 car 
• Airport 
• 1 plane + terminal
  
  

I wrote each item on sticky notes, and used Team estimation game to size the stories. (Think bubble sort). We were about 60% of the way through (when we got to the university), that they started to ask about what I was expecting for the university.

Since we had been sizing the stories as we went, we decided that we needed to start over. This time through we talked about the acceptance criteria before they determined left, right or same for the sizing.

Once all of the stories were grouped and positioned, I assigned Fibonacci numbers to them for the points. We had 1,2,3,5,8,13,21 and 50.

I then organized the stories into a priority order. (I wished I had taken a picture of the final priority order before doing sprint planning). Meanwhile I had told the class to figure out if they were going to represent themselves as the separate teams, or as the company as a whole and to determine what they think is a good number of points to take on for the first sprint, which was 8 minutes.

We had 4 minutes for sprint planning, where the class, having decided that they were one company (instead of 5 teams) choose the items from the backlog that they were going to deliver for the first sprint. (They completely ignored the priority order and choose what they wanted to work on, including the lowest priorty highest point story). Also somewhat independently, some of the students had already started building, while others where choosing the stories from the backlog.

We started our first 8 minute sprint with a 106 point commitment. When the bell rang, there was nothing on the "land", so they got zero points. They were pretty disappointed, because they didn't realize that their structures needed to be on the table by the end of the sprint.

We did a 4 minute retrospective, where again 5-8 students participated and another 4 minute planning, the others continued building. The planning was essentially moving over all of the unfinished stories, but they did add another 3 point story. Sprint 2 started with a 108 point commitment, but many of the structures were "done" and on the land within the first couple of minutes.

The different groups, not surprisingly didn't talk to each other, and using the single story house as a scale reference, the "3 story apartment" was about 1/3 the size of a 1 story house. The hospital was about 1/2 the size of the house. The stadium, (the lowest priority and highest points), was done and used up a significant amount of lego bricks (that they would want for the next round).

Sprint 2 ended with 96 points of the 108 awarded. The Sprint 2 retro was largely ignored as everyone just kept building. One person participated in sprint planning. They didn't move any of the unfinished stories over, but they did add 2 more stories. Ultimately they ended up committing to 6 points but completing 46.

Here is a photo of the finished city.

Front L to R: Water treatment, power station, place of worship, university, stadium, hospital, airport
Back L to R: zoo, elementary school, playground, 1 story house, tv station, 1 story house, 2 story house, apartment

From the debriefing after the last sprint, here is what the students said were issues, especially after talking about some of the things in red from above:

• knowing the scale of the buildings
• not knowing what the other groups were working on
• Initially there was no talking, but it really improved towards the end when the groups started working together
• Pain point: What does the client expect to see
• Pain point: Client Priority
• Pain point: Dimensions / scale
• Pain point: 8 min sprints were stressful
• Pain point: looking for resources / running out of resources

We talked about how they were overall more interested in building (playing with the legos) and less interested in understanding the clients needs. We talked about how they were also skipping the planning, which helps communicate expectations to the client, as well as the retro which would help them improve the internal processes.

We then talked about variations and improvements. Interestingly enough most of them expressed that even though there were improvements that could have happened in the delivery of the exercise, they valued the mistakes that they made as it were, and ultimately decided that I should not add any more explanation or details the next time around.

Overall, it was an incredibly useful exercise and discussion around teamwork and communication with the client.

Treadmill desk as a software developer - injury

So a couple of days after my last post, I did have a treadmill related injury.... sort of. It wasn't cringe-worthy youtube kind of injury. It wasn't even an injury that was ON the treadmill.

I was turning left to go into my closet and something BAD happened within my calf. It was crippling and I could barely put weight on that leg for two days. I used a lot of RICE (Rest, Ice, Compression, Elevation) and was able to start bearing weight again.

My theory is that being on the treadmill, is that given it is a very straight and even surface for such long durations (10+ miles) and low impact, that I have been over developing my "walk straight muscles". So when I went to turn a corner, my now weaker "turn muscles", were literally squeezed out of place by my others.... It is my theory anyways.

Some loose proof that I have that supports this, is that while I was recovering, I was acutely aware of variations in the ground, unevenness, and different textures.

So now that I'm recovered and nearly able to to 10 miles again, I'm spending more time on the treadmill walking sideways. I'm also stretching mulitple times a day, using foam rollers and hard massage balls, and making sure that I spend more time off the treadmill and outside on the un-even sidewalks.

Treadmill desk as a software developer - 3 month

So we've been going on three months now. I'm able to walk about 30K (~14 miles) steps at least twice a week without feeling too bad. I've killed my tennis shoes that I bought during the summer, so I guess one side effect is that I'll be going through shoes much faster now.

Things I've noticed:

• There was an online conference, that I was watching while I was working. This was great, but given that I was already switching between 2 engaging contexts, I didn't notice that I was walking, and I over did it again (37K steps, 2 days in a row before I noticed what was happening - I guess that means I'm getting better endurance). 
• On the day that my fitbit battery died, I wasn't motivated to walk until it was charged. Apparently I definitely want my steps to "count" 
• Grading my class assignments is MUCH more enjoyable while walking. Previously I could barely get through 1 without needing a break, now I can do them all in one "sitting"
• There is a nice pile of dust, crumbs, etc that ends up on the mat at the back of the treadmill. 
• I hardly ever sit down anymore at work. Although I do still stop and stretch occasionally. As I try to hit 30+K once or twice a week. 
• I keep a set of hand weights on my desk for meetings, where I don't have to participate or take notes. 

Overall I've lost 12 lbs (fluctuating wildly as we go through Thanksgiving and the holidays :))

Still nothing but good things to say about the treadmill desk.

What I learned about coding from 5th graders

So today I was mentoring / volunteering for Kolter's Hour of Code (www.code.org) and I got to observe 3 different 5th grade classes come through to try to program a visual game like Angry Birds or Lightbot.

Just for context, both of these games involved sequencing directional puzzle pieces to perform a task. For Angry birds, you would move the bird towards the pig, and for Lightbot, you'd move the robot along a grid lighting blue squares.

Not surprising nobody read the directions or prompts before diving right in. The part that I found interesting, was that very few would try to solve the problem in small steps.

Nearly every pair (they were pair programming.... woot!) whether they read the prompt or not, tried to solve the entire puzzle before hitting play. It of course wouldn't work. Then they'd throw nearly the whole thing away and create another complete solution, which also wouldn't work.

One of the things that I coached them on was to test often.... put down one or two commands and see where you are on the sequence. Basically to get faster feedback.

So I'm curious as to where in life do we learn that we have to solve the whole puzzle at once?

Treadmill desk as a software developer - 1 month

Last month I posted my first week experiences on my treadmill desk: http://squaredi.blogspot.com/2014/09/treadmill-desk-as-software-developer.html

Now I'll be moving into my one month review.

My metrics are:
Steps: 19.3K / day avg (darn weekends killing my average :) )
Distance: 11 miles /day avg
Max steps / distance: 31K / 14 miles

So far I've lost 5 lbs. I'm stretching every night. I'm still taking breaks as needed, but overall I'm taking standing breaks instead of sitting breaks. I have to have some foresight into the evening plans though. If there is a kids soccer game where I'll be helping run around, or a dance lesson that I'm teaching, I will need to stop walking early afternoon and sit so that my legs are capable of the evening activities.

I've noticed an increase in my endurance, where I've gotten 30K steps in a day  a couple of times now and not been sore. I was also able to run the length of our street. (Note, I'm not particularly fond of running, but I was late for pickup from school. I was happy that I made it the whole street length, which is longer than I've run in recent past).

Given that I'm farther from the ground in the office,  both with standing, and with the small step up onto the treadmill, that fans alone don't cut it. I've had to lower the A/C to help keep the room comfortable.

But the bottom line is that I'm loving it. I love being able to walk this much everyday and that it is not something "extra". I love that I can walk and work at the same time. I love that for a having a desk job, and working from home, that I'm lightly active to fairly active 6-8 hrs a day.

Treadmill desk as a software developer

Background:
I got a treadmill desk and will be writing my review from the perspective of a software developer who works from
home.

All metrics are tracked from fitbit, and just as a baseline, I average about 10K steps a day without the treadmill, but it has taken some dedicated effort.

Day 1(Thurs)
Based on the corner of the office that I put this in, I noticed that my overhead ceiling fan was less effective. I didn't break a sweat on the treadmill, I just needed to move some floor based fans to me. (FYI all of the computer equipment in my office gets warm, and instead of air conditioning the whole house, I use several fans in my office. )
I found myself looking forward to meetings, especially those that I wasn't an active participant, so I could up my speed to around 3 mph. If I'm an active participant I found that 2 was about right for me.
The treadmill is super quiet and my colleagues couldn't hear any background noise coming from my end of the call. Personally though, due to my own cognitive processing inability to separate noises, I found that I needed to move to loud speakers / headphones so I could hear better. But as I said, even though my hearing is fine, I know that I'm not able to separate sounds, so the treadmill, fans, and meeting was slightly indistinguishable for me.
I didn't get bored as much, so I found myself talking less breaks. I also noticed that when I did feel like taking a break, there was a "stop" action. Literally pressing pause on the treadmill, was a more commitment to the break, then my usual get up to go to the bathroom or grab a snack from the kitchen. 23K steps - a little more than double my average up to that point

Day 2 (Fri)
Okay, I was a little stiff today. Clearly I pushed myself too hard. Today my pace was more around 1.5 for the whole day. I found myself inverting my day. Previously my breaks were to get up and walk around. I'd go to the farthest bathroom in the house, or to walk around and pace while eating my lunch to get more steps in. Today I found myself not doing those things. I even took a couple of breaks just to go sit on the couch for a couple of minutes. Then around 2pm. I couldn't walk anymore. I moved the laptop back to my desk and sat for about an hour or so. That night I had to stretch.

Stretching isn't a bad thing, it means that I'm actually doing something with my muscles. 22K steps, which is still more than I was planning. I was hoping to only get to around 18K today.

Thankfully a weekend is coming up, so I can start fresh again on Monday.

Day 3 (Mon)
Spent all day at 1.5 MPH. Still needed a significant sitting break around 2 pm. I've been drinking alot more water, because I also realized that I wasn't drinking enough the other days. It is really easy to overdo it, especially if you hit flow for a couple of hours. One tricky bug and 4 hours later I've walked nearly 6 miles. Unfortunately I hit 30K steps today. That is my all time high. I stretched a lot, but still woke up sore.

Day 4
Today I'm going to sit through the morning, and then start walking for my noon meeting. I only walked on the treadmill for 2 hours today, but since it was mostly a non-participatory meeting, I still managed to eek out 20K. In addition to stretching I had to use my wife's foot massager.

Day 5
So here is my new plan: I'll start the day sitting, then probably just after lunch I'll start on the treadmill. I'll put in an hour or two, then move the laptop to the desk. I'll leave the laptop unplugged and when I run low on battery, finish out the rest of the day on the treadmill. That should get me around 20K steps.

Day 6:
Throwing in some tech geekery. Given that I'm walking for a couple of hours and sitting for a couple of hours; I've got two separate external monitors that I'm hooking up to. The one on the treadmill is 25" and the one at the desk is a measly 17". It was very annoying that whenever I switched, I lost the locations of my windows. Be on the lookout for another blogpost regarding Slate for managing my Mac windows state across multiple monitor configurations. I just started with it today, and it is awesome, but will need to dive in more to be able to write up the post.

Week 1: Metrics
19.5K step average
62 Miles



Day etc.
I'll do a followup post in a couple weeks, after a month or so of use. But as of today, I'm still following the sit in the morning, walk in the afternoon approach. This works well for me, that way I'm walking when I'm most awake / alert. I do need to stretch every night, which is not a bad thing. I'm feeling really good and haven't noticed a decline in productivity - actually I feel more focused when I'm walking. I have discovered that if I'm in the middle of something, and don't want to shift spaces from the treadmill to the desk, I'll sometimes just stand at the treadmill for a break. That works better than I expected. It is quiet enough to use at night with the kids asleep in the next room, but the kids informed me as they were going to sleep, that if I had my speed too high, that my steps were too loud (me walking, not the machine). I had one co-worker that could hear the treadmill  (my steps) when I wasn't on the headset, but just on the computer, but when pushed, she said she really had to strain to hear it and it was very faint.

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

• Java Performance (Specifically Chapters 3,5,7... and a 2nd edition should be coming out soon)
• Functional Javascript
• Javascript Allonge
• Mistakes were made (but not by me)