Welcome to TiddlyWiki created by Jeremy Ruston; Copyright © 2004-2007 Jeremy Ruston, Copyright © 2007-2011 UnaMesa Association
Professional development - week of July 27
!!! Html5 canvas
It's been interesting and somewhat challenging to get all this stuff running. I don't feel like I've really improved my skill much, but I have definitely increased the breadth of my knowledge. Not bad for a guy who couldn't really grok GWT a few years ago.
!!! Simplify and Explain
Enjoyed Beyer's session on the quick hit and getting the big idea out there. Good advice I can use, like shut up after talking. And I've latched onto this idea of trying to get other people to finish my sentences. Too often I put all the words I can out there, like the best thing the conversation can use is a "yup" or "that's pretty much it".
!!! Crucial conversations
Read ch8 and ch9. The book has gotten much better. Actionable things I can try - great!
!!! Deep Dive apprenticeship
Good session pulling the interviews into a cohesive framework. Here are the "phases" and here's the goals for each. Looking forward to next week when we try it out on Nick and Nicole's memory of past deep dives.
Professional Development: Week of July 5
!!! Two stack overflow answers
http://programmers.stackexchange.com/questions/288990/do-objects-in-oop-have-to-represent-an-entity/289013#289013
http://programmers.stackexchange.com/questions/289401/is-there-a-practical-way-to-manage-a-physical-task-board-if-one-or-more-scrum-te/289425#289425
Felt good to share some knowledge - mostly concerned that I spend a lot of time talking, far less time doing.
!!! Crucial conversations
Read ch4 and ch5. Some of it really resonates, but most of it doesn't.
!!! Met with Euler
Enjoyed the conversation, but not sure what the goal is. I'm sure I could use mentoring in the things Bill is good at. How do I practice?
!!! Deep dive apprenticeship
Our current concern is understanding the flow and when to transition between stages of the deep dive. This is somewhat frustrating because it seems intuitive, so how can it be taught. Additionally we're skipping over the easy productive work of making a playbook and focusing on the deeper issues which don't have clear solutions. I'm going to concentrate on the pattern matching theory with regards to intuituion. I feel like the right answer here is interviewing Nick and Nicole and getting them to focus a bit more on when they know enough is enough. Our homework for this week was to think about the stages of a deep dive, which I think I have a handle on, but honestly have never paid much attention to.
Current frustration - how do I find more opportunities to practice?
!! What did I accomplish?
* Can't think of anything
!! What did I want to work on, but didn't?
* Just a vague desire to do something. I've been wasting a lot of time lately.
!! What is still important?
* Hmmmm....
!! What did I waste time on?
*imgur, questionable content, twitter stalking. Nothing useful.
!! What Did I Learn?
* My completionist tendencies are dangerous
* Started reading Thinking Fast and Slow. Not sure I've learned anything yet, maybe I'm not paying attention?
!! Next week's experiment
* WIP limit on a project list? So things move back and forth to someday maybe?
* Need some sort of heartbeat rule as well. I don't want to fill a slot with somehing important but never worked on.
* I think there's something I'm missing. Like my next action is too big? Can I get to a 5 minute next action? Then If I limit to 3 projects, that's 15 minutes a week.
!! What if?
* Thinking about talk ideas. Don't feel like I have the experience to put it together.
!! What did I accomplish?
* Gave my vagrant talk!
* Met new people, got introduced to some new things
* Really excited about how awesome the conference was. Great crowd, enjoyed talking to almost everyone. Feel great.
!! What did I want to work on, but didn't?
* Pretty stoked that my talk got done. Not much else to complain about.
!! What is still important?
* Need to upload my slides and tweet them out
!! What did I waste time on?
*Besides avoiding my talk for two months?
!! What Did I Learn?
* All sorts of cool stuff. Hoping to come back and write much better cukes that are declarative and focused. Want to play with the browser tools and cucumber.pro. Maybe learn some cucumber-elixr?
!! Next week's experiment
* Maybe setup a projects list like David Allen talks about (note: Find GTD book)
!! What if?
* I'm back to the place where giving talks sounds like a great thing. But I know I still don't love putting them together. So how can I make that less painful?
First try at weekly journaling.
!! What did I accomplish?
''How big should an accomplishment be?''
* Sorted out test data cleanup and got regressions back on track
* Started exercism.io - did three exercises
!! What did I want to work on, but didn't?
I'm really disappointed about GiveCamp. I wasn't assigned to a team and failed to find a way that I could be valuable (other than gofer). I was hoping to give back or at least learn something. All I really learned is that my skills don't translate well to throw up a webpage in 12 hours. The worst part is I don't have any real interest in learning those skills - I don't care about static content and hosting. I know I can contribute to open source, but at some level I want something I can point people to and say - 'I built that'.
I'm also not sure how to balance all the stuff I want to do. I'd like to:
* Work out
* Get home early and play with Alec
* Let Laura sleep past 6am
* Have a productive day at work
* Learn something new
* Work on finances app (or other gem)
* Mentor someone
* Catch up on all the cool stuff other people are talking about
* Play basketball
* Do my other chores
That's like a 20 hour day. And I want to do these things every day. Oh and maybe do something mindless every once in a while
!! What is still important?
I really need to find a way to workout regularly. It doesn't seem like it should be that hard to find 20mins a day to do a little cardio.
I also need to start on my vagrant talk.
!! What did I waste time on?
I tried to catch up on a number of internet things I had tagged to follow up on. The javascript koans were largely a waste, as well as venkat's polyglot talk. I'm really disappointed with screencasts and conf talks because they take up an hour where I have to pay pretty close information and I might get 5 mins of knowledge. But I don't know until I put the time in and I'm such a completionist....I just don't know what to do.
!! What Did I Learn?
* PHP basics
** PHP isn't very interesting. I shouldn't be afraid to jump into it, but given that people weren't knocking it out in 30 seconds, there's probably some subletly I don't understand. Or my experience with other server-side scripting just makes it uninteresting?
* Intro to AntiFragile
** This is very cool. Not sure what to do with it, as I'm tempted to draw conclusions that may or may not be the point. Like tying TechSafety to AntiFragile - is a focus on safety the same thing as adapting to adversity?
* Intro to TechSafety
** Nice idea. Not sure how to tie it back to the lean ux focused principles I'm also learning. When is making quality the key driving focus useful for a startup situation? I think some quality requires more strategic thinking than may be appropriate for a biz that needs to survive to next week.
* Tried exercism.io
* function_module or module_function for static helpers
!! Next week's experiment
* Do 20 mins of cardio after work M-W.
!! What if?
What if I knew what to ask about?
Back fill off of notecard
!! What did I accomplish?
* First deep dive
* CleAg workshop
* Lightning talk
!! What did I want to work on, but didn't?
Better lightning talk.
!! What is still important?
!! What did I waste time on?
* TV
* Workshop slides
!! What Did I Learn?
* Talks take a lot of time
* I'm still scared of estimating
* Scared of making architecture decisions without trying things out
!! Next week's experiment
* Experiment with remote work
!! What if?
What if I could work effectively from anywhere?
Mary Thorn
!! Case 1: Greenfield
Before:
* New project
After:
* Made automation part of done
* PO wrote gherkin
* Dev/QA pair to get cuke ready before work started
* PO wanted to see cuke go green before accepting
!! Case 2: Backward Implementation
Before:
* Team was not building the correct thing
* Lots of rework
* No idea what QA was testing
After:
* QA wrote gherkin
* QA sent feature files to DEV/PO to verify assumptions (probably not read)
* Developers write unit tests from feature files
* Manual testing of feature files
* Eventually got PO involved upfront (lots of begging)
!! Case 3: Hybrid
Before:
* Waterfall project
* No colaboration
* Ineffective communication
* Crazy requirement specs
* No test automation
* Lots of issues
After:
* BA wrote Acceptance Tests
* Discussion with Dev + QA
* Estimation based on feature file
* Devs code and handover
* Manual testing of cukes
* Decreased bugs SIGNIFICANTLY
Richard Lawrence
There are 2 kinds of weaknesses - opportunities for improvement, and those that teach us what the thing IS (what it is good for)
!!! Weaknesses
1. Gherkin isn't a powerful language (No macros or loops)
* Good! These things make for bad expressions (Cukes are meant to be read).
2. I have to describe things in two places (Why can't I just put the english with the code - rspec)
* Separate things to TALK about vs implementation details
3. Step defs are global
* Forces you to use ubiquitous language
4. Regular expressions
* It's not that hard!
5. My stakeholders won't write feature files
* Don't let customers throw things over the wall
Christina Aldan
@luckygirliegirl
#5TIPS4EQ
!! 5 tips
# Create space - Pause
# Shift Perspective
** If you can't see it from someone else's perspective, you are holding yourself back.
# Get curious
# Make a List
# Be engage-y
Starts with you - self-reflection
"You still have to show up"
Not talking about disconnecting - "I tried fake it or make it, it only works for two months. You can't contain that crazy"
!!! Self assessment
!!! Behavioral Self Control
4 superpowers
Thoughts
Emotions
Words
Actions
//sounds like think feel act//
!!! Integrity
* How you behave when no one is watching. How you do one thing is how you do anything.
Two thoughts:
Looking for an idol: Realizes code is writing, good at empathy, codes 90% of the time while still being an influential and useful person, realizes coding is usually the least important thing, but has managed to get everything else right so that coding is joy. Understands that being part of a team is teaching and knows how to present information in such a way that it's understood and need not be repeated.
Coding analogy
Eggs, steel blocks / rocket precision machinery, legos, new
http://www.jbrains.ca/permalink/a-critical-step-towards-noestimates
Change language to one of budgets: //I can afford to spend 2-3 days on this task//
* Parkinson's Law
** work expands so as to fill the time allotted
** "we need something in 2 days" leads to conversations about options
* Task -> Outcome
** Tasks in a plan usually lose sight of the desired outcome
** If we can't get done with this task in 3 days, "what can I give you instead?"
** Lets not argue over the fact that we're lousy at estimating
* Cost -> Value
* Estimates focus on cost and when they turn out to be wrong we focus on "broken commitments" rather than the value of doing this in the first place
* "If you always knew that this task would cost 2 weeks (revised estimate), would you have invested in it anyway?
Henry Ward - CEO eshares
!! How do I get employees to perform better?
Tell them what they are doing well
* Don't minimize their bad work, maximize their great work.
* Positivity creates more positivity
!! How do I give negative feedback?
By being curious
- Assume you hired rational human beings that want to do a good job - what's keeping them from doing it?
- Have a true curiosity for this - why did you do x?
!! How do I decide what to delegate?
Delegate the work you want to do
// I hate this, but realize it's the correct answer//
!! How should I prioritize?
Fix problems. Then prevent problems.
"Sprint to the fires"
!! How should I grade employees?
Dont. Teach them to self-evaluate.
Scoring is easy for orgs to sort and filter, but does the employees no-good.
Ask them how they think they're doing and then offer feedback on that.
!! When do I fire somebody?
When you know they can't succeed
- Do not build a case for firing (perf improvement plans)
- Do it swiftly and humanely
!! How do I fire somebody?
By apologizing for our failures
"Unless you were lied to, it is your fault you're firing him". You either hired incorrectly or didn't support him, either way it's your fault.
!! Why can't I just tell people what to do?
Because the more responsibility you have, the less authority you have.
Employees don't have loyalty to you, they have loyalty to their immediate manager.
You need to work on influencing rather than commanding.
!! How do I know if I am a good manager?
Employees ask you for advice
!! How do I know if I have a good management team?
Shit rolls uphill.
If you delegate all the work you want to do, all you're left with is the stuff no one else wants to do.
http://www.enterprisetech.com/2014/11/14/rare-peek-massive-scale-aws/
<<<
The above shows the US East region in Ashburn, Virginia. It has five availability zones, and these are protected areas that are isolated from each other by a couple of kilometers and linked by high-speed, low-latency networks where synchronous replication is possible but there is enough geographic isolation that the odds of two availability zones (housing multiple copies of your data and applications) are very small. The AZ units are connected by optical fibers that use dense wavelength division multiplexing (DWDM) to transport packets between the AZs in the region, and in the case of US East, there are 82,864 fiber strands. The AZs are usually under 1 millisecond apart in terms of latency and are always less than 2 milliseconds apart; this speed is what allows for synchronous data replication, since committing data to a solid state drive takes 㠷ait for it 㠢etween 1 and 2 milliseconds.
<<<
<<<
Now, drill down into one availability zone. The datacenters inside the availability zones in US East are about a quarter of a millisecond apart on the network, and no datacenter spans more than one zone. In fact, as noted above, an AZ can have multiple datacenters, and in fact, US East appears to have ten datacenters even though the chart above says some AZs have as many as six DCs. There are redundant transit centers into the availability zones. So Amazon can lose a transit center and multiple AZs and everything keeps working.
<<<
<<<
A single datacenter has up to 102 Tb/sec of bandwidth allocated to come into it 㠦our times the aggregate inter-AZ bandwidth across the US East region, and Hamilton adds that the bandwidth inside the datacenter is 췩ldly higher�han this 102 Tb/sec.
<<<
Jerry D'Antonio
@jerrydantonio
github.com/jdantonio
!! From Clojure
* Future
* Agent
** Queues up operations against a value
* hamster gem
** high-perf data structure - immutable
*thread_safe library
** threadsafe agent and hash. Not immutable.
!! From javascript
* Promise
!! From java
** ScheduledExecutorService
** TimerTask
!! From erlang/scala
** Actor
!! From F#
** Functional actor style
!! From Erlang
** Supervisor
!! Concurrent gem
** has future
*** takes observer
** has agent
*** takes observer
** has promise
** has ScheduledTask
*** Written like a future / same API
** TimerTask
*** takes observer
** Actor
***Actor pools sharing a mailbox
** Channel
*** Functional actor
** Supervisor
*** Can add actors and timer tasks
Even after 15 years, there's a lot of zealotry around pair programming. Opinions range from "I'd never work on a project that didn't pair" to "Pair programming? You mean cluster disaster?".
!!! Issues
* Expert Beginner trap?
* Finding Mentors?
!!! Questions
* How do you know when you've "graduated from an apprenticeship?"
** Smooth transition to full-time work
** Consistently giving back and living up to it
** No longer focused on learning
* Where do I start?
** A fear / personality trait of knowing the whole thing
** Pick one!
** Control your curiosity
* Right tool for the job?
** Don't be afraid to experiment
Josh Sureth - Typesafe
Add more actors - fragment - to specialize information (scatter phase)
Gather phase - re-aggregate back up the heirarchical tree
It's cheap to make an actor - create a new actor to handle results (gatherer actor)
Scala - Akka - create lots of layers of actors to handle recovery and keep the core functional
Akka clustering - works a lot like Riak
- Supports automatic cluster membership
Weird code
{{{
context.actorFor(rootactorpath(a) / "user" / "singleton" /"search-tree" )
}}}
Clustered routing options
Metrics based routing
Recap:
- Partition state of the system into small pieces - improve concurrency
- Communicate with immutable messages
- Spawn new actors to track temporary state or do dangerous things - keeps the parent safe
- Design app as a topology
- Partition threads on the topoology
** Can do the same thing with roles - these 10 nodes are for incoming requests, these 20 nodes are for data processing, etc
* Bubble errors on the topoloyg
* Keep singleton actors on the leader
* Avoid excessive inter-node messaging
** Use statistics based routing
** Fragment in 'large pieces'
* Allow time for cluster convergence and fault detection
** new nodes think they're the leader until they find out otherwise
Key Point - Design a system that can recover from failure (and be concurrent)
* auto healing, auto
'' Links ''
github.com/jsuereth/intro-to-actors
Example code (clusters branch)
akka.io
Sandi Metz - Ruby on Ales 2014
!! Squint test
* change in shape - conditionals
* change in color - multiple levels of abstraction
!! Making changes
Novices feel like they're not allowed to make classes
Feel like you can't create a 20 line class if there is already a 5000 line active record model. Can you break the pattern without feeling bad?
Procedures are hard to change because there are no seams
- make a seam
!! Duplication is cheaper than the wrong abstraction
The 43 line if statement exists because someone picked an abstraction and got it wrong. Don't reach too soon for an abstraction.
-- Don't DRY it up as soon as you see it
!! When Inheritance
Shallow and narrow
child uses all the parts of the parent
objects are leaves in the graph
"Duplication is far cheaper than the wrong abstraction"
@Theotherzach
http://theotherzach.com/writes/2016/1/7/angular-2-in-plain-javascript
https://github.com/theotherzach/codemash2016-ng2-js
http://directivesdemystified.herokuapp.com/#/slides/0
@BrianGenisio
github.com/BrianGenisio/directives
Another directives presentation: https://www.youtube.com/watch?v=WqmeI5fZcho
* Supporting IE7 in production!
Types of directives
* Behavioral
* Component
!! Component (templates)
ui-codemirror - angular directive to show code snippet in text area
{{{
App.directive('hello', function() {
return {
template: 'hello!'
};
});
}}}
* Element based directives need a hack in IE8 earlier
* Use templateURL property instead of template to point to an html file
* Angular has a templateCache - used to avoid fetching templates. Could also override the options.
* Uses grunt task that stringifies/minifies templates and puts it in the templateCache
* App.run runs before compile time
!! Behavior
* The directives are using the same scope as the view
** You usually don't want this
!!! Isolate your scope
{{{
App.directive('hampsterDanceIsolate', function() {
return {
restrict: 'EA',
scope: {},
controller: function($scope) {
$scope.toggle = function() {
$scope.animated = !$scope.animated;
};
},
templateUrl: '/app/directives/hampster-dance.html'
};
});
}}}
* You can pass parameters to the isolated scopes
** This is object binding (two-way)
** use '='
{{{
App.directive('hampsterDanceIsolate2', function() {
return {
restrict: 'EA',
scope: {
animated: '='
},
controller: function($scope) {
$scope.toggle = function() {
$scope.animated = !$scope.animated;
}
},
templateUrl: '/app/directives/hampster-dance.html'
};
});
}}}
{{{
<input type="checkbox" ng-model="dance" />
<hampster-dance-isolate2 animated="dance"></hampster-dance-isolate2>
}}}
* Isolate scope string binding
** One way
** Use '@'
{{{
App.directive('interesting', function() {
return {
restrict: 'AE',
scope: {
'header': '@',
'footer': '@'
},
templateUrl: '/app/directives/interesting.html'
};
});
}}}
{{{
<div class="interesting-man">
<img src="/img/man.jpg">
<div class="header">{{header}}</div>
<div class="footer">{{footer}}</div>
</div>
}}}
{{{
<interesting
header="I don't always write directives"
footer="But when I do, I isolate my scope">
</interesting>
}}}
* Isolate Scope Function Binding
** Directive callsback
** Use '&'
* You can do optional and aliased bindings
!! Lifecycle
* ng-app triggers a "compile" Go through the DOM and look for interesting directives
* You can override compile and link behavior in directives
* Compiling a directive happens once (and has a link function)
** Run-time modifications to a template
* Linking happens every time the directive is used
** On-load - modify elements and attributes
* This knowledge is important in testing
{{{
describe("hello directive", function() {
var element, scope;
function bootstrap($rootScope, $compile) {
var html = "<div hello></div>";
element = angular.element(html);
var compositeLink = $compile(element);
scope = $rootScope.$new();
compositeLink(scope);
scope.$digest();
}
beforeEach(module('SlidePlayer'));
beforeEach(inject(function($rootScope, $compile) {
bootstrap($rootScope, $compile);
}));
it("says hello", function() {
expect(element.text()).toBe("hello!");
});
});
}}}
* This is essentially what ng-app does
* $digest
** Processes all of the watchers of the current scope (and it's children)
*** Has this expression changed?
* Angular knows that there's only 4-ish ways to change a page
** After a click for instance, angular calls apply
* $apply
$apply() pseudocode:
{{{
function $apply(expr) {
try {
return $eval(expr);
} catch (e) {
$exceptionHandler(e);
} finally {
$root.$digest();
}
}
}}}
** You use apply when you know something has changed (outside of angular) and angular needs to figure itself out
*** Say we get/cause an event?
{{{
App.directive('whatDoesTheFoxSay', function() {
return {
restrict: 'AE',
link: function(scope, element, attrs) {
scope.message = "What does the fox say?";
element.click(function() {
scope.$apply(function() {
scope.message = "Wa-pa-pa-pa-pa-pa-pow!";
});
});
},
template: '<span>{{message}}</span>'
};
});
}}}
scope.$apply tells the watcher on the template to update
!! Recursion
* By default you can use recursive tags in a directive - stack overflow!
{{{
App.directive('tree', function(recursionHelper) {
return {
restrict: 'AE',
scope: {
nodes: '='
},
compile: function(tElement) {
return recursionHelper.compile(tElement);
},
templateUrl: '/app/directives/tree.html'
};
});
}}}
{{{
<ul>
<li ng-repeat="(key, value) in nodes">
<a ng-click="hide = !hide">{{key}}</a>
<tree nodes="value" ng-hide="hide"></tree>
</li>
</ul>
}}}
{{{
// Mark Lagendijk
// http://stackoverflow.com/questions/14430655/recursion-in-angular-directives
App.factory('recursionHelper', function($compile){
return {
compile: function(templateElement){
var contents = templateElement.contents().remove();
var compiledContents;
return function(scope, element){
if(!compiledContents){
compiledContents = $compile(contents);
}
compiledContents(scope, function(clone){
element.append(clone);
});
};
}
};
});
}}}
!! Transclusion
* Put my content in the directive
{{{
App.directive('panel', function() {
return {
restrict: 'AE',
transclude: true,
scope: {
heading: '@'
},
templateUrl: '/app/directives/panel.html'
};
});
}}}
{{{
<div class="panel panel-primary">
<div class="panel-heading" ng-if="heading">
<h3 class="panel-title">{{heading}}</h3>
</div>
<div class="panel-body">
<div ng-transclude></div>
</div>
</div>
}}}
{{{
<panel heading="Chuck Norris Facts">
<ul>
<li>First program was `kill -9`</li>
<li>Throws exceptions across the room</li>
<li>Can divide by zero</li>
<li>Writes self-optimizing code</li>
</ul>
</panel>
}}}
!! Dependncies
!!! Dependent Directives
{{{
<tabs>
<tab title="Double Rainbow">
<img src="/img/double-rainbow.jpg" />
</tab>
<tab title="Star Wars Kid">
<img src="/img/starwars-kid.jpg" />
</tab>
<tab title="Chocolate Rain">
<img src="/img/chocolate-rain.gif" />
</tab>
</tabs>
}}}
*Tabs need to tell a tab it's selected
* Tab needs to register itself with Tabs
!!!! Tabs
{{{
App.directive('tabs', function() {
return {
restrict: 'AE',
transclude: true,
scope: {},
controller: function($scope) {
$scope.tabs = [];
$scope.select = function(selected) {
angular.forEach($scope.tabs, function(tab) {
tab.selected = tab === selected;
});
}
this.register = function(tab) {
$scope.tabs.push(tab);
$scope.select($scope.tabs[0]);
}
},
templateUrl:
'/app/directives/tabs.html'
};
});
}}}
{{{
<div class="tab-list">
<ul class="nav nav-tabs">
<li ng-repeat="tab in tabs" ng-class="{active:tab.selected}">
<a href="" ng-click="select(tab);">
{{tab.title}}
</a>
</li>
</ul>
<div class="tab-content" ng-transclude></div>
</div>
}}}
{{{
App.directive('tab', function() {
return {
require: '^tabs',
restrict: 'AE',
transclude: true,
scope: {
title: '@'
},
link: function(scope, el, attr, tabsCtrl) {
tabsCtrl.register(scope);
},
replace: true,
templateUrl: '/app/directives/tab.html'
};
});
}}}
{{{
<div class="tab-pane"
ng-class="{active:selected}"
ng-transclude>
</div>
}}}
John Lindquite jetbrains http://egghead.io/
Recommends putting properties inside models to avoid wiping out references (model.bacon, avengers.cast)
{{{
$scope.myMethod = function(param) {
alert(param)
}
}}}
!!! ng-repeat
ng-repeat allows pipes to add filters (filter, orderby, limitBy etc)
pipes can be stacked
map a text-field input to a property and pipe into filters
you can add your own filters
{{{
<ul>
<li ng-repeat="member in avengers.cast">{{member.name}}</li>
</ul>
}}}
!!! ng-app
ties to ng-app "baconApp"
{{{
var app = angular.module= ("baconApp", [])
app.controller("BaconCtrl", function() {
};
}}}
!!! debugging
{{{
//$0 is the currently selected element
var s = angular.element($0)
}}}
!!!Services
Services treated as Singletons
{{{
app.service("AvengersService", function() {
this.cast = data
});
}}}
!!! Resources
http://angularjs.org/
http://jsfiddle.net/
!!! Directives
allow to create tags based off templates
May not be useful, but been holding them for awhile
http://docs.angularjs.org/tutorial/the_end
http://localhost:8000/app/index.html#/phones
http://localhost:8000/test/e2e/runner.html
http://jsfiddle.net/vojtajina/js64b/14/
To show:
repeater
filter
order by
e2e runner
Scenario:
List of devs with skills. Skills are rated by aptitude and enthusiasm.
How to handle currently booked? What-if scenarios?
http://localhost:8000/test/e2e/runner.html
http://jsfiddle.net/e9DXU/
http://jsfiddle.net/VX5LE/224/
http://jsfiddle.net/9PHdf/1/
https://vimeo.com/131410262 - Andy Hunt
Agile is not a sprint (series of sprints) or marathon - It's an obstacle course
!!Training for software obstacle course
!!! Grow Skills
* Learn a new programming language a year
* Write same program/function 3 different ways
* Strengthen where you are weak
!!! Develop Awareness
* Standup, Flow, Value
* Keep the conversation ALIVE
* Don't rely on static communication (documentation, backlog)
!!! Disposable Software (React to Change)
* Stop treating software as precious
* Wasting effort in maintainable, extensible, reusable - you can't predict this
* Put effort into making it replaceable
* Helps coupling, cohesion, encapsulation
''If you can't rip out every piece of the software easily, then the design sucks''
!! The principles are more important
But beginner's can't apply principles
They need to do the practices and follow the fine print to learn the principles
Following the fine print is hard, and seems to be pointless until you understand the principle
!! The problem
* One size DOES NOT fit all!
* Misunderstanding the practices and principles
* Little support for beginners
* No method for continuous learning (evolving the practices)
* Anyone who isn't a dev is ignored
* ''Agile methods haven't changed or adapted''
<<<
A development method is just a way of figuring out how to work together. Everyone.
<<<
<<<
When is it ok to go beyond the rules?
When is a practice good?
<<<
<<<
Practice ''is different'' depending on your skill level.
No one else's experience is the same as yours.
<<<
!!! New method
* Be empirical
* Need different levels
** Beginners cannot self-reflect
* Sensitive to our cognitive limits
* Be inclusive and integrated (no us and them)
!! Pillars of Grows
# Skills Model
# Directed Empirical
# Inclusive (execs, users, etc)
# Self-determined (you decide what works)
!!! Skills Model (Dreyfus)
* Novice
** No experience
** Just want to accomplish a goal
** Just follow the rules
** Novices need steps
* Advanced Beginner
** Don't want the big picture
** Want small, frequent rewards
** Still based on rules
* Competent
** Building models
** Can troubleshoot
* Proficient
** Want to understand the big picture
** Don't like oversimplified explanations
** Looking for patterns
** Can now reflect and self-correct
* Expert
** Source of knowledge
** Work from intuition
** Performance is degraded if they actually follow the rules
** Knows what details are relevant and irrelevant
** Usually bad at explaining how they arrived at a decision
<<<
Skills model is not per person
<<<
** Novice at software development, expert at management, advanced beginner at process
!!! Directed Empiricism
* Make decisions and answer questions based on outcomes
** beware proxies(graphs), theories, estimates
* Feedback loops!
** Intentional, short, real-world, iterative, incremental, anti-fragile
* Don't change or adopt => experiment and adapt
** Need to put your egg in
** It's just an experiment
* Experiments should be:
** Cheap
** short-term (few weeks at most!)
** generate specific, measurable outcomes
** Conditions and outcomes must be agreed to by the team (all)
** No failures, just learning => data has been generated.
!!!! The key to writing software: Is To Write Software
*''This is how to answer questions''
**Try a few and prototype
**Try a few and extrapoloate
**Stick it in front of users
{{{
Pick a tech stack:
We have three competing javascript frameworks.
Let's write hello world in each in one week and see which one we like.
Oh we can't do that. #2 will take that long to set up.
That's a data point.
}}}
!!! Working on GROWS Method practices
* A playbook (Practices of an Agile Developer ?)
Testing clustring and DR software
If it hurts - do it HARDER
exercise, nutrition, healthcare
science vs engineers
Failure as a non-event
- Risk + consequences
GameDays - google and amazon
Chaos Monkey, Chaos Gorilla, Latency Monkey
Evolve - discover weaknesses and adapt
Failure as an opportunity to learn
Blameless culture - Fear to innovate - if we're constantly changing and improving, we should fail alot, or we're not doing interesting experiments.
Antifragile talk - rather than trying to make arguments, how about posing hypotheses as questions?
TDD makes failure predictable. DebugLaterProgramming is expensive and wasteful. Which system is antifragile? (Anti-fragile vs robust).
Unit tests as change enablers (vs quality control)
* Feedback
* No fear
!! Links
http://www.goodreads.com/review/show/464463848
http://www.goodreads.com/work/quotes/19092611-antifragile-things-that-gain-from-disorder
http://www.amazon.com/Antifragile-Things-That-Gain-Disorder/dp/1400067820
http://www.amazon.com/The-Black-Swan-Improbable-Robustness/dp/081297381X
http://www.industriallogic.com/blog/why-are-most-agile-adoptions-failing/
Past: speakerdeck.smetz
''Mentor TODOs''
* New blog posts
* Nitpick exercism
* Kata Roman Numeral
* Sit down on website
''Think about''
* How do we build confidence in our tools?
''Accomplishments''
* Pull request
* Nitpicks
* Building frontend
''Questions''
* Masonry vs other grid systems - Will took this one
''Feeling''
* Unsure about tool selection
Deploying is a great experience
* Feelings about going live: nervous
* Forgot things (links to pdfs from the old site) - had to scramble and fix
Dealing with frustration - sink or swim, being overwhelmed
Feelings on pairing more
* Don't like working alone
* It's hard to externalize thoughts
Preferred "owning" a "real" project to pairing more - wouldn't have changed anything
'' Mentor TODOs
'' Accomplishments
* OhioLink Deep Dive
'' Questions
'' Feeling
Juan Delgado
@wadus
Driving mobile apps with BDD
Mocked Backend
* Sinatra on a hook
* Data in tag
* Assert against the app
{{{
Gherkin
Ruby Steps Java steps
| |
Calabash Instrumentation/Robotium
| |
iOS Android
}}}
Backlog stages
- Freezer, Fridge, Ready to Cook
Backlog metrics
- Group by types: Features, Bugs, Technical
Account for all work - technical "stories" should be first class citizens
Backlog grooming is a three amigos type stuff: Group of people pick apart a story
- Starts with prioritized, well-defined work
Story: Along with token for future conversation - A check for understanding
No predetermined roles in grooming meeting
Nicole and Paolo
muti-disciplinary collaboration
iterative delivery
focused on value
Deep dive - what does success look like writing exercise
Optimizely - A/B testing
Balancing with Clients presentation
* LeanStartup
!! Cornerstones
* How do we measure success?
* Learning over short-term value
* Customer feedback is king
* Experimentation/Feedback drives from the outside
* Experimentation/Collaboration drives from the inside
!! Customer Facing
* Reduce Requirements and Assumptions to Experiments
* Experiment _with_ customers to discover what they want
* Learning is more valuable than customers/revenue/growth - e.g. A/B pricing tests
** Testing/Action/Risk vs Analysis Paralysis/Arguing/Inaction
*Design Thinking = empathy + creativity + rationality
*User Stories as Market Validation Stories (Hypotheses)
** Reqt to Conversation: Move from "system shall" to "we believe" to "as a, I want, so that"
{{{
We believe that
[building this feature]
[for these people]
will achieve [this outcome].
We will know we are successful when we see
[this signal from the market].
}}}
!! Team Focus
*Emphasis on Shared Understanding vs Deliverables
*Move from delivery of features (output) to business value (outcome)
** Focus teams on outcomes over impact
** Outcomes are less binary (not done/done vs "close enough")
* Work together / ignore roles
* Test Ideas Ruthlessly
!! Look out for
* Quality is defined by the ''customer'' not the dev/engineer
** ComplexityInTheServiceOfQuality
*Vanity metrics vs actual use
** Does signing up for a service count as success? Are they using it? Will they spend money on it?
!! Product definition assumptions
* Who is our customer?
* What pain points do they have related to our product/service?
* What features are important?
* What is our differentiation?
* What is our business model?
Matt Wynne @mattwynne
!! Stage 1: Burned Toast
# Programmers write bugs
# Testers find bugs
# PM prioritize bugs
# Prog fix bugs
# Goto 1
!! Stage 2: Auto Burned Toast
# Programmers write bugs
# Write automated tests
# Tests find bugs
# PM prioritize bugs
# Prog fix bugs
# Goto 1
!! Stage 3: 3 Amigos
# Team defines behavior
# Programmers write bugs
# Write automated tests
# Tests find bugs
# PM prioritize bugs
# Prog fix bugs
# Goto 2
!! Stage 4: Test First
# Team defines behavior
# Automated test for behavior
# Programmers make the tests pass
# Testers find missing scenarios
# Goto 2
''Now you're at BDD''
!! Stage 5: Disillusionment
# Lots of scenarios
# Build takes ages
# Build normally broken
# Some scenarios flicker
# Poor/mixed readability
# I hate cucumber
** Test value peaks at the time the test is written and drops sharply thereafter
** You don't have to test at the UI - use hexagonal architecture
** Turn testing pyramid 90 degrees and expose more area to test
** Acceptance Tests do NOT have to be full-stack tests
!! Stage 6: Transcendence
# Problem Domain is well understood by the team
# Solution models the problem well
# Clear architectural boundaries
# Fewer end-to-end tests
# Scenarios are readable
# More Fun!
David Girard (MSFT evangilist)
What does it mean to say "Best way to display data"?
'The visual display of quantitative information' - Tufte
Brain prefers light to dark better than red to green or whatever.
!!! Graphical Integrity
* Don't lie (Fox news!)
Lie Factor = Size of effect shown in graph / Size of effect in the data
14.8 = 783% / 53%
Be careful using 2d or 3d objects to represent 1d of data. If the data increases 30% and you change the height of a 2D object by 30% you also grow it's width, making it a 900% change.
* Keep things proportion
* Use real dollars
* Provide context
!!! Data-Ink
* Bar charts tend to use a lot of ink to display very little data
* Remove metadata, lighten what is left.
* SHOW THE DATA
* Iterate, removing things and see if it's "better"
!!! Data Density
* Don't be afraid of density
* small multiples
* spark lines
Ole Michaelis
@codestars
https://github.com/nesQuick/elixir-hpack
Writing a parser almost entirely via function defintions. Look, ma, no ifs!
Writing a binary parser in elixir is a perfect match! -
dnsimple/com/o/ole - free month of dnsimple
!!HPACK
* Compression protocol for headers
static table + dynamic table of columns (keys) to values
2 = method: GET
19 = path (key only) then encode the value: huffman('/resource')
dynamic table starts at 62
62 = user-agent:Mozilla/5.0
!!! dynamic table
* The dynamic table share between request cycles in a "connection"
* Also shared by streams in the connection
* This makes requests "un-stateless"
!!! pattern matching
x = 1
Looks like assignment
Is actually a pattern match
1 = x
!!! Binaries & Strings
* Strings are binaries
{{{
defp parse(<< 1::1, rest::bitstring >>, headers, table) do
{ index, rest } = parse_int7(rest)
hdr = Table.lookup(index, table)
parse(rest, [hdr | headers], table)
end
}}}
This pattern matches a bye that starts with 1. So this method handles all bytes that start with 1 (or maybe a byte stream since it's recursive)
{{{
# Figure 7: Literal Header Field with Incremental Indexing — New Name
defp parse(<< 0::1, 1::1, 0::6, rest::binary>>, headers, table) do
{ name, rest } = parse_string(rest)
{ value, more_headers } = parse_string(rest)
Table.add({name, value}, table)
parse(more_headers, [{name, value} | headers], table)
end
}}}
This handles bytes that start with 01 (or maybe a byte stream since it's recursive)
----
{{{
defp parse(<< >>, headers, _), do: Enum.reverse(headers)
}}}
Ok, out of characters. Reverse the memo to get the headers in the right order
(Pre-pending is faster than appending because lists are linked lists in elixir)
----
Look ma, no ifs! Strings that start with 1 are huffman encoded.
{{{
defp parse_string(<< 0::1, rest::bitstring >>) do
{ length, rest } = parse_int7(rest)
<< value::binary - size(length), rest::binary >> = rest
{ value, rest }
end
defp parse_string(<< 1::1, rest::bitstring >>) do
{ length, rest } = parse_int7(rest)
<< value::binary - size(length), rest::binary >> = rest
{ Huffman.decode(value), rest }
end
}}}
----
@gergdotca
Don't Block the Event Loop!
Not necessarily IO!
* CPU - 100MB JSON serialization took seconds, crashed the system.
* Deadlock - 2 requests tried to grab a DB connection from the pool (Momoko)
** No stacktrace available
* Out of connections
Real life advice from @gergdotca - If your boss won't give you time to refactor/upgrade, just arrange for that old software to cause a critical production outage.
Beware the hidden non-functional requirement. We never built the websocket client that needed all this async I/O.
* Package manager for the browser
* Can be anything, not just javascript
* can be retrieved via git or http (joe fiorini using S3)
* Semantic versioning via tags
@sadukie
!! Finding mentors
* Within a company
* User Groups
*MentorNet
*mentoring.org
!! Have multiple mentors
* Multiple expertise, multiple perspective
!! Lessons learned
<<<
Leadership is responsibility, not privilege, action, not position, guidance, not knowledge, and outcome, not disposition.
<<<
survivingtheworld.net
* Trust and respect, until burned - be honest with them if they burn you
* Separate opinions from fact
* Demystify questions - use examples, not definitions
* Encourage their curiosity - admit what you don't know
* Learn their strengths and weaknesses
* Do lunch
* Encourage questions - don't use words to impress
* Say I don't know - encourage mentees to say I don't know
* Push them out of their comfort zone
* Encourage personal development
* Respect career paths
* Discourage Imposter Syndrome
* Analysis Paralysis - They don't have the why - take the the time to explain it
* Gender Concerns
<<<
Our mission is to empower every person and every organization on the planet to achieve more
<<<
Microsoft
@cc_jonknapp
http://whatdoeslambdasupport.com
"People are coming to us with ideas of things that don't exist and they say 'Make it So'"
"I personally would like to be responsible for as little as possible. Did I mention I'll be a father, soon?"
serverless - js framework
"Serverless is a mindset" - Relying on amazing work by other people to build your own amazing things.
!!! Objectives
* Get data from 3rd party
* Make it searchable
* Provide search interface
!!! Hidden objectives
* Work with a terrible 3rd party apis
* no tech team to maintain
* unknown load
* small focused codebase
* easy to maintain
!!! New and Shiny!
* Environment variables
* Lambda dead letter queues
* API gateway supports ANY and star routes
* Modify cloud front headers on requests at endpoint
* Upgraded node
* SAM file (Serverless Application Model)
* KMS integration to encrypt/decrypt env values
!!! Lessons Learned
* Log vigorously
* Use error notification service
* API gateway is not great for complicated things (run your own tests)
* API gateway works with Swagger (kind of) - http://swagger.io/
* Think of your app in discrete parts
* Learn IAM roles
Dave Mosher @dmosher
https://speakerdeck.com/dmosher/building-dsls-with-javascript-and-coffeescript
https://bitly.com/bundles/dmosher/8
extend.js + Namespacing
- creates or appends for a namespage/object string
{{{
extend('app.views.config', {})
}}}
vs
{{{
app.views.config = {}
}}}
! Why should I care
*Meaningful semantics
*Extend erd party
*web components
"KendoUI has a wrapper for angular"
ng-directive example: bitly.com/bundles/dmosher/8
Michael Danko
@mikedanko
registry, containers, images
docker handles deployment, no god, monit, capistrano
fig - links stuff?
very fast
ubuntu core - 100MB, autoupdates
Mesosphere - manage containers
Can replace vagrant - this docker image is the same thing as production
matrix builds
flynn, deis - mini PaaS
dokku - micro PaaS (single instance)
!!! Questions
compare against packer
kernel level changes?
java audit framework - Google Search
https://www.google.com/search?q=java+audit+framework&oq=java+audit+&aqs=chrome.1.57j0l3j62l2.4830j0&sourceid=chrome&ie=UTF-8
Eclipse BIRT and JasperReports | My Tech Tip
http://www.mytechtip.com/2011/04/eclipse-birt-and-jasperreports_6325.html
Experience is might!: BIRT vs JasperReports comparison
http://xmight.blogspot.com/2012/03/birt-vs-jasperreports-comparison.html
Birt Queries: Birt vs Jasper
http://birtgrip.blogspot.com/2012/10/birt-vs-jasper.html
CFR - Code of Federal Regulations Title 21
http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfCFR/CFRSearch.cfm?CFRPart=11&showFR=1
URL List from Saturday, Jun. 29 2013 12:57 PM
To copy this list, type [Ctrl] A, then type [Ctrl] C.
airblade/paper_trail נGitHub
https://github.com/airblade/paper_trail
Overview (Spring Data JPA 1.3.2.RELEASE API)
http://static.springsource.org/spring-data/data-jpa/docs/1.3.2.RELEASE/api/
Inspektr Auditing נdima767/inspektr Wiki
https://github.com/dima767/inspektr/wiki/Inspektr-Auditing
java - Business Audit log - recommended library or approach? - Stack Overflow
http://stackoverflow.com/questions/3778281/business-audit-log-recommended-library-or-approach
License
http://logback.qos.ch/license.html
Logback-Audit Manual
http://audit.qos.ch/manual/index.html
Chapter 1: Introduction
http://audit.qos.ch/manual/introduction.html
Chapter 2: Server
http://audit.qos.ch/manual/Running_the_Server.html
Chapter 3: The Contents of Audit Messages
http://audit.qos.ch/manual/Invoking_lba.html
LOGBACK-AUDIT FAQ
http://audit.qos.ch/faq.html
Use appfuse to set up spring/hibernate app and try to plug in audit framework
Jacob Smith 0025 and Stephen Scott
glitch
<ul> whenever you have the same thing repeated
so
{{{ <ul><li /><li /><li /></li /></ul> }}} to show 4 side-by-side boxes (instead of floated <div>)
Double underscore or hyphen to show the difference between location and a type
{{{ panel-block__title }}}
{{{ panel-block__header }}}
{{{ overflow: hidden }}} lets you do clearfix on the parent, whereas {{{ clear: both }}} is for a sibling (that you might add just to make the styles work)
Careevolution
- No
90 - 70 software devs, 20 clinical specialists
Distributed org - 30 in Ann Arbor
!!! Structure
1. Single Owner
1. 89 non-owners
Only flat because it works for them.
Minimal Viable Process - is this actually a problem or a one-off thing?
"Controlled Chaos" - embrace that somethings will be ad hoc / informal
!!! HR
* Have to be careful hiring
* Look for people comfortable with ambiguity and have a bias towards action
* Use partner/mentor system to help new hires
Takeaways
* We're doing things right
Automatic - car diagnostic and tracking
nascent object - send CAD get object with circuits embedded
smallorange - starting at $3/month - very limited, lots of tiers
squarespace - $8/month - comes with e-commerce, reasonable limits
mediatemple - $20/month shared/grid, $30/month for wordpress specific
digital ocean - start at $5/month very limited, $10/month reasonable - a Virtual private server, not a web host
Aaron Salvo
https://twitter.com/naunga
16 year old service with 4.1 million lines of code
!!!Interfaces
Interface = List of 0 or more functions
Implemented implicitly
Empty interface types accept any type - 0 functions satisfy the interface!
{{{
type capitalized interface {
Capitalize() string
}
}}}
!! Go Kit
Toolkit to solve common problems in distributed systems
* logging
* instrumentation
* transport layers
* rate limiting
* service discovery
GoKit - opinionated that requests should look like RPC - requests have a structure, need to be decoded, responses are encoded
!!! How Go applies to microservices
* Concurrent programming
* Runtime reflection
* GC
* End up with a single statically binary
!!! Drawbacks
* Go get doesn't have a good dependency management system. Semantic versioning is a problem.
* Does have vendored libraries
http://diiq.org/#/blog/church-of-interruption?page=the_church_of_interruption
||I Interrupt | I wait for you to finish |
|I Let You Interrupt| Church of Interruption | The Meek |
|I will say my piece no matter what | Barkers | The Church of Strong Civility |
THE HOLY CREEDO OF THE CHURCH OF INTERRUPTION:
# Thou shalt interrupt when thou understand鳴.
# Thou shalt speak until I interrupt.
# Thou shalt use physical cues to indicate when I ought continue talking.
DOCTRINES OF THE CHURCH OF STRONG CIVILITY
# Thou shalt not interrupt.
# Thou shalt speak briefly.
# Thou shalt use physical cues to indicate your understanding and desire to speak.
Interruptors will interrupt to indicated understanding and use physical cues to keep you talking.
Civility will never interrupt and will use physical cues to indicate you should stop talking.
@scott_triglia
https://www.slideshare.net/ScottTriglia/protect-your-users-with-circuit-breakers-72991406
Feature flag are just manual circuit breakers
https://michaelfeathers.silvrback.com/code-change-complexity
Algorithmic complexity as a metaphor for code change.
O(1) - only one file has to change
O(n) - changing from SQL to NoSql in a badly encapuslated code base
Label code changes between O(1) and O(n)
11/11/2017 - @Hyland, with @Tech_Elevator
Gisted: https://gist.github.com/stevenjackson/89834917efdf1aa0fcfd0cc7412b42db
"The jobs are here, we don't have the workers to fill them"
!! Review
* It was good, I'm glad I saw it. I'm not sure who the intended audience was, sometimes young women, sometimes corporate leaders?
* The first half of it didn't keep my attention, but it's a nice intro if you don't understand why this is important and the importance of women to the field.
* The second half was much more powerful to me, more current examples of women trying to fight "the man" and why it's hard.
* They touched lightly on solutions, but it was kinda disappointing. Fight stereotypes, create more role models.
* The only solution presented for a company: Spend lots of money, recruit out of bootcamps, grow talent, fight to retain.
* http://shescoding.org/ for more.
!! Outline
* Everyone should know something about CS
** Code is everywhere
** Teaches problem solving skills, need to be precise and creative
* Role Models are important
** Unfortunately most female role models are historical
** Need more Grace Hoppers
* Women were the first programmers -> Now there are few
** In the 50s companies started filtering out woman by marketing programmers as "conquerers of the electronic machine"
** Hacker culture took this a step farther: young, male, antisocial, slobs, focused on domination and anarchy
** Brogrammer culture ratcheted it up a few more notches
* Pipeline is the problem
** We need to reach everyone with the talent and give them the skills
* Raising boys and girls differently changes the way their brains function
** Has nothing to do with innate ability
** CS should be required curriculum (it is in 5 countries and emphasized in a dozen more)
** Not enough teachers in US
* We need more diversity on teams to build solutions that positively impact people
** (other than white men)
** Airbags killed a lot of woman and children because there were designed based on the engineering team's physicality
* Grace Hopper was awesome
* Stereotypes are holding us back
** "Girls are bad at math"
** Normal frustrations caused by the work cause you to "feel" the stereotype a bit more. You waste energy trying to fight through that.
** Girls are conditioned to appear "average" at math and science starting in high school
** College is worse, more active discouragment: "You won't like this"
* Hard for women to be encouraging
** Please join this field where you will certainly be belittled and sexually harassed!
** Death by 1000 cuts - unconscious bias
** Women leave tech because they don't want to be "that woman" who speaks up about sexist behavior
** Being excellent isn't good enough
http://icodemash.com/
Jan 10-11 2013
Neal Ford - Evolutionary Architecture and Emergent Design (Devworks)
IntroToAndroid
ParseApp
PizzaAndHelicopters
TheCaseForNovices
''Functional Superiority With Clojure''
* OOP/D is good for GUIs - a button is a natural for inheritence, it sends messages, has behavior, etc.
* It's not good for everything else - shared data, object graphs, etc add complexity, and are difficult to parallelize.
ScalaAsABetterJava
GettingYourCustomerToWriteAcceptanceTests
''Scala/Play hack'' https://github.com/jamesward/seminarmash
AngularJS
https://github.com/TechConf/CodeMash2014
Leon Gersing's Speaking pre-compiler was a great experience. This was a hands-on session with opportunities to practice speaking and get immediate coaching on things like diction, energy, and projection. It was structured as a master class, where the attendee presents material and Leon repeatedly stopped the presentation to make suggestions for dramatic and subtle improvements. Leon guided presenters through identifying their narrative structure and building a better talk.
The Elixir pre-compiler was an interesting look at a newer functional language that's rapidly gaining interest. Elixir is a dynamic language built on-top of the Erlang Virtual Machine and is designed to build distributed fault-tolerant applications. Ryan Cromwell and Chris McCord spent the morning leading the class through the syntax and structure of an elixir program. In the afternoon, the focus shifted to making a distributed application, using all the attendees, to perform a DDoS/build a tweet aggregator. Here the power of Erlang and OTP mixed with the simplicity of Elixir to make a compelling case for the language. Nodes were brought on-line and integrated into the mesh with very little ceremony. The Erlang/Elixir philosophy of error handling blew some minds: just let it die and configure your program to start a new process. With the ability to create several thousand processes per application, one can quickly grasp how distributed, concurrent and fault-tolerant a system built in this way could become.
Jeremy Edberg of Netflix gave an interesting talk about how Netflix is architected. This talk went deeper than just talking about pieces and parts; Jeremy made a compelling argument for the culture of Netflix and how they value responsibility and independence over carefully gated processes and unified architecture. Their culture assumes everything is automated, redundant and repeatable. They recognize that blame is pointless and have built the famous Netflix Simian Army to take down nodes and services - in production - and actively find problems to resolve. Jeremy also talked about some of the challenges Netflix has had scaling with Amazon and a number of cool tools they've built. Many are open-sourced and will continue to be. [link: https://github.com/Netflix]. Their build process was particularly interesting as they've taken continuous delivery to an interesting end - every commit spins up a new amazon cluster with the latest image and directs traffic to it.
The Secrets of Clojure Web Development was a fast-paced ride through the bleeding edge of web development in clojure. Clinton Dreisbach's enthusiasm for this language and its ecosystem was infectious. He compared a number of tools to rails equivalents and made it easy to understand how the tools are used and why they might be attractive. Liberator was very interesting, Clinton managed to build a fully compliant REST API in a handful of lines of clojure. The demonstration of HTTP Kit was also impressive. The combination of a functional language and streaming over web sockets seemed very attractive for those scenarios where there is a lot of data to move and HTTP is the least painful way to get it there.
There were also some more advanced sessions that were attended. Brian Genisio gave an in-depth overview of AngularJS directives that was well done. Directives are a difficult concept to grasp and Brian did a nice job of working through all the options and presenting some entertaining examples that kept the audience engaged. With directives a developer can essentially extend html and create semantic or domain-specific tags that can be re-used through the application. An intuitively functional <tab> html element in a <tabs> container is a common example that most web developers would love to have. Jerry D'Antonio gave an interesting talk on ruby concurrency and explained examples of concurrency constructs from other languages like clojure, javascript, erlang, scala, and F#. He "concurrently" presented the same abstraction re-written in ruby using the ruby-concurrency gem. This provides an interesting alternative for building those applications that would benefit from concurrent constructs.
A possible highlight of the conference was the lightning talks. Corey Haines did a magnificent job hosting in what appeared to be a crushed velvet dinner jacket. Most of the talks were good to great, but Gary Bernhardt stole the show with "Useing You're Type's Good" [link: https://www.destroyallsoftware.com/talks/useing-youre-types-good]
http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf
Rules 1-4 are pretty pragmatic:
1. One level of indentation per method
2. Don鴠use the ELSE keyword
3. Wrap all primitives and Strings
4. First class collections
http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt
http://www.youtube.com/watch?v=hd0v72pD1MI
High cohesion
* easy to find where a change needs to occur
* limits scope of the change
Low coupling - easy to make a change
Cohesion as explict coupling
!! Cohesion as coupling within a shell:
*Two methods that need to change together are coupled, but the class that contains them is cohesive - for instance readConfig and writeConfig
*What story is your method telling - what story is your class telling?
* If something is stable (rarely changes) can we take advantage of that and use it to couple things together?
** How do you know it won't change?
* Coupling only matters when things change - so something that's tightly coupled might be ok - it's a potential energy vs kinetic energy concern.
!! Detecting coupling
* Detect coupling by looking at diffs (see the trends of things changing together)
* Turbulence, NDepend
* Look at when a file was created vs when it was last changed. Churning files vs encapsulated ones.
* Things should be easy to name and easy to find - fiddling with cohesion/coupling should help
!! Cohesion vs Coupling - Which is more important
* In general, I've worried about coupling because I have so much battle damage from dealing with code that's hard to change
* Dale Emery: Focusing on cohesion means you have to improve the names, coupling does not force that
* JB - it seems like one feeds off the other. So it's more of a question of which you should start with
* Kent - theoretically everything can be coupled to everything else. So by focusing on cohesion I can limit my scope and avoid thinking about all those potential connections.
* Dale - There are many ways to detect coupling - I just have to be aware of the pain of change and address it then. Our tools don't help us with cohesion.
Cutting an Agile Groove - David Hussman http://devjam.com/2013/07/12/cutting-an-agile-groove-overview/
!!! Dude's Law
Value = WHY / HOW
Do you start with why on a given practice?
!!! WHY
Why Collaborative Environment? Visualize, Create, Inform, Fun, Build Community
!!! Environment Checklist
* Do you have real information radiating?
* Connecting Remote Teams?
* Space for Design?
**Table over whiteboard
{{{
3D 2D
}}}
* Do your tools serve you?
** Test-drive your tools
!!! Key Questions
* How much time should we take to figure out where we're going?
Combinatory Logic was invented by Moses Sch殦inkel and Haskell Curry to to eliminate the need for variables in mathematical logic. A combinator is a higher-order function that uses only function application and earlier defined combinators to define a result from its arguments.
This elminates the need for temporary variables and procedural logic. Instead it provides a way of thinking about common problems in terms of functions.
Combinatory Logic is a building block for good functional programming. Reginald Braithwaite wrote a series of posts and an e-book to explain using combinators in ruby or JS. The idea is to pick a language you're comfortable with and stretch it to learn functional paradigms, rather than learning a language and FP at the same time. He uses songbird metaphors to describe each combinator.
https://leanpub.com/combinators
https://github.com/raganwald/homoiconic/blob/master/2008-10-31/songs_of_the_cardinal.markdown#readme
* Architecture is dependent on a world view for a customer use case. Change the use case and all that architecture becomes debt.
* Do root cause analysis (5 Why's) on every "mistake". Learn about your system and how customers ''actually'' use it. Optimize __that__ quality.
*Go fast with discipline
Joel
http://flightjs.github.io/
Not MV*
Component: js has reference to DOM node and can manipulate that DOM. Can listen to and trigger events using that DOM node, so it's easy to integrate with existing js.
Attributes: "member" variables for the component
Inititalizer: Used for setup
Attaches to each match of the selector.
Can only talk to it via events after it's initialized.
Attributes can be defaulted and overridden, or required.
Mixins - work like modules in ruby, add functions to `this`
Advice - Like aspects or hooks. Gives you before and after hooks for your functions.
(jacob smith)
Frequent releases mean more value.
Even if your risk is higher (might ship more subtle bugs because there's less baking and time for testing), the value outweighs that.
Also small releases are easier to do, reason about, modify, so bugs don't last long.
Interesting pressure:
A production bug is going to get prioritized
Reviewing code that's already in production.
Heavy reliance on parallelism - no reason to do things sequentially.
Dan Kacenjar @kacenjar
! OpenBCI
openbci.com
* Org
* $499 for 8 bit board
* EEG(brain), EMG(muscle), ECG (heart)
* Based on arduino uno
!! BCI is hard
* Variable per person
* small signals in a noisy environment (low SNR)
* signal theory, cognitive science, neuroscience
!! Board components
* TI ADS1299
** low noise 8 channel, 24bit analog for bio measurements
** SPI provides i/o to arduino
* LIS3DH 3 axis accelerometer
* ATmega328P microcontroller
** arduino compatible
*** don't need an arduino
* RFduino
** BTLE (4.0)
* OBCI USB dongle
** RFDuino
** connects BCI to PC
** requires FTDI VCP (virtual comm port) driver
board <-- BLE --> dongle <-- serial --> PC
!! Block diagram
3 bytes of data per channel
2 bytes for each axis in the accelerometer (xyz)
!! Programming
* Can use Arduino IDE
* Showed example using Processing (http://playground.arduino.cc/Interfacing/Processing)
!! OpenBCI client software
* has it's own client
http://lizkeogh.com/2011/09/22/conversational-patterns-in-bdd/
!! Context Questioning
* 쉳 there any other context which, when this event happens, will produce a different outcome?튪 What do we do when "Given" isn't true
!! Outcome Questioning
* 쇩ven this context, when this event happens, is there another outcome that鳠important? Something we missed, perhaps?튪 If pixies were doing this instead of software, would it be enough? Or do they need to do something else, too?튊
!!! Indirection
"Indirection should add meaning, not hide it" - Jessica Kerr
!!! Naming
"Name objects for what they're responsible for" - Corey
eg. ProcessesPayment
C# - IDoSomething => ITranslateToSoftwareDeliverySystem => class TranslatesToSMS implments ITranslateToSoftwareDeliverySystem
!!! Testing Pain
If you're doing test first, you change the tests
If you're test-driven, you change the design
Determining business value vs Dispelling ignorance
- Determining most valuable feature is usually a hand-waving exercise of varied opinions. Instead equate "providing value" to "providing knowledge about the system to build"
Why a pentagon for needed CR features?
- So you can draw arrows from below
- Feature support diagrams
Ask questions about the features and figure out what other features can determine the answers to those questions
- The feature that answers the most questions and has the fewest questions about it shows the highest amount of value (core feature)
----
Corey likes to start on the simplest case when writing cukes - the degenerate case. (0th case)
Meat based automation - after the cukes are written but you ned lots of changes at the integration level to get those passing - just use the refresh button and verify by eye - then verify the cukes pass
----
Use cucumber setup steps to drive out the behavior a controller or some integration layer needs
- Move code from the tests to the views to the controller (and keep going). Start with hardcoded data until you get it down to the point where it makes sense to introduce retrieval
Feature support diagram -> Cuke -> hard coded view -> hard coded controller -> ...
http://blog.mattwynne.net/2013/11/18/costs-and-benefits-of-test-automation/
"It鳠important for each test to justify its existence in your test suite." - Does it have more value than it's cost?
Benefits:
* Thorough analysis of a requirement
* Confidence to refactor (regression protection)
* Fast feedback
* Repeatable test
* Living documentation
* Less manual testing
* Time for exploratory testing
* Team collaboration (ATDD)
Costs
* Time spent learning how to write test
* Time spent writing test
* Time waiting for test to run
* Maintenance time
* False sense of security while tests are passing
!!! Successful conversators
1) Know what they want
2) Don't make either/or choices
* How would I behave if I really want this?
* What do I want for everyone?
* What don't I want?
* How can I get what I want and not what I don't want?
! Book notes
!! Chapter 2 The Power of Dialog
* Be 100% honest and 100% kind
* Find a way to get all the relevant information into the open
//Because of a shared understanding people willingly act on decisions with conviction//
//You buy in when you understand//
!! Chapter 3 Start with Heart
(Know what you want)
* Start high-risk conversations with the right motives. Stay focused.
* "What do I want here?"
* "How would I behave if I wanted that"
!! Chapter 4 - Learn to Look
(Is it safe for people to be honest?)
* How do people feel?
* Are they holding back?
How do I know I'm in a crucial conversation? - Look for people who are afraid.
!! Chapter 5 Make it Safe
//There's this undercurrent of "don't pay attention to the content", or at least "pay more attention to the conditions". Which is how I talk to my children and it's exhausting.//
* "What is our mutual purpose"
* "Do others believe I care about their goals?"
* "Do they trust my motives?"
* "Do they believe I respect them?"
!!! Making it safe again
(after screwing up)
* Apologize sincerely
** Only if you're really sorry you did and it's appropriate - don't apologize because some over-reacted
* Contrasting
** "I don't want to say/come across/imply x. I do think y"
!! Chapter 6 Master my Stories
Something happens (Observable Fact) -> Tell yourself a story about it -> Feel -> Act
Cody doesn't text me back -> He obviously doesn't really want to come see me -> Disappointed, angry -> Ignore him
* Am I pretending not to notice my role in the problem?
* What do I want? What would I do right now if I really wanted that?
!! Chapter 7 STATE My path
* Pause for 4 seconds
* EXPLICIT purpose of conversation
** We're explicitly here to come together, not for one party to win
** //You only need to be explicit during crucial conversations?//
!!! When something that makes me feel bad happens
* Think about what I really want
* Think of possible explanations for their behavior - try to get in a place where they're not the worst person in the world
* Start dialog - Confirm your impression before starting a confrontation. There's time for confrontation later if they are, in fact, the worst person in the world.
!! Chapter 8 Explore Others Paths
(Help them get to dialog as well)
* Ask for their view
* Mirror - Acknowledge the way they feel
* Paraphrase - Show you are listening and that you're trying to understand
* Prime - If nothing else works, offer a guess about how they might be feeling/thinking
* Agree - Be sure to agree when you share common ground
* Build - If you agree, but feel like something is being left out, agree and then add your thing
* Compare - If you disagree, don't say they're wrong. Present the two views and acknowledge that there is a disagreement here.
!! Chapter 9 Move to Action
Dialog is not decision making
*Command
*Consult
*Vote
*Consensus
//Orgs use consensus on things that don't matter and command-style on those that do//
!!! How to choose
1) Who cares? Don't involve people who don't care.
2) Who knows? Find the experts. Don't involve people who contribute no new information.
3) Who must agree? Whose cooperation/authority/influence do we need?
4) How many people do we need? Fewer is better. Do we have enough people to make a good choice? Do we need others to get their commitment?
//The goal of a leader is to be completely informed and *choose* to not impose their opinion in most situations.//
!!! Assignments
* Saying a group will do the work is foolish (our problem, not my problem)
* Someone must be assigned to keep everyone accountable
TD hangout: Oct 19
Crystal - statically compiled to be syntactically similar to ruby
* perf improvement in sidekiq
* Uses macros for metaprogramming
* Only use crystal at mac and linux (llvm)
!!! types
nil is a type (check for nil at compile time)
Union types
(string|nil)
!!! cool stuff
go like channels (not parallel, but non-blocking)
c bindings
!!! Distribution story kinda sucks
It's ok for dependency (can specify github repos)
Itamar Hasin @itababy
Relies entirely on Wire protocol (Cucumber Recipe #15)
!!! Remote control
Off board cuke -> Wire -> Listener -> Network -> Target
Pro: Target untouched
Con: All APIs must be exposed to the network
!!! IN-SITU
Cucumber -> Network -> Listener -> Target
(Listener is on-board)
Pro: No APIs exposed
Con: Server part of codebase
Con: Need memory for wire listener
!!! Gateway
Cucumber -> Gateway -> Multiple devices
Orchestrates/Switchboard to multiple devices
Implements wire protcol and dispatches either to another wire protocol listener (in-situ) or translates wire protocol to network or serial commands against the target.
Cucumber2 - rewrite of ruby version
Gherkin3
cucumber-android - built on cucumber-jvm
!! cucumber-ltd/cucumber.pro
* Online collaborative cukes
* Backed by github, bitpucket, dropbox
* Tight integration with travis-ci
* Runs cukes
* Realtime synced collaboratin - as you type
* Doesn't run cukes, mostly ties to CI jobs and shows report
* Free for open source
share.js - used for the real-time piece
Aslak:
BDD = Let's have a conversation -> Examples
Important for examples to be concrete
* Foundation for exploring
* Concrete examples are easier to automate
----
Daniel Wellman @wellman
Alternate step for same gherkin - use ENV variables
----
** Please use cucumber pro - we need feedback **
!!! Ian Dees @undees - Testing embedded
* Mongoose - C Web server - small mostly compatible
* White - Win32 API testing
* rxtx.jar
!!! Richard Lawrence @rslawrence - Story workshop
* Data Personas - Clumps of data that seem to get passed around
** A clump or search criteria
** Personas file to store the data in - like datamagic.yml I guess
Might be a good solution if you have more than one default dataset
!!! Oscar Rieken
* 2700 cukes in 7-10 minutes
* 400 nodes
* Looking at MogoTest and Narcissus for browser testing
!!! Ian Dees @undees - Elixr, Cucumberl
Q: Can you run erlang in elixr? Port cucubmerl to elixr - run every scenario in a process - massive multithreading
Dr. Wayne Newman - CWRU
* Uses planar selection to tell the Atlas robot where walls and surfaces are //Shared understanding//
* Teleoperation is out - takes forever.
* Compliant Motion Control - teach the robot skills it can apply
* Ask the robot what it ''can'' do
** Lots of rejected commands
** "If you ask for the impossible you rarely get something desirable"
@dshultz
@doug_mair
Mike Bobcock - Inventor of D3
presentation - http://codepen.io/team/Dan/pen/JbbBGq
!!! TODO
Play with meteorite strike example, fix states example
http://codepen.io/team/Dan/pen/GrRJoZ
http://codepen.io/stevenjackson/pen/qRbqaV/
http://codepen.io/team/Dan/pen/qqzONY
http://codepen.io/team/Dan/pen/qRWpWY
http://codepen.io/team/Dan/pen/JbbBGq
!!! What do you want to show?
Relationship - scatter, bubble (correlation)
Composition - Pie, stacked columns
* Stacked bar chart better than 50 pie charts with 7 wedges
Comparison - Column, line (versus)
Distribution - histogram (column, line)
http://www.datavizcatalogue.com/
!!! Manipulating data
* Map/Reduce using emojii
http://www.globalnerdy.com/2016/06/23/map-filter-and-reduce-explained-using-emoji/
https://twitter.com/steveluscher/status/741089564329054208?ref_src=twsrc%5Etfw
* Data Details vs Data Size (have to leave stuff out in order to make sense of the data)
!! D3
https://github.com/d3/d3/wiki/gallery
Find an example viz to start from here
enter - update - exit
d3 essentially iterates over your data passing it to the chained functions
You can think of it sort of like sql, for these rows (which might be scalars), do this thing (append, attr, etc).
d3 supports divs, svg, and canvas
!!! Support functions
* d3.csv - load csv from service
* renderlets
* scales - convert from the domain data (1 to 100000) to the chart range (1-100)
** www.dashingd3js.com/d3js-scales
* domains
* ranges
* axes
!!!! Cool tools
https://svg-edit.github.io/svgedit/releases/svg-edit-2.8.1/svg-editor.html
!! Crossfilter
http://square.github.io/crossfilter
!! Chloropleth
Topojson -> GeoJson -> svg geopath -> d3 projection
!! dc.js
fluent interface for d3 charts
@coralineada
"combing a wookie"
bugs = holes in our mental model
test-driven refactoring - write tests to throw away - document your assumptions on how the codebase works.
Capture the old method in a lambda and then compare it against the new.
mutant - less about code coverage, more about finding methods that do too much
approval_tests - reports when ''results'' have changed - useful for apis
!!! Metrics
time the test suite (should not get slower)
feature to bug ratio (per iteration)
code complexity metrics
code smells (reek)
ask your developers
!!! Tools
churn - how many times has this file changed
rake notes - finds TODOs
fukuzatsu - reports cyclomatic complexity
society - reports how tightly coupled different classes are
pandometer - in progress - can report which commits add complexity, coupling, etc
!!!
* Store your results in a database so you can see trends
!!! Questions
Any ideas for testing where the only tests you can think to write are going to constrain your refactoring in a difrection you don't want it to go?
Do you keep these integration tests? Test every edge?
What's the lifetime on these tests you throw away? - as long as needed for assumption checking
noun project
@arethoseclams
https://github.com/Netflix/Hystrix
https://github.com/Netflix/Hystrix/wiki
http://techblog.netflix.com/2011/12/making-netflix-api-more-resilient.html
!!! Circuit Breaker pattern
* Release It!
!!!! Closed
* request succeed -> failures = 0
* request falis -> failures++
* failures = threshold -> trip breaker
(Or measure latency, absolute failures, % error rate)
!!!! Open
*
!!!! Half-open
* How to recover? Retry window?
!!! Pros
* Fail fast
!!! Cons
* Overhead (stat tracking)
!! Bulkheads (thread pools)
Overspecifying cards during estimation sessions
Avoiding dev/product interaction
Solution: 3 amigos during kickoff
"We talk about people over process and then actively go out of our way to create a repeatable process where people don't have to interact more than a bare minimum.
"I find it much more important to go for that elusive Metaphor, and find a common language that all stakeholders can understand. Whether you automate some of that understanding and how, is less important."
" The customers wanted to know the calculations that went in to the acceptance tests. We ended up writing acceptance tests in Clojure, with a small support library to keep the tests clean and readable."
"When embarking on something new, try to understand how you are working, where your feedback is coming from. Then understand where the 讥w頴hing is coming from. While trying the new thing out, keep reflecting and check your understanding against your experiences."
Willem van den Ende (http://blog.johanneslink.net/2014/05/22/veterans-of-tdd-willem-van-den-ende/)
!! Perspective
This is a good book if you feel like you're not ever getting anything done. My chief criticism is that the end goal for Newport's Deep Work seems to be create solo-uninterruptable blocks of time. I don't think software development will improve if we work harder at keeping developers in sensory-deprivation silos. I do think there's a number of nuggets to glean from here - especially around the psychology of distraction and the power of ritual. I'd like a take on this topic that was focused on high-performing collaborative teams doing "deep work". Newport touches on this idea in a few places (two people in front of the whiteboard caught my interest) - but it's mostly lost with the primary perspective of publishing more papers/books = better work.
!! Takeaways
1) Distractions are a problem for me, not because of "deep work avoidance" - I don't have trouble focusing or refocusing. The issue is this idea of residual attention. Seeing the thing I can't deal with right now starts using part of my processing power. This is similar to the psych behind GTD.
2) I should experiment with planning my leisure time. This is kind of frustrating because I usually have a never-ending TODO list, I just don't always want to refer to it when I plop down brain-dead on the couch at 9pm. But I definitely see the value in saying - do I really want to spend the next 45 minutes "catching up" on twitter? As the book quotes in the 4DX section "I know what I need to do. I just don’t know how to do it."
3) I should experiment with a scoreboard. The issue is I have trouble identifying value accrued. I know it's not cards delivered or hours on task - I've measured both of those and they create awful feedback loops.
4) I think I could benefit from a shutdown ritual. I just don't know how to implement one in my current environment. My client works 2 hours later than I can realistically work. As an "async" person on the team, I'm easier to ignore, so it's almost always the case that by the time they're ready to address my concerns it's the end of my day. That means I'm always trying to cram one more thing in while I have the opportunity to talk to them. Additionally my work day almost always ends abruptly with my wife running out the door or needing me to start dinner or a child is desperate for attention. One idea I'm thinking about is shutting my day down pre-emptively and creating the "resume plan" and then immediately resuming? Like if I got good at doing that, could I be efficient enough to employ it every hour? I did something very similar when I was working all spare hours of the day trying to keep all my projects afloat.
5) I've started experimenting with schedule blocks. It feels somewhat nice to have the plan. I haven't ascertained any other benefits yet. I'm also not blocking off anything that wasn't already in my work stream.
6) The core problem I have isn't solved by this book. I have no trouble getting high-quality work done with tons of distractions. My problems are twofold:
A) I'm reluctant to throw low-priority tasks away. Sometimes this is beneficial - my code isn't done until it's repeatedly deployable. Other times it's I can't start this obviously valuable thing because I'm still bothered we didn't quite cover that one cataclysmic edge-case.
B) I want to figure out how to get more done in my day. Not do "better" work - more "better" work. I'm already highly productive, but I want to figure out how to do a 6 month high-quality project in 48 hours. I want it to be ok to clock in for four highly productive hours of business-value and leave more time for crazy experimentation.
!! Highlights
Highlight (Yellow) | Location 148
To remain valuable in our economy, therefore, you must master the art of quickly learning complicated things.
-----
Highlight (Yellow) and Note | Location 264
Once the talent market is made universally accessible, those at the peak of the market thrive while the rest suffer.
//is this true given the enormous demand for devs?//
-----
Highlight (Yellow) | Location 268
talent is not a commodity you can buy in bulk and combine to reach the needed levels: There’s a premium to
being the best.
----
Highlight (Yellow) | Location 293
In this new economy, three groups will have a particular advantage: those who can work well and creatively
with intelligent machines, those who are the best at what they do, and those with access to capital.
----
Highlight (Yellow) | Location 305
Two Core Abilities for Thriving in the New Economy 1. The ability to quickly master hard things. 2. The ability
to produce at an elite level, in terms of both quality and speed.
----
Highlight (Yellow) | Location 327
this process of mastering hard things never ends: You must be able to do it quickly, again and again.
----
Highlight (Yellow) | Location 341
If you don’t produce, you won’t thrive—no matter how skilled or talented you are.
----
Highlight (Yellow) | Location 416
By batching his teaching in the fall, Grant can then turn his attention fully to research in the spring and summer,
and tackle this work with less distraction.
----
Highlight (Yellow) | Location 422
it’s important to enforce strict isolation until he completes the task at hand.
----
Highlight (Yellow) and Note | Location 423
My guess is that Adam Grant doesn’t work substantially more hours than the average professor at an elite
research institution (generally speaking, this is a group prone to workaholism),
//hmmm//
----
Highlight (Yellow) | Location 437
attention residue.
''OH YES''
----
Highlight (Yellow) | Location 439
it was more common to find people working on multiple projects sequentially:
----
Highlight (Yellow) | Location 452
minimizes the negative impact of attention residue
----
Highlight (Yellow) | Location 460
by seeing messages that you cannot deal with at the moment (which is almost always the case), you’ll be forced to turn back to the primary task with a secondary task left unfinished. The attention residue left by such unresolved switches dampens your performance.
----
Highlight (Yellow) | Location 482
If deep work is so important, why are there distracted people who do well?
----
Highlight (Yellow) | Location 500
There are, we must continually remember, certain corners of our economy where depth is not valued.
----
Highlight (Yellow) | Location 613
client that each member of her team would be off one day a week.”
Instead, the consultants found more enjoyment in their work, better communication among themselves, more
learning (as we might have predicted, given the connection between depth and skill development highlighted in
the last chapter), and perhaps most important, “a better product delivered to the client.”
//batch slack time//
----
Highlight (Yellow) | Location 622
cultures of connectivity persist, the answer, according to our principle, is because it’s easier.
----
Highlight (Yellow) | Location 623
If you work in an environment where you can get an answer to a question or a specific piece of information
immediately when the need arises, this makes your life easier
----
Highlight (Yellow) and Note | Location 625
you’d instead have to do more advance planning for your work, be more organized, and be prepared to put
things aside for a while and turn your attention elsewhere while waiting for what you requested.
//isnt this the same as doing multiple projects sequentially? Its somehow ok if you plan for it?//
----
Highlight (Yellow) | Location 630
it becomes acceptable to run your day out of your inbox—responding
----
Highlight (Yellow) | Location 674
The feeling of taking a broken machine, struggling with it, then eventually enjoying a tangible indication that he
had succeeded (the bike driving out of the shop under its own power) provides a concrete sense of accomplishment he struggled to replicate when his day revolved vaguely around reports and communications
strategies.
----
Highlight (Yellow) | Location 686
Busyness as Proxy for Productivity: In the absence of clear indicators of what it means to be productive and
valuable in their jobs, many knowledge workers turn back toward an industrial indicator of productivity: doing
lots of stuff in a visible manner.
----
Highlight (Yellow) and Note | Location 764
Having just established that there’s nothing fundamentally flawed about deep work and nothing fundamentally
necessary about the distracting behaviors that displace it, you
//when did this happen exactly?//
----
Highlight (Yellow) | Location 829
Our brains instead construct our worldview based on what we pay attention to.
----
Highlight (Yellow) | Location 901
“The best moments usually occur when a person’s body or mind is stretched to its limits in a voluntary effort to
accomplish something difficult and worthwhile.”
----
Highlight (Yellow) and Note | Location 905
Ironically, jobs are actually easier to enjoy than free time, because like flow activities they have built-in goals,
feedback rules, and challenges, all of which encourage one to become involved in one’s work, to concentrate
and lose oneself in it. Free time, on the other hand, is unstructured, and requires much greater effort to be shaped into something that can be enjoyed.
''omg''
----
Highlight (Yellow) | Location 910
Human beings, it seems, are at their best when immersed deeply in something challenging.
----
Highlight (Yellow) | Location 919
flow generates happiness.
----
Highlight (Yellow) | Location 950
“is not to generate meaning, but rather to cultivate in himself the skill of discerning the meanings that are
already there.”
----
Highlight (Yellow) | Location 1276
waiting for inspiration to strike is a terrible, terrible plan. In fact, perhaps the single best piece of advice I can
offer to anyone trying to do creative work is to ignore inspiration.
----
Highlight (Yellow) | Location 1319
the grand gesture. The concept is simple: By leveraging a radical change to your normal environment, coupled
perhaps with a significant investment of effort or money, all dedicated toward supporting a deep work task, you
increase the perceived importance of the task. This boost in importance reduces your mind’s instinct to
procrastinate and delivers an injection of motivation and energy.
----
Highlight (Yellow) | Location 1370
“We encourage people to stay out in the open because we believe in serendipity—and people walking by each
other teaching new things.” For the sake of discussion, let’s call this principle—that when you allow people to
bump into each other smart collaborations and new ideas emerge—the theory of serendipitous creativity.
----
Highlight (Yellow) and Note | Location 1416
The professors at MIT—some of the most innovative technologists in the world—wanted nothing to do with an
open-office-style workspace. They instead demanded the ability to close themselves off.
//so what? how does this prove anything? everyone else was wrong because some professors wanted
special treatment?//
----
Highlight (Yellow) | Location 1425
We can, therefore, still dismiss the depth-destroying open office concept without dismissing the innovation-producing theory of serendipitous creativity. The key is to maintain both in a hub-and-spoke-style arrangement:
Expose yourself to ideas in hubs on a regular basis, but maintain a spoke in which to work deeply on what you
encounter.
----
Highlight (Yellow) and Note | Location 1440
the whiteboard effect. For some types of problems, working with someone else at the proverbial shared
whiteboard can push you deeper than if you were working alone. The presence of the other party waiting for
your next insight—be it someone physically in the same room or collaborating with you virtually—can shortcircuit
the natural instinct to avoid depth.
//hmmm..pairing works the same way. So maybe open space without pairing is too distracting to work.//
----
Highlight (Yellow) | Location 1444
Indeed, their example indicates that for many types of work—especially when pursuing innovation—
collaborative deep work can yield better results. This strategy, therefore, asks that you consider this option in
contemplating how best to integrate depth into your professional life.
----
Highlight (Yellow) and Note | Location 1447
First, distraction remains a destroyer of depth.
//aha....and pairs are difficult to distract.//
----
Highlight (Yellow) | Location 1464
I asked you how to do it, and you told me what I should do. I know what I need to do. I just don’t know how to
do it.”
----
Highlight (Yellow) | Location 1477
Discipline #1: Focus on the Wildly Important
----
Highlight (Yellow) | Location 1488
Discipline #2: Act on the Lead Measures
----
Highlight (Yellow) | Location 1497
For an individual focused on deep work, it’s easy to identify the relevant lead measure: time spent in a state of
deep work dedicated toward your wildly important goal.
----
Highlight (Yellow) | Location 1502
Discipline #3: Keep a Compelling Scoreboard
----
Highlight (Yellow) | Location 1513
To maximize the motivation generated by this scoreboard, whenever I reached an important milestone in an
academic paper (e.g., solving a key proof), I would circle the tally mark corresponding to the hour where I
finished the result.* This served two purposes. First, it allowed me to connect, at a visceral level, accumulated
deep work hours and tangible results. Second, it helped calibrate my expectations for how many hours of deep
work were needed per result.
----
Highlight (Yellow) | Location 1517
Discipline #4: Create a Cadence of Accountability
----
Highlight (Yellow) | Location 1524
During my experiments with 4DX, I used a weekly review to look over my scoreboard to celebrate good weeks,
help understand what led to bad weeks, and most important, figure out how to ensure a good score for the days
ahead.
----
Highlight (Yellow) | Location 1558
I want to suggest a more applicable but still quite powerful heuristic: At the end of the workday, shut down your
consideration of work issues until the next morning
----
Highlight (Yellow) | Location 1565
Reason #1: Downtime Aids Insights
----
Highlight (Yellow) | Location 1572
Dijksterhuis’s team isolated this effect by giving subjects the information needed for a complex decision
regarding a car purchase. Half the subjects were told to think through the information and then make the best
decision. The other half were distracted by easy puzzles after they read the information, and were then put on the
spot to make a decision without having had time to consciously deliberate. The distracted group ended up
performing better.
----
Highlight (Yellow) | Location 1584
The implication of this line of research is that providing your conscious brain time to rest enables your
unconscious mind to take a shift sorting through your most complex professional challenges. A shutdown habit,
therefore, is not necessarily reducing the amount of time you’re engaged in productive work, but is instead
diversifying the type of work you deploy.
----
Highlight (Yellow) | Location 1587
Reason #2: Downtime Helps Recharge the Energy Needed to Work Deeply
----
Highlight (Yellow) | Location 1619
Put another way, trying to squeeze a little more work out of your evenings might reduce your effectiveness the
next day enough that you end up getting less done than if you had instead respected a shutdown.
----
Highlight (Yellow) | Location 1643
to support your commitment to shutting down with a strict shutdown ritual that you use at the end of the
workday to maximize the probability that you succeed. In more detail, this ritual should ensure that every
incomplete task, goal, or project has been reviewed and that for each you have confirmed that either (1) you
have a plan you trust for its completion, or (2) it’s captured in a place where it will be revisited when the time is
right. The process should be an algorithm: a series of steps you always conduct, one after another. When you’re
done, have a set phrase you say that indicates completion (to end my own ritual, I say, “Shutdown complete”).
----
Highlight (Yellow) | Location 1658
the Zeigarnik effect. This effect, which is named for the experimental work of the early-twentieth-century
psychologist Bluma Zeigarnik, describes the ability of incomplete tasks to dominate our attention.
----
Highlight (Yellow) | Location 1665
In this study, the two researchers began by replicating the Zeigarnik effect in their subjects (in this case, the
researchers assigned a task and then cruelly engineered interruptions), but then found that they could
significantly reduce the effect’s impact by asking the subjects, soon after the interruption, to make a plan for
how they would later complete the incomplete task. To quote the paper: “Committing to a specific plan for a
goal may therefore not only facilitate attainment of the goal but may also free cognitive resources for other
pursuits.”
----
Highlight (Yellow) | Location 1677
Decades of work from multiple different subfields within psychology all point toward the conclusion that
regularly resting your brain improves the quality of your deep work. When you work, work hard. When you’re
done, be done.
----
Highlight (Yellow) | Location 1761
The idea motivating this strategy is that the use of a distracting service does not, by itself, reduce your brain’s
ability to focus. It’s instead the constant switching from low-stimuli/high-value activities to high-stimuli/lowvalue
activities, at the slightest hint of boredom or cognitive challenge,
----
Highlight (Yellow) | Location 1807
To summarize, to succeed with deep work you must rewire your brain to be comfortable resisting distracting
stimuli. This doesn’t mean that you have to eliminate distracting behaviors; it’s sufficient that you instead
eliminate the ability of such behaviors to hijack your attention.
----
Highlight (Yellow) | Location 1831
In particular, identify a deep task (that is, something that requires deep work to complete) that’s high on your
priority list. Estimate how long you’d normally put aside for an obligation of this type, then give yourself a hard
deadline that drastically reduces this time.
----
Highlight (Yellow) | Location 1835
At this point, there should be only one possible way to get the deep task done in time: working with great
intensity—no e-mail breaks, no daydreaming, no Facebook browsing, no repeated trips to the coffee machine.
----
Highlight (Yellow) | Location 1839
Remember, however, to always keep your self-imposed deadlines right at the edge of feasibility. You should be
able to consistently beat the buzzer (or at least be close), but to do so should require teeth-gritting concentration.
----
Highlight (Yellow) | Location 1841
The main motivation for this strategy is straightforward. Deep work requires levels of concentration well beyond
where most knowledge workers are comfortable.
----
Highlight (Yellow) | Location 1859
The goal of productive meditation is to take a period in which you’re occupied physically but not mentally—
walking, jogging, driving, showering—and focus your attention on a single well-defined professional problem.
Depending on your profession, this problem might be outlining an article, writing a talk, making progress on a
proof, or attempting to sharpen a business strategy. As in mindfulness meditation, you must continue to bring
your attention back to the problem at hand when it wanders or stalls.
----
Highlight (Yellow) | Location 1900
This cycle of reviewing and storing variables, identifying and tackling the next-step question, then consolidating
your gains is like an intense workout routine for your concentration ability.
----
Highlight (Yellow) and Note | Location 1923
it was instead his quest to improve this memory that (incidentally) gave him the deep work edge needed to thrive
academically.
//leaping to conclusions again!//
----
Highlight (Yellow) | Location 2084
I call it the craftsman approach to tool selection, a name that emphasizes that tools are ultimately aids to the
larger goals of one’s craft. The Craftsman Approach to Tool Selection: Identify the core factors that determine
success and happiness in your professional and personal life. Adopt a tool only if its positive impacts on these
factors substantially outweigh its negative impacts.
----
Highlight (Yellow) | Location 2314
But the logical foundation of his proposal, that you both should and can make deliberate use of your time outside
work, remains relevant today—especially with respect to the goal of this rule, which is to reduce the impact of
network tools on your ability to perform deep work.
----
Highlight (Yellow) | Location 2330
Put more thought into your leisure time. In other words, this strategy suggests that when it comes to your
relaxation, don’t default to whatever catches your attention at the moment, but instead dedicate some advance
thinking to the question of how you want to spend your “day within a day.”
----
Highlight (Yellow) | Location 2333
websites of the type mentioned previously thrive in a vacuum: If you haven’t given yourself something to do in a
given moment, they’ll always beckon as an appealing option. If you instead fill this free time with something of
more quality, their grip on your attention will loosen.
----
Highlight (Yellow) | Location 2350
if you want to eliminate the addictive pull of entertainment sites on your time and attention, give your brain a
quality alternative.
----
Highlight (Yellow) | Location 2442
Down the left-hand side of the page, mark every other line with an hour of the day, covering the full set of hours
you typically work. Now comes the important part: Divide the hours of your workday into blocks and assign
activities to the blocks.
----
Highlight (Yellow) | Location 2459
Your goal is not to stick to a given schedule at all costs; it’s instead to maintain, at all times, a thoughtful say in
what you’re doing with your time going forward—even if these decisions are reworked again and again as the
day unfolds.
----
Highlight (Yellow) | Location 2484
Joseph’s critique is driven by the mistaken idea that the goal of a schedule is to force your behavior into a rigid
plan. This type of scheduling, however, isn’t about constraint—it’s instead about thoughtfulness. It’s a simple
habit that forces you to continually take a moment throughout your day and ask: “What makes sense for me to
do with the time that remains?” It’s the habit of asking that returns results, not your unyielding fidelity to the
answer.
----
Highlight (Yellow) | Location 2515
How long would it take (in months) to train a smart recent college graduate with no specialized training in my
field to complete this task?
----
Highlight (Yellow) | Location 2580
because when considered in isolation, to say no to any one of these activities seems like you’re being lazy. By
instead picking and sticking with a shallow-to-deep ratio, you can replace this guilt-driven unconditional
acceptance with the more healthy habit of trying to get the most out of the time you put aside for shallow work
----
Highlight (Yellow) | Location 2682
I call this approach a sender filter, as I’m asking my correspondents to filter themselves before attempting to
contact me.
----
Highlight (Yellow) | Location 2721
I will do a good deed for some random stranger if Antonio responds within 23 hours.
----
Highlight (Yellow) | Location 2742
I suggest, therefore, that the right strategy when faced with a question of this type is to pause a moment before
replying and take the time to answer the following key prompt: What is the project represented by this message,
and what is the most efficient (in terms of messages generated) process for bringing this project to a successful
conclusion?
----
Highlight (Yellow) | Location 2773
Second, to steal terminology from David Allen, a good process-centric message immediately “closes the loop”
with respect to the project at hand. When a project is initiated by an e-mail that you send or receive, it squats in
your mental landscape—becoming something that’s “on your plate” in the sense that it has been brought to your
attention and eventually needs to be addressed. This method closes this open loop as soon as it forms. By
working through the whole process, adding to your task lists and calendar any relevant commitments on your
part, and bringing the other party up to speed, your mind can reclaim the mental real estate
----
http://lizkeogh.com/2014/09/01/deriving-gherkin-from-real-conversations/
* Get examples by asking for them
** If the answer is tautological - "When I select text and make it italic it should be italic" - drive into specifics
!! Conversational Tricks
* people use 쩦�here Gherkin uses 짩ven튪 or they use 쌥t鳠say this happened杊* or say 췥ll, if I鶥 already done X杊* people use 촨en�nstead of 취en�when they鲥 talking about an event they鲥 performing
* people often skip 촨en�ltogether when they鲥 talking about an outcome, and occasionally skip 취en�
!! Success vs. failure
* Don't make success and failure look the same. Assume success
<<<
Given I鶥 submitted my application
<<<
vs
<<<
Given I tried to submit my application
But it was audited and rejected
<<<
!! It's OK to have steps that don't execute code
Given I lost my dog
SE radio - Fred George
! Definition
Anarchy = Self-organization
Developers are not managed by anyone, including the business
!! Basic idea
* Time to market is paramount
* PO doesn't have time to guide developers
* Fast feedback is required
* Good for solving problems where the solution is fuzzy ("Make more money")
* Developers experiment quickly (several a day, in production) to find better solutions
!!! Anarchy
* = Self-organization
* Attention grabbing "Marketing" like extreme programming
!!! P.O role
* Describe business goals
* Give developers metrics to "game" (google hits, $ earned per minute, search ranking, etc)
* Educate developers on business
<<<
"Customer now educates programmer on business domain, rather than picking what story to play next"
<<<
* Stay out of the way
!!! Caveats
* Requires high-trust relationship
** You pay these people a lot of money, vaguely describe what you want for that money, give up authority on how they spend that money, and in return you get fast results
* Non-prescriptive results
* Has to "sold" to C-level and forced down throats (like agile). Social/culture change.
* Managers/Architects/QA etc must adapt or leave
** At Daily Mail, most managers left rather than become coders. 25%+ left in first six months.
** Most architects became coders
** Had no trouble filling those positions with people who really wanted to work in this environment (leaving banks, google, etc)
* Have to leave the developers alone (judge on merits alone)
** Team chose to rewrite the same service 3-4 times (Managers would never allow this!). Ended up being the right call.
* Best suited for internal tools?
* Only really works so far with microservices
!!! Innovation
* You have to want it
* Understand that innovation means failing
* Rules will be bent, ignored, and broken
!!! Gaming
* We measure the wrong things for developers (story points, cards per iteration, lines of code).
* Measure money made, improving google results, KPIs.
* Developers identify metrics to game and do so.
!!! No management
* Let programmers vote each other off the island
* There are management like roles
** Mentor - usually senior dev
** Feedback - 360 reviews
** Ambassador - represent team to rest of company (still a programmer)
** Concierge - handle the things the team needs (skills, lan adapters, deal with "fired" programmers) - probably not a programmer
!!! Skills / Pay scale / title
* Competent in a tech - Developer
* Expert in tech - Expert - Senior Developer
* Competent in 5-7 techs - Expert - System Developer
* Expert in 5+ techs - Uber Expert - Master Developer
!!! Is it agile?
Yes,
* Value Communication
* Value Feedback
* Value working software
but...
* No stories
* No iterations
* No retros
* No standups
(The feedback loop on all of these things is too large if you're deploying multiple times a day)
* No refactoring
* No unit testing
* No QA
(microservices make this waste, just spend another hour and spin up a replacement microservice)
* Deploy it to production and measure the feedback there
* Requires instrumentation
<<<
Could lose $300/minute if there was an error, but could produce $1000s per day with an alogrithm update.
<<<
!!! Key question
"How much do you value time to market?"
!! Microservices
* Microservices and rapid development leads towards Programmer Anarchy
* Microservices work well when success is very fuzzy and in degrees.
** "Can I tweak just this piece of the feature and have 2-3 versions competing in production?
!!! How big?
* < 100 lines of code (java, C#)
* 15-20 lines of javascript
* Forward had 300 microservices
* Netflix had 800 microservices
!!! Services are scripts
* Logic is simple
* Pull in input
* Make 1-2 decisions
* Produce output
//this rang home with me, I don't TDD most of my scripts - it's hard to mock out IO, wire up a test harness, etc when I'm writing a bash script to move files around //
!!! microservices @forward
* Ruby front-end
* Clojure for heavy lifting
* Node for traffic monitoring
* R for analytics
!!! Duplication
Didn't worry about it. 2 hours to write a new service shorter than maintaining the documentation and library for knowing another service already exists.
!!! Logging, monitoring, deployment
* Logging is just another event on the event bus (if doing async architecture)
* Each service announces it's presence/disconnect, does heartbeat (like MQTT). Another microservice does monitoring.
* Use the cloud for deployment
** Cloud costs cheaper than programmer costs
!!! My Questions
1) Does this work for customers who don't want to learn tech? Will we naturally mask the costs they are deferring by ignoring tests, refactoring, docs, etc?
2) What's the worth of creating an environment where developers get to write code as much as possible? Can we abandon the desire to prevent building the wrong thing the first time?
Cory House
@housecor
* Luck Surface Area
* Find what scares you and run at it
* "You are the average of the five people you spend the most time with"
* Consistently do things that people want
George Dunwiddie
"Express all the details that matter and none that don't matter" - Dale Emery
Clue: Big setup
Clue: Big Expectation
Clue: Run on scenario (when and then when then when then)
Essence of a cooking timer
hour glass, wind up, digital
Clue: Does the cuke change when we change the workflow?
minute button vs 1-0 keypad for entering minutes
Clue: Does the cuke change when we change the UI?
Start button vs Go button
1, 2, 3, vs -, --, ---
WARNING: Don't eliminate all the details - stay away from tautological
Is your essence (of this test) domain or workflow? Depends on the test. Should we run/group these tests together? Or maybe accept slower feedback on workflow tests.
@jeffhoover
@schmonz
Chzy suggested a doc from pivotal about remote pairing - FIND IT
https://schmonz.com/2017/05/05/aab-2017-best-team-anywhere/
Scatterspoke
Kel Cecil
@praisechaos
http://github.com/kelcecil/docker-techfest15
!!! docker hub vs quay.io
* prefers quay
* better for teams
* quay has an easier "build image from commit" feature
kubernetes - linux like process application over multiple boxes.
deis - heroku-like abstraction
containership.io - abstracts away the providers (digital ocean -> aws)
!!! Ideas
* Pull the CI env to a dev machine to fix/play
* Take someone's dotfiles for a spin
Takeaway: simply uses docker the way I use vagrant
Most asked questions follow a normal
Every page is page 1 - You need to tell users where they are because they come in from anywhere
Give orders
Write a unit test (make the user do something that verify they set it all up correctly).
If you can't check that it worked, it's not a task.
What's next -> add a pointer to the next step. If you don't say anything they're not sure if they're done or not. Reduce uncertainity.
Get out of the way -> People have other stuff to do.
AR Parrot Drone
argus - gem
CFields - module -> Convert C style headers to ruby class
Ratscheller?
Pulling the Value Forward - most valuable first
Amount of value for each story goes down, so second iteration is less valuable than the first
At some point the value of a sprint becomes negligible (when you get to the nice-to-haves)
It costs the same amount to do the first iteration as the 10th
There should be a point where we notice that we've spent half the money and gotten 80% of the value
ROI - Sooner?
How does this approach compare to the all or nothing comparision?
https://github.com/cromwellryan/sweetelixir
Ryan Cromwell
Chris Mccord
IRC: elixir-lang on freenode
http://elixir-lang.org
----
What do you do when there's no match? - Throws error, let it die?
Uses guard to load exs files into iex to help with playing (don't have to re-write whole modules in iex)
quote shows the AST for any expression
cond do
conditions...
end
// would you assign this to something?
#iex:break
Elixr is tail call optimized
Processes are used like Objects in the sense that you give them work and wait for a result - thousands per machine is normal
* Messages are non-durable - so we assume messages are not delivered by default?
* Servers are OTP naming convention for a process that stays alive
* ''Tests are falining for genserver_stack
* iex pry
@mudetroit
https://github.com/mudetroit/elm-and-elixir-made-for-each-other
!!! Undirectional data flows
* Undirectional data flows push us towards time being a first class //I don't get it//
* No longer think about what a model is -> just what it looks like afterwards
* Moving towards streams
!!! Time as a first class citizen
* Pushes us to think about the system as a state machine in a moment of time.
* Think of all the bugs that have been caused because we obsess over the output of the state machine but aren't good at thinking about what the internals look like.
* //Replay//
Eric Hankinson
Deb bootstrap - take major version of debian, ABI (cpu arch) - knows how to copy files to a block (virtual file system) and make a minimal debian
uboot - point here to launch the OS
* Tfttp here to get the kernel
Ran qemu-arm-static to compile "AS ARM" in a VM (rather than doing a true cross-compile)
MAKEDEV - makes things in the /dev folder
sfdisk - scriptable fdisk
use {{{pv}}} to record pipe progress
{{{
zcat | pv | dd
}}}
- Build an architecture to scale first, be efficient second
12 year old aaron (''find github account'') contributing to travis pulled in by first accepted pull request.
github.com/rkh
@medyyoulook
Perseverance, Grit, Growth Mindset
Embrace the Suck -> There's stuff that's got to be done, it's not going away. Putting if off doesn't make it any less sucky.
The longer you procrastinate the harder it is to get started. Acknowledge it sucks, get it over with.
Zen horse metaphor:
I'm on my zen horse I can do anything, little problems don't knock me off. Xcode crashes, whatever.
My horse ran away, can't find it
Can see my horse, not there yet
Not going to get back on today
@_toch
!!! X-talk
* 30 mins talk, 30 mins discussion - 1 night a month
* Drawback: passive
!!! Group Code Review
* Homework - review this and send comments
* Activity - discuss reviews
* Drawback: Too many languages
!!! Code Retreat
!!! Hands-on-workshop
* Based on Junior questions
* Drawbacks: Takes a lot of time to build
!!! Legacy Code Retreat
* Used Gilded Rose Kata
* Topics/Challenges
** Fix a bug
** Add a feature
** Introduce DI
** Extract Methods
!!! Open Forum
* Round table suggest topics
* Top 3 discussed 20 mins each
John Daily
@macintux
https://gist.github.com/macintux
x=x+1 -> you're doing it wrong!
"If this is the kind of code you want to write for the rest of your life, you are wrong."
"Crashing is not the worst thing that can happen when you have an exception, silently swallowing an exception is".
Rebootable code - How often has rebooting failed to fix your computer problem? Rebooting is an awesome feature.
If you're already in an error state, can you trust "yourself" to clean and restore state?
"Why do computers stop and what can we do about it?" - Jim Gray
!!! Tandem Computers
* Fail fast modules: do the right thing or STOP. Why carry corrupted behavior forward
* Detect module faults quickly
* Configure extra modules for rapid failover
!!! Tandem's Software
* 4 million lines of code
* Several thousand bugs
* Estimated mean time between failure - 50 years
!! Things we need
!!! Isolation
*Erlang module is a process
* No shared memory
* Need messages to transfer data
* Async messaging is better (sync message is fragile)
!!! Supervision
* Should have as little code as possible
* Lazy edge case handling by default - why spend all that time tracking down weird bugs?
!!! Fast Reboot
* Processes are itty-bitty small. Like 1200 bytes.
!!! Network transparency
* We tried to pretend for years that network calls didn't exist (RPC, CORBA, etc)
!!! State management
* OOP encourages you to keep your state intertwined with your code. Functional encourages you to separate that.
!! Nice to have
* Hot code loading / REPL
* Garbage collection (lots of little processes to clean up)
* OTP - best practices for Erlang
* Pattern matching (parsing messages)
* Symbolic debugging
!! Resources
learnyousomeerlang.com
tinyurl.com/cm-erlang
worrydream.com/TheFutureOfProgramming - Must watch video
* Where is prod?
* Look at Gemfile
* Look at database.yml
* tools - simplecov, turbulence, etc
* Installed DB from heroku (db:pull)
@crebma
!!! Self Awareness
* Who do you interact with?
* Who do you follow on twitter?
* Do the people you admire in the community all look the same?
!!! Expand Your Network
* Say hello to new people
* Don't recruit out of homogenous network
* Your job posting has "Straight White Dude" written on it
* Care publicly when a public figure says something weird
* HIre diversity consultant
* Sponsors groups and conferences that promote diversity
* Support continued learning - make it ok to not know something
!!! Group awareness
* Invite speakers that are under-represented
* Make new people feel welcome
* Have a good of code of conduct that you understand -> shows you've thought about this and you care
** Don't just copy/paste
** Have a contact person/committee to help with code of conduct questions
** Enforce the code
* Reach out to local groups
* Find speakers of different experience levels
* Don't center social hours around alcohol
** I don't feel comfortable being around a bunch of people drinking
** Mocktails,
** Lower the barrier
!!! Group Awareness in Your Conference
* Have a code of conduct
** Know it, Enforce it
** geekfenimist.com
* Reach out to local diverse groups for CFPs
* Ask for recommendations of speakers to invite
* CallbackWomen, Technically Speaking
* Partner with organizations
* Offer scholarships, free tickets, discount codes
* Always give your speakers and volunteers free tickets
* Cover travel expenses
* Offer child care, closed captioning, signing, quiet room
!!! Do Research
* Don't rely on the one non-"straight white dude" to help you
Do you like failure?
In this session we'll talk about why your mind reacts to failure the way it does and what you can do about it. Using concrete examples, like TDD and Lean Startup, we'll work through some cognitive biases that might hold you back. We'll talk about failing safely and building environments where failure is encouraged. Then we'll move on to anti-fragile systems and how focusing on failure pushes a system to thrive on randomness. We'll close with a discussion on failure-focused strategies that allow us to build to an ultimate success.
Agile distilled
-Feedback!
- Why do we care about feedback - learn, grow, etc
-Failing and Learning
- What lessons are you most likely to learn from?
- What stories do you remember?
-Regret avoidance
-Practice failure
-ATDD
-Lean startup
-Scientific method applied to ATDD
-Write it down
-Start with a hypothesis
-Try to fail! Embrace failure
! Post Codemash
* Afraid to show unfinished app to a customer?
* Afraid to let customer drive
* Show and Tell with nothing to show?
* View failure as permanent and success as temporary
** Do your friends let you forget your mistakes?
** Can we create spaces where it's ok to mess up?
* Perfectionism
** Story about my dad
** Very limiting, afraid to try new things
* Distinguish between valid and invalid criticism
** Trusted Advisors / Mentors
* After failing
** Ignore or dismiss the data
*** Ego protection
**** The lifeblood of the ego is fear. Its primary function is to preserve your identity, but it fears your unworthiness. As a result, ego pushes you harder in order to achieve more. Ego communicates to you through "oughts," "musts," and "shoulds," persuading you to believe that by achieving more and more, you must be worthy, right?
** Attribute to a personal defeciency
*** Ego protection
*** Afraid to try again
** Attribute to strategy
*** Creates new ideas
Helen Keller, 샨aracter cannot be developed in ease and quiet. Only through experience of trial and suffering can the soul be strengthened, ambition inspired, and success achieved.튊* Prefer local evidence to theory
** Design patterns, etc
!! Killing your darlings
* Stuff - How does this fit?
!! Practice "when things go wrong"
* http://www.jbrains.ca/permalink/test-driven-development-as-pragmatic-deliberate-practice#fnref:1
** Work in mentions of the quotes here, all very good about teaching yourself to learn
!! Antifragile
* Tie-in - the capability to embrace failure and react to mistakes is useful in random, uncertain environments
*** Avoid Analysis Paralysis
*** Disorder Paralysis
** The ability to quickly reverse small errors makes a person/system antifragile
** Maximize Luck Surface Area
** Innovation depends on tinkering
** If we get good at reversing expected failure we can get good at reversing random failure
*** It's all about reducing fear of a negative effect
** Randomness and Disorder
*** vs attempts to stabiliize the environment (PROCESS) vs stability by embracing change and randomness
** Stress up to a point
** Barbelling (90% cash, 10% high risk, vs 100% medium)
** Things that are antifragile
* Bones and muscle
* Antifragile things are complex and random
** And need complexity (zoo animals)
* Robust things are simple
* Complex systems resist top-down design - emergence
* Instead use minor tweaks (like evolution does)
* Local failure vs Global failure
** Tech safety
"Good systems are set up to have small errors, independent from each other, or negatively correlated to each other, since mistakes lower the odds of future mistakes"
* Debt makes you fragile - vulnerable
* You have to feel the consequences of your actions
* Don't waste time trying to get better at predicting the world or making it more predictable.
"Antifragility is beyond resilience or robustness. The resilient resists shock and stays the same; the antifragile gets better. The antifragile loves randomness and uncertainty, which also means - crucially - a love of errors, a certain class of errors."
* Understand that freedom and accountability are the same thing.
** What does this mean to me?
* Antifragile systems are redundant
** They expect failure of one part
* Redundancy vs Waste
** Antifragile systems are redundant, which looks like waste. Until the unusual happens.
* CI/Delivery - Antifragile
** Again this comes back to the idea that we try more often, even if that means failing. Let's keep the failures small and local.
** Balancing act?
*** Antifragile - TechSafety
** Github
*** Jan8 postmortem - one small failure takes down the whole system
!! Closing?
In the end there's nothing significant about success or failure. What we're looking for is fast feedback for fast improvement. If you can succeed fast, great! Please teach me how. The magic about focusing on failures is that you can still build to a larger success. With a focus on success, it takes me longer to get that feedback. I'm also less open to changing tack while I'm succeeding. All of us take on endeavors that in hindsight, we should have quit very early on. And in hindsight, the warning signs were there. But it's going "well enough", it doesn't hurt that bad, let's keep going and hope it works out.
William Klos
@williamklos
github.com/centricconsulting/alexa-framework-go
Bad Voice UI: Requires a specific order of words, innotation
Alexa Ask MyApp
Alexa Tell MyApp
Conversation:
Keeps a topic open until you "close it" - Is this a timeout thing?
Steps:
1. Move all the script in a page to a single block (jquery can help)
1. Create a namespace for js
1. Move all script on a page to a js file with the same name. Use the new namespace
1. DRY it up
1. Isolate components
1. Inject dependencies
1. Use templates
!!! mockajax library
- Used with spiking out a design with a designer - can build widgets without a server
!!! Wrapping functions
Wrapping function calls in anonymous functions instead of just passing the function (like to jquery) allows you to call functions that you haven't defined on the page yet (because the page loads top to bottom)
{{{
$('#stuff).on('click' doStuff);
doStuff = function() {
}
}}}
'' Undefined ''
!!! Namespaces
* Use namespace as interim step to organize code
* Not a good solution long term if you have collisions with another library - last write wins
----
Why on earth would you add functions to an object that require it to know things outside the function definition? (Step 6ish)
!!! Templates
Templates allow you to stop sending markup across the wire. Add rows to a table asynchronously, for instance.
!!! amplify
amplify - allows you to publish events to topics. You can further decouple components from each other. Also components from server:
amplify.publish("needData")
http://www.paperplanes.de/2014/12/10/from-open-to-minimum-vacation-policy.html
Open vacation policy was a failure.
* People were unsure how many days were "ok" and no-one wanted to be the slacker. Forgetful people would just burn themselves out.
"People take less time off, and it's celebrated as a success of giving people more responsibility."
* People would stay hooked in during vacation, and avoid recharging.
"When someone starts checking in during their vacation, it lowers the bar for others to do it, and it increases the uncertainty of whether or not you should be checking in. "
"A company has to learn how to function when people are on vacation and unavailable, however important their role is."
Ended up with 25 MINIMUM vacation days for every employee, including founders
@chriskeathley
Property Tests
1. Generate lots of data
2. Pass it through a function
3. Validate the output
How to do it:
1. Think in properties
...
5. Models as FSMs.
{{{
test "addition with zero returns the same number" do
ptest c: int() do
assert(add(x, 0))
end
end
def add(x, _y) do
x
end
}}}
-----
https://github.com/keathley/phoenix_qc_example
How do you think about applications?
Imagine a model. Think of it as a FSM:
User -> logs in -> logged_in -> vote -> logged_in -> log out -> logged_out
{{{
test "users votes increase after voting" do
ptest [commands: gen_commands("chris")] do
VoteCounter.reset()
[_state, result } = run_commands(commands, client)
end
end
def gen_commands(name) do
list(of: gen_vote(name), max: 20)
end
gen_vote(name) do
tuple(like: {
value(:vote),
value(name),
)})
end
}}}
Raymond Chandler III
@raymondchandler
https://github.com/kitanata/genetics
Fighting borrow checker
```
let v = vec![1,2,3];
let v2 = v;
```
v2 now owns v, v is pretty much worthless.
**Only one pointer can point to a spot in the heap**
Functions can move ownership - calling a function and passing a ref means it's gone to you.
Primitives are "copied".
`
You can hand back ownership in a function by returning it
```
fn foo(v1: Vec<i32>) -> vec<i32>, i32 {
(v1, 5)
}
```
Can also pass refs
```
foo(&v);
fn foo(&Vec<i32>)
```
''Key Question'' Who is it that cares about what you're building?
Using the gherkin as a measure of progress - these features are done, these might not be good tests, this is what we're working on today
Rephrase all conversations as gherkin steps
Whether the gherkin can run or not is not important //to Doug Alcorn//
Writing Acceptance Tests forces a conversation and make expectations explicit. Gherkin gives us a language that the Whole Team can understand.
Feature = epic
Scenario = story
Rules for communicating status to remote clients
- If there's not a story for what you're doing, you're doing the wrong thing
- If your story takes more than a couple days, it's too big
- You're not really doing anything unless you have a story in progress
Fowler: (OOPSLA 2000) Because the cost of predicting software is so high, it makes sense to treat it as unpredicatable
Instead of scheduling a meeting, instead start with the question you want answered and encourage a conversation for that.
It's all about talking to your client
!!! Q&A
Psychology of dealing with customers that don't want granular small stories - It's all about the relationship. To foster breakdowns, ask questions, do experiments
Kirsten Hunter
@synedra
akamiapibootcamp.com
Git vs Database
DB:
bad at heirarchies, needs infrastructure and maintenance, doesn't do diffs
Git:
lightweight, portable, can use branches to label information, tags to label commits and state. Logs for free, has grep and diff.
Fluid girds
flexible images
media queries
Don't use inline styles, include media query last.
https://www.youtube.com/watch?v=OqmdLcyES_Q
David Marquet
Turn the Ship Around
! Intent-based leadership
"Who's the Captain here?"
Don't give instructions - given intent
Stop requesting permission - "Captain I intend to submerge the ship"
Moves psychological ownership
! Give control
* Competence - Is it safe?
* Clarity - Is it the right thing to do?
"Captain I intend to submerge the ship" - it is safe because....It is a good idea because
I don't care how smart you are - 1 person thinking controlling 134 people can't beat 135 people thinking
! Move the authority where the information is
* The software programmer decides when to ship
* The salesman closes the deal
!! This is not chaos
* They make decisions as if the CEO is standing behind them
* Better decisions
* Better execution speed (No delay)
* Feel like they matter
* They are thinking
!! It will feel wrong
* You have been programmed to take control
* You need to give control and create leaders
* Angry at yourself
* Failure -> Go back to the old ways
!! You are creating an environment
GREATNESS
Andy Hunt
@PragmaticAndy
!!! Agile development
* Agile development is supposed to be like the Borg. We will adapt. Resistance is futile.
* Wrong words - sprint, marathon. Development is an obstacle course.
* The suck curve - it takes time.
!!! Neuroplasticity
Carla Dweck
- self-modifying brain
- if you think you can't increase intelligence, then you physically can't.
- growth vs fixed mindset
!!! Pragmatic Learning Plan
# Pick a place and time, What do you want to do next.
** Smart mirror, elm front-end for finances
# SMART goals
# Diversify Topics
** How do you decide when/how to diversify?
** How to take ownership on problems (Extreme Ownership) - //Add to reading list//
# Plan
** Next action
** Year goal
** 5 years, __what will be different__
# Rebalance
** Schedule a re-planning session
!!! Make it stick
* Don't break the chain
!!! Three Track Attack
# Deliver - git stuff dun
# Discover - experiment
# Refine - fine-time and improve
!!! Share the Secret Sauce
* "Good catches" - willing to write down the near-misses if you can take it positively
* What was the thing that made this good catch possible. What popped in your head?
!!! Shared traffic circle, see if can grab that slide. Hans Monderman
!!! Iteratoins
* Can''t get it right the first time - don't waste time
* Get it right the last time
!!! Sign your work
* Be proud of it
JS Task Runner (like Rake)
* Joe Fiorini uses it like guard to run tests
* chain tasks together for a workflow: requirejs, copy, qunit, watch
http://en.wikipedia.org/wiki/Hash-based_message_authentication_code
AWS-like security
Bill Sempf
* OWASP - has all the tools and stuff
* "Google Hacking" for pentesting
robots.txt - big list of stuff that you don't want people to look at.
Comments should not be revealing, don't hide files, deploy as little as possible.
Services exposed for mobile are ripe for attack
Client objects can be decompiled
Failing to handle exceptions allows the pentester to know TOO much about the system and potentially take the app down.
Research -> Exception -> Source -> Research
Attackers do not use a web browser (they use proxies and scripts)
!! All data is evil
* Incoming data
* Outcoming data
* 3rd party data
!!! Reflected XSS
The error you encountered was: <%= Request.QueryString("error") %> for blah.com?error=<haxor code>
!!! Stored XSS
$.post ("insertRecord.php", { field: "Comment", data: "<script>haxor code</script>"})
!!! Preventing XSS
Get Data -> Encode it -> Transfer it
!!! DOM XSS
basically anytime user input is directly executed as javascript (like "hi Steve!")
Modern Agile
modernagile.org
Heidi Helfand
Joshua Kerievsky
Secure - without fear or care
!! Psychological Safety needs:
Be yourself
Make mistakes
Take risks
raise problems
ask questions
disagree
Amy Edmunson - Teaming
Fear of being seen as
* ignorant, negative, disruptive, incompetent
In Psychological Safety - Silence Kills
!!! Have you changed your behavior to avoid being seen as ignorant, negative, disruptive, incompetent?
* DoD meetings
* When I want the meeting to end
* When I think others want the conversation to end
The leader's job is to drive out fear
!!! The horsemen
Criticism, Contempt, Defensiveness, Stonewalling
What's your "go to"
What shows up in your team?
!!! Empathy Triangle
- my view
- their view (imagine it)
- relationship view (why does this matter)
!!! C.O.I.N
* Context - Neutral
* Observation - Factual
* Impact - How I felt
* Next Time - How it could be better
-Trying to integrate with an unknown part of the system
- I was struggling and asked for help several times.
- I felt abandoned. When I tried to soldier through independently, I found there were a number of bugs in the implementation. Then I got angry.
!! Psychological Safety in Meetings
* Smarter, Faster, Better -> Book list
* Encourage everyone to contribute
** Keep track of everyone who speaks - tick marks - easy way to see if it's safe for everyone to contribute
** Individual / Pair / Group - breakout activities
** Lean Coffee
** Brainstorm / Stickies
** Set-based design
*** Each individual or small group solves the problem individually. Then bring them all together to get "best of breed"
* Listen to One Another
** Level 1: Focused on yourself
** Level 2: Focused on the other person
** Level 3: Focused on body language & environment
* Review/Repeat Other People's Points
* Avoid Dominating or Interrupting
** Facilitators can help
** Give feedback privately
* Be Caring, Curious, and Non-Judgemental
** "I'm curious. Why do you think that?"
** Don't rush through the "Groan Zone"
https://onedrive.live.com/?cid=59d41466dbc75b47&id=59D41466DBC75B47%2141451&ithint=folder,mp4&authkey=!ANVrmMtni6D5uGk
@geepawhill
! self.conf
!! Software Development Excellency
The Flock and the 3 Flows
* Valued Results - I show it to you, you tell me if you like it
* Geek Joy - when we're in, we're all in
* Courageous Curiosity - Ask real questions and get real answers
!! Complex vs Non-complex
Linear error factor - if you're a little wrong in the guess you're a little wrong in the result - this is a sign on non-complex system
complex system - any error mean any result - can be off by an order of magnitude, or be completely impossible.
Make small changes and then reset. Start from zero. Radically revise your approach. Don't assume you can do the same thing twice.
Every practice has to prove itself in every practice. It has to be working in practice.
!! Optimize for collaboration
* It backs us when you follow a change and revise methodology
* Frequent Focused Direct Dialog
1) Thinking outside your head
* Power of expression forcing thinking
2) Energy Balancing
* Constant change is very draining
* More peaks because our energy curves are not perfectly in sync
3) Shock Absorption
* When the thing we're centered on jerks around it's a shock to each individual
* complexity exists in 100% deterministic systems (no randomness)
* with collaboration, our relations cushion us when the center moves
4) Domain Bridging for Ideas
* Most ideas come from other domain
* More people = More domains = more ideas
* Insights per hour
!! Activities
* Coding to Target - I know what I want to do, I just need to execute
* Coding to Experiment - Have an idea, need to feel out the solution
!! Dependencies
Help make things work - especially early on
* Physical space
* Permission - Mental space
* Inception - Encourage alot early on.
* Technique & Practice - This isn't "natural", real skills need practice
* Voluntarism - you need to be deciding, teaching, or learning
* Inclusion - invite everyone
* Acceptance - no one can do all the things well. Every strength is a weakness. Every weakness is a strength.
!! Is it working?
Buzz, whiteboards churing, tight standups
Not working: forced engagement, conflict suppression, room elephants, long process discussions,
! aab17
!! Software Development Excellency
The Flock and the 3 Flows
* Valued Results -> Where are we going?
* Geek Joy -> How will we get there?
* Courageous Curiosity -> Where are we now?
//Suspect All Systems//
!! Complexity
* The theory is rich, but very little practice
!!! Three difficult ideas
# Intricacy is Not Complexity
* Lots and lots of parts = intricacy
* Not complex -> those parts are often predictable
* Running software in the browser is intricate, not complex
* Complex things don't need lots of parts (they certainly can)
* The parts have agency -> I don't know how this works. Not just a black box. I do the same thing twice and get different results. It's unpredictable.
# The Predictability Knee
* We think that estimates that are further out are a less accurate. And the further out, the less accuracy. It feels linear.
* Predictability is actually a huge drop off. There is a point where once you get far enough out, accuracy drops to zero.
* I can't choose to be more accurate past the "knee". It's not possible.
* The "point of the knee" is difficult to figure out. The horizon.
* We don't know how long it will take to get from A to B. What's worse: We don't know if it's possible to get there.
# Step Tree vs Step Sequence
* We think if we break into 5 steps from A to B we'll fix it.
* We can't get there in a linear fashion
* We're mostly trying not to step away from to A
* We don't know our "new" small destination is achievable either
!!! Professional software development is all-in, all-the-time, all-around, compexity
* Too many unpredictable agents/actors
* Assume every practice has to justify itself
* Change everything that doesn't work
!!! Optimize for Collaboration
* We have a constant need of ideas (ideas per hour)
* More domains, more ideas, more people
* We need people to give us stability (the problems are ever-changing)
* We need Juice
* Nobody can be on all the time
* Accept peaks and valleys
* Frequent Focused direct dialog (F2D2)
@catswetel
Cool idea: a request stack...something goes on, something must come off.
Diversity is being invited to the party, Inclusion is being invited to dance
Watermelon project - green on the outside, red on the inside
Tips:
* Introduce Participants
** Point out why Sue needs to speak up - Glad you could make it Sue, you can tell us about the mainframe
** A way to assign roles in the meeting
* Schedule the meeting
** You set the agenda
** Can frame roles in the agenda
** Create an enviroment for success
* Set team agreements
** Can we agree that no cell phones / laptops?
** Chatham House Rule - You can share the stories but strip out the identifying information
* 1- 5 exercise
** Do a fist of five, I'm a 5 I can't handle silence, 1 I would rather than do anything but talk in front of a group
** No 3's!
* Lean Coffee
* End the meeting
The Discipline of Noticing
* Account of the event -> Just make observations, no judgements (Don't account for)
@onealexharms
"To speak up without fear"
"Safety happens one person at a time. It's an emergent process"
----
Carl Rogers: People have what they need inside of themselves and he can assist them with finding it.
Conditions for Therapeutic Change:
1. Congruence
2. Empathy
3. Consistent Fondness
!!! Congruence
How I see myself and how I want you to see me is aligned.
No bullshit
Align your values with who you are. Do the work.
!!! Empathy
The ability to understand what someone else is feeling.
Empathy can be learned.
What needs might this person be trying to meet?
Courageous Curiosity - What's going on inside this person?
Joyful mistake making
@searls
http://blog.testdouble.com/posts/2016-12-01-a-creativity-talk
Creative ideas stress me out -> How will I find time to do them?
Don't cede control of your happiness to someone else
1. Inadequacy -> People to imitate
2. Indignation -> Something to say
3. Incompetence -> Always have room to improve
* Recognize when it's safe to make a mess
* Find the smallest thing you can get caremad over
* Working code can sell ideas
* Ideas require no maintenance!
* Popularity without purpose is toxic
* No shame in "hobby-grade"
* Selfish toy-apps can inspire
* Not getting through? Tweak your message
* Criticism is easier than contribution
* It's okay to build things for fun
What thing bothers you -> Reflect -> Take those ideas and find an outlet
@jedberg
!! Netflix Way
* Built for three - three of everything
* Automated
* Fully automate machine image bakery (no chef or puppet)
* Automated deployment
* Every Independent teams responsible for DEV and OPS
* Redundancy through mult-regiion deployment
!! Freedom and Responsibility
* Hire responsible adults and give them the freedom to do what they think is right
* Things usually don't break
* Manage capacity and autoscaling
* Fix anything that breaks at 4am!
Shared state should be sotred in a shared service - replicate data everywhere
Engr boot camp to teach them how to build in a highy distributed (highly redundant) environment
2B requests per day into the Netflix API
Netflix has all the content stored on a local CDN, rest is on amazon
!! Highly aligned, oosely coupled
* Teams are good at communicating
* Auto-scaling (SOA)
* Effects are narrow
!! All systems choices assume failure is inevitable
* Reliability vs $$
* Chaos Monkey
!! Asgard
Cloud orchestration tool - modifies Amazon - open source
# Push code,
# Launches new cluster with the new software (as an image).
# Load balancer
# Use new cluster
# Delete the old cluster after a day
# If something goes wrong the balancer can shift some of the traffic back to the old code, or all of it if the new code is SNAFU
* ''Moves granularity from the instance to the cluster''
!! Why Bake?
* Take Base Image
* RPMs
* Jenkins / Yum / Artifactory
* Own your service, own your machine, pick your platform, language, etc, doesn't matter
!! The simian army
* Chaos, Latency
* Everyone knows chaos monkey is coming and builds for it
!! Data
* Cache (memcache)
* Cassandra
* little bit of MySql (fringe)
!! EVCache
* open source
* Wrapper around memcache
* Replicates writes to multiple zones
* Pulls cache data from local zone first (affinity)
!! Cassandra
* Distributes data around the ring
* Horizontal scaling is easy - just add more nodes
* Uses quorum among distributed nodes to determine what will be returned - caller configured
* Prefer availablity over consistency
* Prefer Writes over reads
* Jave-based
* Open-sourced and with commercial support
* Fast negative lookups
!! Going multi-zone
* Loosely connected
* Low latency between zones
!! Leveraging Multi-region
* Claim: 100% uptime is theoretically possible - IF you replicate all your data
!! Acitve/Active
* Data replication challenges
* Cache invalidation
* Misdirected user
* Sudden load increase during failover
* When do you fail over?
* How do you replicate cache?
!! Cache Replication
* Three strategies
** No replication - recommended. Can you write your software to work without data replication?
** Invalidation only - default mode. Just re-grab data from the database again when you fail over.
** Full copy - For the teams using memcache as a DB
!! Failover
* Need to scale up
* Need to route misrouted users back "home"
** Mismatch between actual IP and resolver location
* Blog post on netflix (active/active failover)
!! Chronos
* Logging/Event tool
!! Best Practices
* Incident Reviews
** No blame
** What went wrong?
** Detect it sooner?
** Prevent it?
** Prevent this class of problem?
** Improve our reaction to this kind of problem?
!! Circuit Breakers (Hystrix)
* If your dependencies are failing, return a default response
* Gives dependency a chance to recover, rather than hammering it
!! Autoscaling
* Obviously good for peaks
* Good for scaling down too. Reduces complexity, deployment times, etc
* Leads to renewal of machines as well
!! DDOS
* Believes Amazon has some DDOS protection
* Autoscaling covers peak problems
!!
* No teams share data, all access is through the service
@NathanDotz
https://github.com/sleepynate
!! Intro
* Command pattern is same as passing functions
!! Definitions
* A monad is and object that lets you use the object inside it
** Lists are monads
* Functors are stuff you can map over
** Lists are functors
* Applicative functors are stuff you can map over and get a stuff of functions back
* Currying is a function that takes and argument and gives you a function that does the same thing with one less argument
** Special case of applicative functors
!! Crib sheet
* Declare, don't assign
* Calculate, don't mutate
* Pattern match, don't if-else
* recur, don't loop
* pass functions, not structs
* map, filter, reduce
http://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-development/
https://www.facebook.com/notes/990860537613477/
Kent Beck on how he spreads ideas.
# Adopt personally
# Find the totem
# Repetitively broadcast
!! Adopt personally
Seems obvious, dogfood and work on the theory and mechanics of the idea.
!! Find the Totem
Starts talking one-on-one with the idea that he will fail to explain the idea well. Focus is on spreading the idea, not convincing everyone that every part of the idea is worthy of consideration. The idea is to find the hooks that make this resonate.
//This is obviously a problem with my failure talk and how reluctant I was to cut any part//
* Name.
* Motto.
* Metric.
* Mascot.
* Gesture.
* Utopia.
* Abbreviation.
* Diagram.
!! Brute Repetition
This is hard and it sucks. It takes years and decades of repeating yourself.
Robert Cialdine Influence - The Psychology of Persuasion
Switch
'' Giving ''
Give gift
Give time
Set a rule - give a pass
''Commitment Consistency ''
After making a commitment you'll work very hard to keep it
- Get people to make concessions and keep twisting - Chinese army did this to make soldiers look like they were against the US
Standups create commitment consistency by getting people to publicly declare what they will do today
Commitment consistency will cause people to follow through on a commitment even when conditions change and make it a bad idea or impractical or violates the original spirit on the commitment.
Scrum changed from team commitment to team forcasting to allow for teams to change with conditions rather than sticking with bad commitments.
'' Authority ''
- Can use second hand - "Kent Beck says.."
'' Scarcity ''
Let's do this for a short amount of time
Quantity scarcity, knowledge scarcity
'' Social Proof ''
- If nobody's doing nothing then it must already be taken care of
Vague blanket statements - everyone assumes someone else will do it
Pick someone! Force action.
'' Liking''
Body language mirroring - miror inflection, speed, temper of the voice - helps make connections. People like themselves and like people like them.
"I'm one of you, I want to work with you, make it easier for you"
Key concepts of Industrial Revolution:
* Break endeavors into small, easy tasks (assembly line)
* Mechanize some of those steps
* Who do you most admire and why?
* In your last employee review, what areas for improvement were identified?
* Why are you here?
* What is your passion?
* Describe an environment in which you would not thrive.
* If you could do anything, what would be your ideal job?
Tell me about a problem you solved recently.
Tell me about your most recent project: what was your role?
What kinds of challenges did you have?
Tell me about the problem you solved that you have the most pride in. When was it and what happened?
Tell me what you are learning about these days.
-Books
-Side projects
!!Intro to Android
developer.android.com /-- Start here, most popular google hits are out of date :)
Use android support library (selection in SDK)
Create Android Application Project
Create an android virtual device(AVD)
- Set an SD card
- Create snapshots (VM style)
Launch AVD from AVDM
Activity - Intent - App whats the relationship?
Everything in res is autogenerated into R.java
* If this gets out of wack, clean your project
Everything in android is a view - buttons, controls, etc are views
Activity.onSaveInstanceState - used to save everything when user changes orientation, switches app, etc
----
Can I write an app for alec? Click on letters to spell words?
ABCDE
FGHIJ
KLMNO
PQRST
UVWXYZ
Pick C
filter letter list based on dictionary?
AEHIORUYZ
After finishing a word go grab an image from wikipedia of it? (hmmmm...could get messy)
----
Intents wrap Activities
An activity can launch another activity by creating an intent.
Hand off loading to Loader (vital if doing network, probably good idea regardless)
Use AndroidHttpClient to execute web requests
Open templates for requests using a resource from the context
http://arlobelshee.com/is-pair-programming-for-me/
* Pairing is a skill you have to learn
* Mostly communicative norms, like a foreign language
* Arlo converted 198/200 people to pairing (introverts, skeptics, etc)
* If pairing is not working, then it's because the team has taken for granted how hard it is to learn
* 3 weeks to break-even productivity if pairing 100% of the time
!! Cronology
* First two days - this is a good way to collaborate and learn
* End of first week - this is exhausting, too much noise
* 2nd week - same
* End of week 2 - filters are starting to build, still hurts
* Sometime in week 3 - Huge payoff is discovered: huge bug fixed easily, fewer meetings, pair-thinking, etc
* week 4 - lots of wins, lots of converts
!! Arguments
* What about half-day pairing - probably takes longer. Approach pairing as an experiment, something the team wants to learn/try.
!! Arlo rules
* Full team must commit
* 4 week commitment
* It's an experiment that can be abandoned
* Team understands it will learn these skills
** Speak in half-sentences (allow the pair to pick up)
** How to talk about unformed ideas safely (accept a low signal-to-noise ratio)
** Establish subconscious filters
** Collaborate creatively
** Collaborative research
** Collaborative analysis and deep thinking
*
http://blog.toolshed.com/2015/05/its-an-experiment.html - Andy Hunt
!!! Very few "Agile" teams are actually agile
* Not adhering to a particular methodology
* Continuous Deployment might be the shining indicator of a truly agile team
** " It doesn鴠matter if your design is awesome and you鶥 figured out the customer鳠needs if you can鴠then actually get software out the door consistently, reliably, and automatically."
!!! No one likes change
"What folks want is new and different results. Preferably for free, without having to change anything significant. But most of all, folks really don鴠like to be changed. For any chance of success at all, change needs to come from one鳠own desire. It鳠like the old joke where the lightbulb has to want to change. "
''What's the upside for me?''
!!! Experiments as a first-class feature of the methodology
* "For novices, the feedback and evaluation are very concrete and unambiguous, with no judgment required. That part comes later."
* Experiments are time-boxed
** Limit risk, limit the "change" fear
* Everyone participates in the experiment and the evaluation
** Put your egg in
** Participation is KEY
!!! Build feedback loops to advance
* Try it before you "buy" it
* Encouraged to modify and reject experiments
https://code.likeagirl.io/i-am-a-woman-in-tech-and-this-is-what-i-want-in-a-company-f6177569a287
!!! Don't talk, show
* See another woman, ideally on the team. Need to feel safe to ask questions, it is easier to ask a woman
* Meet + chat with members from every team, see how awesome they are
!!! Tell me how you're going to help me grow
I won't ask for promotions, I want to know what the expectations are so that I know when I've leveled up and can move to the next thing
!!! I should forget that I'm a minority, *but* be supported when I remember
<<<
If I tell them I want more women to get into tech I want them to say “So what are you going to do about it?” and know that they will push and support me.
<<<
!!! Help me fight my imposter syndrome
<<<
A lot of people don’t like to brag or bring attention to their accomplishments, that’s why you need to do it for them. Seeing others be supportive of their team mates and brag about other’s accomplishments is a powerful thing. That is an environment you can’t fake, and everyone deserves to be a part of.
<<<
* Closures
* Interface enhancements
* Bulk collection
shapes.forEach(s -> {
if(s.get Color() == RED)
s.setColor(BLUE)
}
@macdonst
Anyyang - 2K great library
github.com/macdonst
@docondev
An invitation is not a command or order, it is request or enabler. Encourage, not mandate.
Both Lord-leader (Command and Control) and Servant-leader are extremes on a spectrum.
Servant Leadership is a poor model. The 7 pillars tell us who a leader should be, but not what they should do.
A leader can never answer the question: "Do I lead with moral authority?" It can only be given to you by every person you lead. And it can be ripped away by a single misstep, a single betrayal.
------------------------
Let go of your expectations, let what *is* to emerge.
----
Host Leadership
* Initiator - provides the spark
* Inviter - invites others
** "What sort of invitations do you send"?
* Space Creator - creates the "right kind" of space. Sets up the rules for the interaction.
* Gatekeeper - defines and protects the space. Enforces the rules.
** Reminding team agreements
* Connector - puts people together. Enable conversation. Bridge the gaps. The glue.
* Co-participator - Be a member of the team. Experience.
@jonathanpopham
In essence, a community is a collection of relationships.
!!Social capital
* trust, reciprocity, cooperation
* difficult to build, how likely people are to do something for you, how likely you are to help out.
!!! Trust
* You do the things you say you'll do
* If you know there is a trust boundary, don't get too close to it. Don't press your luck.
!!! Reciprocity
* Do good things without being asked
* If someone does something good for you, repay that in kind
!!! Cooperation
!!!Positive Conflict Resolution
* Accept conflict, look for good result
* Interested in building relationships (between the parties and between each party and you (relationship-triangle?)
!!! Find Out
1. What is the main problem?
2. Who is involved?
3. When/where did it happen?
4. Is this dangerous?
Lean
* Improve Cycle Time
* Smaller Batches
* High Quality
Startup
* Major disruption environment
* Customer uncertainty
* What do people want?
= __Lean Startup__
* Avoid Building the Wrong thing efficiently
* Find the Right Thing
Strategic:
* Remove barriers to real-world
* Help kids open up
* Push boundaries
* Building empathy
Tactical:
* Mobile apps are the bridge to real-world pitches - Give kids scaffolding
* Change perspective by changing environment
* Get Out - ''Iterate'' - Pivot
* Embrace Failure - Let them fail
* Self eval, Peer eval
* Constant communication creates safety + comfort
Actionable:
* Great Idea gong
* Taught by critique
* No tutorials
IoT client giveaway - neat lamp that lights up when mentioned on twitter
Hackathon every 2 months?
How do we build slack?
https://blog.dnsimple.com/2017/02/learning-to-fail-fast-at-dnsimple/
* Fail as Fast as you deploy
* Failing Fast helps avoid Sunk Cost Fallacy
* Stop and figure out what you learned
* Start over with knowledge to avoid failure areas
So I've tried to explain a phenomena to a few people lately and I keep falling flat. I can only conclude I'm explaining it badly, or it's a solved problem that I haven't seen the solution for.
So imagine some legacy code. My most recent example was a chunk of a few thousands of lines in a class spread across a handful of methods. Pretty much status quo for this app, but this was particularly painful because it was a huge chunk of the business rules for various validations. There was temporal coupling, where half the code was basically ignored under some conditions. This caused some issues when we'd go to add new checks - it wasn't apparent that this 1200 line chunk was effectively dead code under normal operations, because the coupling was enforced three layers up.
So we did our due diligence and got most it under test coverage. At least to the point where we felt comfortable pulling at it a bit.
It's hard to describe test-driving a change where the "wrong" solution is already in place. Here we have 6 years of tweaks and pokes of fairly complicated code all dumped in the middle of an even larger class (this logic is probably 5% of the total class size). It's a big, awful, mess. I had two goals in mind:
1) Make the temporal coupling explicit
2) Put a fence around this minefield
So here's where I have trouble explaining what happens. Here I have a chunk of code. I want to change it safely with small refactorings. So I make a small change. Run my tests. Repeat for hours/days/whatever. Unfortunately, unlike "normal" TDD - I'm not getting feedback on design direction. I'm running my tests constantly and staying green, but I have no idea that this idea for trying to pull out a class is a good one. Or that changing the return value on this method helps in any way.
I think part of the problem in my explanation is that I'm saying "refactor" but I'm really talking about "re-design" in a significant way. Refactoring a class is easier to think about; hopefully I can wrap my mind around all the relevant parts and keep seeing the simple steps forward. This is still refactoring in the application sense, I don't want to change it's behavior. However I do often want to change how several classes work together to simplify the design. With TDD that's easy (for me), I just listen to the tests.
Normally in TDD I can listen to my tests. If the setup is excruciating for a test case I can see where it needs to change. If the assertion is complicated, I can see that I'm probably testing via the wrong method. If I'm copy/paste/hacking chunks of code around, that's an alarm that I'm making this too hard to understand. Tests provide great FAST feedback on design decisions. I detect obvious seams and can see where my classes are taking on too much responsibility. I can make little experiments very quickly and get that fast feedback where a first class collection worked well here, but introducing this value object didn't clear much up.
With this case - we have a ton of painful tests. Think about how many unit tests we needed to cover all the conditional complexity in this example. I'm completely immune to this pain - I just spent days sucking it up to get the code under test. And I don't want to change these tests - they're now my safety net for future change.
So yes, I make my changes. I run my tests. I keep the bar green. But I'm not getting anywhere. I might spend hours gradually building the wrapper for this code and plumbing it through the layers. Just to find that it won't work because X. Or it's making things worse! Some abstractions just don't work. How many code bases have I dumped a new idea into that didn't take off? Too many code bases are swamps of vestigial tails.
I've only stepped away from one of these sessions twice feeling like I'm now "ok" with this code. *That* problem won't haunt my dreams forevermore. The first time I was extremely lucky. Everything just worked, I focused my chi, I was guided by the Muses - just one of those "zone" experiences that only seem to happen at the rarest of times. Generally I fail/fumble my way to a solution - I tell myself it's the scientific method. I have no idea how to reproduce this miracle, I took small refactoring steps as I'd prefer to, I just always picked the right one that led to a simpler solution.
The second time I essentially started test-driving the solution from scratch. I built the whole thing up again, using the existing tests as my guide. And then I had a big-bang switchover where I drove the new solution with the old tests before deleting those monstrosities forever. And that sucked. First there was the process of doing 4x the work of just getting it under test in the first place and hacking something together. Then there was the problem that the new solution was completely worthless until it was done. Then there was the integration step at the end. Back to the bad ol' days of pulling it all together at the end and wondering why it didn't work.
I've tried to detect places where you can split the big ball of mud and test-drive those into smaller-bang switchovers. But I seem to pick the wrong splits to keep my old tests working and still move towards a better design. In this case we were just trying to get it all into a single terrible class. And we couldn't figure out how to get there from here without breaking everything. Twice.
Every other time, I've tried what seems like the safe route. Get it under test. Refactor the obvious stuff. Hem, haw, and pontificate. Get burned out and move on to something else.
There has to be a way to handle this problem. If not, we're screwed, because code like this isn't going to be wished away. It's strange that when we build every line of code of a project with an eye to the future, it doesn't last. But if we get a few things right, we can pile terrible hacks on top of it for decades and it just keeps plugging along.
Any ideas?
http://legacycoderetreat.typepad.com/blog/2011/11/how-i-run-legacy-code-retreat.html
http://www.github.com/jbrains/trivia
Jeremy Miller @jeremydmiller
shadetreedeveloper@gmail.com
First used in production in 2004
Nothing remains but the name.
!! Long lived codebases
* language has evolved
* use cases become obsolete
* new cases become very important
* architecture is obsolete (no xml)
* Tooling evolves
* performance and threading issues due to adoption outside the original case
Need feedback mechanism to evolve
"Crimes against computer science" = Instead of re-architecting just bolt it on.
** Used chain of responsibilty to fix a deep copy
!! Architecture cannot be Set in Stone
* Should have done a rearchitecture
** Key question: Why is this thing I'm trying to do so hard? Don't get locked into a bad idea.
!! Re-write or Improve in Place?
** Started a re-write, got distracted, bombed.
!! Automated Testing
* You have to do both acceptance and unit level
* Self contained acceptance tests - test inputs should be defined with the setup (no fixtures for acceptance tests!)
** Follow same rule with unit tests - duplication is A-OK
!! The great refactoring
"When we say big refactoring we're lying...It's fine I'm just rewriting the whole data layer"
* Introduce an alternative programmatic configuraiton
* New, better ways to do it
* Tried to shove a bunch of wouldn't it be cool features
!! Don't couple runtime code to configuration
* Aerosmith doesn't setup the stage
* Roadies do configuration
!! Build features for real needs
!! 2004 vs 2015
* 2004 Everything explicit "never surprise me"
* 2015 Try to figure it out "just let it work"
!! API
* Don't let the impl bleed through the API - hard to change
* Be the client first
* Be consistent
!! Diagnostics and Errors
"Here's your error. And here's what you might do to fix it."
If you have any magic - provide diagnostics that explain the magic for a given input
!! Documentation
"Do as I say, not as I did...."
"Living" documentaiton - part of your build process. - save yourself the future headache - bad documentation is a constant pain point.
*** DocTest
!! The cost of backward compatibility
* You cannot win
* Take the trash to the curb
* "Python 3000"
* Semantic Versioning
@samjonester
!!! Concepts
Forget about nil
declarative modeling
composition
Let the compiler drive
!!! Forget about nil
* "Whats the return type?"
* if nil is involved, it MAYBE will return the correct type
''consistent return type''
Maybe ''will'' go viral => good thing
Can handle errors at the edges.
!!! Declaratively modeling our domain
WE can't control transitions. Going from creation time to "full valid" object provides a state where a model might be inconsistent.
So we code defensively to keep things from blowing up.
//Interesting observation!//
Haskell forces us (via compiler) to handle all the types of the customer whenever we use a customer.
!!! Composition
* Use domain concepts as things
* Build big things from little things
Change is cheap before the implementation
''Types provide context''
{{{
type chunks :: [String]
}}}
//I like this idea of types avoiding primitive observation - seems cheaper than a class//
Build a mirror with live data (weather, calendar, notes)
15" LCD with 12"x12" mirror seems the cheapest, materials in the $150 range.
http://www.raspberrypi.org/magic-mirror/
http://michaelteeuw.nl/post/82565319113/magic-mirror-part-iv-install-the-hardware
http://www.eetimes.com/document.asp?doc_id=1278280
http://www.hiddentelevision.com/sample.htm
http://www.hiddentelevision.com/samsungledmirrortv.htm
http://www.hiddentelevision.com/diyframelessmirrortv.htm
http://www.hiddentelevision.com/mirrorpricequote.htm
Or a LCD controller
http://www.ebay.com/usr/e-qstore
http://www.element14.com/community/people/knight_rider1977/blog/2013/11/26/hp-lcd-screen-comes-back-to-life
Or a LCD controller + screen
http://www.sainsmart.com/7-inch-tft-lcd-monitor-for-raspberry-pi-touch-screen-driver-board-hdmi-vga-2av.html
!! Six questions you should know the answer to about your manager
* Where does your manager come from?
* How does your manager compensate for their blind spots?
* How does your manager communicate to the rest of the org?
* How does your manager talk to you?
* Do they do what they say they'll do?
* Do they make things happen?
* What happens when they lose their cool?
!! Freakouts
* Don't pile on
** Listen, nod
* Give the benefit of the doubt
** They've obviously given this a lot of thought and it concerns them
* Ask questions - try to move towards a rational conversation
* Listen for solutions
!! Agenda detection
* Identify Pros
* Identify Cons
* Identify Issue
!! Make a rolodex
* People you respect and would go to war with again
!! Teams
* Incrementalists need Vision
* Completionists need Action
* Pair Incrementalists with Completionists
http://www.amymorinlcsw.com/mentally-strong-people/
* Don't feel sorry for myself
* Don't blame others for my choices (My boss made me)
* Embrace change, adapt
* Accept that some things are outside of my control, focus on what I can change
* Don't try to please everyone - be kind and fair
* Don't fear calculated risk (CBA)
* Don't dwell on the past - acknowledge past, embrace present, plan for future
* Don't repeat mistakes
* Don't resent others - celebrate their accomplishments
* Use failure to grow and improve
* Don't fear being alone
* Don't feel entitled - try, fail, adapt, try again
* Don't expect immediate results - anything worth doing takes time
I need a mentor
(Venkat, Angela, Doc)?
* What do I want?
** Advice on delegation, letting go, finding time
*** Angela on Collaboration, Cooperation, Delegation - consider each person is an autonomous agent. They have to agree to be delegated to.
* How do I approach it?
* What do I offer?
How to be sociable?
* Canned icebreakers
!! Mentoring
* What is the one thing a student can do to move them forward?
* Encourage Why? And beginner questions.
* Being Geek - Michael Lopp
* How to get an inexperienced mentee engaged with solo experimentation and discovery?
Will Evans
@semanticwill
6 Keys to Lean Startup
* Uncover your customer's pain points through research
* Invalidate your assumptions
* Formulate hypotheses
* Experiments, Not Features
* Learning isn't failure
* Amplify what works
Think -> Make -> Check -> Think -> ....
As quickly as possible - start with what you're trying to learn. What's the smallest thing you can do to get feedback? 1 hour sprints, 1 day sprints.
Lean Startup: Customer Development Process
1) Problem Solution Fit
Focus: Validated Learning
Experiments: Pivot
2) Product/Market Fit
Focus: Validated Learning
Experiments: Pivot
3) Scale
Focus: Growth
Experiments: Optimizations
!!!Meta-Rules:
1) Clearly articulate & test your assumptions about the customer - "The customer is the person that gives you money"
2) Get out of the building
3) Fast Think > Make > Check
4) Think in terms of experiements (not features)
5) Iterate
6) Don't sink time into something that hasn't been validated
!!! Minimal viable Product
* Means something different to everyone
In Lean UX - It's the minimal amount of effort you have to do to make one turn of the feedback loop.
"Features based on user stories without customer validation are called guesses"
Maximize:
Solving Customer Problems
Learning
Minimize:
Cycle Time
Waste
The delta between a prediction and the observed outcome is the "amount" you've learned
!!! 4 Kinds of MVPs
* Exploration - investigation with a customer's problems
* Pitch - attempt to sell
* Concierge - Provide the proposed product as a manual service (no software product)
* Wizard of Oz - Small testable model that exists to generate feedback
!!! Vanity Metrics
* Don't lead to action
* Always go up (and to the right)
** hits, followers, etc
!!! Good Metrics
* Actionable
* Accessible
* Auditable
!!! One Metric That Matters
* Capture everything, but focus on the most important team
* Success == THIS ONE THING
* Forces a line in the sand
* Must be a ratio
* Must be actionable
* Must be understandable and auditable
!!! The LeanUX Kata
* Who is the customer?
* What is their problem?
* What do you know and how do you know it?
* What are your assumptions? How will you test them?
* What have you learned and what should you learn next?
* What is your very next experiment?
* How will you measure it?
@mdclement
blog.softwareontheside.com
Mob Programming where three people were researching and would swap into navigator after doing some research.
Added more people - > too crowded! Tried to add a remote "viewing" station. Didn't go well.
!!! Discoveries
* Physical Space is very important
* Bought a keyboard for every developer
* Strong pair typing -> For an idea to go from your head into the computer, it MUST go through someone else's hands
* Start with intent, Move to location, detail -> "hey type this". Imagine doing voice command with a brilliant AI, somethings will be easy, others will need lots of hand-holding.
* Mobbing Timer -> Can I use this for pomodoros?
* The hard work is when you're not at the keyboard. That's when you have to think. So you need to keep the off-keyboard time short.
* No standups
* Resilient -> vacations, sick time, bus factor, no big deals
* Focused on working on the right thing - more sensitive to waste from side tasks
!!! Downsides
* Less worktime flexibility
* Looks funny from the outside
* Product management.....PM didn't want to participate in the mob
!!! Workshop
One navigator many pairs
One navigator, many mobs
** Table navigator is the buffer between the room navigator and the table driver
github.com/willemlarsen/mobprogrammingrpg - Gives more roles for the mobbers, since it's not clear what they're supposed to be doing
It's fun!
* LTE network latency is ~50 ms
!! Big steps
# Distribute Delivery (CDN)
# Store objects closer to the end user (Advanced CDN (pre-cache)), user cache
# Decrease end-to-end time
!!! Dynamic Content Accelerator
* Essentially a private backbone to conquer a geographic constraint (edge-to-edge)
!! Optimize for Mobile
* Deliver mobile content first - Make desktops throw it away
* Mobile browsers have small caches (32M)
* Send the right images (use headers)
* Pre cache based on user's guided experience (interaction diagrams?)
!! Embrace mobile constraints
* Imagine no cache. How do you conserve power (avoid requests)?
* Assume user will not stay connected. How will they use the app?
* Avoid Polls
* Group requests and pushes
!! Ideas
* Monitor state of radio and piggyback when its active
* Decouple UI from network calls
* Burst and idle
* Optimize network for bursty traffic like that (TCP window adjustments)
http://www.cio.com/article/739333/How_to_Move_Beyond_Project_Estimates_and_Provide_Better_Value
!!! Fundamental problem with software estimates
* Estimates work well on products - you've done the same thing many times and have a good idea what it takes.
* Software isn't a product, it's design all the way through.
* If you get to the point where you can estimate accurately, you've screwed up. Since a software product is FREE to duplicate, your estimate should be zero by the time you can estimate it accurately.
* It doesn't matter what you estimate if you build the wrong thing
!!! Flip the question around
* What estimate would change how you approach this problem? Does it make a difference?
* What's the go/no-go figure?
** Sometimes it's easier to say what can be accomplished on a budget rather than "what's the combined time for everything I might want?"
** Could this drive us to decide when to pull the plug on a project?
* How can we make better decisions?
* Can we prove estimates help us make good decisions?
* Would you prefer to hit the deadline if it means you don't get what you want?
* If we spent the time estimating on building the project, would we learn something useful?
** So rather than spend two months figuring out how big it is, spend two months building it and see if it's worth pursuing further?
!!! What if we could decide when to start and stop projects?
* Focus on modeling values and risk
!!! Why are estimates attractive?
* Estimates are easy. They make decisions easy
* Should we have confidence in them?
!!! Where could this go?
* What if we could build the top %5 in a week? Release, measure, iterate
* What if a week of work could fund itself?
* By quickly adding value, increasing efficiency or increasing revenue - we can fund the next piece.
* We stop when something else shows up when there doesn't seem to be additional value of something else seems more valuable
* What if I have to pick between multiple projects? How about starting them all and figure out which one is most valuable TODAY?
Flow
Same size
Slicing Heuristic
* One acceptance criteria per story
* others...
Key to the heuristic is that it's something concrete that you know before you start working on the story
More...
Steve Klabnik "I happened to get an X1 Carbon. I was coming from a 13" MacBook Air 13", and the Carbon is very similar. It鳠14" though, which is a really nice size; it still fits in the same pocket in my bag as the MBA did, but I get a little more screen real estate. A note for those who give presentations: the X1 Carbon uses a MiniDisplay port, so save your Apple connectors!'
Avdi:
Hanselman: http://www.hanselman.com/blog/ReviewTheLenovoX1CarbonTouchIsMyNewLaptop.aspx
http://lkuk.uservoice.com/forums/205869-lkuk13-call-for-papers/suggestions/4242723-the-guessing-game-alternatives-to-agile-estimati?utm_campaign=shorturls&utm_source=lkuk.uservoice.com
http://www.infoq.com/news/2008/08/estimates-wasteful
http://dannorth.net/2013/08/08/blink-estimation/?relatedposts_exclude=1018
http://dannorth.net/2013/01/15/accelerating-agile/?relatedposts_exclude=1097
http://www.confreaks.com/videos/2427-railsconf2013-nobody-will-train-you-but-you - Zach Briggs
* Everytime you do a google search - make it your own
** Create an index card - search on one side, answer on the other
** Review those cards
* Memorize a good tutorial. Treat it like a kata
** Spent 40 hrs on Gary Bernhardt's Suck Rocks screenscasts
* Sentinel Object
** Don't return nil! They're useless in stacktraces.
** You don't need to go overboard with errors either. Just do something simple:
{{{
class Scoreboard
NoScore = Class.new
def score player
calculate_score player || NoScore
end
end
}}}
Leads to stack trace like:
{{{
NoMethodError: undefined method 'each' for Scoreboard::NoScore
}}}
Public, part of the users 좩ography�n an internal web site. Includes past OKRs and 짲ades"
Benefits:
* Discipline + Focus
* Communicates accurately (what is important)
* Establishes feedback loop
Hygiene:
* 5 objectives, 4 key results MAX
* 60%+ objectives come from the bottom-up
* All must mutually agree - no dictating
* One page best
* Not for perf evals
* 60-70% good, 40% bad. Should be uncomfortable
* Continue with Incomplete Key Results only if they are still important
Grades:
don't really matter other than to talk about direction
Public grading:
Don't get it, why would you want to sit through that?
Impl:
Use google sites
http://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html
!! Strawmen refuted
** OO is not state
** All programs are functions bound to data
** FP imposes discipline on assignment
** OO imposes discipline on pointers
** Design patterns are useful regardless of the constructs of your programming language
----
<<<
What benefit does polymorphism have that normal Functional Programs don't have? By the same token, what benefit would OO programmers gain from imposing discipline on assignment?
<<<
!! OO provides polymorphism. What does that get you?
Polymorphism inverts the source-code vs runtime dependency. This provides interfaces and makes plugin systems possible.
!! FP provides immutablity. What does that get you?
Concurrency!
On Being An Agile Change Agent From The Inside - John Ceglarek
https://www.boxcast.com/show/#/on-being-an-agile-change-agent-from-the-inside-john-ceglarek
* "We sent IT off to learn agile. We thought agile was a process. Agile's not a process. Agile is a culture"
* "The sizing step didn't add any value, so we got rid of it. We were always wrong anyway"
* If you have to integrate with silo'd teams, you just steal one of their people to pair with you.
* "For every three cards we write, we only end up implementing one...get it into someone's hands and you'll find you don't need it"
!!! How to fund an agile team in a project budget allocation environment
Made the case: Here's our "contractor" spend year to year
Fund a product roadmap instead - "Eternal funding" for a "product line"
Justification: "We always need stuff"
humanutility.org
I was a hacker who gave a damn
We just mechanical turk'd everything together to make a difference.
This doesn't require a ton of engineering effort.
http://www.jbrains.ca/permalink/one-practical-alternative-to-estimates
<<<
Whenever I find myself expressing 졮ti-�houghts I think back to a wonderful trick that I learned from Arlo Belshee and James Shore. They ran a workshop about integrated tests where they asked what benefits they give us, rather than focusing on all the problems that they cause. When they did this, the discussions in the room became so much more constructive than the ones I餠seen online. Not only that, but we (mostly) stopped dwelling on the problems we faced, and instead shared numerous ways that we get those same benefits by other means. It can also help find essential benefits that we don鴠get by other means, and encourage us to look for alternatives.
<<<
What is beneficial about estimates? ''They reveal assumptions''
!!! How do we avoid the trust breakdown?
* PO upset about conservative estimates
* Programmers pulling rank to pick an estimate
* PO pressure when estimates are higher than expected
* Work is already committed so estimate is worthless
When the trust is broken, I'll tell you what I think you want to hear so I can get away from you.
!!! Expiring estimates
* Encourage revisiting estimates - say every 2 weeks
** If we're going to assume estimates go bad quickly, why put any real time into them?
''It seems clear that talking about the estimate is more valuable than the estimate itself''
//Obviously true (to me) shared understanding is the thing//
!! A practical alternative to estimating = BDD
* Task/story-level estimates routinely cause more problems than they solve.
* The act of estimating with people that we trust helps us reveal significant risks in the assumptions we make about the work.
* The act of estimating with people that we don鴠trust leads eventually to ritual, Cargo Cult, whatever you prefer to call it.
http://words.steveklabnik.com/how-to-be-an-open-source-gardener
Figure out:
* What are issues for? (on this project)
* How to tackle?
** Read all of them (find your bearings, what sort of things are common?)
** Do it again. Now you can triage.
* What's our triage algorithm?
** Is it a feature request? Do X
** It is a request for help? Do Y
** Is it potentially stale? Ask if anyone knows if affects the current version.
** Not enough information to even try reproducting? Ask for more information - ideally the specific things it needs.
** Enough info to repro? Try against HEAD. Leave a comment indicating how that went.
** If reproducable, assign it according to the bugfix policy.
* How will you tend the garden?
** Need a scheduled time to stay current on all the issues.
*** Klabnik used github notify and read the emails every morning - small repeatable chunks
!! Results
* 200 issues were closed during the initial run-through (out of 800)
* After two weeks of no comments, the rails team decided that meant the issue was stale. - Close
** Closing is not permanent. If someone really cares they can reopen. Guilty until proven innocent.
* 150 more issues closed this way after 2 months.
!! Side affects
* After 2 months of this, knew enough about Rails to know about every open bug and enough to submit patches or at the least leave dead-simple reproduction instructions for someone else to pick up.
"The only thing better than reproduction instructions are when those instructions say git clone."
* After stopping the constant tending the issues blew up again.
@mattbarcomb
Catherine Swetel
!!! Experiment Outline
We believe that by doing [action / countermeasure]
For
Will achieve [measurable outcome]
And when it succeeds/fails we will [recovery strategy]
We should try ____ because _____
What process / condition are we trying to change?
How often does the condition occur?
Who will be affected?
!!! Measurable Outcome
* Must be falsifiable
!!! Experiments: Create and Destroy
(create meaningful experiments, destroy the ones that aren't)
* (I tuned out)
* Consider the impossible
* Small
* Impactful
* Keep it succinct -> Look for a short summary we can share
!!! Pitfalls of Experiment Design
* We want to reward experiments that validate hypotheses
* Information Value
!! How to choose experiments
!!! Theory of Constraints
* Prefer non-local optimization
* Mechanic systems are linear (people are systems are messy webs)
* Seeing local suboptimization in a mechansitc system is easy, it's very visible
!!! Social Systems
* Wildly entangled
* Multiple simultaneous goals
* Need to collaboratively make visual
!!! Measurement
* It might be ok to be fuzzy. Quantifiable, but maybe hard to measure.
* Prove better happened
* Measure connected things -> are these changes a result of the experiment?
* Use local optimizations to sense - create gravity wells. If the team suddenly gets blocked, that creates tension and shows the problem is somewhere else.
!!! Optimizing For Change
* Alignment over opportunism
* Simplify - Amplify - Modify - Try
* Set enabling constraints
!!! Find Change Partners
* Innovators, Early Adopters, Early Majority, Late Majority, Laggards
!!! Interest over Impact
Ideally you'd do things that are both, never do things that are neither
!! Pitfalls of Experiment Selection
!!! Misalignment
!!! Bad Planning
- Great experiment, don't have the things we need
!!! Risk analysis
- Is the experiment taking someone else's stuff
- How long until we feel the failure
Creates images for multiple providers (VM softwares) from a single template.
Think of it as a speedier way to do the initial vagrant install (provider + provisioning)
packer.io
Will Dages - https://github.com/willdages
''Parse''
1M pulls and 1M pushes a month for free
Easy to use, lots of options for integrating with other service
Create an app on parse.com, quick start, pick your platform
Parse will autogenerate help text to the SDK and API keys(if using web)
{{{
function saveQuote() {
var Quote = Parse.Object.extend("Quote")
var quote = new Quote();
quote.set("key", value);
...
quote.save(null, {
success: function(quote) {
console.log("saved")
getQuotes();
closeModal();
},
error: function(quote, error) {
console.log(error.message);
}
}
}
function getQuotes() {
var Quote = Parse.Object.extend("Quote")
var query = new Parse.Query(Quote);
query.limit(25);
query.descending("createdAt");
query.find({
success: function(results) {
$ ("#quotelist").html("");
var template = Handlebars.compiles...
$(results).each(function(i, e) {
var q = e.toJSON();
$("quoteList").append(template(q));
})
}
error: function(error) {
console.log(error.message);
}
}
}
}}}
Parse can allow some code to run on their server "CloudCode" - parsing, validation
Do something - creates a "project" on your local file system
- Looks like JS
{{{
Parse.Cloud.beforeSave("Quote", function(request, response) {
response.error() //-- sends error callback
request.object.set("by", "Anonymous")
response.success()
}
}}}
Another command sends the project back to the server. No need to reload clients, just run the app.
!!!Problem
Provide service to track inbound helicopters to a hospital
!!!Constraints
Needed a cloud based solution (no servers, no IT staff) - cheap hosting for hospital budget
200 records, 20000 read-writes
!!!Solution
heroku, ruby, sinatra, couchdb, redis
Used resque to mock out dispatcher calls
dispatcher -> resque -> couchdb -> hospital
most of the work is just plain ol development, small slices for mobility and cloud
Hospital polls
Hospital has push capability just to request a helicopter
!!! Issues
Heroku assigns blocks, but you cannot request more when load increases.
Creates lots of queues to take that fixed block allotment and assign resources horizontally.
All these queues causes a request to split into multiple transactions (parallelism, right?)
!!! Patterns
* Dynamic scaling
* Colocation - colocating data and processing to cut response times
Async processing is king because data is orthogonal and easy to correlate
* Loose error handling - if it's wrong, don't worry about it
*Receipt pattern Return a receipt for an async call. Caller can then use that receipt to make another call to check on the real-time status of that operation (like a UPS tracking number/ coat check)
* web api
* pub/sub - uses redis - an in memory database
** redis is a cache that supports 5 data structures (strings, hashes, lists, sets, sorted sets) with the BigO performance you'd expect for each type
** It has support for pub/sub among many other things. Supports partitioning, replication, etc.
* async sinatra
** Sinatra::Async allows a request to complete async, sending the response to GET/POST etc later. Use aget in the sinatra configuration.
server-side caching is good?
!!! Security
- key based system with known pad challenge
- All data goes away after flight ends
- HTTPS
!!! Postmortem
AWS is your weak spot - all systems seem to run on AWS
Cloud developers don't need to know a lot of "cloud" stuff, it's more important to know all the systems and how to put them together (systems engineering)
Use simulators
* Use named roles instead on "I" in scenario
* Describe they system instead of what the user should do "I should see"
* Avoid ambiguity
Given I login as Mary
When I have a lamb
And I go to school
Then a lamb should go to school
Given ''Mary'' had a little lamb
When ''Mary'' goes to school
Then ''her'' lamb ''goes'' to school
* What do you like about this evil thing?
Let them answer. Allow for some silence. Let them answer further. Let them notice that they actually like this evil thing more than they think. Now, once they鶥 got that out, ask them:
*What other things can we do to get all these benefits?
* Pinch hitter
** Verify posts
* Clojure
** re-build hot or not
** Something with hobbitses
* Scala
** Rewrite play tutorial test-driven
* Python
** Leandog dashboard
* Stack overflow
** Mind map
* Finances
** Next steps
* Gametel
** Add List View accessor
* Blog
Re-read TDD and live blog it
http://www.jrothman.com/blog/mpd/2013/08/trust-agile-program-management-being-effective.html
http://xprogramming.com/articles/artifacts-are-not-the-problem/
Requests for estimates with a high-level of precision (hours/days) are a sign that management does not trust you.
Build trust by delivering frequently, demoing frequently - basically giving the impression that you get shit done.
Teams need to finish features. Maybe not at a predictable velocity, but they get to done.
숯w much will this project cost? When will this project be done?� Even with all our expertise, we're giving you a guess. Are we negotiating a contract or trying to make decisions here?
Better question: Is this project worth doing? Given an order of magnitude estimate, would you want this project done?
"If we spend time on this program, will we get something valuable that is releaseable to customers before we鶥 spent all our money?튊If we're not sure, suggest using the time (that order of magnitude) that the estimate could be off by to build a walking skeleton. Now that it took us this long to get this far, do you still want this?
Embrace change! If we can release something in x weeks, then you can decide if you want to spend another x weeks working on it. Or if that release teaches us something we can radically change our direction.
Run to a milestone. Once we hit this place, what does the situation look like?
If I discover the program is not on track, when would you like to know? As soon as I know; after I鶥 done some remediation work; when I鶥 done everything I can and it鳠a disaster?
Software is about delivering value. Getting value sooner is better. Large things are a waste of time, the value is always hidden inside there. Do the small stuff. Do the most valuable stuff first. Everything that is valuable today may not be tomorrow. These valuable things have to work. They have to continue to work.
webinar
Bill Horan - Bressler Group
Get pics from phone
Mike Ward
@mikeward_aa
https://github.com/mike-ward/talk-riotjs
* Has a virtual DOM like React
* One way data flow
* Does server-side rendering
* Use what you want, plays well with others
* Only has 12 APIs
* 20K
!! Plumbing
* Source the "tags"/components
* Mount the app
In React you start with JS and put HTML in
In Riot you start with HTML and put JS in
!! Style
* You can put your style in the component
* markup, style, js all in one place
* supports sass, less
Len Smith
https://twitter.com/ignu
Slides:
https://github.com/ignu/react-everywhere-workshop
https://github.com/ignu/codemash-react-workshop
https://babeljs.io es6 to es5 viewer
https://lebab.io/try-it
surge - static site on the web: https://www.npmjs.com/package/surge
npm run build && npm install surge && surge
ramda
Can share store between react-web and react-native
In practice the views are quite different so you need two codebases
Skip to the end:
https://github.com/ignu/react-everywhere-web-demo
https://github.com/ignu/react-everywhere-native-demo
Kevin Swiber @kevinswiber
http://www.slideshare.net/kswiber/reactive-hypermedia-apis
Works on Zetta
Zetta hubs connect to devices and local clients. The zetta hubs have APIs. Another zetta hub/serer can exist somewhere in a data center and proxy calls between the internet and the other hubs.
!!! Desired Architectural Problems
* Decouple implementations (devices in differnet locations/zones should be able to evolve indepentdently)
* Independent evolution
* Scale
* Load balancing
* Centralize complexity, distribute simplicity (taken from xmpp)
* Reduce latency
* Support event streams
= '' Good fit for REST ''
!!! Hypermedia spec
* http://sirenspec.org
!!! How HTTP streams are done
* Webhooks
** Requires registration
** params can get stale
* Chunked Transfer-Encoding
** Not well supported
* HTTP Pipeling
** Not really used by anyone (keeps socket open - kinda slow)
* Long Polling
** kinda slow, awkward
* Server Sent Events
** Not supported by IE
!!! Other protocols
websocket
mqtt
amqp (rabbit mq uses this)
wamp
stomp
rss
!!! How it works
* Model responses (future request) based on current state
* Model resources as finite state machine
* Zetta built on nodejs
!!! Reactive clients
Load a url, parse the response, subscribe to a resource.
!!! Producer-Consumer problem
** Consumer can't keep up with producer
*** App crash
*** network throttling
*** server resources
!!! Reactive Stream Control Protocol
*** Consumer controlled streams
*** Runs over websockets
*** Multiplex streams
*** uri scheme definition
@vmbrasseur
https://archive.org/details/confoo2017-remote
https://www.zotero.org/groups/remote__distributed_teams/items
"The people that have to be micromanaged need that attention whether they're in the office or not." @vmbrasseur
Incredibly rich cultures are possible without colocation. Look at any online community.
Blah - document more so remote can keep up. Ain't doc'd ain't done.
If there are people who cannot work remote because of their position. You could potentially make it less about the job and more about the tasks they have to do. If there are certain tasks that must be done "in office" then make that clear, but can you say that other tasks could be done from home.
Zander on setting up a VPS: http://www.civet.ws/2013/06/dont-fear-pair-programming-a-guide-to-starting/
Stuff from Zee:
Stuff from Levi:
Tmux woes on OSX: http://www.economyofeffort.com/2013/07/29/reattach-to-user-namespace-the-fix-for-your-tmux-in-os-x-woes/?utm_source=buffer&utm_campaign=Buffer&utm_content=buffer6208e&utm_medium=twitter
SSH+Tmux pairing on a mac: http://jjasonclark.com/Remote-Pairing-with-SSH-and-Tmux-on-a-Mac
Madeye.io - google hangout: http://t.co/wunrtbmeoC
Equipment: https://speakerdeck.com/rietta/why-and-how-we-remote-pair-program
Zander is using https://www.sococo.com/ for a virtual office where everyone has an office and you can move your avatar to go talk to people. Pretty awesome idea.
https://zapier.com/blog/how-manage-remote-team/
*Team
** Doers
** Trustworthy + Trusted
** Can write (much remote communication is asnyc)
** Can handle less social workplace (fewer opps for chit chat and bonding)
*Tools
** Group chat (campfire, hipchat, etc)
** Video chat (skype, hangout, sqwiggle)
** Email, IM
** Trello (light weight work tracking tool)
** DVCS (github)
** iDoneThis or other standup type tool
** LastPass (no need to ask for credentials)
** Collab writing tools (Draft, Google Docs)
** Hello Sign (for signing docs)
* Process
** Explicit shared values and vision (all hands on deck for support, high quality, etc) - 'How Things Work'
** Weekly hangouts
** Weekly Learning
** Monthly One on Ones
** Daily feedback - don't leave people on an island
** Regular in-person team building (culture)
** Automate everything
** Random checkins (try to stay connected with what other teams are working on/good at)
* Tightly scoped
* Explicit Dependencies
* Minifies, Optimizes
Rider is rational mind
Elephant is emotional mind
Put both in a room - who's going to win?
Provide a path to adopting something new - don't just say it's cool - provide a compelling argument of why and HOW to move from x to y (business case).
https://michaelfeathers.silvrback.com/ripeness-for-refactoring
Sometimes we shouldn't dive in and refactor.
* What if you can identify lots of potential ways to fix it?
* What if none of them is compelling?
* What if you can't think of a name for an extracted responsibility?
This is sorta similar to Beck's DRY rule. If you copy it once, cringe a little but do it. If you copy it twice, start looking really hard to eliminate. If you do it a third time, it's worth a lot of effort to DRY it up.
Scala scales - It's performant, supports actors and parallelization. Has interesting pattern matching feature.
Ruby has more gems, stronger community
Scala can be snuck into a java shop (Eckel)
Both have cleanish syntax, lambdas, implicit types (duck typing), dynamic calls, mixins, testing support
Articles:
http://www.infoq.com/news/2012/11/twitter-ruby-to-java
http://www.slideshare.net/El_Picador/scala-vs-ruby
http://stackoverflow.com/questions/2351433/questions-about-scala-from-a-rubyist
# All the tests pass.
# There is no duplication
# The code expresses the intent of the programmer.
# Classes, and methods are minimized.
Uncle Bob: http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html
We can change Ron's rules for Simple Design, into rules for Simple Tests:
# The test expresses the intent of the programmer
# The test passes.
# The test has no duplication.
# The test has a minimum of classes and methods.
In the TDD cycle, this means that we first write a portion of a test; and before we make it pass, we clean it up to ensure that it says what we mean it to say. We get that tiny portion of the test to express our intent; and then we make it pass.
The red-green-refactor cycle becomes Red -> Clean Test -> Green -> Refactor.
Klabnik
cargo is both a package manager and a build system
crate is a module, binary or library. They are compiled in parallel, though each crate is compiled serially. So a common pattern is to break a binary into libraries to get a faster compile.
semicolon on each line unless it's the return value for a function (expression-based langauge)
Borrowing vs taking the value (pass by reference).
CHEAT SHEETS: https://gist.github.com/carols10cents/1f2066f758be72ecf2ab
@daveshah
TODO: http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/
Controllers deal with the real world - they do the "unclean" stuff. State, side effects, etc.
SRP: Easiest to talk about, one of the hardest to get right.
OCP: How do you extend in Elixir?
{{{ defprotocol }}}
* this is like an abstract "method" that needs to be implemented by implementations.
{{{ defoverridable }}}
* this allows you to do override an existing implementation when you {{{use}}} a module.
ISP: Making a commitment to decrease the volatility of a particular area. These are the things you can depend on.
LSP: If you say you're going to do something, you should do it.
DIP - Caller owns the protocol that the dependency implements. Ripples only go in one direction - down to the details.
* TDD - Caller wins!
Human beings think in abstractions - not details. Named abstractions allow us to group details into larger concepts. This allows us to keep building higher and higher abstractions that can solve bigger problems.
Connect to remote machine and tunnel their http access over port 8080 on localhost
!! Cmd line
ssh -v -L 8080:localhost:80 -p 2298 <username>@<remote_ip>
!! .ssh/config
host remotemachine
Hostname <remote_ip>
Port 2298
ForwardAgent no
ForwardX11 no
User <username>
LocalForward 8080 127.0.0.1:80
http://www.threeriversinstitute.org/HitEmHighHitEmLow.html
"works by taking a failing test and progressively inlining parts of it until you can't inline further without losing sight of the defect." \
1. Inline a non-working method in the test.
1. Place a (failing) assertion earlier in the test than the existing assertions.
1. Prune away parts of the test that are no longer relevant.
1. Repeat.
OR:
1. Literally replace the method call with the source code IN the test.
1. Move the assertion into the source code section.
1. If that fails, you can delete all the code after that.
1. Move your assertion up another level and keep trying, inling additional methods as you go.
Bruce Eckel
http://www.atomicscala.com/
- Objects are a good way to structure code
- Scala brings in functions as first class as well(OO + functional)
- Raises the functional level of abstraction on procedural code
- Since scala compiles to .class files, it can be trojan horsed into a company
- Typesafe: Maintain scala, akka, play
{{{
class Dog(age:Int, val name:String) {
def indent(id:String) = name + age + id + Dog.dogCounter
//Note that anything passed into the constructor is automatically a member and accessible throughout the class
}
object Dog { // Companion object
private var docCounter
def +(n:Int) = dogCounter += n
}
//Companion objects are utilities (like static methods on a class)
object BasicClasses extends App {
val dog = new Dog(4, "Comet")
Dog + 1 //Dog.+(1)
}
}}}
case class => Used to do DTO/structs
{{{
case class Person(first:String last:String)
}}}
public members, hashcode, equals, toString do what you'd expect
* //This talk seems to be mostly about how scala reduces java noise//
** //The result is very similar to ruby//
{{{
s.foreach(x => x.draw) //closure
s.foreach(_.draw) // perl like
}}}
passing blocks
parallel collections
futures
{{{
val a = future { pause("three", 3) }
val b = future { pause("one", 1) }
val c = future { pause("two", 2) }
val result = for {
three <- a
one <- b
two <- c
} yield one + two + three
}}}
Must have scala-library.jar on the classpath when calling scala from java
{{{
(1 to 10).groupBy(_ % 3)
= Map (2 -> Vector(2, 5, 8),
1 -> Vector(1, 4, 7, 10),
0 -> Vector(3, 6, 9)
}}}
atomicscala.com for examples from talk
Scala streams can be passed to other functions to add one more to the stream without recomputing all those that came before. Calculating sensor offsets seems like a plausible use case. Another is breaking a search after finding the result, while in the iterator. So you don't need an interim data structure.
http://stackoverflow.com/questions/2096876/use-cases-for-streams-in-scala
http://www.scala-lang.org/api/current/index.html#scala.collection.immutable.Stream
http://blog.danielwellman.com/2008/03/streams-in-scal.html
Clinton N. Dreisbach
github.com/cndreisbach
Mind Blown. @cndreisbach enthusiasm for clojure is contagious.
https://github.com/cndreisbach/clojure-web-dev-workshop/
http://clojurewebdev.com/
!! Tools
Ring is Rack for clojure
Middleware is manipulating requests (auth, mime-type, routing, etc)
Routing - Compojure
Templating - Hiccup or Selmer
Asset pipeline - Stefon
-Luminus wraps up these libraries as Leiningen tasks. Get started here
!! Hoplon
* HTML as clojurescript
* Compiles to static files, drop in anywhere
!! Liberator
* Provides resources
* Resources are decision trees
* Every result in liberator is added to ctx (fold back it into the context, call the next one in-line)
* Override the decisions (allowed? authorized? exists?) to inject handlers in the code for that kind of request (200, 404, etc)
* Provides default responses in the representation that the mime-type is asking for - want json? want csv?, want html?, want xml? \\This sounds awesome for testing\\
!! HTTP Kit
* Supports web sockets and long polling
* Supports streaming
* SO fast!
!! Resources
* clojure-doc.org
* http://clojurewebdev.com
@bahmutov - Gleb Bahmutov PhD
slides.com/bahmutov
Red flags
* Build time > 15s
* Can't umit test a feature
Software as car assembly:
1. built separately, tested separately, has sku number, shipped to car factory, assembled
12 factor
Single report per app
Relying on human supplied semver is like relying on code comments. - @bahmutov
Relying on human supplied semver is like relying on code comments. @bahmutov - I'll continue trashing semver tomorrow morning at 10 :laughing: #confoo
Automate dependency upgrade
* run unit tests
* update dependencies
* run tests
* if tests fail, revert
https://github.com/bahmutov/next-update
(manual version of greenkeeper)
next-update-stats
semantic-release-cli
dont-break
Brad Colbow
bradcolbow.com/codemash.pdf
!! The asthetic
CRAP
!!! Contrast
' I will never make it as a designer because my brain does not work like the common'
What's important, 2nd important
What goes together (subtler)
!!! Repetition
Sets up patterns, used for "scene" changes
!!! Alignment
Grids can keep a page together when one element might break the normal borders and contrast
!!! Proximity
These things grouped together
!!! Hierarchy
Create levels to the design - important stuff at the top
!!! Intent
"Design is the rendering of intent" - Jared Spool
Comics often create a confusing panel order - what's the intended way to read this
Hamburger is not an obvious menu button
Leave the user a scent (like a bloodhound) - how do I get back where I was?
When everything is exciting, nothing is exciting
Simple Rule: Do the expected in an unexpected way
!!! Interaction
* Wireframes - capture features but don't capture interactions
Found the first few days of the project were the most important
@christainheimes
Secrets: small, required, radioactive
Best practices:
Encrypted at rest
Encrypted in transit
Audit log
Access Control (single container should not have access to all the secrets)
Identiy - container must be known and addressable so you can assign roles to it
Rollover/Renewal
Least Amount of Privieges
(Don't use orchestration to send secrets)
!!! Don't
Use ENV variables to pass secrets (some config will have a plaintext version)
** Kubernets secrets
*** wouldn't use it, no encryption or access control lists
** Square KeyWhiz
*** Focused on PKI and LDAP
Secrets and LIE-abilities - blog post.
!!! Common design problem
* either ENV or file system (even TMPFS)
* Vulnerable
** Accidental backup
** Directory traversal attack
** Debug tools
** Other means
!!! Don't put secrets in the container - Let the application request a secret
! NOW WHAT?
Use unix sockets as auth mechanism - //I guess//
* Find a mentor:
Looking for an idol: Realizes code is writing, good at empathy, codes 90% of the time while still being an influential and useful person, realizes coding is usually the least important thing, but has managed to get everything else right so that coding is joy. Understands that being part of a team is teaching and knows how to present information in such a way that it's understood and need not be repeated.
* javascript koans
* xmpfilter
** http://jamie.ideasasylum.com/2013/07/ruby-markers-for-sublime-text/
** http://justincampbell.me/til/annotate-ruby-code-in-vim-with-xmpfilter
* emacs
* Docker as a New Guy bootstrap tool (redo vagrant project)
* pinch_hitter
** Re-investigate issue, try to think of a way to accomodate or build in another gem?
* pretty face history
** Jenkins like history of scenario counts and passing
** Incorporate timings?
* Data Personas
** Stewing
* Take notes
** http://cwd.dhemery.com/2005/05/motivation/
** http://vimeo.com/68375232 - 10 mins in, looks good
** http://arlobelshee.com/post/being-awesome-step-1-stop-making-dumb-choices
** http://www.cio.com/article/739333/How_to_Move_Beyond_Project_Estimates_and_Provide_Better_Value
**
* Blog
** Script + slides from cukeup
** Coding analogy - Eggs, steel blocks / rocket precision machinery, legos, new
* exercism and work on some issues
** Sign in
** Next exercise
** Review 3 exercises
** Look for issue
*** https://github.com/kytrinyx/exercism.io/issues/478
Simon Sinek
* Why? //you get out of bed//
* How? //you work (values) //
* What? //you produce//
Seceding vs Replacement
http://lizkeogh.com/2011/03/04/step-away-from-the-tools/
<<<
Start by having conversations, engaging both testers and business stakeholders or their proxies (analysts are good here). If you can鴠have those conversations, stop. You can鴠do BDD. You might be able to write some scenarios or some acceptance tests, but they鲥 likely to be brittle and it鳠unlikely that anyone will be interested. Here鳠why.
<<<
* Focus on Discovery - Deliberate Discovery
* Realize this isn't about testing or tools
* Write fewer scenarios
* Assume you got it wrong
** You never get it right the first time
http://vimeo.com/68375232
!!! Two problems to unlearn in TDD
1) Changing Impl details breaks tests. Lots of tests.
2) More test code than impl code
!!!! ProgrammerAnarchy - Devs work directly with customers and throw the code away after a year.
!!! Where did it all go wrong?
* Not testing behaviors - Dan North
* Coupling impl details to test because of failure to refactor
!!! When do I write my next test?
* NOT when you add a method
* When you add behavior
!!! Test the Surface Area
* Only test the surface area (public API to the module). Treat it like a box.
* Start with the "Best possible application public interface" Program by wishful thinking
!!! Kent Beck's definition of unit test: A test that runs in isolation from other tests
* This is different than the rest of the industry - OOPS
* NOT testing a module in isolation
* NOT only one class under test
* YES - no side effects
* Test is isolated, not the system under test
* NOT - mocks everywhere specifying too much impl detail
** Only mock things that keep the test from being isolated, not things that keep the "class under test" isolated.
!!! Red -> Green -> Refactor
* Quick green excuses all sins -> BE SINFUL
** It's difficult to think about both solving the problem and engineering it well
** Don't do engineering yet - you don't know if you're going to SOLVE anything yet
* Refactor -> Now you can be clean
** Refactor to patterns
** Don't write new unit tests!
** You need a new class - Do it! Don't write tests for it.
!!! Ports and Adapters
* Unit test at the port - Tests are an adapter running the code
* System Tests are at the boundary
!!! Gears
* 5th gear is obvious changes - we can't get to green because this obvious refactoring is distracting us. Just do it - but don't get carried away here.
* 4th gear - hack your way to green
* Downshifting - Getting sticky here, not sure how to find my way through.
** If I throw away these tests will I miss them - do I still have tests that check the behavior from a port-type level.
** These tests are coupled to the implementation
** Maybe I should leave them to help another programmer find his way through
** Middle ground - maybe comment that these tests are deletable if they get in your way - Feel free to delete these tests.
!!! Mocks
* Don't mock internals, privates or adapters
http://blog.jessitron.com/2014/09/tdd-is-dead-long-live-tdd.html
"Tests don't enable change. Tests prevent change!"
Mostly we want tests at an interface level (API or UI) but that makes for UGLY tests.
!! Generative Tests
(Or property-based testing)
In generative testing we can't know what the inputs are so we can't specify what the outputs are. But we can put bounds around them.
<<<
Maybe, it should be between these values. It should go down as this input value goes up. It should never return more items than requested, that kind of thing.
<<<
!!! What should we end up with?
<<<
This doesn't preclude small tests that drive our class design. Use them, and then delete them. This doesn't preclude example tests for documentation. Example-based, expected == actual tests, are stories, and people think in stories. Give them what they want, and give the computer what it wants: lots of juicy tests in one.
<<<
Points out this is way harder and requires thinking about boundaries that we usually don't worry about.
//I wonder if this would encourage a more failure-resilient thought process?//
Unity - runner
CMock - mock headers
Ceedling - rake tasks to automate - can do things like sub in test headers and what not
Is CMock the tool that lets you auto-magically mock out 21 headers
- it's used for expectations
- Creates a mock version when you add a mock_
- Links in the mock c impl instead of the "standard".c
http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt
* Set aside time for TD - pay down before adding features
The failure to make the program align to the current understood operation of the system - me paraphrasing Ward
* Each disagreement with reality is interest
* Bankruptcy is when you don't trust the code.
http://www.industriallogic.com/blog/techsafety/
Safety is a keystone habit - this habit grows a culture of excellence. Keystone habits shift, dislodge and remake other habits. Like exercising leads to eating healthy, leads to avoiding drugs, leads to work/life balance.
Tech safety is a pathway to excellence - not an end in itself.
Tim Ottinger, a veteran coach at Industrial Logic, said, "It's in the constant, daily decisions that tech safety has meaning. We don't settle for learning to cope with failures, flaws, injuries, irritants, etc. Instead of accepting a poor work system and an unsafe environment, we transform our environment in ways large and small to make it less prone to failures and injuries."
Tying TechSafety to AntiFragile: http://www.industriallogic.com/blog/why-are-most-agile-adoptions-failing/
Failure is inherently unsafe and most teams and organizations are not places where we can safely learn from failure.
* My hypothesis is that embracing failure (vs XPs embracing change) is the way that we can build high quality software fast. If each failure/injury makes us stronger - is that an antifragile system?
http://samadisy.com/2013/06/05/is-it-safe-to-fail/
Let me explain further. Failure 㠦or most of us 㠩s not an enjoyable experience. However some of us have become good at it. And the major reason behind this is SAFETY. If we feel safe to fail, and are rewarded for it regularly, we can find ways to fail fast and learn quickly.
http://arlobelshee.com/post/being-awesome-step-1-stop-making-dumb-choices
* Making change feel safe = Help people see that others have succeeded + Everyone wants to make the same change + The change is at least as safe as the current approach
* Second-order safety: We need to see the people that have threatened us for trying to make things better in the past and see that they agree with this change. You're not on an island, you're going with the group. Change is the obvious, safe choice.
Ben Rogers
@_ben_rogers
Connectivity is the thing. Users expect an immediate remote upgrade that will fix the thing or they will return it.
!! Test Rig Basics
* Need loader to load code into a device automatically from ci (can't change a flash card)
* Need to mock IO
* Debug interface is nice
!! Start coding (before picking a processor)
* Uses pi to do prototyping- Pi bootloader https://github.com/dwelch67/raspberrypi
* 1 pi for loader/compiler, 1 pi as SUT
!! Processor chosen, order a devkit
* loader (JTAG)
* SUT (devkit)
* logic analyzer on I/O
* UART for debug
!! During hardware design
* Need to ask for JTAG, UART, pins for logic analyzer
!! We've got hardware
* loader (JTAG)
* SUT (prototype)
* logic analyzer
* UART for debug
!! Better tests
* loader (JTAG)
* SUT (prototype)
* I/O mock (pi)
* logic analyzer for debug
!! Hardware characterization test
* Need tests to replace the datasheet (who's going to remember 1400 pages of low-level detail?)
* Need tests to avoid flaws in the hardware
* Do you want to brick a device because the processor has faultly logic around an instruction?
* Exploration
* Analysis - Did pin analysis to see that a chip was failing to respond within the 100ns (according to spec) - this meant that the recommended clock speed was wrong and needed to be reduced
* Codification
** Make sure you write your tests can be included in your manufaturer's test suite and make sure the devices coming off the line are correct
!! Hardware in the loop (HIL) Test
Acceptance level tests demonstrating the correct integrated system
Uses robot framework to build tests (gherkin-like)
HIL is used ATDD, CI, Manufacturing
!! Unit Tests
* Google Test / Google Mock (C++ only)
* cmocka - simple lightweight C testing
!!! Mocking memory
1. Substitute headers with new #define
1. extern variables that get omcked by the test
1. linker scripts that create global variables
!!! Gotchas
* Be wary of state bleed - RESET YOUR STATE
* Test all your boundaries - write tests until your paranoia turns into boredom
saleae - logic analyzer
!!! Network mocks
@Fitzoh
https://github.com/Fitzoh/testing-at-the-boundaries
https://docs.pact.io/
Had problems testing service to service interactions
!!! Microservices: Lessons Learned
:) Faster deployments
:( Automation is required
:) Easier to handle (mental model)
:( Tracing requests
:) code ownership
:( code duplication
:) Speed up tests
:( Decrease test safety, now need end-to-end tests
!!! Testing Service to Service Interactions
1) Standup the whole world
* Ugh, slow, brittle, black box
2) Mock out dependencies
* You're testing against the version of the API that existed when you wrote the mock
3) Contract Tests
!!! Pact Demo
!!!! Consumer-side
Consumer writes the test
Pact Runs the test, mocking out the provider
It also creates a pact file. This is the "published" interface the provider should implement.
!!!! Provider-side
The Provider can then pull the pact file (all the pact files for all the Consumer's presumably)
It will create tests for the pact file, run them against the server and verify the assertions defined in the first step.
This probably won't work out of the box because there needs to be setup, but pact provides helper methods or whatever to allow you to put data in the value.
"TDD at the architectural level - crossing services and doing TDD which is cool"
!!!! Making server-side changes:
Introduce new change, keeping backwards compatibility
Run provider tests, should pass (old consumer still works)
Update consumer to new change
Run consumer tests, creates new pact file
Go to provider, delete backwards feature
Run tests - if all consumers have been updated, they will pass, if not you'll know.
''Postel's Law''
!!! Pact features
* Recommended by TW
* Multiple languages
* Can be used with MQ interfaces (service A will put this message, service B will pull it)
https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c#.3xhbs7f3g
Hypothesis: If the 1:1 is not awkward, you're not talking about the real stuff.
>"Change and growth are always awkward - embrace that."
!!! Two Rules:
1) Don't talk about any topic you could discuss in the open - If it's safe to be overheard, it's not the right content for a 1:1
2) Commit to saying one rather awkward thing every 1:1 and get the other person to commit too. Gives permission and creates peer pressure to be real.
!!! Other Tips:
* Get started by commiting. That's an awkward conversation and counts for the awkward thing in the first 1:1
* Fix any other communication channels. If 1:1s are the only channel, they're going to be spent on updates, easy questions, and simple feedback.
* Plan to be awkward. What would be great to get off your chest?
!!! Awkward stuff
* Meta topics
* Feelings
* Fears
* Trust checks - How would it be easier to share intimate things?
* Extra Honest Feedback
* Are they acting like the best manager/report/partner?
* What have you said or heard said about this person?
* What is everyone neglecting to tell this person?
* Advice Seeking (with humility instead of bragging)
* Growth area advice
* Here's something I complained about, what could I have done differently?
* How can I be better?
* Admit faults and mistakes
http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
This is one of those articles I'm glad I went back and read a bit more carefully. I glazed over the section headers and said, yup, yup, yup, but kept it around for some reason. It's got some nuance in the "stuck" sections and in the idea of consciously drawing boundaries for our system.
Basic outline - TDD as a series of cycles
- Three Laws of TDD (several times a minute)
- Red, Green, Refactor (every minute)
- Specific/Generic (every 10 minutes)
- Boundaries (hourly)
* The Three Laws of TDD are designed to get you the write (and think) about one line of code at a time.
* Specific/Generic - tests get more specific, code gets more generic
** Uncle Bob believes that if you don't generalize your code (because the tests don't make you), then you'll end up getting stuck in your TDD cycle. You'll have to write a ton of code to get the next test to pass.
* Every hour, stop and look for boundaries we want to control. We draw the lines and then stick our work for the next cycle in that area.
Michael Feathers
https://vimeo.com/15007792
Andy Hunt - http://blog.toolshed.com/2015/05/the-failure-of-agile.html
!! Concrete Rut
* Inspect and Adapt are too abstract for new agile teams to follow
* New agile teams take the practices and follow the rules (or worse a subset of practices and rules)
* Following the rules limits you to a novice (Dreifuss) - following the rules means you can't get the experience to break the rules
''We are stuck in a rut because the practices have not changed in over a decade''
!!GRowing Real-World Oriented Working Systems (GROWS)
* Growth means change
* Real-World means we need to base decisions on evidence
* Working software - of course
//But not at the expense of a working, functional team and overall organization//
* Evidence-based
* Dreyfus Skill Model
* Local Adaptation
* All-Inclusive
growsmethod.com
Anthony - founder of dnsimple
@aeden
!! Path based version
* not mime-type based, but could go that way in the future
* Simple transition through minimal changes - picked path-based versioning
* versioned URL is easily visible in the logs
* Easiest implementation for both production and consumption
* Easy to check in a browser
!! New hostname
* Distinguish api calls
* easier to scale
* common error handing
* extract to custom controllers
v0 -> v1 - one month, mostly
simone went out and opened PRs for all open source projects to enable easy API version change.
!! v1 -> v2
* 3 years
* Used Hanami
* Built as a sub application
** Get all that institutional knowledge from years of development
* No longer tightly coupled to the Rails controllers
!!! Conversions to Commands
* Similar to Command design pattern -> "Reusable business logic" -> Encapsulate behavior
** Convert controls to use commands
!!! Remove resource names from parameters
* (don't need them in REST, you know you're dealing with "Zones" for instance from the path)
* It's dangerous to make the response data the top level keys. Using "data" allows you to support "errors", "pagination", "meta" etc.
* Built custom parser to avoid rails serialization in hanami
!!! Error management
* unified error responses
* Use http response codes
!!! Authentication
* Retained HTTP basic auth
** easiest way to get access
** nice for testing
** might get rid of it later
* Access tokens
** Move to Oauth
!!! Pagination
* Add query strings
* using payload
* could be added to the headers later
!!! Sorting and filtering
!!! Throttling
* Used headers
* Why put that in the header? Users care about pagination, but don't care about rate-limiting
!!! Methods (endpoints)
* Track all the new/changed/removed endpoints
!!! API clients
* Ruby - original: 2010, new: 2016
* Go - 0.15, not yet released
** Nice for design feedback
*** https://slidr.io/weppos
* Node - new: 2016
* Elixir - new: 2016
* Java - unreleased
* PHP - unreleased
@geekygirlsarah
Vulnerability helps us build connections.
Empathetic teams are powerful.
J.B http://blog.thecodewhisperer.com/2013/12/07/putting-an-age-old-battle-to-rest/
!!! Kent Beck's version
# Passes tests
# Minimizes duplication
# Reveals its intent
# Has fewer classes/modules/packages
!!! Corey Haine's version
# Passes tests
# Reveal intent
# Don't repeat yourself
# Fewer classes
J.B thinks the difference between 2 and 3 doesn't matter because they form a rapid feedback loop.
<<<
I have noticed over the years that when I try to focus on removing duplication, new, useful structures emerge. I like to say that if the solution wants to be structured a certain way, then removing duplication helps that structure to emerge.2 I have also noticed that when I try to focus on improving names, Feature Envy and its friends become more apparent, and code makes it clearer that it wants to move somewhere else. Similar concepts scattered throughout the system start calling out to each other, hoping for the programmer to unite them in a single module. Crowded, unrelated concepts struggle to get away from one another. Responsibilities gradually move to a more sensible part of the code base. Both of these contribute to higher cohesion.
<<<
Remove duplication -> Structure Emerges
Improve Names -> Redistribute Responsibility
Creating new structures to handle these responsibilities drive these loops. As we struggle to name this new thing we continually add/remove behavior until it becomes cohesive. Eventually it settles into an abstraction (the rest of the code treats it as a black box).
So you end up with:
Remove duplication -> structures emerge -> structures need names -> improve names -> abstractions emerge -> higher-level-duplication -> remove duplication
Or you can start with improving names and end up in the same place.
I would probably think about this more as starting with an abstraction (make the change easy) vs removing duplication (make the easy change).
https://www.oreilly.com/ideas/the-infinite-hows
Criticism of 5 whys. //Why?// is the wrong question because //why?// usually leads to //who?// Then the focus, even if it is positive, is on how to improve a person, as opposed to improving the system.
"Well what you should have done...."
Human error is a simple and satisfying explanation for everything.
Asking //why?// leads towards looking at failures as linear consequences. The world isn't that simple. Our preference is certainly to reject the complex because it's harder to think about.
Asking //how?// invites looking at the context.
Looking at //why?// often leads to a "this was wrong" sort of answer. But it's only wrong in hindsight. At the time it seemed perfectly reasonable. And we lose sight of that once we decide it's ''BAD''. The only logical way for our brains to move is towards prevention.
When we ask //how?// we're inviting stories/a narrative. When we ask //why?// we're inviting excuses.
//Why?// -> Who is responsible? //How?// -> What is responsible?
''DESCRIBE'' vs ''EXPLAIN''
!!! Why novices?
Functional diversity - different backgrounds bring novel approaches to tough problems
Individuals from similar backgrounds identify problems in a similar way(perspective) and similar ways of solving those (heuristic)
//This is basically an exercise in avoiding groupthink//
How do you find novices?
- avoid internal biases (picking people like you, who are easily available, look nice, etc)
!!! Hungry academy
Very intense training schedule - 24 students, 5 months, 40 hrs/week training, 20-30hrs/week homework
Burned everyone out - idea was to take a person up to the standards where livingsocial would hire them normally
5 months on a salary phasing into normal hire - 24 new hires
!!! Assignments
Choose your own optimization points on an assignment, 8 or 9 axes to grade on with a near impossibility to max out all categories (performance, ux, class design, etc) - helps a new dev figure out what they like/are good at
- Rebuild the same app using a different set of buzzwords (new db, design style, api, etc)
!!! Mentoring
Start with the end in mind - what do you want the newbs to learn? Design an exercise (experiment), gather results and iterate. Multiple assessments, fast loops.
Strive to setup devs to be
- autonomy
- mastery
- purpose
Take extra time to teach the devs to increase their mastery and push them towards autonomy.
Tracking tools (pivotal) allow an individual to see their contribution //lencioni idea of transparency//
Have mentors commit to being consistent
!!! Habits
Habit 0: Each novice should have a technical mentor
Habit 1: Take nothing for granted. Set expectations early.
Habit 2: Design a pairing schedule
Habit 3: All code reviewed via pull requests - make sure to find positive feedback
Habit 4: Set dedicated learning time with self-chosen objectives
* Hard to test = badly designed
* Done is in production - stop screwing with this to make everyone look good in reports.
* Trying to "smooth" the path for developers up front is less efficient than figuring it out as the code is written
** With the caveat that devs hate being jerked around
John Van Enk - @sw17ch
* Low precision - high range
** Like all the temperatures in the universe
* High precision - low range
Pull-down resistor - remove noise in analog circuits - default to 0
Circuits:
Reed switch - detects magnet - 1, no magnet = 0
Photo cell - detects light -
analogRead - something between 2.5v and 4.5v with a 10K ohm resistor
temp sensor - transistor
diagram tool: http://fritzing.org
Daniel Kahneman
!! Two Systems
* System 1 - automatic, intuitive, associative memory, rarely confused
* System 2 - requires effortful attention, makes judgements, lazy, appreciates a coherent story,
!! Econs and Humans
* Econs - rational. Always makes coherent, careful, consistent decisions and uses all the information at hand.
* Humans - makes contradictory decisions based on biases, laziness, etc.
!! Two Selves
* Remembering Self - Keeps the score. Often forgets the duration of events and judges goodness of an experience based on the peaks it remembers. Last part of experience is weighted highest (Bad ending ruins the whole movie)
* Experiencing Self - Does the living.
!! The lazy controller (System 2)
* If an easy answer comes to mind (System 1), System 2 will rarely fact check it. Although someone may be able to solve a difficult problem by engaging System 2, if a simple answer springs to mind and "seems reasonable" they will "go with it".
* "Those who avoid the sin of intellectual sloth could be called 'engaged'. They are more alert, more intellectually active, less willing to be satisfied with superficially attractive answers, more skeptical about their intuitions.
* //Am I less rational (more instinctive) about simple math problems because I've been right so often? What does that say about getting the right answer quickly? //
!! Causes Trump Statistics
* After learning a surprising statistic, the normal behavior is to ignore it when looking at a specific case. For instance you learn that after an accident 90% of observers didn't help an injured person. You later interview one of those observers and they seem very nice and upstanding. Although you know the vast majority of people didn't help, you'll assume that this nice person was the exception, despite having no real reason to do so.
* Personal experience trumps reality.
* This is how stereotypes are formed - you met one smart Swedish person, therefore all Swedes are smart. One Indian person was hard to understand, therefore all Indians are difficult to understand.
!! The Illusion of Understanding
* "The core of the illusion is that we believe that we understand the past, which implies that the future also should be knowable, but in fact we understand the past less than we believe we do."
* The world is unknowable
* We usually don't notice that we were surprised by events because we can create a coherent narrative with hindsight. With hindsight, the 9/11 attacks were preventable, there was the memo in August, etc. It was a FAILURE rather than a SURPRISE. Likewise, we knew football team A would win in hindsight because they were better prepared, had homefield advantage, etc.
!! Outside and Inside View
* Extrapolation (Inside View) vs Base Rate (Outside View)
** This feature will take us 2 more days because we've spent 2 days on it already and we're halfway done
** This feature will take us 4 more days because features usually take 6 days
** Wishful forecasting vs Back of the envelope calculation
* Outside view helps anchor reality before giving optimistic Inside View data
* Outside View is often better at predicting failure
* We will always over-value the Inside View because ''this'' project is different because I'm part of it.
* "It is easier to change directions in a crisis, but this was not a crisis, only some new facts about people we didn't know. The outside view was much easier to ignore than bad news in our own effort. I can best describe our state as a form of lethargy - an unwillingness to think about what had happened."
!! The Engine of Capitalism
* "Optimistic individuals play a disproportionate role in shaping our lives. Their decisions make a difference; they are the inventors, the entrepreneurs, the political and military leaders."
** Influential people are optimistic and overconfident. They take big risks.
* Delusional optimism leads to action. Small businesses drive innovation even though 65% of them fail in the first 5 years.
* "Overconfidence is another manifestation of WYSIATI: when we estimate a quantity, we rely on information that comes to mind and construct a coherent story in which the estimate makes sense. Allowing for information that does not come to mind - perhaps because one never knew it - is impossible"
** //Are estimates without a base rate impossible? //
* '"Generally, it is considred a weakness and a sign of vulnerability for clinicians to appear unsure. Confidence is valued over certainty and there is a prevailing censure against disclosing uncertainty to patients." Experts who acknowledge the full extent of their ignorance may expect to be replaced by more confident competitors, who are better able to gain the trust of clients.'
* Humans prefer pretended knowledge to acknowledgement that these are guesses, especially when the stakes are high.
!!! The premortem (Gary Klein)
* Overconfidence cannot be fixed with training
* Prior to committing to a difficult decision
* "Imagine that we are a year into the future. We implemented the plan as it now exists. The outcome was a disaster. Please take 5-10 minutes to write a brief history of that disaster."
!! Keeping Score
* The remembering self controls future behavior
* We go to great lengths to avoid regret
* Doing the default option (nothing) will produce less regret than doing something, even if both cause the same effect.
* If we prime ourselves for regret, we will likely feel less of it
** This movie will suck sooooo bad
** EMBRACE FAILURE
!! HDD talk
* TDD, ATDD, Learning Tests, Exploratory Testing
* Meetings - start with success and failure criteria - end the meeting when either is hit
* Overvaluing personal experience / intuition over data
* Learning from failure requires being aware of hindsight bias. So be "scientific" and record your assumptions beforehand.
* Recording assumptions before you start usually requires at least a trivial amount of imaging and calculation. You can avoid wishful forecasting by ignoring incomplete data of an in-process task. Give some thought to failure criteria to avoid wasted work.
* Evolution in planning? Optimistic External(Waterfall), Extrapolation (Agile), Base Rate anchored (Lean)
* How can we change directions based on data before we we hit a crisis?
** Thought experiment: Your team is part of an effort to integrate with the next hot consumer good - the iGlass. Things seem to be going well, you're ahead of schedule and everyone is pumped. Then you receive the news - your key competitor that you're racing to market is giving up on the iGlass. They claim it's too flaky to work with in a non-trivial application. What would your team do?
*** Celebrate that victory is now assured
*** Give up. After all that other team included half the engineers from the original iGlass team and you're undoubtedly doomed to failure.
*** Re-prioritize the work to stress test the iGlass before moving forward
** Suppose your team was immediately called into the office of the CEO. How would you advise him to proceed?
* Troubles in being honest about assumptions - most people would prefer to hear pretend knowledge over guesses, especially when the stakes are high.
* The premortem - more research
** Alternative to 6 thinking hats?
** A version of hypothesis-driven development - seek to disprove the hypothesis
* Embrace failure to avoid regret from trying things
!! Quotes
* The acquisition of skills requires a regular environment, an adequate opportunity to practice, and rapid and unequivocal feedback about the correctness of thoughts and actions.
* Our subjects left the choice to their remembering self, preferring to repeat the trial that left the better memory, although it involved more pain...An objective observer making the choice for someone else would undoubtedly choose the short exposure, favoring the sufferer's experiencing self.
http://www.jbrains.ca/permalink/three-steps-to-a-useful-minimal-feature
# Write out any, and I mean any, meaningful end-to-end scenario in detail with concrete values at every step.
# Now that you鶥 chosen one real scenario, go to each step in that scenario and ask the question, 엨at would I need to assume to eliminate this step?�f you find those assumptions make for a reasonable scenario, then use that assumption to simplify the scenario.
# Repeat step 2 until exhausted or unable to come up with a simplifying assumption with five minutes頴hought.
Part of this process is discovering other requirements and external systems. We're exposing risk and complexity when we think we're in a "simple" reduction exercise. Neat!
! Load Testing
https://docs.google.com/document/d/1c2-NsJiUjeLRxqWZHlB40h0FSo_nQp0qCcAyKtaeB28/edit
https://drive.google.com/drive/folders/0ByY-UAEDZpUfRUxFMW9SdGo4VTA
Sometimes a Locust Storm is a Good Thing
http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/
! Open Source
!! Removing nokogiri
http://ruby-doc.org/stdlib-2.2.3/libdoc/rexml/rdoc/REXML/XPath.html
http://stackoverflow.com/questions/571663/ruby-xpath-to-find-attribute
http://stackoverflow.com/questions/7243486/why-do-you-need-require-bundler-setup
https://github.com/stevenjackson/pinch_hitter/blob/9cb0cb5c917b4de5900c49a4a43d00f35d0b53c5/lib/pinch_hitter/message/xml.rb
! Deep Dive & Process
http://storiesonboard.com
https://docs.google.com/presentation/d/1rXqJUi4OJxy2JACC4ZNZnjlUtDV42chOV9J5a_Z1G1M/edit?pli=1#slide=id.p (Balanced Team Recap)
! Apprenticeship
http://apprentice.at/
! Happiness
https://hbr.org/2015/12/the-two-sides-of-employee-engagement
https://www.linkedin.com/pulse/employee-engagement-isnt-getting-better-gallup-shares-mark-c-crowley
https://www.mercuryapp.com/learn_more
http://www.amazon.com/Reinventing-Organizations-Frederic-Laloux/dp/2960133501
https://www.covermymeds.com/main/what-makes-a-company-succeed/+
http://andycleff.com/2015/05/agile-team-health-check-models/
http://www.happymelly.com/in-the-pursuit-of-happiness/
http://management30.us6.list-manage.com/track/click?u=38f755d573baf4cdcb1d04318&id=713e9b2e7f&e=916821420b
! Failure
http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf
! Nerdiness
https://webtorrent.io
http://codurance.com/2015/06/17/inflection-point/
https://github.com/littlebee
abstractions.io
https://github.com/TechConf/CodeMash2016/tree/master/6-Ways-To-Prevent-Code-Abuse
https://github.com/coryhouse/react-slingshot
https://leanpub.com/4rulesofsimpledesign
http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-uno/
https://github.com/kitanata/genetics
https://ifttt.com/recipes/286124-find-my-phone
https://ifttt.com/recipes/303971-find-your-phone-by-setting-an-echo-timer
https://flightjs.github.io/
https://github.com/centricconsulting/alexa-framework-go/
https://github.com/TechConf/CodeMash2016
! WISR
http://django-social-auth.readthedocs.org/en/latest/backends/linkedin.html
https://developer.linkedin.com/docs/oauth2?u=0
https://www.cronofy.com/pricing/
https://developer.linkedin.com/docs/fields/basic-profile?u=0
https://developer.linkedin.com/docs/rest-api?u=0
https://developer.linkedin.com/docs?u=0
https://erikreads.files.wordpress.com/2014/04/thinking-fast-and-slow-book-summary.pdf
http://blog.crisp.se/2014/03/27/henrikkniberg/spotify-engineering-culture-part-1
http://www.industriallogic.com/blog/are-your-development-defenses-dangerous/
http://lifehacker.com/become-a-stronger-leader-by-asking-yourself-these-three-1707550666
https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b#.3ktwknxxu
http://derailleurconsulting.com/blog/the-toaster-heuristic
* Strive towards standardizing the size of work so you can optimize flow and enable predictability
Toaster Heuristic: Imagine a software team as a toaster oven.
* The toaster oven is analogous to a work system - it produces a predictable amount of heat when toasting, the only real variables are time and type of bread.
* Usually unhappy with the results - every experience is completely different and the estimates (spots on the dial) are significantly wrong
* What if I just observed the toast and timed how long it took to do a typical piece of bread?
* Provide the toaster oven a small slice of work to do. Measure the cycle time to where the quality of the end-product is satisfactory.
* Adjust the work to meet this measured result. (Slice the bread thinner, but always keep the oven set the same way).
Moral of the story: Use empirical data to inform the amount of work we slice off, rather than guessing at adjustments. This enables predictabiity and and leads towards a stable work system where the baseline is known.
Jessica Kerr
http://blog.jessitron.com/2016/05/tradeoffs-in-coordination-among-teams.html
Balancing Moving Together vs Moving Forward
!! Moving together
One team of 2-7 people can move fast and get a large interplay of useful ideas.
Two teams will mean more coordination with lots of lines of communication. Each team gets about half as much done as the first team did by itself (but is tackling problems in parallel). Both teams are moving in the same direction.
4 teams, different levels of communication, different levels of coordination. The teams that have more coordination are moving slower, but moving together. A team that is less connected is moving faster, but is off target.
Coordination costs are now burdensome. Moving quickly is hard because you might break everyone's stuff.
!! Moving forward
Create boundaries and decouple everything. Very few coordination pathways, but every team must do more stuff because they can't leverage another team's work without more coordination. Backwards compatibility and degradation must be built in so the teams can work on different release schedules.
Amazon works this way, every team moves forward with a full set of armor. You have no idea what anyone else is doing.
Google is the opposite extreme, monorepo and lots of tooling and shared libraries allow integration. They've built tests, refactoring tools, custom version control and programming languages to support this. Thousands of engineers work on infrastructure.
!! Balance
Consensus is needed at the business level. What are our objectives and direction? Consensus is crippling on the back end. Agreeing on databases, upgrading libraries and coordinating releases slows us down.
We should try to share some tools and expertise. Don't make every team re-invent the wheel. If it makes sense, create shared service teams that are more like the "full armor" amazon teams and let the "full speed" teams leverage them.
!! Conclusions
* Avoid shared libraries unless you have dedicated support for them
* Avoid shared databases (but create DBMS tools that can be shared)
* Encourage shared ideas
* Reach consensus on what we want to achieve and why we are doing it. At a high-level, agree on how it will be done.
sadukie
* UX is before, during, and after. Expectations, beliefs, preferences, emotion.
* Dan Willis - UX umbrella
* Convenience + Design - Cost = UX
* Mind Maps and Site Maps
** Freemind - mind mapping tool - sadukie uses for brainstorming
* Personas
** Crisis persona
* Gherkin
* Wireframes
** Balsalmiq, Pencil
* Focus groups to test
* Heatmaps & analytics
Eric Evans @ericevans0
!! Modeling mistakes
* Looking for the 1 true model
* DDD says 4 models in 4 separate contexts is fine.
** Elephant : Tree, Elephant : Wall, Elephant : Snake, Elephant : Rope
!! Translating between models
Rope context - > Translator -> Snake context
Rope.tiedown -> Translator -> Snake.location
Rope.tiedown -> Translator -> GIS Context.address -> GIS Context.geo_loc -> Snake.location
!! What are models for?
* Identifying risk
* Exploring other models
!! Modeling breakthrough!
Parts of a whole: Elephant : Wall + Tree + Snake + Rope
Now we have 5 models!
!! DDD Whirlpool
# Tell a story
# Flesh it out
# Refocus on hard part
# Refocus on core domain
Describe Scenario -> Define model -> Probe model
Story -> Theory -> Experiment
Get in, swirl around, GET OUT
!! New data
Elephant seems to crush people's feet some of the time
Can we maintain our model with this data?
So Elephant : Tree must hop = New Hypothesis to test.
This is just an iteration of our original model. Still have 5 models.
!! Model breakthrough
Elephant is-a animal and has-a trunk
Animal has-a tail and has-a leg (one to many)
Now we have 6 models!
!! Translation is tricky
In Tree Context: Tree.Trunk -> Translator -> Animal.Leg (Not Elephant.Trunk)
!! DDD in a nutshell
* Bounded context
* Ubiquitous language (UL is context specific! So we have 6 languages)
* Model Exploration
''"We'll never get to perfect, perfect is the enemy of the good"''
!! Where to start?
* Start with scenarios that worry the domain experts the most. They'll want to talk about them and help you model them to mitigate that risk.
* Don't strive for perfect language. Cut off theorizing at some point and experiment. Use the language and see where it falls short.
@toddkaufman
Stakeholders say add more people, PMs suggest working more hours instead, Devs decide to write fewer tests instead.
Does adding resources to a project that is already late speed it up? - Nope. Why not?
# Ramp up
# Communication
# Separation of work
# Integration
# Dysfunction
Dysfunction is amplified when you have bigger teams. Adding people to a dysfunctional software environment makes it even *more* inept.
Nobody in the history of software development has come in at 1/4 of their original estimate!
#noestimates - track cycle time - it's real data!
Quick sizing - just small and large.
#noestimates -> Now the PMs are stakeholders are stressed out. They have no knobs to turn! This gets turned on the developers.
Software quality is how easily and safely we can change a codebase.
Left with only this data $150K estimate, they're going to go with it.
We need estimation to help stakeholders make decisions.
Team Level Cycle Time, BUT Changing Teams means Unpredictable Estimates
Stakeholders don't trust that developers will give a reasonably accurate estimates. Developers don't trust that stakeholders won't beat them with those estimates.
!! How to go faster?
# Remove negativity and waste
# Focus less on stress, more on why
# Be intentional
# Make debt visible
# Pair more
Change the conversation to how predictable we are instead of how fast we are.
Christopher Houdeshell
@choudeshell
Had takeaway as early slide - good idea!
Made productive and efficient
Autonomous
Instill Confidence
Tolerate mistakes
Make Time - 8 hours per week
No grunt work - no maintenance apps
Help define their goals - must be attainable, can't be lofty
!! Takeaways
"I am trying to __ so that I can ___ I'm running into ___ . I've looked at __ and tried ___."
Add interviewing day - day 2 - what do you do here?
http://vimeo.com/89909482
Fizzbuzz
Number | Expected | Actual | Pass/Fail |
<typed> | <typed> | <function> | expected == actual |
Actual ties to a spreadsheet function
! TODO
Record time to start from scratch ''23 minutes'' + 20 mins to install virtualbox, vagrant, and java
Record talk again, find 5 minutes to cut
Put slides on memory stick
-----
Start from scratch (vagrant destroy) ''done''
How many steps to get to testing? ''doc'd''
Test with no wifi ''works fine''
fork play2 - ''done''
- chown vagrant
- update default
write cukes - ''done''
test selenium remote ''done''
Slides
- picture showing vagrant, chef-solo, virtual box, Berkshelf
- picture showing cukes, app, dev/new tester
- picture showing cukes, app - new CI box
!! Steps
vagrant up
start selenium
vagrant ssh
cd /vagrant/todolist
play run
'' Need a way to warm up play'' - ''play compile'' in vagrantfile
cd /vagrant
cucumber
!! Issues
* New tester
* Multi-project developer
* Synching CI with prod
* Shared resources
* Trying out new envs
* Envs changing outside of version control
* works on my machine
!! Outline
* What is Vagrant
* magic formula slide
* Environment as code
* Problems and Solutions - can I build up to the finale?
* Ecosystem, plugins, etc
* Selenium remote
!! Cons
* VM incompatibilities
* Slower
* No UI - Windows users
!!Other
Immutable deployments
AWS demo
Tips:
http://ashedryden.com/blog/what-you-need-to-know-about-speaking-at-conferences
cloud.images.ubuntu.com
https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins
https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Boxes
http://www.vagrantbox.es/
Intro
Vagrant is a pretty powerful tool that will let you setup virtual machines the same way, everytime automatically.
Formula slide
Providers
VMWare and Amazon EC2, via their plugin system.
Provisioners
It has the ability to take a VM provider. Initially this was just virtualbox, but they've recently added integration with VMWare and Amazon EC2, via their plugin system.
chef, puppet, ansibile, shell scripting, there are a ton of plugins out there, - salt
* Env to source code
- Vagrantfile lives with your source
* Vagrant = How do I run my application?
* Vagrant = Executable Readme?
* Vagrant = Multi-platform setup script
* Vagrant = Environment as Code
* Options!
* 1: Setup machine that looks like my production server
Works on my machine!
* Env changes in source control!
* Show vagrantfile
* Show vagrant up
* Show vagrant ssh
* 3: Demo system
My history - 3 day install process
Out-of-date
Build machine as demo box
Solution: Vagrant supports multiple VMs networked together with the enviroment up-to-date
*2: Try new system - new OS, new app server version, etc
* 4: Perf test
2 week perf test
* New CI server
*5: Hate installing stuff
- Clean machine joy
- Oracle DB, hard to install, what did I install
- Use a VM, snapshots, easy to throw away and start over
*6: Multi-project developer/designer
- VM for every project
*5: Test isolation
*7: VM for QA = joy
- On issue, pause VM, send it over to a dev for on the spot troubleshooting.
*7: Ruby installs
- History lots of crappy installs
- Goal: Make a new user productive in under an hour
- Examples: windows, rvm, link headers, missing libraries, homebrew and mac ports
*8: Shared resources BAD
-NO time to set him up, lets share some resources
- Point him at the build machine!
- Cleanup to a clean state
- Want to know what the system looks like before we execute tests
- Why is this test failing
- False positives
- Deleting stuff, conflicts
- New build being pushed
* Browser test on the VM
- Not ideal, resources
- Would you install a browser on your prod server?
* How to start from nothing
- install vagrant
- install virtualbox
- install java
- selenium
- clone repo
* Finale!
* Drawbacks
Katie Quehl
@KatieQuehl
#ContrarianDesign
http://katiequehl.com/ixda-cincinnati-contrarian-design-presentation/
!! Why
*Encourage creativity
*Overcome being stuck
*Gain perspectives
*Develop empathy
*Explore uncomfortable topics
!! Questions to generate bad ideas
How would I design for the opposite of what I want to accomplish?
How would a kindergartener solve fore this?
What would I suggest if I wanted to kill this project?
!! Examine ideas
* What is bad about this?
* Why is it bad?
* Is there a different context where this would be good?
https://speakerdeck.com/juliepagano/i-am-a-front-end-web-dev-and-so-can-you
Mozilla Developer Network
HTML5 Boiler Plate
Dive into HTML 5
html5rocks.com
caniuse.com
css-tricks.com
A List Apart
modernizer
css - compass
* What does it do?
*What's a css property?
*What's hoisting in javascript?
https://support.cloud.engineyard.com/entries/23852283-Worker-Allocation-on-Engine-Yard-Cloud
http://engineering.chartbeat.com/2014/01/02/part-1-lessons-learned-tuning-tcp-and-nginx-in-ec2/
https://rtcamp.com/tutorials/linux/sysctl-conf/
http://tweaked.io/guide/nginx-proxying/
http://unicorn.bogomips.org/TUNING.html
http://engineering.chartbeat.com/2014/02/12/part-2-lessons-learned-tuning-tcp-and-nginx-in-ec2/
Tian Davis - Respoke developer advocate
@tiandavis
tiandavis.com/talks
WebRTC
* Video from rep, customer audio only
DataChannel - secure data xfer - p2p
Chunking images
API will converge at 1.1
Firebreadth - > activex and nbap
ICE - framework for browser p2p
STUN - candidate = (ip and firewall (ports?))
Singaling - websocket server- facilitates the STUN connection
TURN - provides for situations when p2p fails
* (How does that work?)
* Why is it more reliable?
** When STUN fails - can't get through firewall - TURN is the mediator
rfc5766-turn-server (stun and turn server from google free)
Not just websockets - p2p - it's free from a server standpoint.
''what's the story on mobile?'' - not ready
''clojure signaling server''
''lunch and learn - create video to video app''
http://www.justinweiss.com/blog/2015/01/13/when-edge-cases-poke-holes-in-your-perfect-solution/
<<<
You can鴠fight too much cleverness with more cleverness. At least, not directly. Instead, go the other way. Go simple. Go straightforward.
<<<
<<<
Inline the code you were trying to abstract away. Do repeat yourself. Keep your code explicit.
<<<
@housecor
Cory House
http://www.bitnative.com/
* HTML should be a projection of app state not a source of truth (//not the system of record//)
* JS and HTML in the same way
* Unidirectional flow is better than two-way binding
* Inline styles are good.
''react-slingshot - open source from Cory''
!!! JSX
* Markup in this middle of your javascript
* Angular, ember, knockout puts js in your html
* In Angular, you write Angular. In React, you write JavaScript.
* Composing UI in javascript gives you a compile-time error vs runtime
!!! Virtual DOM
!!! Hot reload
Code on the left, browser on the right. Just make a change and save the code file.
!!! Isomorphic
* Code is rendered on the server and shipped to client as html
`renderToString`
* Performance, Accessibility, Maintainability
!!!Unidrectional Data Flow
* So clean
* React, Action, Dispatcher, Store, React
!!! Angular vs React
* Big names are using react. Angular has a bigger list, but less humungous players.
What's your favorite worktime conversation?
What would you like someone else make happen?
What would you change if you were allowed to?
What decision has upset you the most in the last six months?
What incentive would make you change the way you work?
What's holding you back?
@jasonkarns - td hangout dec22
hub clone testdouble/testdouble.js - Get the "github" url for free in any hub command
hub browse -> open a page to github
hub compare v1.0.0...master
hub browse -- issues
hub fork -> fork to my user
hub pull-request -o -> open github with a pull-request from my current HEAD to origin/master
can checkout PRs directly
hub checkout (url to pr) - > create a local branch with that PR
Nathan
!!! component based
Focused on components - components take data and spit out html.
* React figures out how to change the DOM
// Does this mean rendering is atomic?// - ''YES''
!!! jsx
syntax used by facebook to avoid boilerplate - basically can embed html tags in javascript code
{{{
return <h1> Hello from React </h1>;
}}}
** Should be precompiled in production
!!! Components
{{{
<TodoItem text="Code" />
//elsewhere in TodoItem render() function:
return <li>{this.props.text}</li>
}}}
!!! Flux
* Events from components are broadcast to a "Dispatcher"
* Dispatcher has listeners that register for interesting things
!!! Wiriing up updates
getInitialState - first time data
componentWillMount - called before render (good place to register for listeners)
setState - refresh widget
''Find links''
Romans 7
Punished By Rewards - ''Find link''
To tweet:
@avdi
@greggyb
@rubybuddha
@franklinchen and ... - ML
@TheOtherZach
@justinxreese
@kerrizor
@machuga
@juliepagano
@strand
@jimweirich
To follow:
@tundal45
@thegiftbug
@GavinStark