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:
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:
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.
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.
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.