Forem: Alexander Oloo

From Developer to Design Director: 40 books

Alexander Oloo — Sun, 16 Aug 2020 04:00:00 +0000

Circa 2016 I started my journey into the land of experience design. The journey from frontend dev to design director has been one heck of adventure. I’ve been extremely lucky to have had some excellent mentors, managers, and sponsors along the way. This post is not about them, but rather the books that accompanied me along the way.

It all started when Phil threw down the gauntlet.

Needless to say, I didn’t finish them all in a year. And I still haven’t read them all. But it was the beginning of a great reading habit. If you’re not a reader (or listener) yet, I can’t recommend it enough. Here’s a list of the books I’ve read on my journey. They’ve all been been quite value in my career and development.

One last thing before the list. It’s a long list and will take you longer to read than you expect. You won’t remember everything you read. Some will be hard to read. You’ll get tired of reading. And feel like you’re not growing. All those things are okay. In the words of Josemaria Escriva:

“Don’t forget that, on earth, every big thing has had a small beginning. What is born big is monstrous and dies.”

Happy reading. Happy learning.

The List

Becoming a better leader

The Managers Path
The Five Dysfunctions of a team
Creativity Inc
The Three Signs of a Miserable Job
The Hard Thing about Hard Things
Multipliers
What You Do Is Who You are
Never Split the Difference
Non-violent communication
The Art of War
What to do when you become the boss

Expanding your thinking

Predictably Irrational
Thinking in Bets
Misbehaving
Thinking, Fast and Slow
Algorithms to Live By
Interior Freedom
Originals
How to Get People to Do Stuff
12 Rules for Life

Supercharging your UX

About Face
How to make Sense of any mess
Don’t Make me think
Lean UX

Designing better products

Zero to One
Competing Against Luck
Inspired
Hooked: How to Build Habit forming products
The Lean Startup
Lean vs Agile vs Design Thinking
The Service Startup
The Lean enterprise

Shipping quality products and software

The Phoenix Project
The Unicorn Project
Accelerate: Building and Scaling High Performing Teams.
Making work Visible

Telling better stories

Ted Talks
Story
Creating Character Arcs
The Silmarillion

May your build always pass.

Alex

Loading Google Credentials without .json

Alexander Oloo — Fri, 31 Jan 2020 04:00:00 +0000

I primarily use heroku to run my applications and Travis for CI/CD. I’m also currently giving Github Actions a try. So what do all those have in common? Well, for starters they have generous free tiers, but more importantly they’re not in the Google Cloud. Google cloud has some really nifty capabilities and so I end up using them pretty often. That’s where my problem started.

When you want to authenticate your application from outside the Google Cloud you need to read in a .json file that contains the service account information.

File credentialsPath = new File("/home/user/Downloads/[FILE_NAME].json");

export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/[FILE_NAME].json"

So we basically need to get this .json file into all our CI/CD pipelines and our application servers. Obviously we can’t store the credentials in git so we need to encrypt and upload the file. Admin!

alekcz/google-credentials solves exactly this problem. Your clojure app can now load credentials from an environment variable using alekcz/google-credentials.You need not keep that super secret .json file anymore. Copy its contents into the environment and delete the file!

And there you go. Nothing but net.

May your build always pass.

Alex

P.S. Rest in peace Kobe.

Fun with Clojure maps

Alexander Oloo — Mon, 09 Dec 2019 05:00:00 +0000

There was a time where I was working exclusively in clojure and using SSR for the frontend. It was a peaceful time. But alas peace doesn’t last for ever. And then I picked up a new full stack project. A project building a SPA.

And JSON said to me: “Peace has cost you your strength. Victory has defeated you”.

The hastle of parsing json Node was all too fresh in my memory. Would Clojure be different?

(def json { :action "link-profiles", 
            :data { :user "alekcz", 
                    :social { :github "https://github.com/alekcz" 
                              :twitter "https://twitter.com/alekcz"}}})

The first time I had to parse a json request I hit a quick google. I was still quite new to Clojure so most problems involved a quick google. And voilà.

So I tried get. And it was ridiculous

(get (get (get json :data) :social) :twitter)

And when something is unwieldy in Clojure there’s probably a more elegant way of doing it. You just need to be willing to look beyond the first google result.

(get-in json [:data :social :twitter])

Oh isn’t that nice. You gotta love the elegance. To be honest I thought that was as good as it got, until I stumbled across this gem. Turns out you can access data in a map using key like so:

(:data json)
; => {:user "alekcz", :social {:github "alekcz", :twitter "alekcz"}}

(:data nil) ; and doing this didn't crash anything.
; nil

It was like magic. Immediately it made me think of the thread-first macro. Maybe? Just maybe we could? Was it too good to be true? Surely not?

(-> json :data :social :twitter)
; => "https://twitter.com/alekcz"

Sublime.

May your build always pass.

Alex

This post is part of the “Advent of Parens”.

Clojure’s thread-first macro: ->

Alexander Oloo — Sun, 08 Dec 2019 07:00:00 +0000

Don’t you just hate functions with names that you can’t pronounce. I mean how do you pronounce -> ? On top of that, its name is not consistent across languages so learning it once is not a guarantee that you’ll know its name in another programming language.

In Clojure this, ->, is the thread-first macro. You’re welcome.

(-> x & forms)

"Threads the expr through the forms. Inserts x as the
second item in the first form, making a list of it if it is not a
list already. If there are more forms, inserts the first form as the
second item in second form, etc."

A super practical everyday example

To help us illustrate how the thread-first macro works we need a few functions

; let's set everything up
(def ws "wheat-seed")
(defn plant [seed field farm] (str seed "->planted"))
(defn harvest [plant farm] (str plant "->harvested"))
(defn grind [grain machine] (str grain "->ground"))
(defn prepare-dough [flour salt sugar olive-oil] (str flour "->prepared-dough"))   
(defn make-base [dough] (str dough "->made-base"))   
(defn add-toppings [base tomato cheese meat] (str base "->added-toppings"))
(defn bake [dough oven] (str dough "->baked"))
(defn enjoy [pizza] (str pizza "->enjoyed-macro-pizza"))

Now let’s get threading!

;Now lets make a macro pizza
(-> ws
    (plant "far-field" "Old McDonald's Farm") 
    (harvest "Old McDonald's Farm") 
    (grind "stone-mill")
    (prepare-dough "sea-salt" "white-sugar" "ev-olive-oil")
    (make-base)
    (add-toppings "rosa-tomatoes" "mozzarella" "ham")
    (bake "stone oven")
    (enjoy))

You’ll notice that each function in our pizza maker has one less argument than in its function definition. The first argument is handled by thread-first macro. The thread-first macro takes the output of ws and makes it the first argument of plant and makes the output plant the first argumemt of harvest. In other words it does this:

(harvest (plant ws "far-field" "Old McDonald's Farm") "Old McDonald's Farm")

And hence its name. It threads previous output as the first argument of the next function and continues doing so until it’s done.

The true benefit of the thread-first macro is that it can make code easier to read. You can do your future self a huge favour by using the thread-first macro. Using this macro coupled with naming your functions sensibly makes for code that is a pleasure to read and maintain.

Happy threading!

May your build always pass.

Alex

This post is part of the "Advent of Parens".

Clojure shootout: keep vs filter

Alexander Oloo — Sat, 07 Dec 2019 07:00:00 +0000

Oh no, it happened again
it’s time to filter or keep
you ponder for hours it’s so
you don’t know which way to go

It doesn’t really help that there are two clojure functions that do exactly the same thing. Isn’t that PHPs trademark? I’ve been burned by these twins. One of them is evil. One of them is good. Which is which?

Keep docs

(keep f) (keep f coll)

"Returns a lazy sequence of the non-nil results of (f item). Note,
this means false return values will be included. f must be free of
side-effects. Returns a transducer when no collection is provided."

Filter docs

(filter pred) (filter pred coll)

"Returns a lazy sequence of the items in coll for which
(pred item) returns logical true. pred must be free of side-effects.
Returns a transducer when no collection is provided."

From the docs we can see they have the same function signature, they’re both lazy, both live in clojure.core, they can both produce transducers, and both the applied functions must be free of side effects (yum, clojurey). But if you look a little closer there’s a gremlin waiting to hurt you…

Let’s try keep the odd numbers less than 10.

(keep odd? (range 10))
; => (false true false true false true false true false true)

That’s not ideal. keep told us which numbers to keep but didn’t give us the actual numbers. And this is where the gremlin lives. keep will return the result of applying to f to each element if and only if the result is not nil. f must then be written specifically to work as such. In others words you can’t reuse the transducer you’ve already written as is.

(keep #(if (odd? %) % false) (range 10))
; => (false 1 false 3 false 5 false 7 false 9)

; keep really needs that nil
(keep #(if (odd? %) % nil) (range 10))
; => (1 3 5 7 9)

; or more concisely (relying on the inner workings of if, eek)
(keep #(if (odd? %) %) (range 10))
; => (1 3 5 7 9)

And what does filter do? Exactly what you expect. And that, that is the right thing to do.

(filter odd? (range 10))
; => (1 3 5 7 9) 
; Yay!

No matter how whacky you get, it does what you expect.

; you shouldn't do this (not a predicate)
(filter #(if (odd? %) % false) (range 10))
; => (1 3 5 7 9)

; and definitely not this (not a predicate)
(filter #(if (odd? %) % nil) (range 10))
; => (1 3 5 7 9)

; and this is just plain odd (not a predicate)
(filter #(if (odd? %) %) (range 10))
; => (1 3 5 7 9)

Filter works even if your predicates are not predicates. Filter has your back either way. And when you’re building your confidence in a language, that’s important.

Filter what you don’t need. Keeping them is just plain weird.

May your build always pass.

Alex

This post is part of the "Advent of Parens".

* Predicates are functions that given a value return either true or false, based on their internal citeria

Gotcha! It’s the trailing slash

Alexander Oloo — Fri, 06 Dec 2019 07:00:00 +0000

You’ve discovered the Luminus framework. You’ve reached unparalleled levels of productivity. You can build a web app at the drop of a hat. You can’t believe no-one told you about this before. You’re life is perfect except for one small thing.

Every now and then an existing route returns a 404. It doesn’t make sense. The error only occurs some of the time. Should that even be possible? You want to pull you hair out…

GOTCHA! It’s the trailing slash!

Luminus relies on the awesome routing library by reitit. And reitit uses exact route matching. So /apply and /apply/ are two different routes. Therefore depending on how your end user enters the url, they may or may not get a 404.

Here’s how I fixed it:

(mount/defstate app
  ...
      (ring/routes
        (swagger-ui/create-swagger-ui-handler
          {:path "/swagger-ui"
           :url "/api/swagger.json"
           :config {:validator-url nil}})
        (ring/create-resource-handler
          {:path "/"})
        (wrap-content-type
          (wrap-webjars (constantly nil)))
        ; Here is it is => 
        (ring/redirect-trailing-slash-handler {:method :strip})
        ;<= and you're good to go
        (ring/create-default-handler
  ...

You can learn more about handling the trailing slash here.

May your build always pass.

Alex

This post is part of the "Advent of Parens".

Today’s post is late courtesy of our wonderful electricity provider Eskom. Loadshedding is the best!

Destructuring keys in clojure

Alexander Oloo — Thu, 05 Dec 2019 07:00:00 +0000

Oh, you think JSON is your ally? I do a lot work with JSON. So much so that my favourite library is a JSON parsing library (cheshire). The most tedious thing about working wiht JSON is pulling keys out of JSON objects over and over again.

Associative destructuring is the hero we need but don’t deserve. It’s syntactic sugar for extracting keys from an object in a way that makes code more readable. More readable code is more maintainable code. It’s made my life much easier.

Given the following map, that was created by parsing a JSON object using cheshire:

(def json-object {:fname "Alexander" :lname "Oloo" :handle "alekcz" :location "ZA"})

The standard approach to using data from within the map is as follows:

(defn twitter-link [user]
    (str "<a href='https://twitter.com/" (:handle user) "'>" (:fname user) " (@" (:handle user) ")</a>")))
(println (twitter-link json-object))
; => <a href='https://twitter.com/'>Alexander (@alekcz)</a>

But when we use associative destructuring we get:

(defn twitter-link [user]
    (let [{:keys [fname handle]} user]
        (str "<a href='https://twitter.com/" handle "'>" fname " (@" handle ")</a>")))
(println (twitter-link json-object))
; => <a href='https://twitter.com/'>Alexander (@alekcz)</a>

Isn’t that so much nicer? I think it is. It’s a pity I didn’t see transit until I was already a man.

May your build always pass.

Alex

This post is part of the "Advent of Parens".

My 5 favourite clojure libraries

Alexander Oloo — Wed, 04 Dec 2019 07:00:00 +0000

In my travels I have collected a set of clojure libraries that I can rely on to help me solve problems effectively. These are my top 5.

cheshire by @dakrone
http-kit by @shenfeng and maintained by @ptaoussanis
nippy by @ptaoussanis
at-at by @samaaron, @rosejn, and @michaelneale
charmander by @alekcz

1. cheshire

cheshire is a library for “JSON and JSON SMILE (binary json format) encoding/decoding”.

I’m currently using [cheshire "5.9.0"] successfully in production. My favourite thing about cheshire is that when parsing JSON it can automatically convert the keys to keywords in Clojure. I must admit I’ve abuse this feature in places where I probably shouldn’t have. Haha.

2. http-kit

http-kit is a “minimalist, event-driven, high-performance Clojure HTTP server/client library”.

I’m currently using [http-kit "2.4.0-alpha3"] successfully in production. #cowboy

My favourite thing about http-kit is that the HTTP client is really straight forward. Checkout the docs, you’ll see what I mean.

3. nippy

nippy is a “high-performance serialization library for Clojure”.

I’m currently using [com.taoensso/nippy "2.14.0"] successfully in production. My favourite thing about nippy (besides it being rediculously fast) is that after processing large datasets I can save the object straight from memory directly to disk. This allows my application to pick up instantaneously from where it left off after a reboot.

4. at-at

at-at is an “ahead-of-time function scheduler”.

I’m currently using [overtone/at-at "1.2.0"] successfully in production. My favourite trick with at-at is to use it to schedule a ping every 5 minutes to keep my dynos awake. Obviously I use http-kit to do the ping.

5. charmander

charmander is a “set of libraries to make working with firebase easier in clojure”.

I’m currently using [alekcz/charmander "0.6.0"] successfully in production.

My favourite thing about charmander is that it has been the project that has taught me the most about clojure. Writing it has been one heck of a journey.

May your build always pass.

Alex

This post is part of the "Advent of Parens".

Living Clojure

Alexander Oloo — Tue, 03 Dec 2019 07:00:00 +0000

There was a time where I was so fed up with lisps, Clojure, stack traces, and EOF errors. I was ready to go back to Node.js. And then I came a turning point. I stumbled across episode 29 of the Functional Geekery.

The episode was an interview with @gigasquid. It was entertaining and I learned a thing or two. And, and, she sounded like a normal human being. One who had had to work hard. I was energized. So after Functional Geekery, I looked for more podcasts with @gigasquid. There were a fair number of them. Living Clojure had just come out and so everyone was keen to chat about it. It was great fun. I even ended up buying the book. Those podcasts became my companions as devoured the other episodes.

Eventually, my travels led me to the Cognicast. It was amazing! There were close to 100 episodes (at the time). All relating to Clojure. On days when I was too tired to code, I listened to an episode of the Cognicast. Some days I would just listen to an episode for entertainment.

Alternating between coding, reading and listening turned out to be a great way to keep forward momentum. It was like I was truly living Clojure. The switching contexts also helped me deal with the frustration of learning a new skill, in an calm, entertaining and educational way.

Give it a try and lemme know how it goes for you. I’ll be on twitter. And remember when you get frustrated with Clojure, remember @gigasquid’s words: “Parens are like hugs for your code”. Do you really want to write code that’s deprived of hugs? Keep fighting the good fight. Keep living Clojure.

May your build always pass.

Alex

Podcasts on Living Clojure

This post is part of the "Advent of Parens".

I know. I know. We were supposed to chat about dealing with dodgy internet while trying to learn Clojure. It’s been one heck of a day so we’ll have to chat about that next week.

5 Tools for Getting Started with Clojure

Alexander Oloo — Mon, 02 Dec 2019 07:00:00 +0000

Greetings friend. Today we’re going to talk Clojure tools. And no, you don’t have to use emacs. There are many tools and they’re all slightly different. Which tools are the best? Well, you see, like everything else in programming, it depends. It depends on many things. And therein lies the difficulty. Since our aim is to make it easier for people to enter the Clojure community we’re going to evaluate our decisions on beginner friendliness.

A quick disclaimer: if your primary dev environment is Windows you’re in for a world of hurt. I’d strongly recommend getting your hands on a distribution of Unix. It’ll make it easier to get help online.

The 5 tools

To get started with Clojure you need 5 main tools.

An internet connection
A terminal
A Java SDK
A build tool
An editor

1. An internet connection

Let’s be honest, without internet there is very little you can do in tech these days. You’ll need internet to download libraries required for your project and to get help when you’re stuck.

The most of the time the libraries are small. The JavaSDK will be the primary data hog in the early days.

If you’re internet situation is dodgy, let chat ~tomorrow~ next week about some possible work arounds.

2. A terminal

The default one will do just fine. #winning

3. A Java SDK

Fortunately or unfortunately, depending on your point of view, Clojure requires Java. And yip there is more than one Java out there. From a beginner perspective, it’s almost irrelevant which one you pick.

Going with AdoptOpenJDK should create the least drama in your life. It’s free, open source, and supported by some big names such AWS, Microsoft, Red Hat, and IBM to name a few.

You can install AdoptOpenJDK on OSX like so:

$ brew cask install adoptopenjdk

And on Linux you can find the instructions for your distro here

If for some reason you ever need to pick a JVM, go with HotSpot. I have not idea which is better, but when in doubt and you have 0 expertise the beaten path is the way to go.

4. A build tool

It’s very possible to spend hours tinker with config and builds. In the beginning it’s very much shooting in the dark. Leiningen is easy and straightforward. So for now let’s go with that.

Leiningen is the easiest way to use Clojure. With a focus on project automation and declarative configuration, it gets out of your way and lets you focus on your code.

Here are some others:

An editor

For some obscure reason, editors are a particularly charged topic. We’re definitely not getting into that here. Today is a day of peace and tranquility. Unfortunatley, even with lens of beginner friendliness the choice of editor does not become easier.

The most important thing at this point is to pick an editor that feels comfortable. You’ll spend a lot of time in it so choose comfort.

Here are the top 5 most used editors from The State of Clojure 2019. Pick one:

Emacs
IntelliJ
Vim
VS Code
Atom

These 5 all have some plugins that make the particularly friendly to Clojure developers, but that is a discussion for another day.

A final note

All these recommendations are with the lens of beginner friendliness. As you work in Clojure some of these tools may no longer be fit for purpose and your preferences may change. So don’t get too attached. There are enough emacs zealots out there.

May your build always pass.

Alex

This post is part of the "Advent of Parens".

Advent of Parens

Alexander Oloo — Sun, 01 Dec 2019 07:00:00 +0000

A few days ago @plexus (civilian name: Arne Brasseur) shared a pretty cool idea on twitter: Write a blog post every day from the 1st of December to the 24th of December on somethings to do with Clojure. And so the “Advent of Parens” was born!

The Clojure community is filled with elegant code and really smart people. There are, however, very few beginner-friendly tutorials and the documentation is sparse. At times it can be quite intimidating and discouraging. It was so for me. Living Clojure by @gigasquid was the turning point. It was a very accessible introduction to Clojure.

I think accessible writing is critical for the Clojure community to flourish. That’s why I’m super excited about the “Advent of Parens”. I’m not sure I’ll manage all 24 days but I’ll try my absolute bestest. Catch you tomorrow.

May your build always pass.

Alex

Overtone: Music to keep my dynos awake

Alexander Oloo — Wed, 11 Sep 2019 19:00:00 +0000

In my earlier years, I worked with startups as well as the “idea guys” aka “Code this for me and I’ll give you equity in my idea”. So I quickly learnt to contain costs for each of the multiple ventures I was involved in.

I had many misadventures with nohup, upstart, and systemctl. My infrastructure of choice quickly became (and still is) Heroku. No frills. No nonsense. Just git push. They have a free plan that could go up to 1000 hours (there are at most 744 hours in a month). All you have to do was verify your account AKA add your credit card and you were right as rain.

“Verified accounts come with a monthly pool of 1000 Free dyno hours; unverified accounts receive 550.”

The only slightly annoying thing was that the dyno would sleep after 30 minutes of inactivity. It was more than slightly annoying. Every now and then you’d hit the site or the API and you’d have to cold start the JVM. Not on my watch!

I was pretty new to Clojure at the time and was pretty intimidated by all the complexity of scheduling libraries. So I figured that if I could find a music library (and there must be because Java) surely it would have a metronome or wave generator. And so I found overtone: the Open Source toolkit for designing synthesizers and collaborating with music.

After wading through the source code I found the timing part of the library: overtone.music.time. My approach was pretty straight forward. I’d run the interspaced function and ping the dyno every 5 minutes.

And so I sang to keep my dynos awake.

Here’s a REPL.

; in your REPL with [overtone "0.10.3"] as a depdency
keepawake.core => (use 'overtone.music.time)
keepawake.core => (defn ping! [] (println "HTTP GET request")) ; this would be the actual get request
keepawake.core => (interspaced 1000 ping!) ; this was originally 300000 milliseconds

Eventually, it dawned on me to just use overtone/at-at seeing as overtone.music.time was using it anyway.So these days at-at solves all my scheduling needs, while taking me down memory lane to a galaxy far, far away…

May your build always pass.

Alex

References

https://github.com/overtone/overtone
Reading source code in depth