Sunday, October 15, 2017

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

Here is my presentation that I gave at Houston Tech Fest (10/14/2017).

It attempts to describe the agile principles that are naturally applied 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.

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 is the full slide deck.

Monday, June 26, 2017

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 
      • 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


     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 
        • 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) 
      • (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


    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

    Wednesday, April 13, 2016

    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 ( )

    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.

    Wednesday, January 14, 2015

    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.

    Wednesday, December 17, 2014

    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.

    Monday, December 8, 2014

    What I learned about coding from 5th graders

    So today I was mentoring / volunteering for Kolter's Hour of Code ( 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?

    Tuesday, October 7, 2014

    Treadmill desk as a software developer - 1 month

    Last month I posted my first week experiences on my treadmill desk:

    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.