An Ode to My Favorite Line of Elixir !

Adrian P. Dunston — Wed, 29 Jul 2020 16:00:11 +0000

Gather around, and I'll tell you the tale of my favorite line of code

A piece of advice, I thought it concise to bequeath in the form of an ode

|> IO.inspect(label: "!!ADRIAN #{__ENV__.file}:#{__ENV__.line}", pretty: true)

Pipes

We'll start with a pipe |> a wondrous device, feeds one call's return to another

Without such a token, our code would look broken, its calls piled up in a smother.

text_of_poem = "One fish\nTwo fish\nRed fish\nBlue fish"

# Without pipes
Enum.count(String.split(text_of_poem, "\n"))

# ==> 4

First argument in, next function begins; you can see at a glance it looks cleaner

Make functions designed with piped-calls in mind; Your test suite is sure to run greener

# With pipes
text_of_poem
|> String.split("\n")
|> Enum.count()

# ==> 4

Inspect

Now let us reflect on humble inspect/2, a device indescribably lucid

If your bug's a big stinker that's stuck in your thinker, inspect/2 makes it jump as if goose-ed

# Convert data structure to readable string
quoth = %{raven: "nevermore"}
inspect(quoth)

# ==> "%{raven: \"nevermore\"}"

inspect/2 by itself is more than a help, it converts any data to string form

And with option pretty, the output's less bitty; Your brain has more room for a brainstorm

quoth = %{raven: ["nevermore", "nevermore", "nevermore"], 
    poe: "Take thy form from off my door!"}

inspect(quoth) |> IO.puts()

# 👀%{poe: "Take thy form from off my door!", raven: ["nevermore", "nevermore", "nevermore"]}
# ==> :ok

# The pretty: true option gives us more readable spacing.
inspect(quoth, **pretty: true**) |> IO.puts()

# 👀%{
#    poe: "Take thy form from off my door!",
#    raven: ["nevermore", "nevermore", "nevermore"]
#   }
# ==> :ok

IO.inspect

IO.inspect/2 has dual effects, first it needs not a puts/1 to be candid,

The second more subtle, not run in a bubble, this function returns what it's handed

IO.inspect(quote)

# 👀%{raven: "nevermore"}
# ==> %{raven: "nevermore"}

# Inspection without interference!
text_of_poem
|> String.split("\n")
|> IO.inspect()
|> Enum.count()

# 👀["One fish", "Two fish", "Red fish", "Blue fish"]
# ==> 4

Now let's look at :label; It's part of the stable of options inspect/2 can make use of

ID your inspections for further reflection on whatever info's elusive

text_of_poem
|> IO.inspect(label: "Before split")
|> String.split("\n")
|> IO.inspect(label: "After split")
|> Enum.count()

# 👀Before split: "One fish\nTwo fish\nRed fish\nBlue fish"
# 👀After split: ["One fish", "Two fish", "Red fish", "Blue fish"]
# ==> 4

Calling Card

Now IO.inspect\2's not a thing to forget when your feature is primed for submission,

When you fit-and-finish, prestige will diminish with inspect lines as part of commission

Remind to remove and avoid such reprove with calling-card text you're alert to

Make it unique, add your mystique, and before you commit do a search-through

#!!ADRIAN - debug lines easier to spot in console
# Remember to grep and remove !!ADRIAN lines before you push

text_of_poem
|> IO.inspect(label: "!!ADRIAN Before split")
|> String.split("\n")
|> IO.inspect(label: "!!ADRIAN After split")
|> Enum.count()

# 👀!!ADRIAN Before split: "One fish\nTwo fish\nRed fish\nBlue fish"
# 👀!!ADRIAN After split: ["One fish", "Two fish", "Red fish", "Blue fish"]
# ==> 4

ENV file and line

Final reflection on one-line perfection confesses the fact that I'm slothful.

It feels such a bother, each label to author; is cutting and pasting so awful?

Now in walks dear ENV, our quite astute friend; she knows both the file and line number

With this pal in hand, inspect can be canned; and attention advance unencumbered

1  text_of_poem
2  |> IO.inspect(label: "!!ADRIAN #{__ENV__.file}:#{__ENV__.line}", pretty: true)
3  |> String.split("\n")
4  |> IO.inspect(label: "!!ADRIAN #{__ENV__.file}:#{__ENV__.line}", pretty: true)
5  |> Enum.count()

# 👀!!ADRIAN example.ex:2: "One fish\nTwo fish\nRed fish\nBlue fish"
# 👀!!ADRIAN example.ex:4: ["One fish", "Two fish", "Red fish", "Blue fish"]
# ==> 4

Coda - Clipboard Extension Tools

I hope you've admired this line so inspired by the folks who have taught me before,

And with your indulgence, I've one more divulgence, a quirk that can quickly be yours

Clipboard extension is carapal prevention; it works by saving you typing

Along with your copies, it pastes pre-typed drop-ins, so coding continues like lightning!

Ditto Clipboard Extension for Windows
https://www.microsoft.com/en-us/p/ditto-clipboard/9nblggh3zbjq

Clipy Clipboard Extension for Mac
https://github.com/Clipy/Clipy

Have a Calling Card - Putting your personal stamp on things left undone

Adrian P. Dunston — Mon, 27 Jul 2020 14:08:35 +0000

When I'm writing/changing software, and I write something that I know I don't want to go out to production, I put a comment with the string !!ADRIAN in it. Before I commit/push/deploy (depending on the situation), I do a full-text-search for that string. Wherever I find it, I fix it.

This has improved my life in ways beyond measure. It's easy to understand and easy to do, so it's one of the first pieces of advice I give to newer programmers:

Invent a personal calling card
Leave it as a comment wherever you are leaving something unfinished
Search for it before you turn in your work

Why?

So you finish what you intend to. The ability to make your intentions real in the world is the definition of power. Software is complicated. Your mind (while very impressive) is limited. We use tools to leverage the power of our mind. This simple tool gives you more power over software.

How?

Pick something unique to you. TODO doesn't cut it. You'll probably be working in a team soon (if not already). TODO is everyone's responsibility, so it's no one's responsibility. !!ADRIAN claims something as my responsibility. I'm generally the only Adrian on a team. Pick something that no one else will use. When I suggested this to a colleague, he immediately started using 🚨. Brilliant. I would never have thought of that. (I'm still not used to the fact that my editor understand emoji.) If someone else starts using it, my colleague may want to put his initials on it, but let's not go solving tomorrow's problems.

Pick something agreeable. Agreeability is not always the right choice, but here it is. Sometimes you'll forget to search. Seeing your calling-card in production code will be mildly embarrassing, and that's fine. We develop with our feelings. You don't want to exacerbate that by having a calling card that is additionally embarrassing. In general, don't write swears, and try to keep it positive.

Pick something that indicates a problem. Seeing !! , it's easy for other developers to infer that the comment indicates something is wrong or unfinished. 🚨 accomplishes the same thing.

Pick something easy to write. My fingers type #!!ADRIAN automatically now. It's also in certain debug lines I'm always pasting in. My colleague knows how to make an 🚨 appear with a few keystrokes. You may want to use a clipboard manager.

Do the search at the end. I encourage you to have an actual checklist you run through before turning in any work. I have a checklist for fit and finish. It includes searching for #!!ADRIAN and @tag :wip, two artifacts I often leave behind in Elixir development. Your checklist is up to you, but I recommend having one, and I recommend "search for calling card" be on it.

What about the rest of the team?

You use this tool. See if it works for you. If so, suggest it to your closest teammates and then to the rest of the team. Socializing tools helps those around you, and teaching helps you learn. But ultimately, this is an individual tool. It will help you regardless of who else adopts it.

What about you?

Thanks for reading. If you start using this or have been, I'd love to hear it. Feel free to reach out and let me know your calling card or any fun stories from leaving one behind.

DEV Community: Adrian P. Dunston