Simplicity

Simplicity is the art of hiding complexity

Rob Pike, "Simplicity is Complicated", dotGo 2015
(https://www.youtube.com/watch?v=rFejpH_tAHM)

Disabling the Group Policy Client Service in Windows

Scenario:

• You are an administrator on your machine.
• Your machine is either:
• In a Windows Domain, and you don't want the domain admins messing with it.
• Not in a Windows Domain, and you just don't want useless services running.

In this case, what you probably want to do is prevent the Group Policy Client Service from running on your machine.  Unfortunately, that's not a straightforward task to accomplish, because if you go to "services" and try to stop or disable this service, Windows doesn't let you.

Here is how to do it.

These instructions have worked for me on Windows 7; they might also work on other versions of windows.  If there is anything in these instructions that you don't quite understand, what it means is that these instructions are not for you;  don't try to follow them, you are going to wreck things.  Ignore this post, move on.

1. Using regedit go to HKLM\SYSTEM\CurrentControlSet\services\gpsvc and:
1. Change the owner to yourself.
2. Grant Administrators (not just you) full control.
3. Change the value of “Start” from “2” to “4”.
2. Now go to HKLM\SYSTEM\CurrentControlSet\Control\Winlogon\Notifications\Components\GPClient and:
1. Change the owner to yourself.
2. Grant Administrators (not just you) full control.
3. Delete the entire key. (Possibly after exporting it so as to have a backup.)
3. Restart your machine.

My notes on "Greg Young - The Long Sad History of Microservices"

Greg Young - The Long Sad History of Microservices
From the "Build Stuff" event of April 2017.

Talk begins at 9:45.

Highlights of the talk:

27:00 Placing a network between modules simply to enforce programmer discipline 

29:05 There is other levels of isolation I can go to. I can run a docker container per service. That's the coolest stuff right? What that means is I can make it work on my machine so I send my machine to production. 

29:52 Now, one thing that's very useful is I don't necessarily want to make this decision up front. And I don't necessarily want to make the same decision in dev as in production. I may want in dev to have a different way that we run things, why? because bringing up 19 docker containers on your laptop is not very much fun. I may prefer to host everything inside a single process to make debugging and such a lot easier when I am running on dev in my laptop. Whereas in production we may go off to multiple nodes. 

34:16 If you have maintenance windows, why are you working towards getting rid of your maintenance windows? Is this a business drive or is this you just being like C.V. driven development? 

My notes:

Unfortunately his shrieky voice makes him sound like he is bitching about things, which in a sense he is, but it would help his cause to deliver his criticism in a more palatable tone. Also, in order to make his point about microservices being nothing new he seems to disregard statelessness.

Resources referenced in the talk:

https://en.wikipedia.org/wiki/Queueing_theory

https://en.wikipedia.org/wiki/π-calculus

https://en.wikipedia.org/wiki/Actor_model

Leslie Lamport - Time, Clocks, and the Ordering of Events in a Distributed System
(available on the interwebz)

C.A.R. Hoare - Communicating Sequential Processes
(available on the interwebz)

Dear recruiter...

If you are a recruiter wishing to contact me with regards to some job opportunity, please read this.

Migrating a project from java 8 to java 9

Now that Java 9 is out, I decided to migrate to it my pet project, which is around 120K lines of java.

The first step is to just start compiling and running against jdk9, without using any of its features yet.

This is an account of the surprisingly few issues that I encountered during this first step and how I resolved them.

Issue #1: Object.finalize() has been deprecated.

A Hacker's Tale (With a Human Side)

Screenshot of Borland Turbo Debugger found on the interwebz, possibly the same version that I was using back then.

This is a hacking story from my University years. It ends with a nice bit about human qualities. 

Grumpy Posts

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.

Here is a list of them:

On UML (oh, do not get me started)

The Wild, Wild Web

On JUnit's random order of test method execution

On UUIDs and GUIDs

On scripting languages

Why Oracle sucks

The GWX (Get Windows 10) KB3035583 trojan horse

"By using this site, you agree to the use of cookies."

(The list will be extended as more posts are added.)

Rich Hickey - Simple Made Easy

"Simple Made Easy" presentation by Rich Hickey from the InfoQ Software Development Conference, recorded at Strangeloop 2011

Watch the presentation here: https://www.infoq.com/presentations/Simple-Made-Easy 

(the slideshow plays alongside with the video.)

My notes on the presentation:

"Simplicity is prerequisite for reliability" - Edsger W. Dijkstra

Simple vs. Complex, Easy vs. Hard

What is wrong with UUIDs and GUIDs

Introduction

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.

Great. Now, let me tell you why I hate UUIDs.

6 videos from TechSummit Amsterdam 2017 (Jun 1st)

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.

 

My notes on the Fielding Dissertation (REST)

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

YouTube: Roy T. Fielding: Understanding the REST Style

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

https://blog.michael.gr/2017/06/my-notes-on-fielding-dissertation-rest.html

On scripting languages

Foreword

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?

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"