Author Archives: clarecodes

Notes on Go, part 3 of ∞

Posted on by

Here are my notes on how multiple returns work.

package main

import "fmt"

func split(sum int) (x, y int) {
    x = sum * 4 / 9
    y = sum - x
    return
}

func main() {
    results := split(17)
    fmt.Println(results)
    fmt.Println(split(17))
}

Returns prog.go:12: multiple-value split() in single-value context (Check it out on the Go Playground)

package main

import "fmt"

func split(sum int) (x, y int) {
    x = sum * 4 / 9
    y = sum - x
    return
}

func main() {
    resultsx, resultsy := split(17)
    fmt.Println(resultsx)
    fmt.Println(resultsy)
    fmt.Println(split(17))
}

Returns:

7
10
7 10

(Check it out on the Go Playground)

If a function returns multiple things, you are required to give each of those things a name if you are going to save them to a variable. The exception (so far) is if you directly pass the function to another function that can handle that sort of thing.

If you don’t want to save one of the returns, you can assign it to _, which basically says ‘I know there is going to be something here, throw it out immediately’.

Notes on Go, part 2 of ∞

Posted on by

Why aren’t my test running?

The command go test will only pick up tests in the directory that the command is being run in. To have it find tests in sub-folders, try the command go test ./.... This searches recursively through the sub-folders and finds the hiding tests and runs them.

Tests still aren’t running? If you are using godep to manage dependancies, you can try:

godep get

Still getting error messages á la:

somefolder/some_test.go:10:2: cannot find package "github.com/THING/code" in any of:
    /usr/local/Cellar/go/1.5.1/libexec/src/github.com/THING/code (from $GOROOT)
    ~/code/go/src/github.com/THING/code (from $GOPATH)

Try the following series of commands from the root directory of your project.

godep restore
rm -rf Godeps
godep save ./...
godep go test ./...
go test ./...

Stay tuned for an actual explanation of why any of this works when I figure it out!

Notes on Go, part 1 of ∞

Posted on by

When writing tests in Go, there are a few useful ways to get info printed out to the screen.

  • t.log

Inside the test, you can log stuff using t.log. This will only show up if you use the -v flag when running go test.

  • fmt.PrintLn

Inside the actual program itself, you can print things using an fmt.Print command, and running the tests with the -v flag.

Basically, the -v flag is your friend when you want to see things in your go tests!

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!

Free private remote git repos

Posted on by

If you want a remote backup of your private git repos, a la Github but free, there are 3 options I know of.

  1. BitBucket. Has unlimited free private repos, but sets limits on the number of collaborators. Also lacks issue tracking.

  2. GitLab. Has unlimited free private repos, WITH free issue tracking that is very similar to how Github works.

  3. DIY. Host it yourself! Except you have to pay for hosting. So there’s that.

I’m using GitLab for my Ultra Top Secret projects right now. So far so good! Their interface is a little rougher than GitHub, but more than workable.

Tab stops in Microsoft Office 2011 OSX

Posted on by

Apologies for the COMPLETELY DIFFERENT topic, but I spent a lot of time trying to format some stuff, so I’m recording this for next time I want to do this.

Step 1: place the curser near the text you want to align, and double click in the ruler bar area. A small black bent arrow should appear. It will probably point toward the right.

Step 2: double click on the arrow in the ruler bar. A dialog box should appear. Depending on how many tab stops you have, one or more numbers will appear in a list on the left under ‘Tab stop position’. Select the tab stop of interest. In my case, it was the second/last stop. To get the arrow to point toward the left/align the text on the right side of the document, click the ‘right’ selector under ‘Alignment’.

Step 3: Hit save. Drag the arrow to where you want to text to line up. Be happy!

  • 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.

Tips and Tricks: Useful Regular Expressions

Posted on by

I’ve learned a whole lot about regular expressions over the last year and a bit, and there are two ‘phrases’ for lack of a better term that are sort of like the nuclear option or like a blunt object, but will get me most of where I need to go.

Phrase 1: .*?

This is one of the most useful regular expression ‘phrases’ I’ve learned. It selects zero or more of any kind of character, including spaces, but isn’t greedy. (That just means that it’ll stop the first time it sees whatever is put after the question mark). The key limitation of this phrase is that it will not include new lines (though the exact implementation varies from language to language).

Phrase 2: .+?

Related to the first phrase, this one selects one or more of any kind of character, including spaces, but isn’t greedy. This is useful when something has to exist, but can be any number of things. Like the one before it, this (usually) doesn’t include new lines.

Phrase 3: [\s\S]*?

This ‘phrase’ is even more ‘powerful’ than the one above. This one selects zero or more of any kind of character, including all kinds of whitespace (yes, also new lines), but again, isn’t greedy. I used this one a LOT for a while, especially in Java.

Get creative

I was having trouble getting a regular expression to select an section of HTML that was broken up onto different lines irregularly 1. Finally I figured out that I wanted to use \s*? (zero or more whitespace characters, not greedy) to account for the different amounts of spacing, but not to pick up any letters or other characters.

  1. yes, I know regex is not the tool of choices for HTML, but my hands were a bit tied on this project ↩

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