MUST embrace failure: things are going to break, you might as well prepare for it

graphql is just part of the equation, if your resolvers get too complex, can introduce hystrix and push the complexity into other service

monitor at the function level (via hystrix dashboard)

adopt a consumer-driven mindset: the users have the money, don’t leave their money on the table by giving them a bad experience

force yourself to think about fallbacks

start thinking about the whole product: production issues LOOK to users like production features

question: do circuit-breakers introduce latency?

answer: a little bit at the upper end, once it’s been tripped

The Tensors Must Flow

works at magento, lives in philly

really wants to be sure our future robot masters are written in clojure, not python

guildsman: tensorflow library for clojure

tensorflow: ML lib from google, recently got a c api so other languages can call into it

spoiler alert: don’t get TOO excited. everything’s still a bit of a mess

but it DOES work, promise

note on architecture: the python client (from google) has access to a “cheater” api that isn’t part of the open c api. thus, there’s some things it can do that guildsman can’t because the api isn’t there

also: ye gods, there’s a lot of python in the python client. harder to port everything over to guildsman than he thought

very recently, tensorflow started shipping with a java layer built on top of a c++ lib (via jni), which itself sits on top of the tensorflow c api, some people have started building on top of that

gradient gap: guildsman can use either the clojure gradients, or the c++ ones, but not both at once

needs help to port the c++ ones over to clojure (please!)

“python occupies the 9th circle of dependency hell”: been using python lightly for years, and still has problems getting dependencies resolved (took a left turn at the virtual environment, started looking for my oculus rift)

From its title (“Google’s Ideological Echo Chamber”) to its claims that its author is the only human capable of rational thought without bias, to its assertion that modern feminist critique only exists because Communism failed, it’s filled with faulty logic and flawed arguments that wouldn’t have held water in any of the philosophy classes I took as a freshman.

It’s clearly a document meant to inflame, to incite, and most definitely not to encourage the kind of discussion the author claims over and over again to want to facilitate.

Let me be clear:

The gender pay gap is real. Its size varies across countries and industries, but it exists.

Studies of group decision-making show that those with a variation in viewpoints — particularly along gender lines — do better than those that lack such diversity.

Bias against women is long-standing in the technological fields, and should be combatted by any means necessary.

Feminism goes back a hell of a lot further than communism.

Claims of universal values for Left and Right ignore the historical context in which those labels arose, and how fluid the beliefs of the groups assigned those labels have been over time.

Affirmative-action programs are not “illegal discrimination”

Political correctness is the name commentators on the Right have given to an age-old phenomenon: politeness. Certain beliefs or expressions are always considered beyond the pale. Those expressions change over time. The recent trend in Western society has been to push insults of race or gender beyond the pale. This is not a new thing, it is not a new form of authoritarianism, it is not a symptom of a Fascist Left. It’s civilization. Rude people have always faced censure, and rightly so.

Finally, insisting that others are biased, while you are “biased” towards intellect and reason, is absurd. It’s a classic male power move. It denies your opponents any semblance of reason or thought. It’s dehumanizing. And it’s horseshit.

There are parts I absolutely love, like the strong typing, the baked-in matrix operations, and the support for multi-type dispatch.

Then there’s the pieces that seem incomplete. Like the documentation, which is very extensive, but proved useless when trying to find out the proper way to build dictionaries in the latest version. Or the package system, which will install things right into a running repl (cool!) but does it without getting your permission for all its dependencies (boo).

All in all, I’d like to build something more extensive in Julia. Preferably something ML-related, that I might normally build in Python.

Day One

can install with brew

book written for 0.3, newest version is 0.5

has a repl built in 🙂

typeof for types

“” for strings, ” only for single-chars

// when you want to divide and leave it divided (no float, keep the fraction)

has symbols

arrays are typed, but can contain more than one type (will switch from char to any, for example)

commas are required for lists, arrays, etc (boo)

tuples: fixed sized bags of values, typed according to what they hold

arrays carry around their dimensionality (will be important for matrix-type ops later on)

has dictionaries as well

hmm: typeof({:foo => 5}) -> vector syntax is discontinued

Dicts have to be explicitly built now: Dict(:foo => 5) is the equivalent

XOR operator with $

bits to see the binary of a value

can assign to multiple variables at once with commas (like python)

trying to access an undefined key in a dict throws an error

in can check membership of arrays or iterators, but not dictionaries

but: can check for key and value in dict using in + pair of key, value: in(:a => 1, explicit)

So frustrating. I had high hopes going in that Elixir might be my next server-side language of choice. It’s built on the Erlang VM, after all, so concurrency should be a breeze. Ditto distributed applications and fault-tolerance. All supposedly wrapped in a more digestible syntax than Erlang provides.

Boy, was I misled.

The syntax seems to be heavily Ruby-influenced, in a bad way. There’s magic methods, black box behavior, and OOP-style features built in everywhere.

The examples in this chapter go deeply into this Ruby-flavored world, and skip entirely over what I thought were the benefits to the language. If Elixir makes writing concurrent, distributed applications easier, I have no idea, because this book doesn’t bother working examples that highlight it.

Instead, the impression I get is that this is a way to write Ruby in Erlang, an attempt to push OOP concepts into the functional programming world, resulting in a hideous language that I wouldn’t touch with a ten-foot-pole.

I miss Elm.

Day One

biggest influences: lisp, erlang, ruby

need to install erlang *and* elixir

both available via brew

syntax changing quickly, it’s a young language

if do:

IO.puts for println

expressions in the repl always have a return value, even if it’s just :ok

looks like it has symbols, too (but they’re called atoms)

tuples: collections of fixed size

can use pattern matching to destructure tuples via assignment operator

doesn’t allow mutable state, but can look like it, because compiler will rename vars and shuffle things around for you if you assign something to price (say) multiple times

weird: “pipes” |> for threading macros

dots and parens only needed for anonymous functions (which can still be assigned to a variable)

prints out a warning if you redefine a module, but lets you do it

pattern matching for multiple functions definition in a single module (will run the version of the function that matches the inputs)

can define one module’s functions in terms of another’s

can use when conditions in function def as guards to regulate under what inputs the function will get run

scripting via .exs files, can run with iex

put_in returns an updated copy of the map, it doesn’t update the map in place

elixir’s lists are linked lists, not arrays!

char lists are not strings: dear god

so: is_list “string” -> false, but is_list ‘string’ -> true (!)

wat

pipe to append to the head

when destructuring a list, the number of items on each side have to match (unless you use the magic pipe)

can use _ for matching arbitrary item

Enum for processing lists (running arbitrary functions on them in different ways, like mapping and reducing, filtering, etc)

for comprehensions: a lot like python’s list comprehensions; takes a generator (basically ways to pull values from a list), an optional filter (filter which values from the list get used), and a function to run on the pulled values

elixir source is on github

Day Two

mix is built in to elixir, installing the language installs the build tool (nice)

basic project template includes a gitignore, a readme, and test files

source files go in lib, not src

struct: map with fixed set of fields, that you can add behavior to via functions…sounds like an object to me

iex -S mix to start iex with modules from your project

will throw compiler errors for unknown keys, which is nice, i guess?

since built on the erlang vm, but not erlang, we can use macros, which get expanded at compile time (presumably, to erlang code)

should is…well…kind of a silly macro

__using__ just to avoid a fully-qualified call seems…gross…and too implicit

Between the move and the election and the holidays, took me a long time to finish this chapter.

But I’m glad I did, because Elm is — dare I say — fun?

The error messages are fantastic. The syntax feels like Haskell without being as obtuse. Even the package management system just feels nice.

A sign of how much I liked working in Elm: the examples for Day Two and Three of the book were written for Elm 0.14, using a concept called signals. Unfortunately, signals were completely removed in Elm 0.17 (!). So to get the book examples working in Elm 0.18, I had to basically rebuild them. Which meant spending a lot of time with the (admittedly great) Elm tutorial and trial-and-erroring things until they worked again.

None of which I minded because, well, Elm is a great language to work in.

records look like they’re immutable now, when they weren’t before? code altering them in day one doesn’t work

parens around function calls are optional

infers types of function parameters

both left and right (!) function composition <| and |>

got map and filter based off the List type (?)

no special syntax for defining a function versus a regular variable, just set a name equal to the function body (with the function args before the equal sign)

head::tail pattern matching in function definition no longer works; elm is now stricter about requiring you to define all the possible inputs, including the empty list

elm is a curried language (!)

no reduce: foldr or foldl

have to paren the infix functions to use in foldr: List.foldr (*) 1 list

hard exercise seems to depend on elm being looser than it is; afaict, it won’t let you pass in a list of records with differing fields (type volation), nor will it let you try to access a field that isn’t there (another type violation)

Day Two

section is built around signals, which were removed in Elm 0.17 (!)

elm has actually deliberately moved away from FRP as a paradigm

looks like will need to completely rewrite the sample code for each one as we go…thankfully, there’s good examples in the elm docs (whew!)

You’re a nurse. You go in to interview for a new job at a hospital. You’re nervous, but confident you’ll get the job: you’ve got ten years of experience, and a glowing recommendation from your last hospital.

You get to the interview room. There must be a mistake, though. The room number they gave you is an operating room.

You go in anyway. The interviewer greets you, clipboard in hand. He tells you to scrub up, join the operation in progress.

“But I don’t know anything about this patient,” you say. “Or this hospital.”

They wave away your worries. “You’re a nurse, aren’t you? Get in there and prove it.”

….

You’re a therapist. You’ve spent years counseling couples, helping them come to grips with the flaws in their relationship.

You arrive for your interview with a new practice. They shake your hand, then take you into a room where two men are screaming at each other. Without introducing you, the interviewer pushes you forward.

“Fix them,” he whispers.

…

You’re a pilot, trying to get a better job at a rival airline. When you arrive at your interview, they whisk you onto a transatlantic flight and sit you in the captain’s chair.

“Fly us there,” they say.

…

You’re a software engineer. You’ve been doing it for ten years. You’ve seen tech fads come and go. You’ve worked for tiny startups, big companies, and everything in-between. Your last gig got acquired, which is why you’re looking for a new challenge.

The interviewers — there’s three of them, which makes you nervous — smile and shake your hand. After introducing themselves, they wave at the whiteboard behind you.

Each chapter covers a different language. They’re broken up into ‘Days’, with each day’s exercises digging deeper into the language.

Here’s what I learned about the first language in the book, Lua:

Day One

Just a dip into basic syntax.

table based

embeddable

whitespace doesn’t matter

no integers, only floating-point (!)

comparison operators will not coerce their arguments, so you can’t do =42 < ’43’

functions are first class

has tail-call-optimization (!)

extra args are ignored

omitted args just get nil

variables are global by default (!)

can use anything as key in table, including functions

array indexes start at 1 (!)

Day Two

Multithreading and OOP.

no multithreading, no threads at all

coroutines will only ever run on one core, so have to handle blocking and unblocking them manually

explicit over implicit, i guess?

since can use functions as values in tables, can build entire OO system from scratch using (self) passed in as first value to those functions

coroutines can also get you memoization, since yielding means the state of the fn is saved and resumed later

modules: can choose what gets exported, via another table at the bottom

Day Three

A very cool project — build a midi player in Lua with C++ interop — that was incredibly frustrating to get working. Nothing in the chapter was helpful. Learned more about C++ and Mac OS X audio than Lua.

had to add Homebrew’s Lua include directory (/usr/local/Cellar/lua/5.2.4_3/include) into include_directories command in CMakeLists.txt file

No, not my fondness for singing 80s country in a bad twang during karaoke.

I mean a real, nerd-world problem: I have too many books to read.

I can’t leave any bookstore without buying at least one. For a good bookstore, I’ll walk out with half a dozen or more, balancing them in my arms, hoping none of them fall over.

I get them home and try to squeeze them into my bookshelf of “books I have yet to read” (not to be confused with my “books I’ve read and need to donate” or “books I’ve read and will re-read someday when I have the time” shelves). That shelf is full, floor to ceiling.

My list of books to read is already too long for me to remember them all. And that’s not counting the ones I have sitting in ebook format, waiting on my Kobo or iPhone for me to tap their cover art and dive in.

Faced with so much reading material, so many good books waiting to be read, my question is this: What do I read next?

I could pick based on mood. But that usually means me sitting in front of my physical books, picking out the one that grabs me. I could pick based on which ones I’ve bought most recently, which would probably narrow things down to just my ebooks.

But I want to be able to choose from all of my books, physical and virtual, at any time.

It listens to my twitter stream for instructions. When I give it the right command, it pulls down my to-read shelf from Goodreads (yes, I put all of my books, real and electronic, into Goodreads. yes, it took much longer than I thought it would), ranks them in order of which ones I should read first, and then tweets back to me the top 3.