(A book that I might eventually write!)
Gary Bernhardt
I imagine each of these chapters being about 2,000 words, making the whole book about the size of a small novel. For comparison, articles in large papers like the New York Times average about 1,200 words. Each topic gets whatever level of detail I can fit into that space. For simple topics, that's a lot of space: I can probably walk through a very basic, but working, implementation of the IP protocol.
| App configuration in environment variables: for and against | |
| For (some of these as per the 12 factor principles) | |
| 1) they are are easy to change between deploys without changing any code | |
| 2) unlike config files, there is little chance of them being checked | |
| into the code repo accidentally | |
| 3) unlike custom config files, or other config mechanisms such as Java |
I’ve been writing a load of Swift code recently for work and this has lead me into the world of typed functional programming. The app needs to build certain objects from a comma separated string, and this lead me to applicative functors, which lead me to brain ache but enlightenment. So here’s my thoughts on how I got to understand these a little better.
All of the code is in Swift, so less clean than Haskell. I’m also only a about 6 weeks into Swift development so I probably haven’t got all of the idioms right. I’ve avoided the optional shorthand wherever possible here, preferring Optional<Type> over Type? because I believe the latter is hiding something that helps understand this code in the context of other generic classes.
It’s also long! I think it’s probably the longest blog post I’ve ever written but I found it interesting and useful, for myself, to write. If you’re one of those people who skip to the end of a book to find out whodunit then I’ve included
__ _______ __ __ _____ _ _
\ \ / /_ _| \/ | _ / ____| | (_)
\ \ / / | | | \ / | _| |_ | | | | ___ _ _ _ _ __ ___
\ \/ / | | | |\/| | |_ _| | | | |/ _ \| | | | | '__/ _ \
\ / _| |_| | | | |_| | |____| | (_) | | |_| | | | __/
\/ |_____|_| |_| \_____|_|\___/| |\__,_|_| \___|
_/ |
|__/
This describes how I setup Atom for an ideal Clojure development workflow. This fixes indentation on newlines, handles parentheses, etc. The keybinding settings for enter (in keymap.cson) are important to get proper newlines with indentation at the right level. There are other helpers in init.coffee and keymap.cson that are useful for cutting, copying, pasting, deleting, and indenting Lisp expressions.
The Atom documentation is excellent. It's highly worth reading the flight manual.
If you have two days to learn the very basics of modelling, Domain-Driven Design, CQRS and Event Sourcing, here's what you should do:
In the evenings read the [Domain-Driven Design Quickly Minibook]{http://www.infoq.com/minibooks/domain-driven-design-quickly}. During the day watch following great videos (in this order):
Kafka acts as a kind of write-ahead log (WAL) that records messages to a persistent store (disk) and allows subscribers to read and apply these changes to their own stores in a system appropriate time-frame.
Terminology:
I'm currently the lead instructor at Code Platoon and an instructor/developer at the Turing School of Software and Design.
I've been advocating the Fish shell and when the choice is up to me, I choose that for my students. Enough people ask about the decision, particularly in relation to the preinstalled Bash shell, that I figured it's worth laying out my reasoning.