Recently, I had the task of speeding up the response time of an app that depended on a remote API. The issue was that the API could take a long time to respond in some cases, plus four seconds. Four seconds is way to long to wait for a web page…

When you’re developing Rails apps or pretty much any other framework you can name, you typically work with a server running on localhost. This is all well and good until you need to access it from a different location.

I occasionally write about encryption in Ruby, yet somehow I haven’t managed to cover my friend Ara’s Sekrets gem.

Sekrets provides a simple interface to create and manage encrypted files in Ruby. It’s raison d’être is to make it reasonably painless to store sensitive data, API keys and the like, in Git repos and then access that data inside your Rails app, both in development and production.

Hit a bug, couldn’t find the answer, documenting it here for the next person.

I’m working on a Rails project where I need SSL in development. The simple way to do this is with the thin gem for example http://www.railway.at/2013/02/12/using-ssl-in-your-local-rails-environment/

It had been working (on OS X El Capitan), but suddenly thin started blowing up on me, either the server wouldn’t start with:

1
2
3
-bash(3373,0x7fff71f87000) malloc: *** error for object 0x100007f9132d01e4: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Or the server would start but would blow up on HTTPS requests:

1
2
Unexpected error while processing request: negative string size (or size too big)
  /blah/blah/blah/eventmachine-1.0.8/lib/em/connection.rb:488:in `get_peer_cert'

The Emacs Visual Bell issue I previously wrote about has been fixed.

As I understand it, the issue was that the old NexTSTEP visible bell code accidentally depended on an object not getting garbage collected and that improved GC in El Capitan finally caught up with it.

The bell code has been complete reworked to use a NexTSTEP warning icon instead of flashing the screen.

Last week I wrote about my issue with Emacs’ visible-bell on OS X El Capitan. I figured it was about the most esoteric thing I’ve written, but it may have gotten more comments then any other post. I’m not sure if that’s good or bad…

In any case, before coming up with my work-around, I first tried rebuilding Emacs, in case the issues had been already fixed or simply re-compiling/re-linking would take care of it. That didn’t help, but this is fine time to revisit building Emacs from source on OS X.

After I upgraded to OS X El Capitan‎, I started having random display issues with my build from source version of Emacs. After a while I realized that it was caused by the visual bell. I hate terminals/widows beeping at me, so I always set:

1
(setq visible-bell t)

in my .emacs. However, under El Capitan this smears (for lack of a better word) the center of the window with bits of zoomed in text.