macOS High Sierra is out and it’s time once again to build Emacs. Nothing has really changed since my 2017 Sierra update, but let’s put it all together…

If you try to build Ruby 1.9.3 using rvm install ruby-1.9.3-p551, it will barf with compiler errors. The workaround, found here, is to use:

1

rvm install ruby-1.9.3-p551 --with-gcc=gcc

You will get a warning:

Ruby ‘ruby-1.9.3-p551’ was built using clang - but it’s not (fully) supported, expect errors.

However, I have run into any errors.

Yes, 1.9.3 is not supported and, in a perfect world, I would be able to upgrade projects using it.

No, I don’t care if you hate RVM.

A quick update to Building Emacs on macOS Sierra. I recently had to rebuild Emacs due to brew updating the version of libjpeg. My walk-through almost works, however the Emacs build now depends on a newer version of makeinfo (part of the texinfo suite) than the one that ships with Sierra.

An update to my somewhat popular How I Start Rails Projects post. As before, I start with:

1
2
3
4
5
6

rvm use 2.4.1@project-name --create
gem install rails
rails new project-name
cd project-name
rvm use 2.4.1@project-name --ruby-version
echo '/.ruby-*' >> .gitignore

The only change is bumping Ruby to 2.4.1.

But this leads to a rant:

Ever put your Mac to sleep only to come back find it’s still awake? This happens because something is telling the power management subsystem it can’t sleep yet.

A quick one today — creating S3 Static Website Hosting redirects with the AWS CLI. Clients often want to have www.example.com redirect to example.com or vice versa. Why? Because SEO. I suspect “SEO” is smart enough recognize one site with two URLs, but hey, I just work here.

It’s easy enough to do this sort of thing in Apache or NGINX. However, if the real site is in AWS, especially CloudFront, I like the simplicity and single purposeness of using S3 Static Website hosting to for redirects.

OK, you’re in a situation when you can’t use cookies, specifically you’re in an iframe and Safari will only accept a cookie in an iframe if the browser has already visited the site outside of the iframe. Without cookies, there are no sessions. The simple work around is to force the user to visit the site directly, but that’s often not an option. What’s Plan B?

So, I’ve looked at the utility and security of cookies and I’ve at looked the utility and security of sessions. It you’ve been following along, then you know that sessions are great, they provide a secure way to verify who you are talking to.

Sessions are great. Great that is — until you can’t use them.

Sessions depend on cookies, and you can’t always use cookies. When can’t you use cookies? Safari in an iframe for one. I do a lot of integration work, add ons for various platforms, and typically you add on is embedded via iframes.

A quickie this time. I use Capistrano to deploy my Rails apps. There was a gem for Capistrano 2 that added an ssh command as in:

1

cap production ssh

This would open an SSH connection to the production server and cd you to the current directory for the app. Super handy if you work on a lot of projects and don’t want remember what the server names and deploy paths for all of them.

The Capistrano 3 has a much different internal structure and the gem is long abandoned. Fortunately, it’s easy to recreate this functionality in a view lines of code.

Last time I took a reasonably deep dive in cookies. Cookies can keep state information and setting for visitors to a site. However, by default they aren’t secure, being sent in the clear and easily modified. You can turn on security option, but an even easier is stepping up to sessions.

“Sessions” are a common concept across web development platforms, but interestingly, they are actually a standard like, say, cookies.