rockyourcode: Notes on ”Advice for Your First Dev Role”, Notes on “How to Become a Better Developer With Nacho Iacovino“, Notes on “Enterprise Architecture Patterns“, Notes on “Ramping Up at Your First Developer Job”, Receive Webhooks via ifttt, TIL: GitHub Actions on cron Job Might Be Late, My Git Aliases And Abbreviations

Hello 👋! Thanks for subscribing.

Here are the articles from last week:

Notes on ”Advice for Your First Dev Role”

Published on: 2021-06-14

tags: Notes, Lab

Virtual Coffee is a remote community for developers that aim to support each other.
They offer "brown bags" which are talks and discussions about a specific topic.

Here are my notes from Advice for your first dev role by Bryan Healey:

Remember that there will be a ramp-up period. You should take the time to talk to other engineers in your team.
Learn about the tooling stack as soon as possible.
Talk to your manager regularly.

Keep in mind what you want to achieve in a year, 5 years, etc. Be proactive. Don't wait for tasks to come to you — gradually ask for more complex tasks. Take ownership.

Many juniors try to jump in and contribute at scale. That hinders them from seeking help, and opening a dialog. Having a "set of fresh eyes" is valuable for a company.

Bryan looks for continuous contributions on an escalating scale. He doesn't expect a junior to contribute major features right away.

Good engineers should be comfortable with asking questions as its part of the process.
A functional team will collaborate and discuss, so your questions should be welcomed, too.

When should you ask questions? As a beginner, don't spend too much time on trouble-shooting. Nobody gains much when you try to solve a problem yourself that could be solved faster by asking for help.
Rule of thumb: don't spend more than 30 minutes banging your head against the wall.

When you start a new job, there is a "grace period" where everyone expects you to ask questions. Build trust by doing your due diligence (take notes, learn, listen for feedback, etc.).

Also remember that seniors developers can learn from you.

Bryan hires junior developers for their personality, creativity, problem-solving, not for their technical skills. He looks for people that can push the team. He doesn't care about failure, not delivering things.
Don't be quiet, be part of the team.

Links

• Advice for your first dev role – Bryan Healey – Virtual Coffee Brownbag
• Bryan Healey's website and Twitter account
• Virtual Coffee

image credit: Marvin Meyer

Notes on “How to Become a Better Developer With Nacho Iacovino“

Published on: 2021-06-13

tags: Notes, Lab

Notes from the Twitch stream with Francesco Ciulla and Nacho Iacovino (1 hour 17 mins):

Nacho Iacovino is a self-taught developer from Spain who grew his Twitter account in a short time.

Here are some tips that he shared.

Coding interviews: He learned from each interview. Even if you can't answer a question, you can go home, research, and then you can answer the question on the next interview. It's a process.
You also need to interview the company.

Marketing/Followers: Nacho made some useful Twitter threads and pinged the influential Twitter accounts for feedback (no spam, no selling, add value), hit a niche (Tailwind CSS).
Engage with bigger account. Add value to other people's tweets. Use common sense.
Choose one platform and be consistent.

Becoming a better developer: He quit JavaScript twice before he managed to become a developer full-time. Be consistent. You might not have 6 hours a day to learn to code, but at least do a little bit every day.
Find the best way that works for you (video, tutorials, books).
Don't copy a tutorial verbatim, try to experiment, embrace breaking the application and find out how to fix it. Challenge yourself.

Portfolio: Show what you're capable of. Udemy project clones are dimes and dozens, make it your own. Make it easy for others to contact you.
Show the newest work first. Be concise. Say where you're based, so it's easy to see if the company can hire you.

Learn in Public: Nacho shared what he learned publicly on Twitter. People were reaching out to him, because they knew what he learned.
Be your own teacher. What you write down you can use later.

Links

• How to become a better Developer | with Nacho Iacovino on Francesco Ciulla's YouTube channel

Notes on “Enterprise Architecture Patterns“

Published on: 2021-06-12

tags: Lab, Notes

The goal of the workshop is to learn the mental models and patterns to reduce complexity in software development.

The principles from the course are framework-agnostic, but the teacher uses examples from Angular.

(I found the concepts front-end centric. That's unsurprising as the course platform targets front-end developers).

What are "enterprise patterns"?

The core problem across all enterprise software is complexity. We strive to solve complexity by diligently applying first principles.

If you run into a problem, it's tempting to blame it on the framework. More often than not, the problem stems from a problematic implementation. Simplify the architecture to solve the root cause.

Complexity

Out of the Tar Pit by Ben Moseley and Peter Marks ¹:

We believe that the major contributor to this complexity in many systems is the handling of state and the burden that this adds when trying to analyse and reason about the system. Other closely related contributors are code volume, and explicit concern with the flow of control through the system.

Look at the code:

• Can I know the result of this code at all times?
• Can I reuse the code?
• Can I test this code?

It is impossible to write good tests for bad code.

The friction to testing is high because you must write testable code.

The Axis of Evil:

• hidden state
• violating the Single Responsibility Principle
• nested logic

Solve via dependency injection and method extraction.

Aim for fine-grained code.

Four Elements of Programming

1. Describing things (nouns, data structures)
2. Performing Actions (verbs)
3. Making Decisions (conditions)
4. Repeating (iterators)

Object Modeling as Nouns

Take the time to properly model the domain.

Use (TypeScript) interfaces to communicate your intent.

State is a data structure.

Methods as Verbs

Managing Flow Control

Identify the things that are conventionally equivalent, and optimize/automate them.

Find the things that are not conventionally equivalent (UI, business logic), and focus 95% of your time on that.

Collections & Iterators

Prefer higher order functions (declarative vs. imperative approach).

Prefer immutability.

Use the flux pattern.

The Fifth Element of Programming

• Time Management
• Observables: encapsulate, transport_ and transform data from user interactions
• combines Iterator and Observer pattern ²
• Observable streams: initial output -> final input

Distributed Complexity

• create space between interactions and effects (when using the Redux pattern: actions)
• thin components
• example: create stateless front-end application with web sockets and server-side state

Links

• Enterprise Architecture Patterns by Łukasz Ruebbelke
• Out of the Tar Pit by Ben Moseley and Peter Marks
• An introduction to the Flux architectural pattern
• Two Fundamental Abstractions by André Staltz
• JavaScript Getter-Setter Pyramid by André Staltz

image credit: Stefan Cosma

Notes on “Ramping Up at Your First Developer Job”

Published on: 2021-06-11

tags: Notes, Lab

The talk WebOfficeHours - Ramping Up at Your First Developer Job by Mark Noonan is a 1-hour video with useful info for junior developers.

Here are my condensed notes:

First Week on the Job

• tedious computer setup using skills you never need in any other situation
• take notes for the next person

Imposter Syndrome

• remember they hired you on purpose

Communication

• you might get trained on some of the stuff you'll need to do in your job
• BUT: people have no idea what other people have told you or not yet, so they might assume that you know XYZ, when nobody told you about it

Social Circle

• figure out what everybody does and where you fit
• smaller vs bigger team: in bigger teams there are more layers
• in quickly moving teams: it's still not expected that you magically produce work, but you might have to stand up for yourself

Learning a New Codebase

• take a look at the most recent commits/work

Git (Version Control) && Jira (Ticketing System)

• the culture of how Git is used is often different (and might not be documented)
• make sure to ask how to approach version control
• workflows are always different: ask

Be a Little Cynical

• make sure that others see your effort
• don't get stuck even on the things you were hired to do

Asking for Help Is a Superpower

Managing Frustration Is Your Job

• working as a developer is often hard
• learn how to be patient

Debugging

• learn how to debug (inspector, dev tools, break points)

Make a Lot of Notes

• ask a lot of questions

Don't Be Too Shy in Meetings

• it's ok to mostly hang back in meetings, but say at least one thing if you can

Carving Out "Your Job"

• try to find the things you're good at

You Can Do Anything if You Have Enough Time

• your motivation for asking for help is not that you can't get it to work — it's that it's not worth your time to spend too much time on learning all the stuff
• you will often need to work on something that you haven't worked on before

Links

• WebOfficeHours - Ramping Up at Your First Developer Job by Mark Noonan
• How to ask good questions by Julia Evans

Receive Webhooks via ifttt

Published on: 2021-06-10

tags: DevTools, TIL

ifttt is a no-code/low-code tool for automation.

You can chain trigger events ("if someone tweets a new tweet with the hash-tag coding") to commands ("then send me an email").

My goal was to receive a webhook event, so that I can send an email.

I create my newsletter via buttondown.email. I have a script that creates a new newsletter draft from my blog posts via GitHub actions.

Everything happens automatically.

When a new draft drops, I want to receive a notification. Buttondown has a webhooks API that can send POST requests to an endpoint — for example, to ifttt.

You have to create a new ifttt "recipe" with the webhooks trigger.

In your ifttt webhooks settings, you will see an URL that looks like this:

https://maker.ifttt.com/use/<some-random-string>

I need to tell buttondown.email to send a webhooks request to that URL.

But the correct URL is different than the one shown in the ifttt UI.

You'll need to chain it like this:

https://maker.ifttt.com/trigger/<the-trigger-name>/with/key

Then the URL for the POST request looks like this (replace <the-random-string> with your unique ID).

https://maker.ifttt.com/trigger/buttondown.email_draft.created/with/key/<the-random-string>

I could not find that information on the official website, but some third-party blog posts (see below) pointed me in the right direction.

Links

• ifttt webhooks
• buttondown.email webhooks
• Linking IFTTT & Processing with Webhooks
• Use IFTTT web requests to send email alerts

TIL: GitHub Actions on cron Job Might Be Late

Published on: 2021-06-09

tags: TIL, Git

Today I learned that scheduled GitHub Actions might be late or not run at all. 😠

I've written a script which fetches my blog posts every week on Monday and creates a draft with my newsletter provider.

The script uses a cron job.

I assumed that the cron job will run at the specified time.

Unfortunately, that's not the case as per this post in the GitHub support forums:

Many times, there is a delay when triggering the scheduled workflow.
Generally the delay time is about 3 to 10 minutes. Sometimes it may be more time, even dozens of minutes or more than one hour. However, if the delay time is too long, the scheduled workflow may be not triggered at that day.

A possible work-around is using a third-party service like IFTTT to trigger the GitHub Action Workflow.

My Git Aliases And Abbreviations

Published on: 2021-06-08

tags: Git, DevTools, Shell

As a developer, Git is one of the essential tools in my daily work.

Today I want to share my git aliases and fish abbreviations that make working with Git more comfortable.

In my ~/.gitconfig file:

[alias]
  # Git Commit, and Push — in one step.
  cmp = "!f() { git commit -m \"$@\"; }; f"
  # NEW.
  new = "!f() { git cmp \"📦 NEW: $@\"; }; f"
  # IMPROVE.
  imp = "!f() { git cmp \"👌 IMPROVE: $@\"; }; f"
  # FIX.
  fix = "!f() { git cmp \"🐛 FIX: $@\"; }; f"
  # RELEASE.
  rlz = "!f() { git cmp \"🚀 RELEASE: $@\"; }; f"
  # DOC.
  doc = "!f() { git cmp \"📖 DOC: $@\"; }; f"
  # TEST.
  tst = "!f() { git cmp \"🤖 TEST: $@\"; }; f"
  # BREAKING CHANGE.
  brk = "!f() { git cmp \"‼️ BREAKING: $@\"; }; f"
  # Logline
  lol = log --graph --decorate --oneline
  lola = log --graph --decorate --oneline --all
  # Diff, Status
  df = diff --color=always --color-words --abbrev
  st = status -s
  last = log -1 HEAD
  unstage = reset HEAD --
  pj = !which onefetch && onefetch

The first few are from Emoji-Log, a method to decorate git commits with emojis. What I like about the method is that it uses a small subset of defined emojis and make the commits look prettier.

I also have utility commands, like git st which gives me a condensed version of git status.

The logline commands are useful to show a graph of the commits.

git pj (pj for "project") uses onefetch, a CLI that displays project information and code statistics. It's pretty neat.

I also have fish abbreviations that make it easier for me to type common git commands.

One of my favorite ones is gapn which expands to git add --intent-to-add . && git add --patch.

This command shows you all your changes from the last commit with the option to stage hunks.

This blogpost explains how git add --patch works.

I'll leave a list of my fish abbreviations here:

abbr -a -U -- g git
abbr -a -U -- ga 'git add'
abbr -a -U -- gadn 'git add . && git diff --cached'
# interactive git add
abbr -a -U -- gai 'git add -i'
# git add --patch
abbr -a -U -- gap 'git add -p'
abbr -a -U -- gapn 'git add --intent-to-add . && git add --patch'
abbr -a -U -- gbr 'git branch'
abbr -a -U -- gc 'git commit'
abbr -a -U -- gca 'git commit --amend'
abbr -a -U -- gcm 'git commit -m'
abbr -a -U -- gco 'git checkout'
abbr -a -U -- gd 'git pull'
# git diff
abbr -a -U -- gdf 'git df'
abbr -a -U -- gdif 'git diff'
abbr -a -U -- gdoc 'git doc'
abbr -a -U -- gfom 'git fetch origin master'
abbr -a -U -- gft 'git fetch'
abbr -a -U -- gfu 'git fetch upstream'
# git --intent-to-add
abbr -a -U -- gin 'git add -N .'
abbr -a -U -- glst 'git last'
abbr -a -U -- gmg 'git merge'
abbr -a -U -- gnew 'git new'
abbr -a -U -- gp 'git push'
abbr -a -U -- gpl 'git pull'
abbr -a -U -- gpo 'git pull origin'
abbr -a -U -- gpu 'git pull upstream'
abbr -a -U -- grb 'git rebase'
abbr -a -U -- grs 'git reset'
abbr -a -U -- gst 'git status -sb'
abbr -a -U -- gsw 'git switch'

Abbreviations like gcm are handy: The abbreviation expands to git commit -m, so that I now can type my commit message.

Links

• git add --patch and --interactive
• Git Aliases
• Fish Abbreviations
• onefetch

Thank you for reading my blog.

Don't hesitate to reach out via email or Twitter!