Tag Archives: ruby

Notes on Go, part 7 of ∞

Posted on by

Coming to Go from Ruby has been an experience and a half. A lot of the things I’ve stubbed my toes on are either vocabulary things, or things that I don’t know about because I’ve never really used a statically typed language before.

A map is a hash table is a ruby hash

Lets start by paying a visit to Wikipedia, the repository of all modern knowledge.

Default values are unexpected

In Go, some types have a default value (probably to deal with the whole static typing thing???). For example, the default value of a boolean is false.

Similarly, ints also have a default value of 0.

So if I initialize a map of strings and ints, I get a number back, even if that key doesn’t exist in the map.

Multiple returns strike again

To solve the default value problem, Go offers optional multiple returns when querying a map/hash.

Now, when I query the map, I can then check the value of ok, which will return false if the key didn’t actually exist in the map.

The multiple return collection is optional. If I remove the ok assignment, Go will not complain.

make() vs literal syntax

There are two ways to initialize a map. You can use the make() syntax:

Or you can use the ‘literal’ syntax, which I’ve used the the previous examples. Arbitrarily, I like the literal syntax. Maybe I just like curly braces.

Resources

A Tour of Go
Go maps in action
Go By Example
Effective Go

Austin on Rails – July 28, 2015

Posted on by

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!
  • When a test is especially short or simple compared to the application code it tests, lean toward writing the test first.
  • When the desired behavior isn’t yet crystal clear, lean toward writing the application code first, then write a test to codify the result.
  • Because security is a top priority, err on the side of writing tests of the security model first.
  • Whenever a bug is found, write a test to reproduce it and protect against regressions, then write the application code to fix it.
  • Lean against writing tests for code (such as detailed HTML structure) likely to change in the future.
  • Write tests before refactoring code, focusing on testing error-prone code that’s especially likely to break.

— Michael Hartl, Ruby on Rails Tutorial

Writing regular expressions in the context of a new programming language

Posted on by

One of the things that is kind of annoying about regular expressions is that every programming language implements them slightly differently. If you can, find someone who can give you the low-down in this new language. Otherwise, you’ll have to stick with googling, which can take a while to figure out what you need. I’ll get you started with a few languages.

General Resources

Two of my favorite and most helpful resources:

  • RegExPlanet.com: lets you test regular expressions in many different languages.
  • Regex Cheat Sheet: has a pretty comprehensive general overview of regex syntax.

Regular Expressions in Ruby

One of the easiest ways to get started with regular expressions in Ruby is via Rubular.com. This site provides a way to test regular expressions against any text, as well as a quick cheat sheet to help. RegExPlanet.com also has a Ruby tester that is in beta.

Regular Expressions in Java

For help with Java, I really like using the tester at RegExPlanet.com. It does two really cool things.

  1. Different Java methods (apparently) use regular expressions differently. RegExPlanet.com shows if and how a regular expression will work with each of the methods.
  2. RegExPlanet.com also provides the ‘Java string’ for use in Java methods. In Java, we have to escape the backslashes with additional backslashes. This can get pretty confusing very quickly, so having RegExPlanet.comgenerate that string for me is very helpful.

Regular Expressions in JavaScript

Using regular expressions in JavaScript was where I really began using the pattern modifiers. If a regular expression is between two forward slashes, pattern modifiers are the letters that come after the last forward slash.

/hello/i

This regular expression will match the word ‘hello’ as well as capitalized ‘Hello’, and all caps ‘HELLO’. It will even match the super fancy ‘hElLo’, if you are into crazy stuff like that. The i modifier tells the regular expression to be case-insensitive.

Another really useful modifier for regular expressions in JavaScript is g, which stands for ‘global’. In JavaScript, regular expressions will find the first time it matches a pattern and then stop. Using the g modifier tells it to find ALL the instances where a string matches the given pattern.

Some things I learned about case statements in Ruby

Posted on by

I’ve been working with case statements in Ruby, and I was having a difficult time getting it to do what I wanted.

Things I learned:

  1. Case statements that take an argument after the case (ex: case SOME_VARIABLE) can’t take logic after the when part of the statement.

    Bad:

    case thingie
when thingie.match(/some regex/)
# something cool happens
end

    Good:

    case thingie
when "a perfectly boring string"
# something cool happens
end
  2. Case statements that do not take an argument after the case CAN take logic after the when

    Good:

    case
when thingie.match(/some regex/)
# something cool happens
end

Tips and Tricks: Gem pristine

Posted on by

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

Posted on by

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

Tips and Tricks: JSON in IRB or Pry

Posted on by

Trick one: Parse your raw JSON objects when you pull them in.

For our Ruby Gem project, we were pulling down JSON-formatted data from the Wikipedia  API. To successfully work with JSON in IRB, I imported the object with an HTTP gem and then parsed the JSON data with the JSON gem. EX:

require 'json' 
require 'rest_client' 
JSON.parse(RestClient.get <URL>)

Which gives us a nice Hash output that looks like this:

{"query-continue"=&gt;
    {"images"=&gt;
        {"gimcontinue"=&gt;"736|Citizen-Einstein.jpg"}},
    "query"=&gt;
        {"pages"=&gt;
            {"-1"=&gt;{"ns"=&gt;6, "title"=&gt;"File:1919 eclipse positive.jpg", "missing"=&gt;""},
             "-2"=&gt;{"ns"=&gt;6, "title"=&gt;"File:Albert Einstein's exam of maturity grades (color2).jpg", "missing"=&gt;""}}}}

Without parsing, the information was still in JSON format, a thing that looked like:

"{\"query-continue\":{\"images\":{\"gimcontinue\":\"736|Citizen-Einstein.jpg\"}},\"query\":  ...

with extra quotation marks and all the backslashes, and Ruby got pretty cranky about trying to work with that string.

Trick Two: ‘puts’ your JSON

For another project, I was converting hashes into JSON, and I was getting a bit frustrated. I was quite certain that I was converting the hash into JSON correctly, but I kept getting extraneous backslash-escaped quotation marks in my JSON returns like before.

"{\"query-continue\":{\"images\":{\"gimcontinue\":\"736|Citizen-Einstein.jpg\"}}, ...

Thanks to some StackOverflow googling, I realized/remembered that this was because I was directly calling the JSON in the console, instead of puts-ing it from within the script I was running. When I used a puts statement inside the script, I could see that my output was actually formatted correctly, as I expected. Using puts in the console also worked to show me the JSON with it’s correct formatting.

puts <JSON>

instead of

<JSON>

Data Structures: The Secret Life of Hashes

Posted on by

A drawing of the structure of a hash

SPOILER: A hash is secretly an array. Each position in the array contains another array. The inner array contains the key at position [0] and the value at position [1].

I’ve had a few people say they liked seeing my notes, so I’m going to try and make a few posts with what I think are the more key bits of a few lessons! I hope this will also make me write about more complicated topics instead of basic procedural outlines.

The lesson here was our introduction to understanding the inner workings of data structures. Specifically, arrays and hashes.

The cool thing I learned is that hashes are full of secrets.

Specifically, Hashes are secretly Arrays, but disguised by their curly brackets. The cool way Hashes disguise themselves as paired values in no particular order is through nested Arrays and a .hash method which does some secret math. As you might be able to tell from my drawing (click on it to make it bigger), a Hash is just an Array. But it is a fancy Array! The size of the Array is defined ahead of time (by the Ruby computer-brain), and each spot in the array is set to nil. Then, when we add a key => value pair to the Array, some magic happens.

  1. The Ruby computer-brain runs .hash on the key. This generates a pretty large and (mostly) unique number.
  2. However, the Ruby computer-brain don’t actually want (or need) a gigantic Array with hundreds of thousands of places filled with nil values, so it uses the modulo (or remainder) % to make it smaller. Specifically, it divides the giant hash number by the number of spots in the Array.
  3. The modulo gives the Ruby computer-brain the remainder of that division operation, which by definition, has to fit inside the array.
  4. Since it was generated by a (mostly) unique and very large number, the remainder will also be (mostly) unique, so the Ruby computer-brain uses it as the index position in the array to store our new key and value.
  5. The key and value are set as positions [0] and [1] in an array which is nested inside the Hash-Array at the index position calculated via the .hash and modulo operations.

So this is why Hash lookups are so fast! The Ruby computer-brain ‘knows’ where each key and value are because it can take the requested key, do the math for the .hash method really quick (because computers are really good at doing math quickly), calculate the index position with the modulo operation, and BAM! Find your value!

Writing a Ruby gem!

Posted on by

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.