Eyayaw Beze

jobrake for the job

Eyayaw Beze — Sun, 06 Sep 2026 22:00:00 GMT

I’ve been looking for a simple tool for getting new job postings from job boards, because I was tired of doomscrolling on the LinkedIn Jobs tab. Oh yeah, [sg]etting job alerts is equally overwhelming.¹

Who to blame, but I’ve not found any that is “reliable”, simple, and free.²

Tip

I spend bonkers amount of time trying to “automate” my job search, but less on actually searching. So, heed my advice on this matter. 😅

So jobrake () is an ambitious attempt to address these challenges.

It’s a simple CLI tool and Python package that fetches job postings from Indeed and LinkedIn and returns every result as the same small Job dictionary. There is no login, no browser automation, just simple requests via httpx.

I intend jobrake to be simple and light³. It searches, normalizes, and returns jobs. That is it. It helps you swing the rake at the big piles—LinkedIn and Indeed. So, currently, it does not support other boards such as Glassdoor or ZipRecruiter.

Installation

jobrake is not on PyPI so install it from GitHub with uv. Please read the installation guides for your system.

I assume unix-based systems hereafter, sorry Windows-(or dare I say WSL-) people, you’re on your own—read the uv docs, adapt all the code wherever necessary; you can do it!

I personally use jobrake through the CLI, so you can install it as a tool, too. uv installs jobrake and adds it to your ${PATH}.

uv tool install git+https://github.com/eyayaw/jobrake
# For ephemeral use
# uvx git+https://github.com/eyayaw/jobrake

A first rake

Say you’re an economist looking for data science roles in the Netherlands, just like me⁴.

Code

Reproducible research workflows

Eyayaw Beze — Wed, 28 Jan 2026 23:00:00 GMT

I gave my talk at the AMS Institute to research fellows at our all-hands meeting.

My old workflow went like this. Writing in Word, summary stats copied out of Excel, regression estimates and figures made in Stata or QGIS and pasted in by hand. Five or more tools and formats, and every number in the paper copied at least once. Then, say, Reviewer #2 wants one threshold changed, and you are staring at analysis_v3_FINAL.do next to final_final_draft.docx, trying to remember how you cleaned the data months ago.

Sound familiar?

My objective was to show colleagues that there is a better workflow, and how to adopt it slowly until it becomes a habit. I also wanted to emphasize literate programming: a single source of truth makes a research project highly reproducible, with the code and the prose intertwined, no hardcoded stats, and no copy-pasting of stuff.

I organized the talk around four pillars.

Project organization: A self-contained repo per project, with data, code, and outputs together. Separate raw data from processed data, and write docs, a README. For a cumulative dissertation, each chapter can be a git submodule, but I used separate repos.
Version control with Git & GitHub: Use Git for tracking your work (code, prose, or docs). Use it even as a single author, with GitHub or locally.
Dependency management: Our analysis depends on specific package versions, and package updates can break our code. It does not work on my machine! uv (Python) and renv (R) for recording versions of packages for cross-machine use.
Literate programming: Code, results, and narrative in one document: no copy-paste errors, and results update automatically.

I discussed literate programming with Quarto in detail because it encompasses the other three and is highly relevant for reproducibility.

Note

The reproducibility crisis is real. See the Data Colada posts on the Gino case. It may take you down, from earning $1M+ a year to a pleb! :D Journals and reviewers increasingly ask for code and data.

One source but several output formats:

flowchart LR
  project["project/
  ├── data/
  │   ├── raw/
  │   └── processed/
  └── code/
  #nbsp;   ├── download_data.py
  #nbsp;   └── clean_data.R"]

  project --> article["article.qmd"]
  project --> seminar["internal-seminar-2026.qmd"]

  article -->|render| html["HTML"]
  article -->|render| pdf["PDF"]
  article -->|render| docx["Word"]

  seminar -->|render| revealjs["reveal.js slides (HTML)"]
  seminar -->|render| beamer["Beamer slides (PDF)"]
  seminar -->|render| pptx["PowerPoint slides"]

  %% mermaid trims leading spaces in a label, so the code/ children start with #nbsp;
  classDef tree text-align:left,font-family:monospace,white-space:pre
  class project tree

Figure 1: Write in Markdown, embed R or Python, render to HTML, PDF, Word, or slides.

I demoed Quarto with trends of WOZ property values across Dutch municipalities. Load data from CSV, make exploratory plots, run a regression with inline results, add cross-references and citations, and render to HTML and PDF.

Slides, with the WOZ demo and the talk repo.
Dissertation chapters: housing supply elasticity, the German donut effect, and Addis Ababa gradients.

—— Thank you for stopping by! 💚💛❤️ ——

Underwhelmed by stats::reshape

Eyayaw Beze — Mon, 11 Aug 2025 22:00:00 GMT

When was the last time you used stats::reshape? Probably never, in the presence of {tidyr}’s pivot_* and {data.table}’s melt/dcast reshaping (aka pivoting) functions.

A while ago, while perusing through the {data.table} vignettes, I learned about the reshape function. The {data.table} core team described it as “It is an extremely useful and often underrated function.”. As a member of the “dependency-frets” (as reshape is part of base R), I’ve been using it fairly since. However, it has some annoyances that might lead you to think that the function isn’t yet quite “fully ripe”, which could explain its “underratting”.

First, it’s very slow; no further comment is needed, but that could be a deal breaker for some.¹

Args of the reshape function are also a bit cryptic. I have to hit ?reshape time and again because it is not easy to remember what is what. What (or not) to pass to varying (a vector or a list (or a matrix)) and how to order its values? Like varying=c("gdp_2020", "gdp_2021", "pop_2020", "pop_2021"), or c("gdp_2020", "pop_2020", "gdp_2021", "pop_2021")? What does v.names (and frankly most args) do in reshape to wide vs. long? Would not it be helpful if reshape was broken down into two separate functions (reshape_{long,wide})?² Also it is hard to tell which args are optional and which get ignored silently even when you explicitly provide them.³

Futhermore, you have to “nicely” format your column names to unlock reshape to long’s potential: that is use a sep (defaults to .) between the time varying variables and the timevar (like gdp.2020, pop.2020).

Warning

Do you really think about renaming your columns when reshaping? Don’t! 🙃

Even if you “nicely” format your column names say with sep="_", your’re doomed if you have “_” somewhere in the column names as you can’t use perl-compatible regex to force the location of the sep (e.g., you have gdp_ppp_2020 and you’re not allowed to use sep="_(?=\\d{4})" or split(regexp = "_(?=\\d{4})", include = FALSE, fixed = FALSE)). If you look at the source, this could have been done as split and regexpr (where sep and split are used) can handle perl-compatible regex with perl = TRUE.

While reshape is fundamentally built to deal with panel data, it does not handle “unbalanced” (panel) data. A special case that traps reshape (to long) is when a variable (say population size) is available for 2019 but missing for 2020 (for all units), while another variable (GDP) is measured for both 2019 and 2020 (for some or all units).⁴ You may think this is a useless edge scenario, but both {data.table} and {tidyr} support it. This rare edge case may frequently creep into typical use cases, doesn’t it?

Reshaping with `stats::reshape`

Let’s quickly look at how we can use reshape to convert data from wide to long format and vice versa and touch on some of the issues along the way, with sample datasets from the World Development Indicators (WDI) database. The WDI datasets provide a perfect use case for reshaping because you can download the data in wide or long format.

Tip

The official documentation and vignette for reshape are great. I also find this blog post by Jozef Hajnala excellent.

Code

Leveraging Gen AI

Eyayaw Beze — Sat, 12 Jul 2025 22:00:00 GMT

Have you ever called an LLM from somewhere other than its chat window? I motivated my talk with that question at my Ethiopian community gathering in Wageningen, Netherlands, and most of the talk is my answer to it.

Most of us use LLMs daily but still carry the impression of the ChatGPT of November 2022, when they hallucinated a ton, knew nothing past their training cutoff, and came in one flavor from one provider. A lot has changed since then. Models are generally better, and the playing field has gotten crowded with providers and options, closed-source or otherwise: OpenAI, Anthropic, Google, xAI, Meta, Mistral, Alibaba, DeepSeek, and the open-weight models you can run yourself with Ollama or LM Studio.

My objective was to show the community (WUR staff, postdocs, and PhD candidates, plus our kids and other family) that we can go beyond the chat window and put these models to productive use, and to stress calling them programmatically.

What makes these models useful is the context you supply yourself: a system instruction, your own documents, a tool the model is allowed to call. My own use cases are unglamorous. I fix my writing with them, and I draft cover letters from a system prompt that tells the model to act as a career coach, to say upfront when I’m not a good fit for the job, and to avoid clichés and flashy words.

I showed two demos about using LLMs for data extraction from unstructured data.

The first extracts (OCRs) the numbers from a photograph of a blackboard chalked in Mettu in 1972, with Ethiopian medical statistics on it: square miles, population, hospitals, health centers, health stations, beds, and the USA in the next column for comparison. One prompt asking for valid CSV, safe for parsing, in tidy long format, and it comes back as something read.csv takes without complaint.

The second is asking LLMs to extract data and return structured output. Hand the Gemini API a responseSchema and an Amharic rental listing, the kind written in one breath with no punctuation and a phone number at the end, and you get back JSON: the price in ETB, the plot area in square meters, bedroom and bathroom counts, the broker’s commission, and the address both as written and transliterated. That is how a channel full of ads becomes a dataset.

I ended with questions to the audience. What are your use cases? Will this take our jobs? What role does it play in economic development back home? Is Ethiopia lagging behind wrt AI usage and literacy?

Note

At that time, July 13, 2025, Ethiopia was not on Anthropic’s list of supported countries.
The tools keep getting cheaper and more capable, but not everywhere and not for everyone.

Slides: Leveraging Gen AI, source on GitHub.

—— Thank you for stopping by! 💚💛❤️ ——

Setting up a new Mac

Eyayaw Beze — Thu, 24 Apr 2025 22:00:00 GMT

I finally treated myself to a new Mac Mini for completing my PhD. In the past, setting up a new machine meant hours of manual downloading, clicking through installers, and tediously configuring apps and tweaking default OS settings. However, over time I learned setup automation, so now I can get everything up and running quickly with minimal manual effort.

What have I learned? Writing a set of shell scripts that handle everything from app installation to config, and setting default settings. This post walks through my approach to programmatically setting up a new Mac and the tools that make it possible.

The new Mac Mini

Initial setup process completed, ready to hit ./bootstrap.sh

TL;DR

Apps and CLI tools: I use Homebrew as my package manager to install everything from 1Password and Raycast to dev tools like Python, R, and DuckDB. For Mac App Store apps, I use mas.

Configs: I manage my configs with GNU Stow, which creates symlinks from my version-controlled dotfiles to the proper locations in my ${HOME} directory.

macOS defaults: I apply custom macOS settings through a script that changes some default options (like enabling list view in Finder and disabling “natural” scrolling).

The automation process

Package managers are the key to automation. I remember the days when I used to spend hours manually downloading and installing apps until I discovered tools like apt for Ubuntu and Homebrew for macOS. Another milestone was when I discovered about dotfiles, configs that you can version-control and use across machines.¹

By combining package management with dotfiles, and macOS default settings, I created a system that helps me set up a new machine with all my favorite tools and configs in a fraction of the time it used to take me. There are three main components of this system: (1) package management with Homebrew, (2) GNU Stow-ed dotfiles, and (3) customizing macOS defaults.

Component 1: Package Management with Homebrew

macOS, unlike many Linux distros, doesn’t come with a built-in package manager. Homebrew fills this (“the missing package manager”) gap, becoming the first tool I install on any new Mac:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Homebrew lets me install both GUIs (casks) and cli tools (formulae) and through simple commands. Here is how I install my favorite packages via Homebrew:

Core tools

# Password and secrets management
brew install --cask 1password
brew install 1password-cli

# Application launchers (with window management, clipboard history and other features)
brew install --cask raycast alfred

brew install --cask arc  # modern browser
brew install --cask karabiner-elements  # for keyboard customization

# Terminal environment
brew install --cask ghostty  # terminal emulator
brew install git # not to interfere with the system: macOS comes with a pre-installed version
brew install starship # shell prompts
brew install tmux  # terminal multiplexer
brew install stow  # for dotfiles management

Command-line utilities

brew install tldr  # simplified man pages
# Better alternatives to standard tools
brew install fzf # a fuzzy finder
brew install bat ripgrep fd  # modern alts for cat, grep, find

# Additional CLI tools
brew install gh  # GitHub CLI
brew install mas  # for Mac App Store apps

Dev environments

# Programming languages
brew install --cask r # the cask version is recommended, https://x.com/jimhester_/status/1374342249568481288
brew install python lua

# Package managers and code quality tools
brew install uv ruff  # Python package manager and linter
brew tap r-lib/rig && brew install --cask rig  # R version manager

# Editors and IDEs
brew install --cask visual-studio-code zed  # modern code editors
brew install --cask visual-studio-code@insiders zed@preview  # unstable versions
brew install --cask rstudio positron  # R & Python IDEs by Posit
brew install neovim  # for btw

I also install typefaces (mostly coding fonts). My fonts installer script copies my purchased fonts to ~/Library/Fonts/, including MonoLisa and Berkeley Mono. The free ones can be installed via Homebrew, such as JetBrains Mono and Monaspace.

# Fonts
brew install --cask font-{jetbrains-mono,monaspace,ibm-plex-mono}
brew install --cask font-{fontawesome,inter,open-sans,roboto}

I also install Mac App Store apps, mostly not free:

# Mac App Store apps (using mas)
mas install 441258766  # Magnet
mas install 424389933  # Final Cut Pro
mas install 1091189122  # Bear Notes

As an academic, I use Zotero for reference management (sometimes as read-later storage, and has an impressive PDF reader). For academic citations, I use Better BibTex to automatically generate citations keys in Zotero. I write a script to install this addon, instead of manually installing it.

Tip

The citation key formula I use is authEtal(sep='_').lower+year.prefix(_), which generates citation keys like glaeser_2010, glaeser_gyourko_2009, and glaeser_etal_2020 for single, two, and three or more authors, respectively.

You can read this on how to configure the citation key generator.

Lastly, I wrote a script that installs tpm, a plugin manager for tmux, inspired by typecraft-dev’s crucible.

All of these installations are automated in a single script scripts/install/install.sh, which sources the relevant scripts. If you’re curious about in the full list of my favorite tools, see here.

Component 2: Configuration Management with Dotfiles

After installing apps, the next challenge is configuring them. This is where dotfiles come in, which are configs (often hidden, starting with a dot, hence the name) that control how apps behave.

Dotfiles are simply text-based configs. Examples include: .zshrc for Zsh config, .gitconfig for Git preferences, and various configs for editors, terminal emulators, and other tools.

By storing these files in a version-controlled repository, we can easily track changes and sync configs across machines.

Managing dotfiles with GNU Stow

Managing my dotfiles was challenging, and I often lost them since they typically reside in the home directory, which I don’t sync with iCloud Drive. (Of course, you can!) Then I discovered GNU Stow, through Dreams of Autonomy’s video.

Stow creates symlinks from a repository (in my case located at ~/Developer/dotfiles/) to the locations where apps expect to find their configs, usually in the home directory (i.e., ~) and its subdirectories such as .config.

Here is how I structure my dotfiles repository:

~/Developer/dotfiles/
├── zsh/            # Shell configs
│   ├── .zshrc
│   ├── .zshenv
│   └── .zsh_aliases
├── zed/            # Zed editor settings
│   └── .config/
│       └── zed/
│           ├── settings.json
│           └── keymap.json
├── git/
│   └── .gitconfig
└── ... other tools

Notice how the directory structure (for each package) mirrors where these files would normally live in my home directory.This is key to how Stow works.

To apply these configs, I simply run:

# or run from anywhere by adding the `--dir` flag with the location of your dotfiles
# in my case `--dir=${HOME}/Developer/dotfiles`
cd ~/Developer/dotfiles
stow --target=${HOME} zsh ghostty karabiner git tmux zed R rstudio

Symlinked dotfiles
This screenshot shows Stow in action, where configs in my home directory (left side) are pointing to their actual location in my dotfiles directory (right side).

As shown in the screenshot above, Stow creates symbolic links from the appropriate locations in my home directory to the files in my dotfiles repository. When I update a config file in my dotfiles, the change is automatically reflected in the corresponding config file and hence the package that uses the config, and vice versa.

For example, here is a simplified version of my Zed config which is located at ~/Developer/dotfiles/zed/.config/zed/settings.json:

{
  "base_keymap": "VSCode",
  "vim_mode": true,
  "relative_line_numbers": true,
  "buffer_font_family": "MonoLisa",
  "buffer_font_size": 15,
  "ui_font_size": 15,
  "theme": {
    "mode": "system",
    "light": "Zed Legacy: Solarized Light",
    "dark": "One Dark"
  },
  "wrap_guides": [72, 80, 120],
  "soft_wrap": "editor_width"
}

With Stow, this file lives in my dotfiles repository but appears to Zed as if it’s in the expected ~/.config/zed/ location.

Component 3: Customizing macOS Defaults

macOS comes with many default settings that I immediately change on a new system. Rather than clicking through System Preferences, I use a script that modifies these settings programmatically, which are mostly adapted from Mathias Bynens’ dotfiles.

# Use list view in Finder by default
defaults write com.apple.finder FXPreferredViewStyle -string "Nlsv"

# Disable "natural" scrolling (which feels unnatural to many)
defaults write NSGlobalDomain com.apple.swipescrolldirection -bool false

# Faster keyboard repeat rate
defaults write NSGlobalDomain KeyRepeat -int 1
defaults write NSGlobalDomain InitialKeyRepeat -int 10

# Show hidden files in Finder
defaults write com.apple.finder AppleShowAllFiles -bool true

# Disable automatic capitalization, smart quotes, etc.
defaults write NSGlobalDomain NSAutomaticCapitalizationEnabled -bool false

These commands modify the property list files that store macOS preferences. After running my settings script, I restart the machine to ensure all changes take effect.

Putting it all together

My complete setup process is orchestrated by a single bootstrap.sh script that:

Installs Homebrew
Installs all packages, fonts, and apps
Sets up plugin managers for tools like tmux
Configures macOS default settings
Deploys all dotfiles using Stow

Here is the actual workflow:

Boot up the new Mac.
Clone my dotfiles repository: git clone --depth=1 https://github.com/eyayaw/dotfiles.git ~/Developer/dotfiles, macOS comes with a pre-installed version of Git.
Run the bootstrap script: cd ~/Developer/dotfiles && ./bootstrap.sh.²
After a reboot, everything is ready to go.

Note

Installing Homebrew takes longer than I would like because of the Command Line Tools and other dependencies (I assume).

You may be asked for your password repeatedly, so you might need to stay nearby.

You can install Homebrew in unattended mode by setting NONINTERACTIVE=1. If you want to install everything unattended, there may be a way through providing the password upfront (in bash set -v and additional hack), but I couldn’t get it to work in my setup.

The entire process takes less than an hour, most of which is just waiting for downloads to complete. When I return to the computer, all my tools are installed and configured exactly the way I like them.

While saving time is the most obvious benefit, this approach offers other advantages. My dev environment is familiar across machines, the scripts serve as documentation of my setup. I can easily add new tools or update configs. If something goes wrong, I can quickly restore my environment because my dotfiles are version-controlled.

Conclusion

Setting up a new machine used to be a gruelling, unproductive task. Now it’s a matter of running a single script and taking a coffee break. This automation has dramatically reduced the friction of moving to new machine and ensures I immediately have access to my dev tools on a fresh system.

The tools outlined here—Homebrew, GNU Stowed dotfiles, and defaults scripts—form a powerful trio for Mac setup automation. If you’re still setting up machines manually, I encourage you to explore automation. There are hundreds of amazing dotfiles on GitHub.

How do you set up your dev environment? I would love to hear about your approach and favorite tools in the comments!

—— Thank you for stopping by! 💚💛❤️ ——

Expand the appendix if you want to skim through simplified versions of some of my configs.

Appendix

Base R

Eyayaw Beze — Sun, 06 Apr 2025 22:00:00 GMT

You probably engaged in endless debates about {tidyverse} versus {base} R and/or {data.table}.¹ But what does “base R” actually mean? Clarifying this may unite the dichotomy (or trichotomy), that we are all R. But, wait, we’re all R? What about “R or Python”? Oh no, don’t let the holy war escalate! Again, we’re all one . . . embrace both like me, like RStudio . . . in fact, become a polyglot.

Back to base R, it is typically used to refer to the set of packages that come or distributed with R². The name “base” might be confusing, because of {base}, the fundamental package that “contains the basic functions which let R function as a language”. However, base R encompasses more than {base}. Pause and count how many base R packages you can name. . . .

Code

Welcome to my Blog

Eyayaw Beze — Sat, 30 Jul 2022 22:00:00 GMT

This is the first post in my blog. Welcome!

I will blog about what I have learned in my R and Python journey. Stay tuned!

Eyayaw Beze

jobrake for the job

Installation

A first rake

Reproducible research workflows

Underwhelmed by stats::reshape

Reshaping with stats::reshape

Leveraging Gen AI

Setting up a new Mac

TL;DR

The automation process

Component 1: Package Management with Homebrew

Core tools

Command-line utilities

Dev environments

Component 2: Configuration Management with Dotfiles

Managing dotfiles with GNU Stow

Component 3: Customizing macOS Defaults

Putting it all together

Conclusion

Base R

Welcome to my Blog

Reshaping with `stats::reshape`