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:
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.
An update to my somewhat popular How I Start Rails Projects post. As before, I start with:
1 2 3 4 5 6
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.
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.
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:
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.
I’ve been working on a post about using JWTs JSON Web Token (JWT) when you can’t use HTTP cookies for sessions. As I dug into it, I came to realize that understanding the risks of using JWTs requires a bit of understanding about how HTTP cookies (and session) work. So, here’s a primer.