Skip to content

Instantly share code, notes, and snippets.

View fnbk's full-sized avatar
💭
I may be slow to respond.

Florian Böhmak fnbk

💭
I may be slow to respond.
View GitHub Profile
@fnbk
fnbk / gist:5824679
Last active December 18, 2015 18:19
serve current directory tree at http://localhost:5000
$ python -m SimpleHTTPServer 5000
$ ruby -run -e httpd -- -p 5000 .
$ npm install -g http-server
$ http-server your-folder/
#!/bin/sh
curl \
--silent \
--verbose \
--include \
--http1.1 \
--request POST \
--header "Content-Type: text/xml; charset=utf-8; SOAPAction: \"http://service.smartadserver.com/PutInsertionOnline\";" \
--data @- \
@fnbk
fnbk / arm-template.json
Created March 4, 2019 09:13
Log file and ARM template for failed EventStore Service Upgrade in ServiceFabric
{
"authorization": {
"action": "Microsoft.ServiceFabric/clusters/write",
"scope": "xxx"
},
"caller": "xxx",
"channels": "Operation",
"claims": {},
"correlationId": "d09d7609-d41c-4c90-8593-c62be981e8a3",
"description": "",
@fnbk
fnbk / SLA exercise
Last active February 15, 2021 22:17
#
# SLA - Single Level of Abstraction
#
Within a certain method we look to keep all the code at the same level of abstraction to help us read it more easily. - Robert C. Martin
A helpful analogy is a newspaper article:
1) First comes is the most important thing – the heading. From this you should roughly know what the article is about.
2) The first sentence of the article describes it on a high level of abstraction.
@fnbk
fnbk / LOLA exercise
Last active February 15, 2021 22:16
#
# LOLA - Law of Leaky Abstraction
#
All abstractions are leaky. The outsider may need to know some insider information to use the abstraction.
An abstraction should not hide that which it abstracts, but rather simplify access to the underlying complexity. - Joel Spolsky
Example:
* Automobiles have abstractions for drivers: There is a steering wheel, accelerator and brake. This abstraction hides a lot of detail about what's under the hood: engine, cams, timing belt, spark plugs, radiator, etc.
@fnbk
fnbk / POMO Exercise
Last active February 15, 2021 22:15
#
# POMO - Principal of Mutual Oblivion
#
Two modules at the same level of abstraction should not know each other. ("mutual oblivion" - not knowing each other)
It is the independece of parts - no functional units knows another one. They are all completely independent of each other. - Ralf Westphal
Example - muscle movement in human bodies:
A nerve cell does not know anything about a muscle cell and a muscle cell does not know anything about a nerve cell. All they do is follow a simple contract: Acetylcholine (ACh) - one produces ACh as output, the other consumes ACh as input.
#
# SRP - Single Responsibility Principle
#
Each software module should have only one reason to change.
Gather together those things that change for the same reason, and separate those things that change for different reasons. - Robert C. Martin
Example:
@fnbk
fnbk / IOSP exercise
Last active February 15, 2021 22:09
#
# IOSP - Integration Operation Segregation Principle
#
Code is separated into functions of logic (operation) and non-logic (integration) - Ralf Westphal
IOSP calls for a clear separation:
* Operation: a method contains logic, transformations, control structures or API invocations
* Integration: a method only contains calls to other methods within its code base
#
# SoC - Separation of Concerns
#
Definition:
Order your thoughts by focusing on one aspect at a time, establish boundaries and organize the system into meanigful parts. - Edsger W. Dijkstra
Explanation:
Software development is a multidimensional discipline and it involves looking at different aspects simultaneously.
The idea of separating the different aspects of a problem allows us to solve one problem at a time and eases the process of reasoning. Isolating aspects also lets work to be postponed to a later time and allows collaboration to happen.
#
# CQS - Command Query Separation
#
# Definition
* Methods should either perform an action (command) or return data (query), but not both.
* Asking a question should not change the answer - Bertrand Meyer
We should aim to write our code in such a way that methods either do someting or give something back, not both:
* Command: perform an action (change the state of the system; write operations; with side effects)