DEV Community: Papa

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.

How we test our React-Native application with Appium

Andy Sherman — Fri, 06 Dec 2019 21:09:31 +0000

Where it all started

I know what you're thinking... "Oh boy, everyone's favorite phase of the software development life cycle: TESTING!". At least, that was my initial thought. However, proper testing is critical, especially when it comes to my current role in mobile development. When you are writing for an app that will hit the hands of thousands of people, you need to plan for all possible "what if"'s.

Since I began my job at Papa, the mobile testing was done by the engineers, by hand, every time. While it was getting us through our releases, it was obviously not going to be sustainable in the long term as the company continues to grow and features continue to be added. A colleague did some research in to automated testing, and I was then tasked with implementing her results.

Getting rolling with Appium

For anyone unfamiliar, Appium is an open source test automation framework for use with native, hybrid and mobile web apps. As we are building our app with React-Native, this was the clear front runner for our team. (For reference, I do all of my work on macOS) The installation of Appium is as easy as

npm install -g appium

After successfully doing that, all you then need to do is run the command appium and you'll have a local Appium server running on port 4723! It is in this window you'll be able to see all the output and logs from any tests you run.

Quick suggestion

I began my testing process exactly as described above, which does work fine, however if you are going to be writing extensive testing using Appium, I highly recommend you download the Appium desktop client. This will give you a dedicated window for the server, easier view and searching of the logs, among many other customization and capabilities.

Writing the tests

What is normally considered the most painful part of mobile testing is made a lot easier with Appium. The ability to set the desired capabilities of the test right up front allows you to customize the test to your needs and make sure you are testing exactly what you want to be testing. Now, Appium has a very long list of supported capability settings, which can be found here. The best thing you can do is to familiarize yourself with this list before you even get started so you save yourself some major headaches while testing.

Downsides

I know I know, I've been gushing so much over Appium you're probably assuming I work for them, but I don't. As much as their product has begun to make things easier for myself and my team, there is certainly plenty of room for improvement. I could write a whole separate post on that, but for now I'll leave you with my 2 biggest gripes:

Utilities

My biggest road block I ran in to throughout the process was that the app I am testing requires location permissions. The issue being that this notification always pops up before the app is fully loaded, so the built-in "handleAlert" functions are useless. I spent hours trying to track down a solution and settled on AppleSimulatorUtils, which allows you to set permissions for the simulator in the background and not have to rely on responding to alerts.

Sleeping

As far as I could find, there was no easy way to "slow down" Appium as it blasted through all of the test commands. Anyone who has worked in a simulator knows that sometimes they are a little slow and laggy. This often caused the tests to fail because Appium would click a button and then try clicking another one before the next screen had loaded. Appium does have the ability to wait for certain elements to be present before acting, however including the isElementDisplayed() after every screen transition could be a bit tiresome.

My solution was to write a simple sleep function and include that after each command, as it was a lot easier to reuse and adjust as needed, and didn't require the constant discovery of elementId's.

fin.

How Friday developer potlucks can help build stronger, happier engineering teams.

Sergio Tapia — Thu, 07 Nov 2019 01:14:20 +0000

Before joining Papa as director of engineering, I worked with plenty of different startups and mid-sized companies and I would receive these large features to build that would easily take two weeks to complete.

Heading out for the weekend knowing that I had this beast of a feature still there was demoralizing. I couldn't really enjoy my weekend. The beast always lingered there in the back of my mind.

A big part of my job at Papa is making sure our engineering team is happy, productive and unblocked. I always approach things from the angle of: "I've been in their shoes. What would I have liked back then?" and do my best to make their professional lives easier.

This is where I thought of the potluck idea.

Here's the problem:

You have large tasks to work on during the sprint.
Smaller bugs and annoyances pop up during a regular sprint.
These small things build up in your mind and you leave Friday worried about the small things and the unfinished big thing.

Here's the solution, our sprint potluck:

Every Friday after lunch, we take the rest of the afternoon to pick one item from our potluck list and do our best to knock it out.

This simple change brings a lot of benefits:

People go home with a feeling of accomplishment. A finished ticket no matter how small, is finished.
We whittle away at the long list of small annoyances.
People's brains can relax from thinking about that big incomplete thing for an afternoon and two days. Surprisingly, coming back to the large feature yields great results. The break does pay off!

Specifically, we use Clubhouse as our project management tool.

Collecting the small annoyance tickets

Each week we have one person on rotation to triage requests from head of departments in a Slack channel we call department-support.

We figure out:

Is this a real issue?
Is this request too out there and unreasonable?
Is this a feature or a bugfix?

Then we place it into Clubhouse in our Backlog project.

The day of the sprint potluck

We all meet over Zoom and go over each triaged ticket in the Backlog project. Every person on the team picks one ticket they think they can reasonably address during potluck.

We move each ticket into the potluck iteration (Clubhouses' fancy word for an agile sprint)

We feast

We all relax after a Friday lunch and tackle these smaller items with more levity and a fresh set of eyes.

What happens if someone doesn't finish their potluck ticket?

They can take Monday morning to finish it off, but if they can't it means that the ticket is a candidate to become a normal sprint ticket - and no longer potluck. We discuss when its a priority to add it to the sprint.

I'd love to hear your thoughts about our sprint potluck and also if your team has any other engineering rituals.

Thanks for reading!