DEV Community: Monica

TIL about testing commands

Monica — Mon, 18 May 2020 20:35:09 +0000

This is a walk-with-me-while-I-do-things series, I'm going to tell you what I learned while I'm learning

If this was our program

# my_tool.rb

# Removes and returns the first item from the command-line arguments
command = ARGV.shift

puts command

you can test this code using RSpec with

# specs/my_tool_spec.rb

RSpec.describe "my_tool" do
  it "says hello" do
    expect { system "ruby my_tool.rb hello" }.
      to output("hello\n").
      to_stdout_from_any_process
  end
end

Here we have three fundamental pieces:

the method Kernel#system that invokes a command as if we were on the command line itself. The argument passed as a string will be the command being executed;
the RSpec matcher output that checks against the expectation and passes if the expectation block on which it is invoked outputs to_stdout or to_stderr the string passed as an argument;
the to_stdout_from_any_process that we have to use instead of to_sdtdout because the system call is actually spawning a subprocess, and RSpec wouldn't be able to access $stdout otherwise.

If we weren't testing a command line invocation, we could have written

expect { print "Same process" }.
  to output("Same process").
  to_stdout

More sources are here. To use RSpec for capturing the output and where you can go to the official doc.

TIL about Ruby command line execution

Monica — Tue, 05 May 2020 20:01:22 +0000

This is a walk-with-me-while-I-do-things series, I'm going to tell you what I learned while I'm learning

You can execute a Ruby file by passing it on as an argument to the ruby. What if I told you you can require a library and give executable code directly to the command on the terminal?

The ruby command supports two options among others:
-r stands for require and receives as an argument the name of the Ruby file you want to load
-e stands for execute and receives as an argument a script

Let's have a file in the current directory called hello.rb that defines the Hello class like this:

class Hello
  def greet
    puts "Hello there!"
  end
end

By running

ruby -r "./hello" -e "h = Hello.new; h.greet"

the prompt will present you with the following output

Hello there!

You can even write a multiline script as if you were writing in a file

➜  first-repo git:(master) ✗ ruby -r "./hello" -e "
dquote> h = Hello.new
dquote> h.greet
dquote> "
Hello there!

Here is the documentation for all the options you can feed to the ruby command

TIL about zshell startup

Monica — Mon, 04 May 2020 20:40:23 +0000

This is a walk-with-me-while-I-do-things series, I'm going to tell you what I learned while I'm learning

You might remember about my ordeal with bash and Catalina and zshell and iTerm. I bit the bullet and switched to zshell.

I have an alias for starting the postgres server that on bash resides on .bashrc (by the way, did you know that rc stands for run commands?). With zshell, you can use .zshrc for the same purpose.

zshell at startup reads these files for the user in the following order:

.zshenv - always read when launching the shell, no matter from where. you want the important stuff here.
.zshprofile - read at login. don't use, use .zshlogin instead. the purpose is the same.
.zshrc - read when interactive. this is where you should put aliases, key bindings, coloring, etc.
.zshlogin - read at login, use it for things needed once the shell is set up, to execute external commands.
.zshlogout - read when the login shell exits, it should be used to release resources acquired during login.

Before each of these, zshell runs the matching files that can be found in /etc/ for all users on the machine.

More info here (official documentation), here on StackOverflow, and here (switching to zshell because of Catalina).

TIL about tree

Monica — Sat, 02 May 2020 08:02:43 +0000

This is a walk-with-me-while-I-do-things series, I'm going to tell you what I learned while I'm learning

Yesterday I purchased Rebuilding Git by James Coglan and today I set up for Chapter 1. I already learned something new on page 4 📖

tree is a command originated in MS-DOS (apparently) that has been ported to *nix systems.
By running it in the terminal, it draws for you a graphical recursive representation of the content of the current folder and its children (files and directories), and prints the number of files and/or directories listed.

It might not come with your OS, it is a program on its own. If you are on a Mac and using homebrew like me, just type

brew install tree

More info here and here

Yak Shaving My Way To Hacktoberfest - Day 2

Monica — Sat, 19 Oct 2019 09:56:05 +0000

On how an OS upgrade can kill your Terminal

I woke up to the upgrade to Catalina being completed. I had a couple of hours after work I could use to fix the setup.

I launched iTerm that with a very graceful popup tells me something-something command profile. As soon as I acknowledged the popup, the window closed. I tried another couple of times (monkey monkey), decided to close permanently the popup because brainfart. Probably I was hoping to be able to see the content of the iTerm window underneath. Unable to revert the behavior, I realized I have two profiles on iTerm. I opened the default profile and there it was, the popup in its splendor.

A session ended very soon after starting. Check that the command in profile “molli” is correct.

Looking for the message online told me that something was wrong with the command that iTerm launches at start and that I should look at what the window behind the popup says. I couldn't move the popup around so I had to revert to reopen the window a few times and be reading very fast 🙄

It seemed that bash was causing the problem. I went to my bash_profile and commented out everything bash-related. Relaunching iTerm showed the same issue. I suddenly remembered that, with the last version of MacOS, Apple started suggesting devs to switch to zsh. I fired the OS terminal app that presented the same problem: I cannot use it because it's still looking for bash.

In my skimming through internet pages and iTerm settings, I realized there was a Command setting under Profiles > General that was set to Login Shell. Finally a stable iTerm with, guess what?

/bin/zsh/

Of course it wasn't enough, because to my subsequent brew doctor, the terminal replied with the equivalent of "I have no clue what you are talking about". But I knew the little rascal (...) was there. FINE. Maybe it was something in the path that zsh doesn't pick up. I tried to configure it properly, but this meant understanding the difference between .zprofile, .profile and .zshrc.

I ended up with a .zprofile that looks like this

emulate sh
. ~/.profile
emulate zsh
export PATH="/usr/local/sbin:$PATH"
export PATH=/usr/local/bin:$PATH

but still no joy for my brewing.

I checked Terminal and lo and behold, it did indeed recognize homebrew. So I used it to launch homebrew and installed bash (sorry, zsh, we'll meet again soon).

I reverted iTerm to use bash too, but it would still close. I made sure I had the latest version of batch available on homebrew, but when I issue echo $SHELL, what I get is still bash 4.3.0. I couldn't figure out where it'd pick this up, because I was 100% sure at this point I had no version named anywhere.

Apparently, on Mac, you can set your PATH variable in multiple places, one of them will add an entry permanently for all users on the machine.

I dug my /etc/shell, changed the config, iTerm doesn't close anymore.

source ~/.bash_profile
-bash: __git_ps1: command not found

It was 9.15AM. I had a meeting at 10. I was still in my pijiama.

Well...

On my way to the subway, I realized I should save this knowledge somewhere. I was learning stuff. I should have a blog. I should actually have a self-hosted blog, because I would be sure that then the content would belong to me 100%.

I stopped. That would have added a WHOLE new yak to shave. What is the mantra of the agile ~daleks~ software engineers? Iterate! ITERATE!
So I went for the fastest thing I could get my hands on and I opened my DEV.TO profile. On my phone, I hacked the first lines of the first post of this series.

Fast forward to 7PM. I was finally home and decided to finish the first post. I had to search for all the sources and reconstruct in my memory what happened the day before. I also decided to note down what happened on that day (you don't want to see those notes, but as you can see, it was a good call, after a week I would have ZERO recollection of any of this).

Now back to my last problem of the day, __git_ps1.

I have my prompt configured in such a way that, when I am in a folder that is a git repository, it shows me the status of the files and the branch I am in. Since I had an old version of git and an old version of OSX, the former configuration wouldn't work. I updated .bash_profile to

export GIT_PS1_SHOWDIRTYSTATE=1
export GIT_PS1_SHOWSTASHSTATE=1
export GIT_PS1_SHOWUNTRACKEDFILES=1
export PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[01;33m\]\$(__git_ps1)\[\033[01;34m\] \$\[\033[00m\] "

as described here and I had my git status on my prompt again, all cool.

I ran rake db:setup only to be told that - of course - the database server wasn't running. Because I'm lazy, I have an alias for that too

alias pgstart='pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start'

so I added it to .bash_profile and, when sourcing it, bash very nicely told me

-bash: pg_ctl: command not found

I launched and initialized the Postgres app, same outcome. RTFM, Monica: on https://postgresapp.com/ they clearly say to add the Postgres app to the path permanently (remember?) with

sudo mkdir -p /etc/paths.d &&
echo /Applications/Postgres.app/Contents/Versions/latest/bin | sudo tee /etc/paths.d/postgresapp

This was the first time I was seeing tee, a command used to write to two different places at the same time (by default, to a file and to standard output).
But I questioned the permanent add to the path, so I added the postgres app location to the user PATH in .bash_profile and sourced it to pick up the changes.

An echo $PATH showed me that the changes are there, but the PATH itself was ever-growing and also full of duplicates because of the multiple sources. How could I get rid of the duplicates?

There are a bunch of suggestions out there on how to clean and reset PATH or avoid duplication completely, but it would take too long to do it properly, I was still far away from being able to start coding. So I decided to chop everything off, reset PATH to what I believed was a clean slate and sourced again (MVPs, right?!)

export PATH=/usr/bin:/bin:/usr/sbin:/sbin
source ~/.bash_profile

gave me back something sensible and clean. Noice.

Looking at my .bash_profile configuration for environment managers, I noticed and commented out some nonsense shit about rbenv that is not relevant and I realized that I didn't have exenv working anymore. But asdf did indeed work, so I removed the first one permanently.

With my brand new and shiny PATH, I could now try and call pgstart again. The command run but it couldn't start the server. I looked at the logs

2019-10-09 07:43:43.634 CEST [37155] FATAL:  database files are incompatible with server
2019-10-09 07:43:43.634 CEST [37155] DETAIL:  The data directory was initialized by PostgreSQL version 9.4, which is not compatible with this version 12.0.
2019-10-09 07:54:17.196 CEST [49284] FATAL:  database files are incompatible with server
2019-10-09 07:54:17.196 CEST [49284] DETAIL:  The data directory was initialized by PostgreSQL version 9.4, which is not compatible with this version 12.0.

O. K.

I removed current installation, reinstalled everything with homebrew, because it was the fastest option. I could then also upgrade the data with homebrew.

 brew postgresql-upgrade-database

A pgstart later, the terminal still tried to start pg_ctl from the Postegre.app installation directory. I needed to check where the aliases where defined and which where currently available on my machine. I cleaned the aliases and resourced again the profile for bash, now which pg_ctl gave me the correct directory, I can start the postgres server.

The moment of truth, running rake db:setup again.

ActiveRecord::NoDatabaseError: FATAL:  role "postgres" does not exist

It was an error, but I had never been happier to see one. I dug again how to create a role within postgres.

I issued psql to check the current roles and users available, but

psql: FATAL:  database "molli" does not exist

I proceeded to create the db from the command line.

I had no idea which password my molli user has, so I proceeded to look for how to reset user password in postgres and set a new one.

I finally was able to create the role for postgres with the same privileges as my main one.

db:setup works! db:test:prepare works!

8:50AM, time to go to work... I might finally be able to code.

Yak Shaving My Way To Hacktoberfest - Day 1

Monica — Tue, 08 Oct 2019 20:09:51 +0000

On how I tried to get back to coding and all the things I learned along the way

Since more than a year now I’ve been promoted to a lead position. In my current company, this implies much more focus on people management and high level conversations around company priorities and goals than coding, or anything too technical for that matter.

In order to not see my hard skills go more rusty than they are already at the moment, and because I’d like to contribute more to open source, I thought doing something for Hacktoberfest.

So, two nights ago I opened my old and faithful personal MacBook Pro 2016, I evaded Netflix suggesting to keep watching the next episode of Star Trek TNG (yes, I’m rewatching all Star Trek in sequential order), went to up-for-grabs.net and found an issue on the Gitlab repo I believe I can tackle in a reasonable amount of time.

I fired iTerm and cloned the repo, ran bundle and here starts the adventure: I had an old version of ruby, 2.4.9 (yes, I haven't updated in that long) and therefore unable to bundle much because Gitlab develop branch is currently running on 2.6.3. Fair enough, let's install 2.6.3. rbenv had no idea what I'm talking about, so I ran diligently brew update && brew upgrade ruby-build as suggested by rbenv itself.

This was going to take a while, so I went again to up-for-grab.net and find a second candidate issue on diaspora. Diaspora is not so up to date with ruby, but its .ruby-version is asking for ruby 2.4 that... well, I kinda have since my rbenv instance has all ruby version from 2.4.0 till 2.4.9. Unable to make it work, because it's kind of impossible to get anything meaningful if you search for .ruby-version version ruby on DuckDuckGo, I decided to just change the version to a compatible one on the file itself, and god help me. I ran bundle and, magically, the console starts working its way through the Gemfile.

All the while, many, many formulas afterwards, I installed 2.6.3. on the Gitlab repo directory. bundle launched in the second terminal window, I waited. And waited. And waited.

ERROR: Could not find a valid gem 'rails' (>= 0), here is why:
Unable to download data from https://rubygems.org/ - timed out

The status page for RubyGems was telling me everything was cool, so I kept searching. StackOverflow suggested it was a DNS issue. After a ping on RubyGems that returns a nice unknown host: https://rubygems.org, I realized that, nice, too many people are trying to do something good for open source, and we are collectively DDoSing RubyGems.

The bundle on the Diaspora repo directory also failed with the same error. I launched bundle in both windows again. It worked. Until it didn't work. The Gitlab bundling complained about a couple of gems, nothing that a quick check on DuckDuckGo and a brewcommand couldn't help with. Same for diaspora. Keep going, keep going.

I hit the very first wall on the Gitlab bundling, where while trying to install ruby-prof, I get the error

warning: implicit declaration of function 'clock_gettime'
error: 'CLOCK_REALTIME' undeclared (first use in this function)

StackOverflow told me it's a problem of standard, the function is not available in C99 - and that is the dialect my version of XCode developer tools currently supports - but it is available in POSIX, MacOS is POSIX-compatible, so I should add a declaration to set a specific flag in the code I'm running, before time.h is called. O..kay, I guess?

I open the gem, I add the declaration, but of course running bundle again overwrites the content of the gem, deleting my changes. Dead end.

In the mean time, Diaspora has stopped bundling for an error on another gem, fix that with another round of brew install. The bundle completed.

I run the specs out of habits, realized I am still missing the database. After running rake db:setup, bundle complained that it couldn't find the postgres gem.
I found it's indeed in the Gemfile, but it's under the :postgres group and it's optional. You can run bundle with a --with :<group_label> flag.
Running bundle this time installed the pg gem, but when attempting to run db:setup again

rake aborted!
PG::ConnectionBad: could not connect to server: Connection refused
    Is the server running on host "localhost" (::1) and accepting
    TCP/IP connections on port 5432?
could not connect to server: Connection refused
    Is the server running on host "localhost" (fe80::1) and accepting
    TCP/IP connections on port 5432?
could not connect to server: Connection refused
    Is the server running on host "localhost" (127.0.0.1) and accepting
    TCP/IP connections on port 5432?
/Users/molli/.rbenv/versions/2.4.9/bin/bundle:23:in `load'
/Users/molli/.rbenv/versions/2.4.9/bin/bundle:23:in `<main>'
Tasks: TOP => db:setup => db:schema:load_if_ruby => db:create

I ran my pgstart shortcut. Command not found. I don't have it here, only on the laptop at work (for the curious). I have postgres installed with homebrew, so I ran

brew services start postgresql

as stated in the PostgreSQL Wiki.

The service started, but running db:setup gave me the same error. I had a vague recollection of installing PostGreSQL standalone at work, so I removed postgres from the formulas and installed PostGreSQL standalone. While I was moving the app to the Application folder, I noticed a big forbidden sign on the icon. I hovered. The version is incompatible with my MacOS El Capitan (yes, I know).

I could have installed an older version, but this was getting far more complicated than I wanted and somewhat ridiculous, and I might need to keep yak shaving until the end of October.

The dreaded time had come. I needed to bit the bullet. I took the decision to upgrade the OS. This meant that I needed to do a backup first, because god knows when was the last time. I plug the HD with Time Machine in and launched it. Almost 6GB. It took its sweet time, since my last backup was August 2019. Quite impressive, if you think I only watched Netflix on this laptop since then. It is quite inconvenient to have to plug in the external drive every time I want to back up, so I went and started looking for a NAS that I can use with Time Machine. I realize I know nothing of NASes (teh-eh), but having one connected to Internet makes me uneasy regarding my data. I make some more researches. The backup being finally over, I could leave this problem for the future.

The App Store presented me with Mac OS Catalina, all new and shiny. I launched the install. 1 hour. Kill me now. I came back straight from work at 7.30PM to do some coding, and here I was at 11PM, still waiting to even write a single line of it.

I kept digging into the NAS thingy, since I didn't had anything better to do. I found that I can indeed take some measures to avoid people looking around my stuff, and that apparently Synology is very nice.

At 12PM, the Mac told me it was time to install, I hit "Go", but the installer didn't like I had only a couple of GB available. I launched OmniDiskSweeper, waited for it to find that I had 12GB to spare in the MobileSync folder if I would delete an old iPhone backup. I killed the backup. The installer happily abode and restarted my laptop for the actual installation. 1AM, time to go to bed.