2017-05-23

My notes on a youtube video about Roy T. Fielding

  • A youtube videoclip titled "Roy T. Fielding: Understanding the REST Style"

------------------------------------------------

These are my notes on "Roy T. Fielding: Understanding the REST Style" youtube videoclip:




No technical information.

"It's really an accessible piece of work.  It is not full of equations.  There is one equation.  The equation is there just to have an equation, by the way."

2017-05-21

On scripting languages

Michael Belivanakis 2017



Note: this is a first draft. It will be heavily edited. It may contain statements that are inaccurate or just plain wrong. It may also contain language that is inappropriate. There are bound to be corrections after I receive some feedback.



Historically, the difference between scripting languages and "real" programming languages has been thought of as being the presence or absence of a compilation step. However, from time to time we have seen interpreters for compiled languages, and we have also seen compilers for languages that were thought of as scripting languages. Furthermore, some scripting engines today internally compile to bytecode, and some even to machine code, while many compiled languages are compiled to bytecode instead of machine code, and this bytecode is at times interpreted. So, compiled vs. interpreted does seem to be the real differentiating factor between real programming languages and scripting languages. Nonetheless, we can usually tell a scripting language when we see one. So, what is it that we see?

2017-05-18

Devoxx 2016 Belgium - Microservices Evolution: How to break your monolithic database by Edson Yanaga

My notes on Devoxx 2016 Belgium - Microservices Evolution: How to break your monolithic database by Edson Yanaga (I attended this conference)



Reduce maintenance window
Achieve zero downtime deployments
"Code is easy, state is hard"
Changes in a database schema from one version to another are called database migrations
Tools: Flyweight Liquibase
Migrations require back and forward compatibility
Baby steps = Smallest Possible Batch Size
Too many rows = Long Locks
Shard your updates (not updating the entire table in one go)

Renaming a column
    ALTER TABLE customers RENAME COLUMN wrong TO correct;
   becomes:
        ALTER TABLE customers ADD COLUMN correct VARCHAR(20);
   UPDATE customers SET correct = wrong WHERE id < 100;
   UPDATE customers SET correct = wrong WHERE id >= 100 AND id < 200;
   ...
   (later) ALTER TABLE customers DELETE COLUMN wrong;

Adding a column
ADD COLUMN, setting NULL/DEFAULT value/computed value
Next release: Use Column

Renaming / Changeing Type / Format of a Column:
Next version: ADD COLUMN, Copy data using small shards
Next release: Code reads from old column and writes to both
Next release: Code reads from new column and writes to both
Next release: Code reads and writes from new column
Next release: Delete old column

Deleting a column
    Next version: Stop using the column but keep updating the column
Next version: Delete the column

For migrating from a monolithic application with a monolithic database to many microservices with own database each:
    Using Event Sourcing
        tool: debezium.io
    You tell it which tables you want to monitor, and from then on it monitors them
and generates an event for each DDL/DML statement you issue.
The event is propagated to as many event consumers as you want.
So, microservices can receive these events and update their own databases.

"HTTP and REST are incredibly slow"


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."

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

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.


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"

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."

GΟΤΟ 2014 - Microservices - Martin Fowler

My notes on GΟΤΟ 2014 - Microservices - Martin Fowler


Characteristics of Microservices

1. Componentization
2. Organized around business capabilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary Design

With services we typically use some kind of interprocess communication facilities such as web service calls or messaging or something of that kind.

How big should a microservice be?
    "It should have one responsibility" --too vague
"It should fit in my head" --fairly good

"You should not have a team that you cannot feed with 2 pizzas"