Austin on Rails – July 28, 2015

I’m saving some notes from the second talk of this Austin on Rails meeting so I don’t lose them somewhere on my phone.

Securing Rails for the Enterprise – Marcus J. Carey

Marcus was that rare speaker: very casual, very entertaining, and very informative.

Here are some of the tools he mentioned.

General Purpose Tools

  1. PaperTrail – A tool to manage your logs. He recommends only logging errors so it’s really obvious when something is happening.
  2. Burp – General purpose security, most basic tool, number 1 most used tool by people who will try to break in.
  3. Zap – General purpose security tool.
  4. Nikto – General purpose security tool.

Rails-specific

  1. Breakman – Rails-specific security scanner
  2. Bundler audit – checks your gems and gem dependancies for vulnerabilities
  3. Gem Canary – Similar to bundler audit.
  4. Devise – secure authentication!
  5. Devise-zxcvbn – rejects weak user passwords
  6. devise-security-extension – enterprise-level security for devise
  7. devise-google-authenticator – add 2-factor auth to your app that works with Google’s Authenticator app.
General Rails advice:
  • User models should never inherit from active-record::base
  • Use uuid’s instead of sequential ids/keys
  • Rely on current_user from devise instead of anything else
  • No capitals in the controller!

Tips and Tricks: Gem pristine

A while ago, some friends and I were doing some code exploration inside gems, trying to figure out how they worked. All was well and good until we had changed everything and broke the gem. Here are a few great commands for playing around with this stuff, and then resetting it when you are done so everything on your system still works the way it is supposed to.

To open a gem in your default text editor and poke around it’s squishy inner bits:

bundle open GEMNAME

EX:

bundle open rake

Once you are done playing around and just want things to go back to the way they were, there are two good commands to know.

For when you have bundler set up to install gems to a local vendor directory, and that is the gem you were playing with:

bundle exec gem pristine GEMNAME

Or if you want to restore all the possible versions of a gem:

gem pristine GEMNAME

Happy hacking!

Austin on Rails presentation: How to Make a Ruby Gem

I gave the beginner presentation at the January 2014 meeting of Austin on Rails. I was pretty nervous, but I think it went pretty well, and was surprisingly fun. I’ve embedded the slides below, and I’ll add a few more resource links too.

A few notes

Markdown for Readme’s

It seems a lot of people crank about writing documentation, so I wasn’t looking forward to writing some for Wikiwhat, but I knew it was important, not just to for the sake of doing it, but because as the n00biest of n00bs, I wanted someone with no idea of how things work to be able to use our gem easily, on the off chance anyone would want to use it. However, it turned out that writing the documentation for Wikiwhat was way easier than writing lab reports or manuscripts, and I had a lot of fun doing it.

If you have never used markdown before, this page is a good summary of the basics of markdown syntax.

Use Mou

Mou is a great Markdown editor that shows you what you markdown will look like as you are writing it. I found this really helpful as I was experimenting with the different formatting options in Markdown. It can also do a bunch of other fancy things. The one catch is that it does not currently support Github-flavored Markdown, so Github-specific Markdown will not be rendered correctly. To check anything Github-specific, you will have to check out one of the Github-flavored markdown previewers.

Make Internal Links

This one tripped me up for a while, but it’s secretly really easy.

[Google](http://google.com)

gives a link to google like so:

Google

But I wanted to make links within a page, so someone reading the README could jump to the section they wanted to read without scrolling though the whole page. Github makes this easy by turning any header into an internal anchor point!

[Usage](#usage)

will make a link to the ‘Usage’ header lower down on the page. If the header text is more than one word, the text is converted to all lowercase with dashes (-) replacing the spaces, like so:

[A Header With Multiple Words](#a-header-with-multiple-words)

Specify the language

You will probably want to have code examples in your README. Github will syntax-highlight them for you correctly if you tell it what language it is. When you make a code fence, specify the language immediately after the first ‘fence’ for correct syntax hilighting.

```ruby
<ruby code>
```

Ruby Gem: Wikiwhat. It’s alive!

We did it! One functional Ruby gem, made!

If you didn’t come to career day, you can check out our presentation (above) or our github repo: Wikiwhat. You can find Bonnie, my partner in crime on this endeavor @BonMatts on Twitter.

Of course, there are a lot of bits and pieces to still work on, and we have a ton of features we’d like to add, but I’m pretty happy with how well it turned out.

And hey! Jimmy Wales retweeted us! That was pretty cool. :D

Writing a Ruby gem!

For my final project, I’m working with Bonnie Mattson on a Ruby gem, currently called ‘Wikiwhat’, for the Wikipedia API! This is a really fun project, and also really challenging. The last few weeks of class have focused on working with frameworks and engines, and less on writing basic Ruby code, so it has been a nice change of pace.

One of the first challenges for this project has been getting the gem to build and install correctly. We use bundler to install and manage gems for our projects. Awesomely, we can also use it to build our gem too!

Here is a short outline of the process.

  1.  Use bundler to create a scaffold directory for the gem. This is nice because it takes care of a lot of details that are potentially easy to forget, like listing all the files that should be included in the gem.
bundle gem <GEMNAME>
  1. Write your gem! (no, it didn’t go that quickly, but you get the idea)

  2. Build your gem! A hint here is that you need to include the version number in your build command. Also, include the .gemspec file ending. (UPDATE: This is not where you include the version number. That is later!) EX: gemname.gemspec

gem build <GEMNAME>.gemspec

This will build your gem in the directory where you run this command.

  1. In the same directory, run the install command:
gem install <GEMNAME-version>.gem

It did take us quite a while to get to this point. We definitely had some malformed files and/or structure in our gem such that it either would not build or would not install. A few of the problems we had:

  • Bad require statements – It does not like it if things are named badly, or if you are trying to require '' or similar. I can’t remember why we thought we needed it, but you don’t! Don’t do it!
  • Incorrect naming or file structure – The gem builder/installer really really wants things to follow a semi-strict naming convention. Inside lib/, the main .rb file needs to be named the same as your gem name. If you have any additional code files, those need to be stored inside a folder that is named the same as your gem and main file.
    EXAMPLE:

    .
    ├── wikiwhat.gemspec
    └── lib
        ├── wikiwhat
        │   └── api_call.rb
        └── wikiwhat.rb

The final challenge was to be able to require it in IRB and run a command!

  1. Open IRB and require the gem:
require 'GEMNAME'

If it returns true, you’re 99% of the way there!

  1. Run a command! Obviously, this one is going to vary from gem to gem. If it works the way you expect, you are done! In our case, we ran our call method:
Wikiwhat.call("Albert Einstein")

And got back the first paragraph of the wiki article on Albert Einstein, just like we wanted. Yay!

 

Resources:

  1. So far, we have mainly used this great guide from RubyGems.org.

  2. I also really enjoyed this podcast on Ruby Gems from Ruby Rogues.