Besides the delicate grumpiness which is gratuitously scattered throughout this blog like the golden rays of light in a gentle sunset, there exist a few blog posts which have been written with the express purpose of venting out some major grumpiness.
Universally Unique Identifiers (UUIDs) otherwise known as Globally Unique
Identifiers (GUIDs) are 128-bit numbers that are often used to identify
information. In its canonical representation, a UUID looks like this:
2205cf3e-139c-4abc-be2d-e29b692934b0.
The Wikipedia entry for Universally Unique Identifier (⬀) says that they are for practical purposes unique and
that
while the probability that a UUID will be duplicated is not zero, it is
so close to zero as to be negligible. Wikipedia then does the math and shows that if 103 trillion
UUIDs are generated, the chance of duplication among them is one in a
billion.
Despite the infinitesimally small chances of receiving a duplicate UUID, there
exist programmers out there who are afraid of this actually happening, and who
will not hesitate to suspect duplicate UUIDs as being responsible for an observed malfunction rather than first look for a bug in
their code. Clearly, these folks do not understand the meaning of
infinitesimally small chance, so let me try to explain it:
Infinitessimally small chance means practically impossible to happen, and the practically part is only mentioned for scientific correctness: practically, you can disregard the word practically and consider it as simply impossible to happen.
A couple of weeks ago
some of us went to the TechSummit conference organized by LeaseWeb.Here is a list of the talks that I attended, along
with a short description for each.
The first presentation
was “Shaving my head made me a better programmer” by Alex Qin, which was about
what it is like to be a woman, and specifically a programmer, in the U.S. tech
industry. (And in the University before
that.)She talked about the inequality,
the sexism, and the harassment.She
mentioned that she once gave a talk in a really big conference about
accessibility in the U.S., and afterwards she was asked “How do I talk to women
at bars?” The head-shaving part refers
to how changing her appearance resulted in being taken more seriously. It was quite an interesting talk, though I suspect
that in Amsterdam, she was to a large extent preaching to the choir.
These are my notes on Roy T. Fielding's famous Ph.D. dissertation "Architectural Styles and the Design of Network-based Software Architecture"
What follows are excerpts from the dissertation, with my notes usually in parentheses.
Roy Thomas Fielding is: chief Scientist in some tech company; Chairman, Apache Software Foundation; Visiting Scholar, W3C @ MIT CS Lab; etc; Publications, Honors, Awards, Fellowships etc. Involved in the authoring of the Internet standards for the Hypertext Transfer Protocol (HTTP) and Uniform Resource Identifiers (URI).
Abstract:
"The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia system."
(He makes it sound as if it was designed this way on purpose.)
"In order to identify [...] aspects of the Web that needed improvement and avoid undesirable modifications, a model for the modern Web architecture was needed to guide its design, definition, and deployment."
(So, he admits the need to build a model after the fact.)
"An architectural style is a named, coordinated set of architectural constraints."
A youtube videoclip titled "Roy T. Fielding: Understanding the REST Style"
Quote: "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."
For my notes on REST, see other post: "My notes on the Fielding Dissertation (REST)"
Historically, the difference between scripting languages and real programming
languages has been understood as the presence or absence of a compilation
step. However, in recent decades the distinction has blurred; from time to
time we have seen:
Interpreters for languages that were originally meant to be compiled.
Compilers for languages that were originally meant to be interpreted.
Scripting engines internally converting source code to bytecode before
interpreting it.
Real languages compiling to bytecode which is then mostly interpreted and
rarely converted to machine code.
So, compiled vs. interpreted does not seem to be the real differentiating
factor; nonetheless, we can usually tell a scripting language when we see one.
So, what is it that we see?
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"
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."
