Author: sylv3rblade

Install ruby 3.2.0 on asdf

Like clockwork, ruby 3.2.0 has been released on December 25 and given that our build tools now support it, it’s time to start trialing if our projects will be able to run on it without issue.

I’m using asdf to manage my node and ruby versions – switched them from rbenv and nvm respectively to make things a bit simpler.  Here’s what happened when I tried to install ruby 3.2.0 even after making sure asdf and the ruby plugin are updated.

That’s not good obviously.

From reading the snippet of the build error, we see two things it seems to be reinstalling openssl and is having trouble finding libyaml – both errors shouldn’t occur since my system already them  installed via homebrew.

Thankfully, the fix for this is simple.  We just need to make sure to point to existing libraries.

The lib that compiles ruby for us, ruby-build has a way to provide options for it’s builds, via RUBY_CONFIGURE_OPTS.  In my case all I needed to do is run this:

export RUBY_CONFIGURE_OPTS="--with-zlib-dir=$(brew --prefix zlib) --with-openssl-dir=$(brew --prefix [email protected]) --with-readline-dir=$(brew --prefix readline) --with-libyaml-dir=$(brew --prefix libyaml)"

After adding the ruby config opts, we’re now able to finally install ruby 3.2.0!

Add Gitlab CI to your Hanami project

I host my personal projects in gitlab because it’s free and it gives you free runners for your ci.  I recently started studying the Hanami framework in ruby and when it was time to build the test suite, I initially couldn’t properly get it to work because of a strange error.

My initial gitlab-ci.yml was as follows

image: ruby:2.5

services:
  - postgres:latest

variables:
  DATABASE_URL: 'postgresql://postgres/budget_tracker_test'
  POSTGRES_DB: budget_tracker_test
  HANAMI_ENV: test

cache:
  paths:
    - vendor/ruby

rspec:
  before_script:
    - gem install bundler  --no-ri --no-rdoc 
    - bundle install -j $(nproc) --path vendor --quiet

  script:
    - echo 'Trying to create db for develop'
    - bundle exec hanami db prepare
    - echo 'Trying to create db for test'
    - HANAMI_ENV=test bundle exec hanami db prepare
    - rspec spec

Pretty straightforward right? But for some reason I was encountering this error:

Could not find executable in your PATH: `createdb`
/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator/postgres_adapter.rb:104:in `rescue in call_db_command'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator/postgres_adapter.rb:97:in `call_db_command'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator/postgres_adapter.rb:36:in `create'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator.rb:287:in `create'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator.rb:332:in `prepare'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator.rb:247:in `prepare'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-1.2.0/lib/hanami/cli/commands/db/prepare.rb:26:in `prepare_database'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-1.2.0/lib/hanami/cli/commands/db/prepare.rb:17:in `call'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-1.2.0/lib/hanami/cli/commands/command.rb:85:in `call'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-cli-0.2.0/lib/hanami/cli.rb:57:in `call'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-1.2.0/bin/hanami:6:in `<top (required)>'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/bin/hanami:23:in `load'
	/builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/bin/hanami:23:in `<top (required)>'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `load'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `kernel_load'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:28:in `run'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:424:in `exec'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:27:in `dispatch'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:18:in `start'
	/usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.2/exe/bundle:30:in `block in <top (required)>'
	/usr/local/lib/ruby/site_ruby/2.5.0/bundler/friendly_errors.rb:124:in `with_friendly_errors'
	/usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.2/exe/bundle:22:in `<top (required)>'
	/usr/local/bundle/bin/bundle:23:in `load'
	/usr/local/bundle/bin/bundle:23:in `<main>'
ERROR: Job failed: exit code 1

So I looked up some of the discussions on the issue tracker on Hanami’s github and I found this still open issue with Hanami still requiring a local postgres instance :|. Anyway, cart before the horse, I ended up using the postgres service while manually installing postgres in the ruby image just so I could run my specs proper.y

Here is my `gitlab-ci.yml` now

image: ruby:2.5

services:
  - postgres:latest

variables:
  DATABASE_URL: 'postgresql://postgres:postgres@postgres/budget_tracker_test'
  HANAMI_ENV: test

cache:
  paths:
    - vendor/ruby

before_script:
  - apt-get update -qq && apt-get install -y -qq postgresql postgresql-contrib libpq-dev cmake
  - gem install bundler  --no-ri --no-rdoc
  - bundle install -j $(nproc) --path vendor --quiet 

rspec:
  script:
  - bundle exec hanami db prepare
  - bundle exec rspec spec

After pushing this to gitlab, viola!

Starting fresh and with a new goal

I started thinking about it early last year and I guess it’s nigh time I took my current hobbies seriously (I mean, hey I’ve given myself loads of time to prepare already).

sigIt’s a work in progress but I’m hoping to get things set up quick so I can move forward with other, more important things (like actual shoots) :D.

Use PRY with rails console

I love pry.

Aside from prettifying the output of your terminal when debugging, it is a bit more handy thanks to it’s extra features. Here’s a railscast to see what you can do with pry.

If you want to use pry as the default shell for rails console you can simple open up your config/development.rb file and add:

MyApp::Application.configure do
  # start copying here
    silence_warnings do
        begin
            require 'pry'
            IRB = Pry
        rescue LoadError
        end
    end
   # end copying here
end

and ensure that pry has been added to the Gemfile.

or if you want a one liner approach (one line of config and a bundle install to be clear), just add the pry-rails gem to your Gemfile

gem 'pry-rails', :group => :development

Back to my roots

After a looong blogging hiatus, I’m finally posting an update.

A lot has happened (some good, some bad) but for what it’s worth, I’ve learned LOTS of things.  Now that I have some time on my hands and have found the need to reorganize, I thought I’d handle a bit more of my postings online.

Some currently in progress:

  • Simplicity for Project Alter (and Project Alter itself)
  • Crown Carnival
  • Reviving some of my default blogs including this one
  • A few photography stints ( still looking for an account to handle this.  maybe a DA account)

DRYing HTML using content_for and helpers

I recently encountered a scenario where I needed to dry up some HTML code for a navigation snippet that needed to appear on both the top and bottom of my main content. Here’s a snipped version of the code

<div class="tablenav top row">
   <div class="somenavigationfunction"></div>
   <div class="anotherfunction"></div>
   <!-- 
      Some code for the navigation here
    -->
</div>
<div class="display row">
   <!-- 
      Main display page here
    -->   
</div>
<div class="tablenav bottom row">
   <div class="somenavigationfunction"></div>
   <div class="anotherfunction"></div>
   <!-- 
      Some code for the navigation here
    -->
</div>

The code that I need repeated divs with tablenav classes. The usual way to go about this is using content_for and yield:

<% content_for :tablenav do %>				
   <div class="tablenav top row">
      <div class="somenavigationfunction"></div>
      <div class="anotherfunction"></div>
      <!-- 
         Some code for the navigation here
       -->
   </div>
<% yield :tablenav %>
<div class="display row">
   <!-- 
      Main display page here
    -->   
</div>
<% yield :tablenav %>				

A bit DRY-er now right? The problem with this approach is that both instances of the yielded output sports the same set of classes. This is good most of the time but in my current usage, I need the top instance to use a “top” class while the bottom one needed a “bottom” class for proper padding. I could simply add another div to wrap each of the yield lines but that’s requires me to edit the css file to reflect the change. Here’s the solution I came up with using content_for and helpers:

<% content_for :tablenav do %>				
   <div class="tablenav top row">
      <div class="somenavigationfunction"></div>
      <div class="anotherfunction"></div>
      <!-- 
         Some code for the navigation here
       -->
   </div>
<%= nav_block("top") %>
<div class="display row">
   <!-- 
      Main display page here
    -->   
</div>
<%= nav_block("bottom") %>

And the code for the helper

def nav_block(location = nil, &block)
  content_tag("div", content_for(:tablenav), :class => "tablenav #{location} row").html_safe
end

Just fire up the page in your browse and watch it work :). Now how exactly did this works? Turns out that content_for can also be used to output it’s contents. If you’re wondering why yield wasn’t used is because it simply doesn’t work with helpers. If you tried to use yield, you’ll end up with the following LocalJumpError: no block given (yield).

Important Note: I’ve only tested this on Rails 3.x, Rails 3.2 to be exact.
Hope that helps.

[Linux] changing file or folder permission recursively

I recently encountered a permissions problem when installing a new application on my Wiredtree VPS.  The crux of the problem was some of the necessary files have the wrong access permission thereby rendering the application almost inoperable.  To fix that, I needed to change permissions of a whole lot of files and folders.  And while I could’ve changed the permissions individually, it would’ve taken quite a long time so here’s what I found to work

To set all the folders to 755:

find . -type d -exec chmod 755 {} \;

To set all files to 644:

find . -type f -exec chmod 644 {} \;

Let’s say you want to change the permissions of files that end only in .rb and set it to 755 (pattern escaped with slashes)

find . -name \*\.rb -exec chmod 644 {} \;

Simple right?

ArgumentError: invalid byte sequence in US-ASCII

If you’re on Ruby 1.9.2 and have started getting this error when trying to install gems (either by gem install or bundle install), your environment is simply missing the LANG variable and is loading up US-ASCII by default.

To fix this, simply run the command below before installing anything

export LANG=en_US.UTF-8

or to make it more streamlined, add it to your .bashrc or zshrc (if you’re using the zsh shell).