quattro_4 scribble

scribble 落書き (調べた事をただ落書きする)

thoughtbot Build Phase #31

It Had A Good Run

Liftoff 1.1
liftoffのdistribution
pre build binary使えない

facade pattern
decorator pattern Decorator Pattern
Categoryっぽい

AutoCoding nicklockwood/AutoCoding · GitHub
AutoCoding is a category on NSObject that provides automatic support for NSCoding and NSCopying to every object.

view model
mvvm Model-View-ViewModel for iOS | Teehan+Lax

sandi matz rule Sandi Metz' Rules For Developers
Controllers can instantiate only one object.


friday
launch liftoff1.0
vendorize gem dependency
homebrew formulae
github page
tested whole thing
kind of scary
xcode5.1
never experienced
compiler updated
all should break
dependency
cocoapods
native c
hooks ruby
uid generation
plist
serialization
ruby extconf
makefile
c extension
bundle
two binary
two different ruby version
improving release process
previous binary
installation liftoff
get away from
homebrew formulae
notification
four oclock
better test
need test
automated test
everything brew up
freaking out
liftoff dead
couldnt use
pre build binaries
package binary
bundle version
couldnt rely pre build binaries
nothing left do
turns out
ships with xcode5.1
unrecognized compiler error
system version ruby
marvericks
ruby extconf
system ruby
commented out code
native binaries
apple have to update system ruby
only marvericks 10.9.3
very large project
depend on cocoapods
get fix for free
awful
liftoff so far
crazy wired
dumping company name
reasonable default
sanitize company name
downcase strip special chars
remember obj c
writing lot of views
scaffolding
take advantage load view
simple view
overkill
adding constraints
wrong
come up with sort of convention
nib
view controller
nib look for
my view
fall back my view controller
override specific view
previously about
never talked abount
aparent to me
makes me twitchy
almost like implementation detail
ui view subclass
one level away
view controller containment
pass it that way
hierarchy simple
cell object
setter getter
behavior
actually properties
expose subview
interfacing
pushing
model object
passing model object
generally
two string image
controller job
observing model
view unique
Model represent
other thing
displayable protocol
nicer
make things elegant
in practice
over engineering
passing model
setter
anything more than 3 properties
different state
line item
refund
payment green
boolean
semantically correct
determine
view has to know
behavior based on enum
views have condition
state coming in
view has to know
view hard to test
view controller
api standpoint
dillar amount
refund
hiding view
mapping
controller
other abstraction
pass back
refund
protocol
super class
dollar amount
refund cell red
view model
models to be
they shouldnt smart
jumping language
liftoff
content hash
iterate through
kvc
same thing
two method
author name
company identifier
returns
instance variable
author
sensible default
return string downcase
simple object
testable
unit test
cant do that
check this color
object
type check
point is
fat model
skinny controller
rails
passing object
rails isnt actual mvc
not just saying
here
rails isnt mvc
view layer
know enough about
apple version
mvc
ios community
maybe apples fault
decision
convenient place
ns object
glue layer
mvc dont have to be
empty view
sensible value
no address
model object address
time presentation
in vc view
mvvm
view model
general
dont wanna
want specific view
view header represent
awesome to me
rails guys
try to follow
sandi matz
rule
vc only instantiate one object
obvious
third pattern
put those into another objects
modify string
tied to entire midel
view model
facade pattern
sounds
decorator
presentation
decorater expose original interface
different
facade pattern different
it hasnt state
subtle difference
location presenter
hold on two object
decorator essentially category
presenter category
dont import category
run time
cocoapod
nscoder support
runtime
has a
create protocol
similar to view model
protocol feels
abstract
concrete
overkill
decouple
extract as protocol
right way to do this
conclusion
hopefully