Uncle Bob, the well known author of Clean Code, is coming back to us with a new book called Clean Architecture which wants to take a larger view on how to create software.
Even if Clean Code is one of the major book around OOP and code design (mainly by presenting the SOLID principles), I was not totally impressed by the book.
Clean Architecture leaves me with the same feeling, even if it's pushing the development world to do better, has some good stories and present robust principles to build software.
The book is build around 34 chapters organised in chapters.
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
We use infrastructure secrets to encrypt sensitive data, deploy cloud instances, remotely log in and administer systems.
In order to add simplicity and security to infrastructure secret management we are testing the yubikey 4 nano.
NOTE: with the yubikey 4 nano I have noted that ykpersonalize -m1 (CCID mode only) does not seem to have an effect.. Look into this!!! it is annoying mis-firing OTP.
| const I = x => x | |
| const K = x => y => x | |
| const A = f => x => f (x) | |
| const T = x => f => f (x) | |
| const W = f => x => f (x) (x) | |
| const C = f => y => x => f (x) (y) | |
| const B = f => g => x => f (g (x)) | |
| const S = f => g => x => f (x) (g (x)) | |
| const S_ = f => g => x => f (g (x)) (x) | |
| const S2 = f => g => h => x => f (g (x)) (h (x)) |
- Download and install VirtualBox.
- Download the CoreOS ISO
- Create a new VM in VirtualBox
- For the OS, Other Linux, 64-bit should be fine
- Give the VM 1gb of memory, like your physical hardware has.
- Create a disk of whatever size you want. I made a VMDK file that could expand dynamically up to 8gb.
- Mount the ISO in the VM
- Right click on the VM and click settings
- Go to the storage tab
| require 'mkmf' | |
| create_makefile('shellcode') |
| # Bulk convert shapefiles to geojson using ogr2ogr | |
| # For more information, see http://ben.balter.com/2013/06/26/how-to-convert-shapefiles-to-geojson-for-use-on-github/ | |
| # Note: Assumes you're in a folder with one or more zip files containing shape files | |
| # and Outputs as geojson with the crs:84 SRS (for use on GitHub or elsewhere) | |
| #geojson conversion | |
| function shp2geojson() { | |
| ogr2ogr -f GeoJSON -t_srs crs:84 "$1.geojson" "$1.shp" | |
| } |