"If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything."
2017-05-18
Devoxx US 2017, Knowledge is Power: Getting out of trouble by understanding Git by Steve Smith
My notes on Devoxx US 2017, Knowledge is Power: Getting out of trouble by understanding Git by Steve Smith
"If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything."
"If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything."
GOTO 2016 - Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned - R. Meshenberg
My notes on GOTO 2016 - Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned - R. Meshenberg
They have a division making a layer of tools for other teams to build their stuff on top of it.
Exceptions for statelessness are persistence (of course) but also caching.
Destructive testing - Chaos monkey -> simian army - in production, all the time. (During office hours)
Their separation of concerns looks like a grid, not like a vertical or horizontal table.
They have open sourced many of their tools, we can find them at netflix.github.com
They have a division making a layer of tools for other teams to build their stuff on top of it.
Exceptions for statelessness are persistence (of course) but also caching.
Destructive testing - Chaos monkey -> simian army - in production, all the time. (During office hours)
Their separation of concerns looks like a grid, not like a vertical or horizontal table.
They have open sourced many of their tools, we can find them at netflix.github.com
GOTO 2015 - Progress Toward an Engineering Discipline of Software - Mary Shaw
My notes on GOTO 2015 - Progress Toward an Engineering Discipline of Software - Mary Shaw
Notes
17:28 past the bridges and into software engineering
Software Engineering is all design. Production used to be printing the CDs, and nowadays it is hitting the "deploy" button.
"scaling the costs to the consequences" -- the point is not to minimize the cost, the point is to scale it to the consequences. Risks must be taken, and if the potential gains are huge, then the risks can be correspondingly large.
Notes
17:28 past the bridges and into software engineering
Software Engineering is all design. Production used to be printing the CDs, and nowadays it is hitting the "deploy" button.
"scaling the costs to the consequences" -- the point is not to minimize the cost, the point is to scale it to the consequences. Risks must be taken, and if the potential gains are huge, then the risks can be correspondingly large.
GOTO 2015 - DDD & Microservices: At Last, Some Boundaries! - Eric Evans
My notes on GOTO 2015 - DDD & Microservices: At Last, Some Boundaries! - Eric Evans
Microservices and Netflix - what is the connection?
Isolated data stores
"A service is something that can consume messages and can produce messages"
Microservices and Netflix - what is the connection?
Isolated data stores
"A service is something that can consume messages and can produce messages"
GOTO 2014 - REST: I don't Think it Means What You Think it Does - Stefan Tilkov
My notes on GOTO 2014 - REST: I don't Think it Means What You Think it Does - Stefan Tilkov
"People decide they want to build something in a RESTful fashion, so they spend all their time arguing about where the slashes go".
"It is the first litmus test for your REST API whether you depend on specific characters in your URIs for things to work."
(From the client's point of view.)
"Version numbers in URIs just suck. Everybody does it which doesn't make it any less sucky. It is a stupid idea. Don't do that."
"The version number is in the URI because the URI is the API". <-- ? I would assume the URI is NOT the API.
Versioning: "Version your documentation documents. Wait what? --Yes, no versioning".
Postel's law "TCP implementations should follow a general principle of robustness: Be conservative in what you do, be liberal in what you accept from others." http://tools.ietf.org/html/rfc761
Client rules
Don't depend on URI structure
Support unknown links
Ignore unknown content
Server rules
Don't break URI structure unnecessarily
Evolve via additional resources
Support older formats
Discovery/Discoverability: "JSON Home" http://tools.ietf.org/html/draft-nottingham-json-home-03
Hypermedia APIs "give you flexibility", "are cool", "are neat" <-- no explanation
"Excellent question, do I know any examples of widely used public APIs that fully follow this model? No."
"People decide they want to build something in a RESTful fashion, so they spend all their time arguing about where the slashes go".
"It is the first litmus test for your REST API whether you depend on specific characters in your URIs for things to work."
(From the client's point of view.)
"Version numbers in URIs just suck. Everybody does it which doesn't make it any less sucky. It is a stupid idea. Don't do that."
"The version number is in the URI because the URI is the API". <-- ? I would assume the URI is NOT the API.
Versioning: "Version your documentation documents. Wait what? --Yes, no versioning".
Postel's law "TCP implementations should follow a general principle of robustness: Be conservative in what you do, be liberal in what you accept from others." http://tools.ietf.org/html/rfc761
Client rules
Don't depend on URI structure
Support unknown links
Ignore unknown content
Server rules
Don't break URI structure unnecessarily
Evolve via additional resources
Support older formats
Discovery/Discoverability: "JSON Home" http://tools.ietf.org/html/draft-nottingham-json-home-03
Hypermedia APIs "give you flexibility", "are cool", "are neat" <-- no explanation
"Excellent question, do I know any examples of widely used public APIs that fully follow this model? No."
Subscribe to:
Posts (Atom)