Last time I messed with Rust, I made the classic beginner mistake of trying to learn too many things at once. I was trying to learn Rust, learn Lisp, and write a Lisp interpreter in Rust at the same time.
I started messing with Rust again. First, I want to mention a couple of videos that have really helped me understand Rust a little bit better.
Last time, I tried to find an easy way of running mutation testing on a rails app that’s tested by minitest. I did not find an easy way, so today I’m going to try to do it the hard way: use an old PR on mutant as a jumping off point to try to make a version of mutant that hooks into minitest. Continue reading “Mutant and Minitest”
I have a project at work that uses Minitest, but I want to use mutant to test it. Mutant is a gem that does mutation testing. Mutation testing is an important complement to regular automated testing. Regular automated testing asserts that correct code passes your test suite; mutation testing asserts that incorrect code fails your test suite. In this series, I’m going to try to find the best way to mutation test a Rails app that’s covered mostly be minitest.
Last time, I made a simple model called Lightswitch so that I could play with mutable state:
class Lightswitch < ActiveRecord::Base
attr_accessor :turned_on
def turn_on
self.turned_on = true
end
endWhen I first wrote the model, not wanting to suggest that my electrical fixtures were aroused, I named the attribute on instead of turned_on. I immediately saw some strange errors. rake test started complaining that there was no column named true. Today, I’m going to reproduce this error on purpose so that I will understand why, specifically, I can’t use on as a column name with active record. Continue reading “Don’t YAML on, man (in Rails 4)”
Last time, I learned that using let blocks in minitest cause minitest to define a method on the test class, and I hypothesized that this was to allow tests to share code while preventing them from sharing state. But the method that gets defined caches the results, so that the initializing block is only evaluated on the first call. I want to convince myself that test methods cannot corrupt this cache, or rather, can’t corrupt this cache without doing so on purpose. Continue reading “State and Caching in Minitest”
I want to know the difference between a few constructs in Ruby, specifically in minitest-spec-rails, so today I’m going to write several similar tests exploring different pieces of the DSL that minitest-spec-rails exposes, and look at the differing behaviors that result. Continue reading “Let blocks in Minitest”
I’ve been thinking about code reviews a lot lately.
My mom has often worked as an editor, and she once told me of the most difficult thing about being an editor (I paraphrase):
You have to let the writer keep his or her style. The challenge is to improve the writing without making it seem like you wrote it.
Working as a technical writer and as an English teacher, I thought about these things a lot. I would often think, “that is not a sentence that I would have written, but it is clear. It works.” Sometimes I would read a sentence and think, “I don’t know what that meant; that sentence doesn’t work.” I would change the sentence in the second situation but not the first. Continue reading “Throwing Darts at Code”
I’ve been thinking a lot about how and when I work recently. I missed a couple Wednesdays posting here, so I’ve been looking at ways to become more consistent.
I looked at two big resources here: MPJ‘s great video on timeboxing and The Power of Habit by Charles Duhigg. Continue reading “Habits and Timeboxes”
The other day, I had an idea for a simple website. I wanted to find an easier way to deploy side projects than I’ve used in the past. AWS gives me too fine a control over things I don’t care about, so I decided to try out Heroku. It was much easier than I thought it would be. Here is basically what I had to do to get a prototype on the public internet, admittedly at a subdomain of herokuapp.com. Making a Heroku account is the usual “sign up with an email and a password,” to I’m assuming you’ve done that step.
Yesterday at work, a colleague had what I think is a common issue for developers: Code was behaving incorrectly, and he couldn’t see why. We’ve all been there; the trick is not hanging out. Today I’m going to talk about two great developers I follow online, Safia Abdalla and Eric Lippert, and what we can learn from them about not getting stuck in a debug issue. Continue reading “Shrink Your Search Space”
willmurphyscode 