Plough => Ruby Journey through ruby

Yarn Install On Mojave


layout: post title: Yarn install on Mojave date_string: 27 September 2019 —

If you’re having issues in yarn install on Mojave, then it’s probably down to the fact that Mojave doesn’t support different i386 architecture and anything that involves native building, gems or node modules, seems to fail. The solution is to clean the slate and start fresh. That’s exactly what I had to do to fix the yarn installation errors:

rm yarn.lock
yarn cache clean
yarn install

These commands worked like a charm!

Hope it helps!

Installing Ffi 1.11.1 On Mojave


layout: post title: Installing ffi 1.11.1 on Mojave date_string: 27 September 2019 —

If you’ve installed to Mojave and are frustrated by the errors you get on installing ffi (1.11.1), then this blog post is for you.

I had the same issue last week and after trawling through the internet and trying every possible suggestion, one finally worked!

But, before that, a little discussion on the actual error is in order. Below is a small snippet of the actual error on bundle install:

Configuring libffi for i386
configure: error: in `/Users/andhapp/Projects/github/startup/pimful/vendor/ruby/2.6.0/gems/ffi-1.11.1/ext/ffi_c/libffi-i386':
configure: error: C compiler cannot create executables
See `config.log' for more details
make[1]: *** No targets specified and no makefile found.  Stop.
make: *** ["/Users/andhapp/Projects/github/startup/pimful/vendor/ruby/2.6.0/gems/ffi-1.11.1/ext/ffi_c"/libffi-i386/.libs/libffi_convenience.a] Error 2

libffi is trying to configure for i386 architecture. Mojave doesn’t support that architecture, so the actual linking file is missing. A peek into the config.log reveals that fact:

ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd
ld: dynamic main executables must link with libSystem.dylib for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

There are several suggestion to actually link the file present in Mojave and make the missing file available that way, but that doesn’t work either.

After several frustrating hours, the following suggestion worked perfectly:

brew reinstall libffi

export LDFLAGS="-L/usr/local/opt/libffi/lib"
export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig"

Reinstallation of libffi installs it correctly for Mojave and then bundle install works like a charm.

Hope it helps!

Dont Blindly Follow Blog Posts


layout: post title: Don’t blindly follow blog posts date_string: 06 October 2016 —

Technlogy changes fast!

And it’s a blatant fact.

And with changing technology opinions, benchmarks and blog posts become obsolete, fast.

I was reading a blog post recently about adding some performance related gems to improve rails’s performace. It’s a very nice, detailed article with benchmarks.

Instead of just blindly adding the suggested gems to the project, I ran the scripts again and found that:

  • escape_utils gem makes things worse on ruby 2.3.1 and rails 5, so no point in adding it.
  • fast_blank gem, on the other hand, makes things slightly better, so definitely worth adding. With slightly better I mean you are able to make more requests/sec.
  • je and jemalloc gem didn’t install for ruby 2.3.1 at all.

Well, the point of this short blog post was to make you aware that blog posts go out of date and sometimes it’s necessary to re-evaluate the findings and ensure you are adding the gems for the right reasons.

Hope it helps!

Use Sequel For Non Rails Ruby Apps


layout: post title: Use Sequel for non-rails ruby apps date_string: 14 September 2016 —

I am writing a ruby script to retireve some data via HTTP call and then add it to the database.

Now, I decided to use ActiveRecord as an ORM and wrote a gem for the same.

Nothing complicated. It’s just a Rakefile that provides popular activerecord rake tasks.

But, then I stumbled across blog post on Sequel and I feel Sequel is a better choice for an ORM for a non-rails app.

Why?

Because, Rails is opinionated.

And it’s nuances works nice for a Rails app.

Anything outside of the realms of a standard Rails app and all bets are off.

It is like fitting a square peg in a round hole. It’s possible but you will have to shave off the extra bits.

Sequel on the other hand seems like a better fit for a ruby script.

Will post my experience with Sequel. It has ample documentation and the project was last updated on 16th September 2016. There are no outstanding pull requests or issues on github which implies the project is active and nicely looked after.

Improve Bundler Cli


layout: post title: Improve Bundler CLI date_string: 29 August 2016 —

Learn another programming language.

Learn from another programming ecosystem.

Learn from another programming language’s tools and bring it back to the language you love.

Fact is, I love Ruby!

However, I’ve been spending a lot of time with Node.js lately. NPM provides a nice way to install any new packages straight from the command line, like:

npm install react --save

I like this convenience.

With an intention to improve Ruby’s ecosystem and tools, I would like to bring this to Ruby.

So, I’ve added a new issue to Bundler. Let’s see what others feel about it.

Update - 31 August 2016

I had a couple of responses for my Bundler issue and it turns out there is indeed a way to add gems via bundler’s CLI.

You can use the inject command like this:

bundle inject pg 0.18.4

You have to specify the exact version that you want to add though.

Next version of Bundler is going one better and will expose add command that will add the gem without needing a version number.