Skip to content

Instantly share code, notes, and snippets.

@justincampbell
Created April 10, 2012 21:08
Show Gist options
  • Save justincampbell/2354558 to your computer and use it in GitHub Desktop.
Save justincampbell/2354558 to your computer and use it in GitHub Desktop.
PhillyETE 2012 Notes

todo

Storm Threequal js vs ruby

Keynote

The E myth Org chart for yourself

QFD = ideas into actionable items Wants and weights Technical requirements (guesses) Target values Relationship strength (positive or negative to wants) Flip it and do it again

Don't measure process Don't feel comfortable just because you're following a process

Consumer options != life options, see above

Methods should do one thing Match abstraction levels

Mind mapping

Don't hate; iterate

Delaying admittance of failure prolongs positive iteration

Product managers shouldn't create products without measurable goals

Measure everything

Smoothing algorithms and aberration detection

Outsource what you're bad at Document Communicate Delegate Measure Organize

Where are we? Where do we want to be? What to do to get there?

JS and error resiliency

JSLint knows about good parts and bad parts It will hurt your feelings

Prefer forms that are error resilient

Fallthrough is bad (switch)

That hardly ever happens = it happens

Style is about better programs and reducing errors

Never use with(){} confusion must be avoided

Always use threequal in js, double does coersion

Multiline string literals suck
a lot

Programs should look like what they do Don't test for boolean in an assignment

Write in the language you're writing in

Var is function scope Let is block scope

bad++ good += 1

Forms that can hide defects are defective

Language subsets are good

Ember.js

Backbone is lowest common denominator

Ember is

  • data binding
  • computed properties
  • data-bound celarative templates
  • Mvc structure
  • ember-data, rest built in

Apis are less consistent than sql

Weekend projects and large corporate projects peril Ember is in the middle

Optimized for developer happiness

Apis become frozen Performance can always be refactored

Objects! Classes! Mixins! Super! Namespaces!

Uniform access is great for refactoring (computed properties)

Intermediate state or bindings Browser events wait for all to finish Other events use setTimeout

Templates can exist in script tags in the body, good for prototyping

Upcoming

  • Routers
  • state managers
  • persistence
  • improved debugging
  • docs
  • rails

Xfinity App

Mobile is shipped software Users control their updates

Humans only voice complaints

Form a mobile team

  • Products
  • People
  • Process

Hiring People

  • Consultant (depends on cookie-cutter-ness of app)
  • train your best engineers
  • hire young guns
  • engineering managers with shipping experience
  • go to where mobile engineers are

Process

  • simplify (most important, reduce scope to bare minimum)
  • prepare
  • plan
  • build, test, build, test
  • test again as a user
  • release
  • party

QA + Developer = Feature team

Partner with internal teams

Send all of your developers to major confernces

  • Retention
  • Skills
  • Networking

Reach out to Apple and Google

Use the cloud for hard stuff

Use native platform capabilities and abstractions, sometimes denying feature requests from product managers to maintain simplicity

How GitHub Works

Founded by 4 dudes in a coffee shop/bar/somewhere Side project Still had fulltime jobs Had to work async Forced to be distributed, flexible, happy Improve your company Zachholman.com

Hours are bullshit Creative people don't fit in a 9-5 Crafting code is hugely creative Design environment for artists You can't force creativity to happen Best solutions happen when you're in the zone When youre not in the zone, do something else (not work) Embrace flexibility 90 hours a week and loving it = bad programmers, bade of foolishness Pushing code = do it all over again anyway Best work happens when people are happy

First principle What are we trying to solve Solve it the bet way Ignore what people have ben doing

Huge cost to having people leave

Trust your employees Biggest problem in large companies Programmers do this because they love it Youhiredthem

Reaganism: trust but verify

Weekly beer company talk Broadcast and recorded

Recorded required 5 min talks

Team building summits

No offices, required desk switching ~monthly

Stay in the zone Minimize distractions Hey i got a question = worst thing ever Headphones are a good indicator

No meetings ever Few person chats are ok No managers, everyone is a manager Managers only distract Self-forming teams

Many teams Encouraged to stay in team til shipped Shipping culture, unshipped is nothing Can be on multiple teams Chat room per team

Minimal process Fuck agile, standups, xp, retrospectives, chickens and pigs Software answers these Does this generic process work for us? Minimum viable process

Get feedback quickly internally (chat) Pull requests for code review Wikis, internal cht Make it ok to say no (alternative is shitty ideas shipping)

Ideas repo, shareable by everyone, comments, etc. Everyone. This distills good ideas to the top Again, make it ok to say something sucks

Master is always deployable Master deploys to production after CI automatically Pull request' someone else sign off, merge Deploy multiple times a day Quicker deploys mean smaller bugs 3 weeks of code released = 3 weeks of fuckups Have a simple rollback Partial deploys, staff only, certain servers, etc

Git-flow is complicated and sucks Complication screws non-technical people

Fast tests! Slow test is a regression

Graph everything Custom dashboards

Only use staging sparingly Tests are more important than staging Make it automated If something breaks, write a test! Don't just fix it.

Optimize for happiness

0 employees have left Institutional knowledge would go with them Hiring is expensive, people leaving either more Offering more money to people leaving never works Happy programmers are twice as productive

Foster exploration Shared side projects

Give kindles to everyone Give fitbits to everyone

Employees don't go to conferences alone, fly someone else out with them

Shared music system, streams to people at home Helps bonding

Bring people together on fresh and new stuff

Ideation needs people to say it sucks

Client work

Artificial constraints Lack of 9-5 still applies Find your minimum viable process

PJAX

Pages are mostly the same Lots of redundancy Speed matters

Pushstate for urls

Problems Multiple content areas Titles Hidden changes Context switching Computers should do it for us

Auto-Pjax for Django

Hashbangs suck

Security is important

Load url Pass pjax and current Sever does diff Return json Client replaces

PhillyETE 2012 Day 2

TODO

  • Frink (and Ruby?)
  • Big rewrite blog
  • Over emphasis on test coverage
  • Lwes logger
  • instance_methods(true)
  • Minute Physics

Keynote

Alex Payne, Simple

Boring straightforward architecture allows focus on product

Why new languages?

People hate new for some reason, or at least they're vocal about it

If we settled on what was working, we'd still be using languages from the 50's

Evolution continues

Not talking about languages with conferences (Scala Clojure F# Haskell Erlang)

Also not talking about these, been around for a while but no traction (R Groovy D Fantom Lua)

Different languages for different jobs

Just being a better java = boring

Java

Kotlin

  • Java++ or Scala--
  • Moves role of IDE into language

Gosu

  • Pragmatic for JVM
  • Related to Ruby

Ceylon

  • Redhat's new Java
  • Interceptors
  • Return outer

JavaScript

StratifiedJS

  • Concurrent + asynchronous
  • waitfor { }

CoffeeScript

  • The good parts of JS
  • Objects over prototypes

Objective-J

  • Objective-C -> JS

ClojureScript

  • Clojure -> JS
  • Morphing to other output languages

DART

  • Google's JS
  • Optional typing

Roy

  • Functional JS
  • Monads

Full Stack

OPA

  • XML literals

UR/Web

  • Haskell

Systems

Go

  • Compiled
  • Concurrent
  • Heroku uses it a ton

Rust

  • Better C++
  • Kitchen sink

OOC

  • C and Objects

Dynamic

Fancy

  • Actors on Rubinius

Slate

  • Modern smalltalk

Elixir

  • Modern Erlang

Technical Computing

Frink

  • Makes physical calculations simple

Julia

  • Readable high performance technical computing
  • Faster and better than R

Faust

  • Audio DSP

Data Querying

Bandicoot

  • Set algebra
  • Relational

Quirrel

  • Analytics

Make you think

Wheeler

  • "Different", "Special"
  • No variables, functions, or objects
  • Patterns and transitions

Kodu

  • Xbox
  • Programming for kids
  • Visual

Lots of platforms

Explore and experiment

Real time web apps

Aaron Mulder, Chariot Solutions

Why? Push.

Backbone

  • Many ways it can work
  • Place to store data
  • Way to update models

This is not a Rails shop

Chad Fowler, LivingSocial

Ruby since 2000

Mort

Theres always one person trying to change a company for the better (fighting)

You're probably that person if you're here

Eventually if things aren't changing, just leave

Monkey arms and little holes

So far with your head up your ass you miss people who are right

Doing something right leads to blinders

Rails developers had to fight to use ruby

Now they might have those same blinders

This applies to every framework you love

Rails

  • MVC
  • Single threaded by design
  • Not a batch processor
  • Not a message queue
  • Not a work queue
  • Not an event processor
  • Not an analytics engine
  • Not a service bus

Rails is for making websites

Very few useful complicated apps are just MVC web apps

Rails doesn't scale actually means MVC-only doesn't scale for development

Rails scales if you use way more than just Rails

"Vanilla stack" Html JS SQL ElasticSearch Redis Memcached Unicorn Nginx

Raw SQL is good

If youre using relational DB and have no raw sql, you might be a Mort

LivingSocial sends emails with ruby, but not Rails

Probably would have been JVM if from scratch

Big rewrite

Twitter built a social message bus using Rails

It sucked for massive scale

If they used somethjing else from the start, they probably wouldn't be here today

They did it right

Never heard of a project whose goal was to couple decoupled things into a monolith

Legacy

"repercussion"

It means positive things in the rest of the world

Chaos report

Stuff is more successful now

But overall is terrible

Life expectancy of business software is 5 years

It takes 10 years to make good software

Nobody will remember what you made when you're dead

We're all going to create transient legacy crap

We're happier than that sounds 'cause we get paid well

We should be creating things of value

Legacy code: Fear, Stasis, Difficult to change. These are reasons it stays around.

Do one thing and do it well

Your software is alive tinyurl.com/codealive

Our bodies have a lot of cells, a ton die every day

Systems survive because of many small parts

  • What is a cell?
  • What is a system?
  • When do you build a system vs a cell?
  • What if you built everything as a cell?

Fred George

Any developer can use any language or tech

Need to be very tiny and replaceable quickly

Kill and replace cells regularly = refactorung

Force heterogeneity

Stuff will change

If its hard, do it all the time

Simple interfaces

Small things with simple I/O

Pipes

REST

If you write everything as a Rails app, the boundaries are blurry

LAMP/Rails doesn't work for large teams

Hiring is hard

Train people

Lots of candidates we like, but they're not quite ready

Invest in education

Pragmatic programmer

Knowledge portfolio for yourself

LOTY learn a language a year

Learn something that makes you think differently

Threads are better than jobs

Scala can do this better than Resque

Homework!

(to not be a Rails mort)

  • Enterprise Integration Patterns Book
  • Play with alternate data stores
  • Learn HTTP really really well, read server source code, write one
  • Deeply understand and implement HTTP caching
  • Build a client app (js)
  • Learn a new language, Seven Languages in 7 weeks
  • Build a Rails app now

Curing Rails

Aaron Patterson, AT&T

Code charcuterie

Enterprise

What do we care about?

  • Speed, fast development, fast feedback
  • Scalable
  • Stable
  • Testable
  • Integration
  • Understandable, to judge effort, risk, and reward

Enterprise Developers? Trade time to market for reduced risk

Risk Management

  • Hardware
  • Tiers, n+1
  • Expensive
  • Takes a long time

Apps

SOA

Rails -> Rails, Sinatra -> Oracle, Lucene

Delegate

Manage risk

Rails

MVC

ActionDispatch

ActiveRecord, ActionView

Rack -> Dispatch, Journey -> View

Method

AR -> Arel (AST of SQL) DB Adapter -> DB

View

Erb into ruby

Call method, return text

Cached: View, Call method

Logging

Default is so-so

Use Ruby's logger

Fs buffers make logging faster

File.open file, 'wb'

Syslog is better

Lwes is best

Code

Statement caching

.arel.to_dot

Instrumentation

Queue

Pub sub

Mitigate risk by observing

Subscribe to all events

Ruby is awesome

Rails is awesome

Its up to you to manage risk

Avoiding surprise null pointers

ruby -w warns against uninitialized instance variables

Use helper methods? No

Context objects? Informative errors, testable, kinda sucks

Presenter pattern is the ruby community failing to understand what patterns are and calling everything a presenter - Yehuda

Rails 4 getting a queue interface

Memory queues for tests

Testing JavaScript

Trevor Lalish-Menagh

Programmers write code, engineers craft code

Don't be afraid of changing your code

Quality JS is hard

JSLint is awesome

  • Namespace your functions
  • Declare vars at top
  • Encapsulate your code in IIFEs
  • Don't use with
  • Use vars in for
  • Don't abuse eval

You know all of this cause you're awesome and a rockstar

Actually, you're not

False consensus effect

We all write bad code

JavaScript is easy to screw up

So we write tests

Tests in javascript

Unit tests

They run on CI

Jasmine is like rspec

Qunit is like Junit

Now front end engineers can break the build and thats awesome

  • Jasmine
  • Maven / Rake
  • Jenkins

Learn how to write these tests

  • Simple
  • Callback
  • Ajax

Connascence

Jim Weirich, EdgeCase

Time dilation formula

Minute physics

Twins are born together, we expect them to change together

What every programmer should know about object-oriented design book: OO, graphical object notation that nobody uses, design principles

Design principles introduces connascence

In software, things that need to change together

Name Position Meaning Algorithm Type Execution Timing Value Identity

Name

obvious

Position

  • Argument positions
  • Adjacency or appear in particular order

Options hash converts position connascence to name

3 or 4 is a good number to switch at

Connascence is important because change is expensive

Meaning

  • Special values that have particular meaning
  • Named connascence is better, but still connascence

Build dynamic attributes based on logic you need to perform instead of lots of if ors

Control coupling

passing in data to control internal logic

  • Function name includes or
  • Returns a single object or collection
  • Reads or writes
  • Symbols
  • True/false
  • Nil
  • Nil and false are different
  • Case statement from argument

Algorithm

  • 2 regexs that match in 2 places
  • Aggreeance on how to process data
  • Client/server
  • Serialize/deserialize
  • Checksumming
  • Url routing and generation

Reduce degree of connascence

Name is good

Can't place exact value on others

Type

...

Above are static Below are runtime

Value

  • Values of 2 components are related
  • Generally not widespread

Timing

  • Race conditions
  • Timing of execution is important

Execution

  • Ordering of code execution is important
  • Imperative
  • Functional languages lack connascence of execution
  • Queues with multiple workers that require ordered processing

Identity

  • AR doesn't use an identity map
  • 2 components must refer to same object

Type!

  • Set of data
  • Set of operations
  • Semantics and implementation
  • Expectation
  • Contract
  • API
  • Ripe for research
  • Two components must agree on type

Opposite of duck typing is chicken typing

Contranascence

  • Inheritance
  • When two components must agree on different names
  • Namespaces
  • Delegation

Increase locality

DRY

Single responsibility principle

Prefer stability

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment