└── 2011 └── strange_loop └── notes /2011/strange_loop/notes: -------------------------------------------------------------------------------- 1 | ERIC MEIJER ()MICROSOFT) - CATEGORY THEORY 2 | BIG DATA - not only about size, it is about data diverstiy 3 | interaction patterns between producers/consumers 4 | Diff between FK and key/value store? 5 | Design space that spans 3-d 6 | NoSQL 7 | co-sql 8 | objects vs tables 9 | memory is key/value store -> objects 10 | Sql is imperative language (example -> inserting/updating) 11 | arbitrarily deep hierarchy 12 | SQL 13 | not compositional 14 | impedance mismatch -> ORM 15 | indexes implicitedly make object model 16 | 17 | "Nothing new in CS, everything has been discovered 5 times" 18 | 19 | Trade-offs between Sql/NoSql 20 | 21 | Arrows reversed for nosql/sql 22 | 23 | CATEGORY THEORY 24 | interface for functions 25 | compositional 26 | "first OO programmers" 27 | duality -> reverse the arrows, duo, the categories hold for both 28 | de morgens law 29 | can use scientific constraints to pick technology (instead of newness/hipness) -> more like scientists to reason about solutions 30 | 31 | SQL vs NOSQL 32 | Sql - children point to parent, cosql - patent point to childern 33 | sql - entities have identity, cosql - environment (memory) determines identity 34 | sql - environment coordingates changes, cosql - entities responsible to react to changes 35 | sql - closed, co - open 36 | 37 | 38 | FUNCTIONAL THINKING - Neal Ford 39 | not nouns, verbs -> just do it 40 | took decades to use objects, don't see power, only see differences 41 | started as academic offshot 42 | scala, clojure, f#, plus erlang/haskell 43 | Feathers - "OO makes coed understandable y encapsulating moving parts" -> visibility rules, facilities to manage changing state 44 | "FP minimize moving oarts", fewer parts , easrier to reason 45 | 46 | The Productive Programmer -- TDD 47 | 6: 1 + 2 + 3 + 6 = (2x6) = 12 48 | > 2*#: abundant 49 | < 2*#: difficient 50 | 51 | minimize shared state 52 | no internal state 53 | no scoping, all methods are public 54 | pure functions -> only rely on paramaeters and return values 55 | public and static 56 | no information hiding 57 | "more a way of thinking, than a particular toolset" 58 | 59 | first-class/higher order functions 60 | pure functions 61 | prefer recursion over iteration 62 | strict valuation 63 | 64 | think about results, not results 65 | post-imperative world 66 | 67 | fn becomoing popular b/c optimize person time, not optimized for CPU 68 | lnguages handle garbage collction, concurrency, state, test, etc 69 | thinking functionally 70 | immutabliity over state transitions 71 | "functional thinking" articles 72 | "results over steps" 73 | "composition over structure" 74 | declarative over imperative 75 | paradigm over tool 76 | 77 | SUMMARY 78 | new ways of thinking design 79 | new tools for extions, reuse 80 | immutable by default -> beneficial beginning steps 81 | following the general trend in langugage design 82 | enables new way sto view problems 83 | 84 | FOG OR HOW I LEARNED TO LOVE THE CLOUD - Wesley Beary (Geemus) 85 | on demand, flexible, repeatable, resilient 86 | why worry? option overload, expertise, tools have vastly different API/qualitiy, standards 87 | "ORM for cloud services" 88 | why? portable, owerful, established 89 | 90 | A TALE OF THREE TRESS - SCOTT CHACON 91 | esoteric/abstract talk about git 92 | git is... system for storing trees (files, sub-directories) 93 | 1st tree 94 | head - pointer to last commit (a tree) 95 | parent of next commit 96 | 2nd tree 97 | the index (staging area) 98 | single file manifest 99 | git ls-files -s 100 | propsed nex commit 101 | 3rd tree 102 | working directory 103 | still a snapshot 104 | sandbox 105 | 106 | WORKING WITH TREES 107 | git status - difference between three tress 108 | 109 | GIT RESET 110 | tool to manipulate the three tress 111 | git reset [commit] [path] -> opposite of git add 112 | takes content from db (head) into index 113 | git reset [commit] -> works on tress as a whole 114 | --soft -> move HEAD to target 115 | git reset --soft HEAD~ -> revert last commit 116 | [--mixed] -> then copy to index (this is the default) 117 | unstages everything 118 | leaves working directory 119 | --hard -> then copy to work dir (make all tress the same) 120 | 121 | git add -p -> partial commits of logical changes 122 | 123 | git commit --ammend 124 | git soft, git ci 125 | 126 | git reset --soft HEAD~2, git commit -> moves HEAD back, keeps index 127 | 128 | GIT CHECKOUT 129 | moves branch that HEAD points to 130 | git checkout [commit] [path] 131 | 132 | FUN WITH YOUR TREES 133 | git add --patch [file] 134 | git reset --patch (commit) [file] 135 | git checkout --patch (commit) [file] 136 | git rev-parse -> sha for commit 137 | git hash-object -> basically what git add does 138 | git ls-tree/cat-file -> tree objects 139 | git ls-files -s -> staging area 140 | git read-tree -> subset of reset 141 | git update-index 142 | git write-tree 143 | git commit-tree 144 | git symbolic-ref 145 | 146 | COFFEESCRIPT - JEREMY ASHKENAS 147 | stay true to JS 148 | 149 | STARTED 150 | started as potion-y 151 | Ruby compiler 152 | 153 | 0.5 154 | wrote CS in CS 155 | "People shouldn't be compilers, computers are better at it" 156 | 157 | Take JS design pattern, and see the minimalist, easiest way to do them 158 | 159 | CS = Syntax + semantics + goodies 160 | 161 | Binding this in current js is un-usable b/c of the way prototypes are set up 162 | 163 | BUILD YOUR OWN JAVASCRIPT 164 | 165 | GETTING TRUTH OUT OF THE DOM - YEHUDA KATZ 166 | Advanced javascript applications 167 | source of truth for data 168 | 169 | 1st step -> evented jquery 170 | fire higher-level event which updates DOM 171 | reduces coupling 172 | better set of events 173 | click on this DOM, update this DOM -> blerg 174 | 175 | WIDGETS 176 | wrap DOM in object 177 | 178 | ENCAPSULATE state of single view 179 | manage "views" 180 | seperate object that represents reality 181 | 182 | MODELS and OBSERVERS 183 | multiple observers on a model 184 | 185 | INTERMEDIATE STATE 186 | batched operations -> event on particular checkbox for bulk operations 187 | 188 | 1:1 MODEL/VIEW COUPLING 189 | a data object "has an element" 190 | 191 | A PROBLEM 192 | application state 193 | reverse engineer information from aggregates 194 | 195 | EDGE CASES 196 | Mark all checkbox 197 | add new todo 198 | check todo 199 | 200 | REALITY, VIEW, MEDIATING SPACE -> MVC 201 | too many acronyms (MVP, MVVM, etc) pseudo-rant :) 202 | 203 | "Don't actually need a C because we are too hipster" 204 | 205 | SPROUTCORE 206 | MVC auto-sync layer 207 | you declare linkage, SC keeps layers in sync 208 | handles batches 209 | layer of abstraction 210 | changes buffered between layers 211 | 212 | TEMPLATING 213 | had problems with ajax requests to update DOM, but new version deals better 214 | describes living state of DOM, not just first view with more html for updates 215 | 216 | MAGIC! 217 | 218 | WE DON"T KNOW HOW TO COMPUTE - SUSSMAN 219 | Human genome is 1 GB - same as MS Windows 220 | flexible 221 | neighboring cells talk to each other 222 | intuitions about programming come from a time of scarcity (CPU, memory) -- no need to optimize anymore 223 | minimze latency, though 224 | real cost is cost of programmers 225 | pundits worry 226 | about correctness, needs reasonable 227 | security -> humans deal with mutating parasites for 70+ years 228 | 229 | spend all time modifing existing code 230 | good for problems the designer didn't intend 231 | programming into holes 232 | consequences of changes aren't so expensive 233 | 234 | dynamically add methods at runtime 235 | flexibility 236 | pay proof of correctness for flexibility 237 | proofs force specs to be as tight as positive 238 | brittle 239 | 240 | "I hate all computer lanugages nowadays, even the ones I invent" 241 | "A real engineer doesn't want a religion to solve a problem, like, OO, FP, imperative, procedural." 242 | Real engineers want to use the correct solution for the particular problem 243 | Silly to worry about type system 244 | 245 | Filling in details from local information 246 | 247 | Problem is Evolvibility, not correctness 248 | 249 | HERESIES AND DOGMAS - DEAN WAMPLER (LOOK UP HTML5 and DISTRIBUTED SYSTEMS) 250 | Software is faih-based 251 | 252 | GOTO 253 | DESIGN BEFORE CODE 254 | Do the change at the right possible time 255 | DESIGN PATTERNS 256 | Solution ot a problem in a context 257 | Some languages fix patterns - Lisp 258 | Lisp has their own patterns, they just have different terms 259 | Specific patterns come and go 260 | CORBA vs REST 261 | Corba - binary, interface instability 262 | objects are not very modular 263 | interface, composable, reusable 264 | fundamental flaws 265 | Exmaple of modularity 266 | digital circuits 267 | http 268 | OO 269 | "Unconstrained freedom to create abstraction undermines reuse" -> constraints help with modularity 270 | OBJECT IDDLEWARE AND ORMs 271 | largely contextual whether it is a good idea or not 272 | Rich domain model means fewer fatter services 273 | Node.JS/Mongo -> uniform data model 274 | 275 | Whether it's a dogma or heresies is a matter of branding 276 | 277 | EVENT-DRIVEN PROGRAMMING IN CLOJURE 278 | sync is easy, async is more complex (looks like node) 279 | often spend more time waiting on data than we fo computing our response 280 | syncronous concurrency -> fork/join model 281 | threads aren't free 282 | thread pool 283 | "someone is trying to be as clever as you" 284 | nested concurrency 285 | async exposes an inherent complexity 286 | less leaky abstractions 287 | sync/async not mutually exclusive 288 | "complexity is local" 289 | code expresses dependencies 290 | looks like the async module 291 | difficult to debug, complicated flows are still complicated 292 | 293 | STAGE-CRAFT IN UX (ALSO LOOK AT TALE OF TWO RUNTIMES - MOJITO) 294 | Experience is actually psychology 295 | user-interface, as known as UI "user illusion" 296 | 297 | PREPARE 298 | consider the stage and the audience 299 | Effects are different based on scale 300 | phone/tablet/PC 301 | PRACTICE * 3 302 | practice until you have it perfect, then practice 100 more times 303 | magic: makes the trick look natural 304 | testing/alpha/beta 305 | OVERCOME OBJECTS BEFORE THEY ARISE 306 | magic: hyponotize assistant before sawing in half 307 | logins (facebook/twitter/yahoo/open id) 308 | remove barriers 309 | PERFORM 310 | patter and showmanship - presentation as important as content 311 | soda jerkers - best performance 312 | users care about experience, not mechanics 313 | SLIGHT OF HAND (TIMING MATTERS) 314 | brains edit out certain details, to make it understand reality 315 | 1/tenth of a second 316 | direct manipulation - instant 317 | full second 318 | uninterrupted flow - notice lag, but still involved in process 319 | 10 seconds 320 | keeps attention - user's mind start wander 321 | DIRECTION 322 | divert attention 323 | call to action -> color, whitespace 324 | brains evolved to track motion 325 | notification 326 | recognize faces 327 | status lines on twitter/facebook/linkedin 328 | MISDIRECTION 329 | all magic is misdirection 330 | 331 | simulation - trash can for deleting 332 | metaphor 333 | skeumorph 334 | floppy disk 335 | rivet on jeans 336 | ibook 337 | dissimulation 338 | web applications - make web apps look like desktop apps 339 | key in on little details 340 | anticipation 341 | progress bar in web apps 342 | TWO WORLDS 343 | world of the end user (performance) 344 | world of the developer (performer) 345 | 346 | PRODUCT ENGINEERING 347 | appsterdam 348 | amsterdam sounds awesome 349 | 350 | POST-PC COMPUTING IS NOT A VISION - Allen Wirfs-Brock (Mozilla) 351 | No idea of where we are going 352 | Post-mainframe era? 353 | computing era based on impact on society 354 | corporate computing, personal computing 355 | this new era 356 | mobile, cloud, tablet, games/media, 357 | 358 | SOME ORGANIZATIONS 359 | how do you monaitze user? might not be the best 360 | 361 | AMBIENT ERA 362 | centrally augment everyday life of individuals 363 | ubiquitous availability 364 | pervasive 365 | nano on wrist watch, earphones in glasses -> enhance world 366 | 367 | TRANSITIONAL TECHNOLOGIES 368 | rooted in present 369 | has characteristics of era to come 370 | 371 | MAINFRAME 372 | timesharing 373 | shrinking the size of the computers (minicomputer) 374 | AMBIENT 375 | cell phones 376 | always with you, connected 377 | WWW/browers 378 | availability more important than performance 379 | universal presentation platform 380 | when something becomes ubiquitous, it disappears 381 | 382 | DOMINANT APPLICATION PLATFORM 383 | corporate -> IBM Mainframe 384 | personal -> Microsoft 385 | ambient -> JavaScript? 386 | web apps vs native apps 387 | could there be an era based on open standards? 388 | 389 | CANONCIAL PROGRAMMING LANGUAGE 390 | corporate - COBOL/Fortran 391 | personal - C 392 | ambient - javascript 393 | 394 | JAVASCRIPT 395 | ecmascript 396 | interoperability is highest priority 397 | harmony 398 | be better for: 399 | complex applications 400 | libraries (including the DOM) shared by apps 401 | code generators 402 | SmallTalk to JavaScript -> http://amber-lang.net/index.html 403 | modules, namespaces 404 | sand-boxing module loaders 405 | proxy obejcts 406 | control abstractions via iterators and generators 407 | array comprehensions, string interpolation 408 | super references 409 | encapsulated state via private names 410 | better support for class-style inheritance 411 | 412 | USERS: Customers or merchandise? 413 | are we building devices and services that empower people? 414 | build systems we would want to use 415 | keep user in control 416 | identity, privacy 417 | 418 | Need revolutionaries and dreamers 419 | 420 | INFOQ.COM -> for StrangeLoop videos 421 | 422 | SIMPLE MADE EASY - RICH HICKEY 423 | "Simplicity is prerequsite for relibility" - Djikstra 424 | 425 | WORD ORIGINS 426 | simple -> one twist/braid/fold 427 | complex -> many folds 428 | easy -> lie near 429 | hard -> 430 | 431 | SIMPLE 432 | lack of interleaving, not cardinality 433 | objective 434 | 435 | EASY (relative) 436 | near, at hand 437 | in our toolset, IDE, etc 438 | near to our understanding, that we alreay know, familar 439 | self-involved to get things instantly 440 | never learn anything know 441 | near our capabilities 442 | tramples on our egos 443 | 444 | CONSTRUCT vs ARTIFACT 445 | program with constructs 446 | programmer convenience 447 | programmer replaceability 448 | in the business of artifacts -> users don't care of sourcecode 449 | long term results of use 450 | quality, correctness 451 | maintanance, change 452 | must assess constructs by their artifacts 453 | 454 | LIMITS 455 | only hope to make realible those things we can understand 456 | only consider a few things at a time 457 | intertwined things must be considered together 458 | complexity undermines understanding 459 | 460 | CHANGE 461 | changes to software require analysis and decisions 462 | what will be impacted 463 | where do changes need to be made 464 | need to reason about program 465 | informal reasoning 466 | 467 | DEBUGGING 468 | every bug in the field 469 | passed the type checker 470 | passed the tests 471 | guardrail world 472 | don't help you get to where to go 473 | need to reason about program 474 | 475 | DEVELOPMENT SPEED 476 | emphasizing ease gives early speed 477 | "fire starter pistol every 100 yards" 478 | ignore complexity will slow you down over the long haul 479 | throwaway/trivial projects, nothing much matters 480 | 481 | EASY YET COMPLEX 482 | complicating constructs are 483 | succinctly described, familiar, available, easy to use 484 | what matters is the complexity they yield 485 | complexity is incidental 486 | incidental -> "your fault" -> programming with a loom 487 | 488 | BENEFITS OF SIMPLICITY 489 | easy of understanding 490 | ease of change 491 | easier debugging 492 | flexibility 493 | policy 494 | location 495 | 496 | MAKING THINGS EASY 497 | installing 498 | become familiar by learning, trying 499 | mental capability 500 | make things near by simplifying them 501 | everyone is statistically at the same point 502 | 503 | PARENS ARE HARD! 504 | not at hand for most 505 | not familiar 506 | CL/Scheme 507 | overloaded parens used for calls and grouping and data structures 508 | adding a new data structure makes things simplier 509 | 510 | "LISP programmers know the value of everything and the cost of nothing" - Alan Perlis 511 | performance cost 512 | never any trade-offs, only for benfits 513 | 514 | COMPLEXITY 515 | state, objects 516 | methods 517 | variables 518 | inheritance, switch, matching 519 | syntax 520 | imperative loops, fold 521 | actors 522 | ORM 523 | conditions 524 | inconsistency 525 | 526 | SIMPLE 527 | vlaues 528 | functions, namespaces 529 | managed refs 530 | polymorphism 531 | data 532 | set functions 533 | queues 534 | declarative data manipulation 535 | rules 536 | consistency 537 | 538 | COMPLECT 539 | -> to interleave, entwine, braid 540 | complecting things is the source of complexity 541 | best to avoid in the first place 542 | 543 | COMPOSE 544 | -> to place together 545 | compossing simple components is the key to robust software 546 | 547 | MODULARITY AND SIMPLICITY 548 | all done! so simple 549 | partitioning and stratification don't imply simolicity 550 | but they are enabled by it 551 | code organization 552 | 553 | STATE IS NEVER SIMPLE 554 | complects value and time 555 | it _is_easy, familiar 556 | interleaves everything that touches it, directly or indirectly 557 | not mitigated by modules, encapsulation 558 | this has nothing to so with async 559 | same input -> same output 560 | 561 | NOT ALL RES/VARS ARE EQUAL 562 | none makes state simple 563 | 564 | POLYMORPHISM ala carte 565 | protocols, type classes 566 | 567 | ENVIRONMENTAL COMPLEXITY 568 | resources 569 | inherant complexity in implemtation space 570 | all components contend for them 571 | segmentation 572 | waste 573 | individual policies don't compose 574 | 575 | MAKING THINGS SIMPLE 576 | abstract -> drawn away, from the physical nature 577 | vs Abstraction as complexity hiding 578 | "I don't know, I don't want to know" 579 | 580 | WHAT 581 | operations 582 | form abstrctions from related sets of functions 583 | small sets (interfaces, prototypes, specifications) 584 | polymorphism 585 | inputs, outputs, semantics 586 | 587 | WHO 588 | entities implementing abstractions 589 | DI from subcomponents 590 | small interfaces 591 | e.g. policy 592 | beware of component details 593 | 594 | HOW 595 | implementing 596 | abstractions and entities via polymorphism 597 | declaritive 598 | 599 | WHEN/WHERE 600 | strenuously avoid complecting these with anything 601 | can seep in via directly connected objects 602 | queues 603 | 604 | WHY 605 | policiy and rules of application 606 | often strewn everywhere 607 | complected with control flow 608 | 609 | INFORMATION _IS_ SIMPLE 610 | don't ruin it 611 | objects shouldn't be applied to information 612 | thwarts generic data composition 613 | ties logic to representation du jour 614 | represent data as data 615 | 616 | SIMPLIFYING 617 | disentangle 618 | identify threads 619 | 620 | SIMPLICITY IS A CHOICE 621 | culture of complexity 622 | requires vigilence, sensibilities and care 623 | simplicity != ease/familiarity 624 | develop sensibilties around entanglement 625 | reliability tools don't care; just safety nets 626 | 627 | SIMPLICITY MADE EASY 628 | choose simple constructs 629 | it is the artifacts, not eh authoring 630 | create abstractions with simplicity as basis 631 | simplify problem space 632 | simplicity often means making more things, not fewer 633 | reap the benefits 634 | 635 | "Simplicity is the ultimate sophistication" - da Vini 636 | --------------------------------------------------------------------------------