Larry Price

And The Endless Cup Of Coffee

Convincing Rvm to Let You Use Ruby 2.1.0

| Comments

Ruby 2.1.0 went stable a few months ago, and Ruby 1.9.3 support will end in a just over a year.

You know what that means: Warplanes in the sky falling to the ground, dogs and cats getting along like old pals, and people wandering aimlessly through the streets trying to remember the last time they saw a green build.

Believe it or not, all of these things can be prevented. Once upon a time, I wrote about configuring and using rvm to control individual ruby environments for each of your projects. If it’s been a while since you installed your copy of rvm, you might have some trouble installing and using newer version of ruby. Lucky for us, those clever rvm developers made it easy to get around this.

In my case, I want to upgrade a project to use ruby 2.1.0. The first time I tried to run rvm install ruby-2.1.0, I ended up installing ruby-2.1.0-preview1. I realized that I had installed rvm on this machine around October 2013, and ruby 2.1.0 was released in December 2013, so rvm had no idea that ruby 2.1.0 was stable. Updating rvm (in the root of the project directory):

/home/lrp/Projects/2014/projNeedingRuby210
1
$ rvm get stable

There will be some amount of text on the screen if your system needs to be updated. Note that you must be connected to the internet if you want rvm to update. Now we do the install of our brand new ruby:

/home/lrp/Projects/2014/projNeedingRuby210
1
$ rvm install ruby-2.1.0

Again, text on the screen from fetching of data from the internet. But hopefully you see something that tells you the operation was successful. You can also verify which rubies you have installed using the list command:

/home/lrp/Projects/2014/projNeedingRuby210
1
2
3
4
5
6
7
8
$ rvm list rubies
   ruby-1.9.3-p448 [ x86_64 ]
=> ruby-2.0.0-p247 [ x86_64 ]
 * ruby-2.1.0 [ x86_64 ]

# => - current
# =* - current && default
#  * - default

Now we tell our current project to use ruby 2.1.0:

/home/lrp/Projects/2014/projNeedingRuby210
1
2
3
4
5
6
7
8
9
10
$ rm .ruby-version .ruby-gemset
$ rvm [email protected] --create --ruby-version
ruby-2.1.0 - #gemset created /home/lrp/.rvm/gems/[email protected]
ruby-2.1.0 - #generating projNeedingRuby210 wrappers.
$ rvm gemset copy [email protected] [email protected]
Copying gemset from [email protected]by210 to [email protected]
Generating gemset wrappers [email protected]
Making gemset [email protected] pristine.
$ which ruby
/home/lrp/.rvm/rubies/ruby-2.1.0/bin/ruby

Alright! Crisis averted. If you’re using bundler with this project, be sure to change your ruby version (usually located near the top of the Gemfile).

What about setting up a new project using ruby 2.1.0? Easy! Switch to the project directory and:

/home/lrp/Projects/2014/newRubyProject
1
$ rvm [email protected] --create --ruby-version

Oh, rvm, you make life too easy sometimes.

Letting the Browser Decide Betwen HTTP and HTTPS

| Comments

While working on SEP Labs’ Health2Wealth app, I got my first taste of setting up a website to use secure connections. I’ve been using the browser extension HTTPS Everywhere for quite some time now, so all of the web pages that I visit attempt to using HTTPSinstead of the standard HTTP. When I inadvertently started testing our app with HTTPS, things got a little weird.

My machine was able to open most of a page, but it wouldn’t load some of the graphics or javascript we had embedded in the page. I was the only one able to reproduce it, so we chalked it up to a wonky machine. Then I suddenly remembered that I was using HTTPS Everywhere. I found the area in FireFox that warns you about insecure connections and found that our page was only partially loading on my browser because some of the content was insecure. From there I enabled an option to reveal the insecure elements, which forced my page to load everything correctly. So now we needed to find what was insecure about our page. I trekked through the codebase and found that some of our graphs and links were hard-coded to use HTTP. My initial thought was just to force them to use HTTPS, which is almost certainly the impending standard. With a quick search, I found that there exists a real solution to this problem.

Let’s say I have a very normal web application, so I want to include jQuery embedded in my page. I initially copy-paste <script src='http://code.jquery.com/jquery.js'></script> right into my <head> node, which normally seems fine. Unfortunately, this is where issues arise. I’m now forcing the user to make a connection which may or may not be secure to fetch data from an insecure page.

By removing the http: from the http://, the issue of deciding whether to fetch the file using HTTP or HTTPS is left to the web browser. So my script include becomes <script src='//code.jquery.com/jquery.js'></script>. This also works for links, images, and web fonts. In fact, every link included in this post uses the same principal, where I leave the protocol out of what becomes the href tag.

Custom Domain With Github Pages

| Comments

As of today, I’m the proud owner of larry-price.com. On the recommendation from a friend, I used domainmonster.com for it’s cost effectiveness and usable toolset. I wanted to link my Github Pages blog (this blog!) to my new site. In case I ever want to do this again, I’ve provided myself (and you!) with a step-by-step guide below. Note that Github has a page that explains how to do this, but there’s some fluff and ordering issues that turned me off from using those instructions as any more than a reference.

Step 0: Buy your domain

All sites where you can purchase domains have the same domains available, but at different prices. From the sites I perused, GoDaddy had the best search for domain names, suggesting different variations on the searched domain name. I found that domainmonster.com had the ugliest UI but the best prices. Hover.com looked really modern and had moderate prices. Shop around and spend money.

Step 0.5: Exercise restraint

At this point in the process, don’t go to your site.

My guess is you already have. If you don’t have the ability to go back in time, don’t sweat it, just know that you probably won’t be able to verify the fruits of your labor for a few hours.

Step 1: Setting up an ‘A Record’

Find the ip address where your site is currently hosted. For me (replace URL with your own):

1
2
3
4
5
6
7
$ nslookup larryprice.github.io
Server:   127.0.1.1
Address:  127.0.1.1#53

Non-authoritative answer:
Name: larryprice.github.io
Address: 199.27.74.133

You should be able to “manage” your domain on your domain provider’s website. In the “management” area, you should be able to find a section about “DNS”. Find something labeled “A records.” There will likely already be one or two entries here – one for the IP address of your new domain and one with the IP address of your domain with “www.” prepended.

Modify the entry (or entries) with the IP address found using nslookup (“199.27.74.133” from the example above). Save your site settings.

Step 2: Mucking with the “www” instance

While we’re modifying these settings, we might as well move the ‘www’ case out of the “A records”. Go ahead and delete it.

Look for something named “CNAME records”, or figure out how to add records in general. We’re going to add a CNAME record where the “Alias” is “www” and the “Address” is your site’s name. In my case, my “Alias” field is “www” and my “Address” field is “larry-price.com”. Add the record and cross your fingers for success.

Step 3: Telling Github Pages what to do

Alhtough Github Pages is magical in its own right, it doesn’t know what to do when receiving a request from the “A record” we created in Step 2 without further instruction.

If you’re using Github Pages for a user page, we are going to make this change on the master branch. If this is a project page, do it on the gh-pages branch.

All we have to do is put our new domain into a file in the root folder called CNAME. Let’s do it in one fell swoop of the command line.

1
$ echo "larry-price.com" > CNAME

Push that to Github and wait 0 to 10 minutes for Github to refresh your page.

Note: If you’re one of the few, the proud using the brilliant Octopress to generate your blog, you want to make sure to add the CNAME file to the root of your source/ directory. That way, when you call deploy your CNAME file will end up in the root of your _deploy directory.

Step 4: Behold

Check your Github repository’s “Settings” section. In the “GitHub Pages” section, you should now see something along the lines of “Your site is published at http://larry-price.com”. Go, young one, and visit your new site; and behold the glory you have brought to your family.

I’ll note that this is the point where not obeying Step 0.5 will cause issues. Once your internets knows that your page hit a certain DNS, it takes a few hours to refresh. In my case it only took about 2 hours, but it may take between 12 and 48 hours to refresh. A workaround to see if everything is working is to pull out your smart phone and use your carrier’s network to check your new site, since that area of the internets is probably still untainted. (All of this paragraph is a simplified thought process on how DNS works, considering that’s the level I understand it.)

Now fly, my children, and spread yourself over the internet with dozens of silly domain names!

Finishing the Google Go Writing Web Applications Tutorial

| Comments

A golang web app tutorial

I did some work with Google Go recently and had the chance to follow their great tutorial Writing Web Applications. The tutorial is pretty simple: use the Go http library to create a very simple wiki-style site. I like this tutorial a lot because there’s not too much hand-holding, but they do eventually hand you the final code listing. Then the good people at Google give you the tall task of completing the following ‘Other tasks’ without solutions:

  • Store templates in tmpl/ and page data in data/.
  • Add a handler to make the web root redirect to /view/FrontPage.
  • Spruce up the page templates by making them valid HTML and adding some CSS rules.
  • Implement inter-page linking by converting instances of [PageName] to <a href=“/view/PageName”>PageName</a>. (hint: you could use regexp.ReplaceAllFunc to do this)

This is what I’d like to go over. I scoured the web and didn’t have much luck finding solutions to these issues. That would be okay if they were all trivial, but the final step is not straightforward. I’m going to assume you’ve already gone over the tutorial. You can see my repository on Github, and I have included links to the appropriate commits in the code sections of this blog post.

Store templates in tmpl/ and page data in data/

The tutorial originally has the developer store all pages in the project directory. Every time a user made a new wiki page, a new file would creep into the project directory. All HTML templates were also stored in the project directory.

Moving templates is quite trivial. In the global scope:

wiki.golink
1
2
-var templates = template.Must(template.ParseFiles("edit.html", "view.html"))
+var templates = template.Must(template.ParseFiles("tmpl/edit.html", "tmpl/view.html"))

I found moving the page data to data/ was a little trickier, especially if the directory didn’t already exist. You may not have the same issue, but I remedied this by creating the directory if it doesn’t exist. My save function differences:

wiki.golink
1
2
3
4
5
6
7
func (p *Page) save() error {
-    filename := p.Title + ".txt"
-    return ioutil.WriteFile(filename, p.Body, 0600)
+  os.Mkdir("data", 0777)
+  filename := "data/" + p.Title + ".txt"
+  return ioutil.WriteFile(filename, p.Body, 0600)
}

Add a handler to make the web root redirect to /view/FrontPage

All we’re going to do is create a simple handler called rootHandler that redirects to a new page called FrontPage. We then add it in the main function. The tutorial had us wrap out handlers in a function call to take some special actions, but that wrapper would mess up our handler in its current form. So I just Redirect to the view handler, which will then decide whether to view or create the FrontPage.

wiki.golink
1
2
3
4
5
6
7
8
9
10
11
+ func rootHandler(w http.ResponseWriter, r *http.Request) {
+   http.Redirect(w, r, "/view/FrontPage", http.StatusFound)
+ }

...

func main() {
+  http.HandleFunc("/", rootHandler)
  http.HandleFunc("/view/", makeHandler(viewHandler))
  http.HandleFunc("/edit/", makeHandler(editHandler))
  http.HandleFunc("/save/", makeHandler(saveHandler))

Spruce up the page templates by making them valid HTML and adding some CSS rules.

I took my old .html files and put them through a validator. Making them valid only involved adding DOCTYPE, html, and head tags. The head tag needed meta, and title tags and we were valid. I’ve shown view.html below.

view.htmllink
1
2
3
4
5
6
7
8
9
10
11
12
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+<title>Wiki made using Golang</title>
+</head>
 <h1></h1>

 <p>[<a href="/edit/">edit</a>]</p>

 <div></div>
+</html>

Implement inter-page linking by converting instances of [PageName]

Converting [PageName] to a hyperlink was a bit more complicated than expected. I originally just tried to run the string through ReplaceAllFunc and replace all instance of [PageName] with an equivalent hyperlink. This does not work because we use Go’s ExecuteTemplate method to render our template. ExecuteTemplate escapes any HTML that we give it to prevent us from displaying unwanted HTML. Getting around this was the fun part, because I want the benefit of escaped HTML while still having the ability to substitute my own HTML.

As it turns out, ExecuteTemplate will not escape variables of the type template.HTML. So I added another variable onto the Page struct called DisplayBody.

wiki.golink
1
2
3
4
5
type Page struct {
     Title string
     Body  []byte
+    DisplayBody template.HTML
}

Next, I create a regular expression to find instances of [PageName] and I put the defintion above the main method.

wiki.golink
1
+var linkRegexp = regexp.MustCompile("\\[([a-zA-Z0-9]+)\\]")

In my viewHandler, I escape Body and then set DisplayBody to that escaped string with the links substituted.

wiki.golink
1
2
3
4
5
6
7
8
9
+  escapedBody := []byte(template.HTMLEscapeString(string(p.Body)))
+
+  p.DisplayBody = template.HTML(linkRegexp.ReplaceAllFunc(escapedBody, func(str []byte) []byte {
+      matched := linkRegexp.FindStringSubmatch(string(str))
+      out := []byte("<a href=\"/view/"+matched[1]+"\">"+matched[1]+"</a>")
+      return out
+    }))
  renderTemplate(w, "view", p)
}

To finish up, I modify the view.html to show DisplayBody. I don’t use printf, because that would turn DisplayBody back into a string and ExecuteTemplate would escape it.

wiki.golink
1
2
-<div></div>
+<div></div>

And that completes the extra exercises for Google’s Writing Web Applications tutorial. Hopefully one day this helps someone who gets stuck.

Setting Up a Go Environment in Ubuntu

| Comments

Some very light cajoling led me to do some investigation into Google Go (often called golang for ease of internet search). This is a brief recounting of how I got up and running on Ubuntu (first 12.04 and then 13.10). Luckily, this has been made espcially easy for us with the introduction of a golang package in the Ubuntu package repositories. There are also official installation instructions if you don’t like mine.

Open up a terminal and let loose:

1
$ sudo apt-get install golang

The download is pretty heavy, so this step may take some time. Eventually the installer for golang-go will ask you if you want to “Report installation of public packages to Go Dashboard.” I’ve been choosing “No” to this question and have no complaints.

Now comes the fun part. Serious Go development relies on having a “workspace” setup involving a specific directory structure including bin/, pkg/, and src/ directories. Google’s official set-up page contains more information about these workspaces.

I’m not a big fan of putting a visible directory in $HOME, so I opted to make a hidden directory called .go. After creating the directory, the environment variable $GOPATH needs to be set and $PATH needs to be adjusted.

1
2
3
4
5
$ mkdir ~/.go
$ echo "GOPATH=$HOME/.go" >> ~/.bashrc
$ echo "export GOPATH" >> ~/.bashrc
$ echo "PATH=\$PATH:\$GOPATH/bin # Add GOPATH/bin to PATH for scripting" >> ~/.bashrc
$ source ~/.bashrc

Now I’m going to create a go project and add a link to it in the workspace I just created.

1
2
3
$ mkdir -p $GOPATH/src/github.com/user
$ mkdir ~/hello-go
$ ln -s ~/hello-go ~/.go/src/github.com/user/hello-go

For some actual test code, I’ll add a file in my hello-go/ directory called hello.go with the following code:

hello.go
1
2
3
4
5
6
7
package main

import "fmt"

func main() {
  fmt.Println("Hello world")
}

Now I’m going to install the binary created from compiling this code into my $GOPATH to verify that my workspace is set up correctly, then I’ll run it to behold the fruit of my efforts.

1
2
3
$ go install github.com/user/hello-go
$ hello-go
Hello world

Installing is not necessary every time I want to test that my code compiles; running go build in the source directory will create a local executable that can be executed for incremental testing.

If you’re interested in learning golang, I would recommend doing the go tour. It goes way beyond a trivial hello world program and gives you some insight into many coplex go concepts (I even posted my solutions as a gist, if you’re interested).