DEV Community: olistik

Compiling Ruby 3.3 on OpenBSD 7.4

olistik — Sun, 14 Jan 2024 18:14:18 +0000

Resuming the work done for

https://dev.to/olistik/a-naive-installation-of-ruby-and-rails-on-openbsd-4d50

I wanted to test the latest Ruby 3.3.0 on the latest OpenBSD 7.4 and here are the results.

First of all, let's download the sources:

$ curl -LO https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0.tar.gz
$ tar xvfz ruby-3.3.0.tar.gz
$ cd ruby-3.3.0

Add libyaml dependency if you don't have it already:

$ doas pkg_add libyaml

Configure the compilation so that it picks libyaml and it outputs the binaries in our rubies directory:

$ CONFIGURE_ARGS="--with-libyaml-dir=/usr/local/lib" ./configure  --prefix ~/.rubies/3.3.0
$ make
$ make install

Update the symlink for the current version:

$ cd $HOME/rubies
$ rm current
$ ln -s /home/$HOME/.rubies/3.3.0/ current

And then check if everything works as expected:

$ ruby -v
ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-openbsd7.4]

A naive installation of Ruby and Rails on OpenBSD

olistik — Fri, 27 Aug 2021 16:21:24 +0000

image credits

Here's the environment we'll play with (just an excuse to use neofetch):

The packages are handy but I'd prefer to keep the installation within my home in order to make actions like bundle install work without the need for super user permissions or custom configurations.

Also, I don't mind reducing the number of indirection layers.

First of all prepare the directory in which we'll install Ruby.

$ mkdir ~/.rubies

Note that we're doing this to avoid the need for the superuser.

Then download the sources of the latest version (3.0.2) and install them into our user directory:

$ curl -LO https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.2.tar.gz
$ tar xvfz ruby-3.0.2.tar.gz
$ cd ruby-3.0.2
$ ./configure --prefix ~/.rubies/3.0.2
$ make
$ make install

For convenience, link the newly installed version with the "current" alias:

$ ln -s $HOME/.rubies/3.0.2 $HOME/rubies/current

Edit ~/.profile and add $HOME/.rubies/current/bin to the $PATH so that the binaries will more easily be available in the terminal:

PATH=$HOME/.rubies/current/bin:$HOME/bin:__the rest of the path list here__

Here's our little precious:

$ ruby -v
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-openbsd6.9]

Nokogiri

Using the same approach described for FreeBSD in https://nokogiri.org/tutorials/installing_nokogiri.html#installing-using-standard-system-libraries we'll install the pkgconf package (note that the current user needs to be enabled for doas):

$ doas pkg install pkgconf
$ gem install nokogiri --platform=ruby -- --use-system-libraries

A new dawn

Time to test that the big boy works (picking "rails API only" to make things simpler):

$ gem install rails
$ rails new --api yolo
$ cd yolo
$ rails server

Now open another terminal (or the browser at http://localhost:3000) and enjoy the view:

$ curl http://localhost:3000

image credits

Poor man's file watcher

olistik — Tue, 24 Aug 2021 22:35:42 +0000

Image source

Suppose you want to perform a certain action each time one or more files change, for example running a spec each time they're updated.

You should definitely use something more polished like Guard but you could also experiment with a "simpler" approach.

First of all create the Ruby script check_event.rb:

# frozen_string_literal: true

last_mod = Time.now
loop do
  path_parts = gets.split
  path = "#{path_parts[0]}#{path_parts[2]}"
  next unless path.include?('_spec.rb')

  now = Time.now
  # Debounce: skip if another event has been notified less than a second ago.
  next if now - last_mod < 1

  last_mod = now
  puts `rspec "#{path}"`
end

Make sure the command inotifywait is installed:

sudo apt install inotify-tools

And then you can combine inotifywait with our Ruby script:

inotifywait --monitor --event modify --recursive ./spec | ruby check_event.rb

Note: I added a debounce in the Ruby script. This is because a modify event is called twice upon file save (tested with Vim on Ubuntu).

Delete all untracked files in git

olistik — Mon, 23 Aug 2021 19:50:24 +0000

Suppose that you've just done a git checkout -f to cleanup your local modifications.

New files added will slip out of the previous command, because they're treated by git as "untracked".

Here's a one-liner to get rid of these little fellas (requires a Ruby interpreter, because I <3 Ruby):

git status \
  --untracked-files=all \
  --no-column \
  --short | \
  rm $(ruby -e "puts STDIN.read.lines.map(&:split).map(&:last).join(' ')")

Image source

Update: as @kwstannard rightfully pointed out in the comments, there's also the prettier git-clean.

Dealing with the lifecycle of a Tempfile

olistik — Fri, 23 Jul 2021 14:50:15 +0000

When dealing with Tempfiles in Ruby it's important to remember that when a tempfile object gets deallocated, the referenced file gets deleted as well.

require 'tempfile'

def foo
  Tempfile.new.path
end

path = foo # => "/tmp/20210723-30107-1h52x7" 

# Soon after:

File.exists?(path) # => true

# But wait for it..

File.exists?(path) # => false

Playing with execution flows in Ruby

olistik — Fri, 30 Apr 2021 17:05:11 +0000

Let's define a simple Result class:

class Result
  def initialize(success: true, data: nil); @success = success; @data = data; end
  def success?; @success == true; end
  def error?; !success?; end
  def data; @data; end
  def self.success(data = nil); new(data: data); end
  def self.error(data = nil); new(success: false, data: data); end
end

and then a Flow class:

class Flow
  attr_accessor :tasks, :result

  def initialize(tasks: [])
    self.tasks = tasks
    self.result = nil
  end

  def step(task)
    self.tasks << task
  end

  def call
    tasks.each do |task|
      begin
        self.data = task.call
        self.result = Result.success(data) unless result.kind_of?(Result)
      rescue => exception
        self.result = Result.error(exception)
      end
      return result if result.error?
    end

    result
  end
end

We can now do some interesting things such as:

flow = Flow.new
flow.step -> { puts '#1' }
flow.step -> { puts '#2'; 3 * 3 }
flow.step -> { puts '#3 (error)'; raise 'foo' }
flow.step -> { puts '#4' }
result = flow.call

result.error? # => true
result.data # => #<RuntimeError: foo>

Configure a custom Git repository on Netlify

olistik — Fri, 21 Feb 2020 10:43:06 +0000

My personal web site (https://olisti.co) is a Gatsby.js project I used to serve publicly through Netlify but this required me to use Github.

Since I have my own Gitlab instance (https://source.olisti.co) I wanted to configure Netlify's CI to point to my Gitlab repository instead.

After a few attempts, I discovered that it's currently not possible to update the repository URL via:

the web UI: since it doesn't provide the option to specify a self-hosted Gitlab instance or to specify a manual Git URL.
netlify api updateSite since passing a build_settings object doesn't change the remote configuration, at least for the repo_url attribute.

I had to delete and recreate the Netlify site and configure it with netlify-cli specifying these parameters:

λ netlify sites:create --manual --with-ci

Here, --with-ci does the trick since it allows to specify the ssh URL of the Git repository.

One last hiccup has been while trying to provision the Let's Encrypt SSL certificate. A worrying error message showed up even though the required checks were passing.

It eventually went away after, I suppose, their local cache expired.

And now that I know this, I can import my other repositories. ;-)

Resuscitating my personal website 🧟‍♂️

olistik — Thu, 20 Feb 2020 00:27:02 +0000

It was the time.

My old personal website was getting so old that it contained even the link to my Google+ profile.

I could have kept it that way..

.. but instead I finally took the occasion to play with NES.css and Gatsby.js, adding a sprinkle of ✨CSS Grid✨.

Thanks to GitHub and Netlify's hosting 🎩 the result is https://olisti.co

And here's the source code.

My minimalistic zsh prompt

olistik — Wed, 19 Feb 2020 10:12:34 +0000

In ~/.zshrc:

export PROMPT="%F{9}λ%f "

✨🎩✨

Experimenting simpler execution flows in Ruby

olistik — Mon, 03 Feb 2020 09:50:40 +0000

I created the gem Mu::Result because I feel the need to pass Result objects instead of raw values.

This allows me to write this kind of code:

def fetch(post_id:, author_id:)
  result = api_call("https://foo.com/posts/#{post_id}")
  return result if result.error?
  post = result.unwrap

  result = api_call("https://foo.com/authors/#{author_id}")
  return result if result.error?

  author = result.unwrap
  Result.success(author: author, post: post)
end

result = fetch(post_id: 23, author_id: 42)
if result.error?
  case result.code
  when :network_error then puts 'Some troubles in the network'
  when :bad_request then puts 'Maybe a malformed request'
  when :forbidden then puts 'Check your credentials'
  when :not_found then puts 'They are gone, Jim'
  else
    puts 'Generic errors'
  end
  exit 1
end

puts "The post is: #{result.unwrap(:body)}"

with some wins like:

it's relatively easy to propagate errors without relying on exceptions;
there's a common API to handle richer return values;
pattern matching can be performed with a simple case statement against result's code attribute;
no big boilerplates involved as Mu::Result is really tiny.

Yet, I feel it can be improved even further. 🤓

Taking heavy inspiration from dry-rb's do notation here's a draft implementation I came up:

require 'mu/result'

module Mu
  module Flow
    def self.do(stuff, *args)
      stuff.call(*args) do |step|
        return step if step.error?

        step
      end
    end

    def Success(data = nil)
      Mu::Result.success(data)
    end

    def Error(data = nil)
      Mu::Result.error(data)
    end

    def Flow(method_name, *args)
      Mu::Flow.do(method(method_name), *args)
    end
  end
end

Everyday code can use it this way:

include Mu::Flow

def logic(n)
  age = yield Success(n / 2)
  yield Error(age.unwrap).code!(:too_low) if age.unwrap > 10
  magic_number = yield Success(age.unwrap ** 2)
  yield magic_number.code!(:wow) if magic_number.unwrap > 50
  magic_number
end

# simpler way with the helper:
result = Flow(:logic, 18)
puts "result: #{result.inspect}"
# result: #<Mu::Result::BaseResult:0x00007fd3d8027520 @code=:wow, @data=81>

# or more explicitly:
result = Mu::Flow.do(method(:logic), 8)
puts "result: #{result.inspect}"
# result: #<Mu::Result::BaseResult:0x00007fd3d8027160 @code=:ok, @data=16>

The example is contrived but it shows that there's no need to write explicit returns for error results anymore.

The implementation of Mu::Flow aims to remain tiny.

I'm still experimenting with this approach to see whether it produces a tangible gain or not. 🧐

Team Renovation Proposals

olistik — Sun, 02 Feb 2020 21:10:53 +0000

(This is a post I made 5 years ago on my old svbtle account. Some links might not work and I will probably update this content in the near future.)

What happens if we invest in developing our people and then they leave the company?

What happens if we don’t, and they stay?

Rationale

Developers are the most valuable assets of the Company.

Disclaimer

Everything I’ve written is highly influenced by my past experiences and readings. Several kudos to 37 Signals for their amazing books (Rework and Remote).

Proposals

The following is a list of proposals that can’t nor shouldn’t be imposed.
They shouldn’t be implemented at the same time as well. Things need to roll out incrementally.

The direction you’re taking is more important than your current position.

Economy is by definition the management of scarce resources and we all face constraints on daily basis, so don’t consider the following as must-tohave since day 1. Start by applying the right mentality and try to introduce, in the best possible way for your use case, some of these proposals. Some of them are actually very cheap to adopt.

Also, give them a honest try and don’t let any previous attempts make you think these are not worthwhile.

Pair Programming
20% Projects
Dev Blog
Fight Workaholism
Company’s Brand, Public Team Pages, Social Presence
Tech Events Presence
Embrace Remote Working
Invest on Innovation

1. Pair Programming

What

“Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.” Wikipedia

Why

Increases Developers Skills
Increases Design Quality
Helps Quality Assurance and decreases the production of bugs
Helps Team Building

2. 20% Projects

“We encourage our employees, in addition to their regular projects, to spend 20% of their time working on what they think will most benefit Google. This empowers them to be more creative and innovative. Many of our significant advances have happened in this manner. For example, AdSense for content and Google News were both prototyped in “20% time.” Most risky projects fizzle, often teaching us something. Others succeed and become attractive businesses.” Google’s 2004 Founders’ IPO Letter

When developers can’t improve their skills they feel like stagnating, they start to lose faith in the project and, worst of all, in the Company itself.

Sometimes they’d prefer to dive deep into some technical issues encountered during the development of a project instead of hopping from a project to another without having enough time to collect the necessary experience.

There are some people that have 10 years of experience, others that have 1 year repeated 10 times.

More often than not they simply want to experiment with a crazy/useful idea that can potentially:

turn into a profitable business
improve the current communication or work flow
improve current client work

3. Dev blog

Developers should be encouraged to write technical posts on a blog the Company makes available.
This helps the developers to improve their communication skills and to gain peer recognition.

A by product of this activity is that the Company itself gains popularity by the tech community and this also helps to attract skilled developers.
Some examples of companies providing a developer’s blog:

4. Fight Workaholism

Always leave office on time

Work is a never ending process. It can never be completed.
Interest of a client is important, so is your family.
If you fail in your life, neither your boss nor client will offer you a helping hand; your family and friends will.
Life is not only about work, office and client. There is more to life. You need time to socialize, entertain, relax and exercise. Don’t let life be meaningless.
A person who stays late at the office is not a hardworking person. Instead he/she is a fool who does not know how to manage work within the stipulated time. He/She is a loser who does not have a personal or social life. He/She is inefficient and incompetent in his work.
You did not study hard and struggle in life to become a machine.
If your boss forces you to work late, he/she may be ineffective and have a meaningless life too; so forward this him/her.

Leaving Office On Time

Efficient
Good Social Life
Quality Family Life

Leaving Office Late

Inefficient & Incompetent
No Social Life
Less Family Time

source

5. Company’s Brand, Public Team Pages, Social Presence

Customers are highly influenced by how a Company presents itself and value a lot the human factor.
Knowing the people behind the Company’s name, effectively seeing their faces, helps the Company make a connection to the customers.
Developers are also happy to be considered as part of the family.

Would you be happy if your girlfriend/boyfriend is afraid of speaking about you to her/his friends?

This is accomplished by providing a cool About Us page (possibly combined with a Team page).

The appearance of solidity of the Company also depends on its ability to communicate with its customers and with their broader potential audience as well (some of them might be considered potential customers).

The Company’s blog (i.e. Signal vs. Noise by 37 Signals) is one of the central places where the Company publicily states its awesomness.

Don’t forget to write frequently stuff that matters and to spread every post across your online accounts (i.e. Facebook, Twitter, Google+ and Linkedin).

Your very same developers will look forward to sponsor autonomously your online presence.

To wrap things up:

Abouts Us page
Our Team page
the Company’s Blog

Some examples of About Us pages:

6. Tech Events Presence

Make your developers upgrade their skills by encouraging them to join tech related conferences and events.
Try to tag your Company’s name to these events as well as hackatons, for example via sponsorships and by hosting some events in your own offices.
Other developers will know your name, and will be attracted to you.

Tech companies will consider your company as a reference for the technologies your name is associated with.

7. Embrace Remote Work

As an employer, restricting your hiring to a small geographic region means you’re not getting the best people you can. As an employee, restricting your job search to companies within a reasonable commute means you’re not working for the best company you can. Remote

8. Invest on Innovation

Don’t ever stop to move, your developers want to keep up with technology advances so you should too.
This also helps you to differentiate your offerings and to be ready to catch up with the new competitors that will, without any doubt, start by default to use the new opportunities.

Nothing lasts forever, so do programming languages and frameworks.

If you stick only with one programming language (be it PHP or Java), you’re already losing some opportunities.
Nowadays, the cool kids on the block are Ruby, Node.js, Go and some purely functional programming languages. Some of them are based on the JVM.
You should always strive to keep up with the state of the art, no less.
You can’t innovate if you stay behind this line.
If you don’t allocate enough time to experiment (for example, see 20% Projects), you won’t ever start using the new available stuff and you will slowly and inadvertently slow down your efficiency becoming the old Mammuth Companies you were mocking when you started.

Scratch Your Own Itch (Ruby edition)

olistik — Sun, 02 Feb 2020 17:55:54 +0000

If you feel perfectly comfortable using a tool it means that you haven't used it enough. - me

This is why I'm creating some tools (Ruby gems) to help me feel more comfortable when developing software.

Scratch 👏 your 👏 own 👏 itch 👏.