My current client does not use any chat tools like Slack. While this is uncommon these days, and was really unexpected when I started with them, I came to appreciate it. It introduces friction into the communication. Which is good. It makes you think before you send an email.

It's that time of the year where I am tempted to create a clean .vimrc file and start using vim again.

What a bullshit

I wanted to reach out as an opportunity is now available for a Developer to join a very exciting, innovative and dynamic company based in Berlin to work on a strategic life changing application that supports thousands of business executives of the greatest companies in the world.

Our cat died yesterday. She would have turned 10 this summer. Fucking pancreatic cancer took her within one month. Have trouble not crying all day.

This happens when you use a Ubuntu USB device to boot from. The wifi adapter isn’t recognized in this old(er) MacBook Pro 13". Well, I have other things to do anyway. 🙁

Alright. It takes some time for the posts to appear, but it works. I post to my WordPress category „microblog" first (https://holgerfrohloff.de/category/microblog/). This gets syndicated to micro.blog and to Twitter. #success

If everything works you should be able to read this. Tech is confusing. This needs to be easier for people.

I will now host my micro.blog posts on my own site holgerfrohloff.de. Just tried to set everything up. So consider this a test post—which should still crosspost to Twitter as well.

Inspecting changes locally before pushing

If you work on your branch you run into the situation that you would like to push your changes to the remote repository. CI will then pick up your changes and run the linting and code quality checks on it. Afterwards, you will see whether you improved the quality. But perhaps there are some new violations that crept into the code? Happens to all of us!

I usually like to see and check if any new issues might come up on CI. This lets me improve them before I push.

The checks I run locally depend on the kind of work that I do. Lately that's a lot of Ruby on Rails again — which is great. I love that framework and the language.

To grade my code, I use Rubocop, Reek and Flay. If you run their respective commands on your repository, they will check the whole code base. This might be ok, if you didn't have any issues before. Since I join teams, these days, that work on legacy projects it is rare that there are no problems with the code. If I run the commands just so, I will get a long list and couldn't possibly see the issues that I introduced through my changes. Lucikly, there is Git and some "command line foo" that can help us here:

git fetch && git diff-tree -r --no-commit-id --name-only master@\{u\} head | xargs ls -1 2>/dev/null | grep '\.rb$' | xargs rubocop

This command will fetch the current state from the remote and diff your branch/changes to master branch. It then runs rubocop on these changes.

In my ~/.aliases.local file I added three lines for all three linters.

# Code Quality
alias rubocop-changes="git fetch && git diff-tree -r --no-commit-id --name-only master@\{u\} head | xargs ls -1 2>/dev/null | grep '\.rb$' | xargs rubocop"
alias reek-changes="git fetch && git diff-tree -r --no-commit-id --name-only master@\{u\} head | xargs ls -1 2>/dev/null | grep '\.rb$' | xargs reek"
alias flay-changes="git fetch && git diff-tree -r --no-commit-id --name-only master@\{u\} head | xargs ls -1 2>/dev/null | grep '\.rb$' | xargs flay"

I am still working on a way to just call one command and have all thee commands run. That doesn't yet work. Probably because of exit-code reasons, when one linter finds issues.

These simple commands offer a convenient way to find local issues and correct them before pushing to CI.