Polishing Ruby + Software Releases - zenspider.com

hoe version 3.0.6 has been released!

2012-05-15T17:24:29-07:00

Hoe is a rake/rubygems helper for project Rakefiles. It helps you manage, maintain, and release your project and includes a dynamic plug-in system allowing for easy extensibility. Hoe ships with plug-ins for all your usual project tasks including rdoc generation, testing, packaging, deployment, and announcement..

See class rdoc for help. Hint: ri Hoe or any of the plugins listed below.

For extra goodness, see: http://seattlerb.rubyforge.org/hoe/Hoe.pdf

Changes:

3.0.6 / 2012-05-15

1 minor enhancement:
- Added install_plugins to the newb task
bugs: https://github.com/seattlerb/hoe/issues
code: https://github.com/seattlerb/hoe
other: http://github.com/jbarnette/hoe-plugin-examples
doco: http://seattlerb.rubyforge.org/hoe/Hoe.pdf
rdoc: http://seattlerb.rubyforge.org/hoe/
home: http://www.zenspider.com/projects/hoe.html

Repeating Tasks

2012-05-14T12:00:00-07:00

This is my fourth entry detailing my personal “productivity pr0n”.

What They Do

One of the gems I got from my meeting at omni was the sheer scope and power of repeating tasks. I didn’t use them at all before that and honestly didn’t understand what I’d use them. Since then they’ve completely turned my workflow around.

Basically, any task can have a “repeat” and the repeat interval is very customizable, esp with the latest version of omnifocus. Repeating just means a new version of that task is created with a new start and/or due date.

You can have a task repeat every N days/weeks/months regardless of when it was completed, or have it repeat N days/weeks/months after you complete it. The difference is subtle but important. For example, If you need to write and send a weekly status report every friday then you’d use the former. But if you need to check your oil 3 months after you last checked it, you’d use the latter.

Daily

For me, initially at least, it was all about the daily task. I had a lot of backlog in my project planning, execution, and life in general. The daily task gave me bite sized chunks to do so I had continual progress across all of them. I didn’t have to get overwhelmed by the size of the overall task. Here’s my current daily tasks:

There were a lot more, but most of them got caught up and then eventually promoted to weekly repeating tasks.

The important part is that I didn’t say “Empty Inbox Mail”, instead I focused on “Process Inbox Mail”. The original comment was something like “Do 5-10 quickly”. The task is only estimated at 10 minutes and that’s all I wanted to do. Strategically, you’ll notice that I only have 6 10 minute tasks and many of them are often much faster than that.

Also important, notice that I have “Process OmniFocus Inbox” and “Triage Due Perspective”. Tasks about tasks. By creating and working on these you know that you don’t have to have all your tasks perfectly organized and it also means you don’t have to put all the info on a task. You can just write enough information for you to be able to do the task, and organize it the next day when you process your inbox.

Weekly

And here are my weekly tasks:

One thing to note is that I treat a lot of these like a pipeline. I don’t have to get everything right all at once. All I have to do is progress something to the next stage. “Contextualize new tasks” is only there to fill in the context field on new tasks. That moves them on into “Estimate new tasks” and so on. Again, the intent is just to make it so I have simple digestible tasks.

And yes… I hate processing my physical inbox. :(

How to Write MiniTest::Spec Expectations

2012-05-11T12:00:00-07:00

Originally published by Jared Ning at: https://gist.github.com/2032303 . Republished with permission.

I’m a fan of MiniTest::Spec. It strikes a nice balance between the simplicity of TestUnit and the readable syntax of RSpec. When I first switched from RSpec to MiniTest::Spec, one thing I was worried I would miss was the ability to add matchers. (A note in terminology: “matchers” in MiniTest::Spec refer to something completely different than “matchers” in RSpec. I won’t get into it, but from now on, let’s use the proper term: “expectations”).

Understanding MiniTest::Expectations

Let’s take a look in the code (I’m specifically referring to the gem, not the standard library that’s built into Ruby 1.9):

# minitest/spec.rb

module MiniTest::Expectations
  # ...

  ##
  # See MiniTest::Assertions#assert_instance_of
  #
  #    obj.must_be_instance_of klass
  #
  # :method: must_be_instance_of

  infect_an_assertion :assert_instance_of, :must_be_instance_of

  # ...
end

That entire module is filled with almost nothing but one-line “definitions”. They each give a very brief description and instructions to see the related assertion. One great thing about MiniTest::Spec is that it’s built right on top of MiniTest::Unit, which is very simple and therefor very fast. infect_an_assertion simply calls the assertion and passes the arguments. For example, from the above definition:

'foobar'.must_be_instance_of String calls assert_instance_of String, 'foobar'.

Notice the order of 'foobar' and String in the assertion as opposed to the expectation. See how they’re flipped? The convention for the order of arguments in an assertion is expected value goes first, then actual value. With expectations, it’s the opposite:

assert_equal 'expected', 'actual' and 'actual'.must_equal 'expected'

Let’s look at another example:

infect_an_assertion :assert_includes, :must_include, :reverse

assert_includes [1, 2, 3], 1 is the same as [1, 2, 3].must_include 1. But notice that the order of the arguments isn’t flipped. That’s why the :reverse argument above is needed.

Similarly, another example of when it’s necessary not to flip the arguments is when there is only 1 argument. For example:

infect_an_assertion :assert_empty, :must_be_empty, :unary

The assertion is assert_empty [], and the expectation is [].must_be_empty. infect_an_assertion splats (*args) the arguments, so the lack of arguments to flip doesn’t mess up anything. But we do need to flip, nevertheless. The :unary argument does this for us. It does exactly the same thing the :reverse argument does. In fact, anything other than nil or false will work, but it’s good to be descriptive.

Writing our own custom assertion/expectation

Now that we understand how MiniTest::Expectations uses infect_an_assertion to define expectations, let’s write our own custom assertions and corresponding expectations.

require 'minitest/autorun'

module MiniTest::Assertions
  def assert_equals_rounded(rounded, decimal)
    assert rounded == decimal.round, "Expected #{decimal} to round to #{rounded}"
  end

  def assert_palindrome(string)
    assert string == string.reverse, "Expected #{string} to read the same way backwards and forwards"
  end

  def assert_default(hash, default_value)
    assert default_value == hash.default, "Expected #{default_value} to be default value for hash but was #{hash.default.inspect}"
  end
end

Numeric.infect_an_assertion :assert_equals_rounded, :must_round_to
String.infect_an_assertion :assert_palindrome, :must_be_palindrome, :only_one_argument
Hash.infect_an_assertion   :assert_default, :must_default_to, :do_not_flip

describe 'custom expectations' do

  describe '#must_round_to' do

    it 'rounds correctly for Float' do
      1.2.must_round_to 1
    end

    it 'rounds correctly for Fixnum' do
      1.must_round_to 1
    end

    it 'catches failures' do
      proc { 1.5.must_round_to 42 }.must_raise(MiniTest::Assertion)
    end

  end

  describe '#must_be_palindrome' do

    it 'read a string backwards and forwards' do
      'racecar'.must_be_palindrome
    end

    it 'catches failures' do
      proc { 'kriss kross'.must_be_palindrome }.must_raise(MiniTest::Assertion)
    end

    it 'only works for Strings' do
      proc { 1.must_be_palindrome }.must_raise(NoMethodError)
    end

  end

  describe '#must_default_to' do

    it 'compares the default value of a hash' do
      hash = Hash.new(42)
      hash.must_default_to 42
    end

    it 'catches failures' do
      proc { {}.must_default_to 42 }.must_raise(MiniTest::Assertion)
    end

    it 'only works for Hashes' do
      proc { 1.must_default_to 2 }.must_raise(NoMethodError)
    end

  end

end

Notice that I was specific about what I used to call infect_an_assertion. infect_an_assertion is a method defined on Module, which means we can call it on just about anything. I was specific about String and Hash because I only want those expectations to be defined on instances of those classes. I defined must_round_to on Numeric because both Integer and Float (among others) respond to round.

The code above is completely executable. It works with Ruby built-in MiniTest too. Play around with it.

Contexts

2012-05-10T12:00:00-07:00

This is my third entry detailing my personal “productivity pr0n”.

Defined, sorta…

Every task has a project and a context. Project is obvious. Context less so.

According to wikipedia:

“During a weekly review, determine the context for the tasks and puts them on the appropriate lists. An example of grouping together similar tasks would be making a list of outstanding telephone calls, or the tasks / errands to perform while downtown. Context lists can be defined by the set of tools available or by the presence of individuals or groups for whom one has items to discuss or present.”

Context is not a Thing

GTD originally suggested things like “email” and “laptop”. My interpretation is that GTD’s obvious bent towards business means their original idea of context originated more from making the very best of whatever situation you’re stuck in… like while waiting in the airport you might as well make a bunch of phone calls or queue up email to the marketing dept.

I don’t work like that. Fortunately, I’m not (usually) a victim of my context/situation. It isn’t about what I have available to me as much as it is what mindset I’m in. If I want to work on new features I should work on new features. If I’m NOT in the mood to work on new features, then doing so would be less than inspired. I should work on those things I’m in the right mood to work on or I won’t be as effective/efficient as I would be otherwise.

For me context is the mode I’m in when I’m working on a task.

Person, Place, and Verb

Shortly after my productivity pr0n meeting at omni I had an epiphany: I see context as three orthogonal dimensions:

what mode I’m in when I’m working on this task (this is a verb in my world).
where I need to be to work on this task.
and optionally, who I’m working with on this task.

For example, a bug on racc might be: Aaron Patterson, Vivace (our café we work from), Coding (Bug).

So if I’m in the mood to work on a bug and at vivace but aaron isn’t available… well, I go find something else to work on or I work less effectively on it and wait for him for a code review before I commit.

Ideally I’d be able to assign multiple contexts to a task. Unfortunately omnifocus only allows for one which is a real shame. I’ve talked to them about it and while there are ideas on how to address this, nothing is coming soon. For now, I do the one I find most important to completing it (usually the verb).

Not everything even has all three dimensions, and that’s fine too.

Omnifocus Project Organization

2012-05-09T12:00:00-07:00

This is my second entry detailing my personal “productivity pr0n”.

As I said in my previous post, I have 3 hierarchies of projects: personal, nerd, and work.

Non-nerd Projects

Personal and work are similar in that they’re just bundles of projects and there is no structure beyond that. In personal I have projects like:

condo
entertainment
vacation
kittens
cooking

and inside there are any number of tasks in there with no sub-projects.

Work is even less structured with a single project called: Tedium. It’s for the stuff I don’t like to do, but have to and without a reminder I won’t get it done.

Nerd Projects

Nerd projects are different. First, I have a lot of them. Currently there are 44 active nerd projects with 12 others currently put on hold. I’m probably also missing some and should automate some sort of audit against my repos. Second, I take a much more active stance with my nerd projects than I do my personal ones. Personal tasks are much more “dumping ground” than my nerd projects. So, in order to maintain the chaos caused by having so many active projects, more engineering needs to be put into my daily/weekly process.

Each nerd project corresponds to an open source product that I work on whether it is one of my own or a group project I contribute to. Each project has at least 2 repeating tasks to schedule release and task triage (assuming I have release responsibility for that project):

Every project has a priority level for me. For example, hoe and minitest are much higher priority than something like image_science. I have 5 levels of priority for projects. The triage and release tasks repeat on an N weekly basis where N is a prime number corresponding to it’s priority: 1, 2, 3, 5, 7. This helps spread out the work I have to do. I got this idea from the Cicada Lifecycle (how cool is that?!?) and it has helped balance things out tremendously. If I used the priority for the repeat then every 12 weeks I’d have to release all of 1-4 in the same week and every 60 weeks I’d have to release everything. Using primes ensures that things are evenly spread out as you can see in my review table:

          date\ tot 1w 2w 3w 5w 7w 
2012-05-11 Fri:  27  9  7  3  7  1 
2012-05-18 Fri:  19  0  7  4  7  1 
2012-05-25 Fri:  10  0  0  3  6  1 
2012-06-01 Fri:   7  0  0  0  6  1 
2012-06-08 Fri:   8  0  0  0  7  1 
2012-06-15 Fri:   1  0  0  0  0  1 
2012-06-22 Fri:   1  0  0  0  0  1 
   total:  73  9 14 10 33  7

I’ll talk more about the repeating tasks and how I work on projects in a later post.

minitest version 3.0.0 has been released!

2012-05-08T20:36:55-07:00

minitest provides a complete suite of testing facilities supporting TDD, BDD, mocking, and benchmarking.

"I had a class with Jim Weirich on testing last week and we were
 allowed to choose our testing frameworks. Kirk Haines and I were
 paired up and we cracked open the code for a few test
 frameworks...

 I MUST say that minitest is *very* readable / understandable
 compared to the 'other two' options we looked at. Nicely done and
 thank you for helping us keep our mental sanity."

-- Wayne E. Seguin

minitest/unit is a small and incredibly fast unit testing framework. It provides a rich set of assertions to make your tests clean and readable.

minitest/spec is a functionally complete spec engine. It hooks onto minitest/unit and seamlessly bridges test assertions over to spec expectations.

minitest/benchmark is an awesome way to assert the performance of your algorithms in a repeatable manner. Now you can assert that your newb co-worker doesn’t replace your linear algorithm with an exponential one!

minitest/mock by Steven Baker, is a beautifully tiny mock (and stub) object framework.

minitest/pride shows pride in testing and adds coloring to your test output. I guess it is an example of how to write IO pipes too. :P

minitest/unit is meant to have a clean implementation for language implementors that need a minimal set of methods to bootstrap a working test suite. For example, there is no magic involved for test-case discovery.

"Again, I can't praise enough the idea of a testing/specing
 framework that I can actually read in full in one sitting!"

-- Piotr Szotkowski

Changes:

3.0.0 / 2012-05-08

3 major enhancements:
- Added Object#stub (in minitest/mock.rb).
- Mock#expect mocks are used in the order they’re given.
- Mock#verify now strictly compares against expect calls.
3 minor enhancements:
- Added caller to deprecation message.
- Mock error messages are much prettier.
- Removed String check for RHS of assert/refute_match. This lets #to_str work properly.
1 bug fix:
- Support drive letter on Windows. Patch provided from MRI by Usaku NAKAMURA. (ayumin)
vim: https://github.com/sunaku/vim-ruby-minitest
home: https://github.com/seattlerb/minitest
rdoc: http://docs.seattlerb.org/minitest

The Dumping Grounds

2012-05-08T12:00:00-07:00

This is my first entry detailing my personal “productivity pr0n”.

Collection

According to 43folders:

The Collection stage is where all stuff is gathered together in an unstructured manner. This stage involves writing down whatever things one can think of that needs doing (possibly using trigger lists), and all places where relevant information might accumulate, such as in folders and drawers, are emptied into one place.

The important part there is that it should be as easy and quick as possible to get that thing out of your brain and into the trusted system.

What that means to me

As I’ve said elsewhere, I use omnifocus. I’ve been using it religiously since it came out and for a couple years I used it solely as a dumping ground for all my ideas, todos, and lists. I was burnt out enough that it didn’t serve any other purpose. But knowing that I had a place for all that stuff to go and it wouldn’t get lost or forgotten really helped me deal with that burnout.

For me there are two parts to this phase:

It must be easy as hell to get things in. Easy to the point where you don’t lose concentration on what you’re actually doing.
It must be trustworthy. I need to know that what goes in is safe and accessible.

If nothing else, omnifocus solves this problem perfectly.

Omnifocus Quick Entry

By simply hitting a global keybinding, omnifocus’ Quick Entry window pops up:

This lets me paste/type my tasks in quickly and as soon as I hit Cmd-S, it’s gone and I’m back to work. There are several other ways of capturing new tasks, but this is the one I use 90+% of the time.

If you provide extra information for project and context, it’ll automatically get filed into that project w/ the correct context. Otherwise, it goes in your inbox and you can organize later. This lets you quickly choose which path you want. If you just want to capture and go, don’t bother filling out the info and you can get back to work in a few seconds. If you’re in planning mode, you can take the time to provide all the extra info you want and things will wind up in the right places.

What I put in omnifocus

Anything and everything! I have 3 hierarchies: personal, nerd, and work as well as some miscellaneous groupings for daily/weekly/monthly repeating tasks. In personal I have things as varied as errands I need to run, to music I want to buy, to things to study, as well as one titled “Live Volcano Vacation”. For my nerd hierarchy, I’ve have a folder for every open source project I work on and presentation I’m planning. Random ideas go in here. Yaks go in here. And I use software to sync from bug tracking systems into here. I’ll explain these more fully in later posts.

The important thing to understand is that if I want to do something and I can’t do it right now, it goes in omnifocus.

Inherited Sucks

2012-05-07T17:00:00-07:00

Found via a rails SNAFU:

# in rails spread across many modules and classes :(

class A
  def self.inherited(x)
    p x.instance # create a singleton upon inheritance
  end

  def self.instance
    @instance ||= new
  end

  def initialize
    p :A_initialize
  end
end

# in your application.rb

class B < A
  def initialize
    p :B_initialize
  end
end

This prints out :A_initialize only.. and is terribly confusing because it is about 8 layers of indirection deep. tenderlove and I poked at this for about 30 minutes trying to untangle why his simple initialize method wouldn’t get called.

Turns out it is that crafty instantiation inside of the inherited hook. inherited triggers on the class opening… when initialize hasn’t been defined yet.

This sucks big time and is a perfect illustration of why I think ruby needs a hook for the close of a inherited class, not just the opening. So many powerful tools could be written with such a simple hook. I have yet to see inherited be used for much more than the horrible cargo-culted ClassMethods+InstanceMethods pattern.

I found a workaround… It sucks, but it does ensure that your initialize gets called:

class A
  def self.method_added m
    if self != A and m == :initialize then
      instance.send :initialize
    end
  end
end

class B < A
  def initialize
    # NEVER call super since this is instantiated through inherited :(
    p :B_initialize
  end
end

image_science version 1.2.3 has been released!

2012-05-07T16:09:42-07:00

ImageScience is a clean and happy Ruby library that generates thumbnails – and kicks the living crap out of RMagick. Oh, and it doesn’t leak memory like a sieve. :)

For more information including build steps, see http://seattlerb.rubyforge.org/

Changes:

1.2.3 / 2012-05-07

2 bug fixes:
- Fixed thumbnail float imprecision errors. (jdelStrother)
- Switched to using tmpdir for INLINEDIR to avoid failures in CI environments w/o homedirs
http://seattlerb.rubyforge.org/ImageScience.html
http://rubyforge.org/projects/seattlerb

hoe version 3.0.5 has been released!

2012-05-07T16:04:03-07:00

See class rdoc for help. Hint: ri Hoe or any of the plugins listed below.

For extra goodness, see: http://seattlerb.rubyforge.org/hoe/Hoe.pdf

Changes:

3.0.5 / 2012-05-07

1 bug fix:
- Fixed ridocs argument handling (erikh)
code: https://github.com/seattlerb/hoe
doco: http://seattlerb.rubyforge.org/hoe/Hoe.pdf
other: http://github.com/jbarnette/hoe-plugin-examples
bugs: https://github.com/seattlerb/hoe/issues
home: http://www.zenspider.com/projects/hoe.html
rdoc: http://seattlerb.rubyforge.org/hoe/

productivity pr0n

2012-05-07T12:00:00-07:00

Productivity is a very personal thing. What works for you might not work for me and vice-versa. That said, there’s nothing wrong with sharing what works for me in the hopes that I might help others or learn something new from you.

GTD Phases

I do some sort of GTD with my own little twists and turns thrown in. The main tenet that got me on GTD that I really liked was the idea that by dumping all the lists and ideas and todos out of your head. Putting all of that into a trusted system frees up cognitive space and allows you to focus on the task and hand and be more creative as a result. Bunk? Maybe… but the idea works for me. I tangent a lot less when I have this system in place. Less yak to shave.

Last year, I met up with an old friend at the Omni Group to talk about how we work (specifically, how we use omnifocus) and I dunno… something he said lit a fire under my ass and I got back in gear and moving on a lot of projects very quickly. In the 36 months I’d been using omnifocus preceding this meeting, I’d finished 668 tasks (or about 18/mo). In the 6 months after the meeting, I finished 1273 tasks (212/mo). In the last 6 months, I’ve been maintaining an average of 252/mo… so something has clearly worked for me.

Collection

According to 43folders:

The Collection stage is where all stuff is gathered together in an unstructured manner. This stage involves writing down whatever things one can think of that needs doing (possibly using trigger lists), and all places where relevant information might accumulate, such as in folders and drawers, are emptied into one place.

The important part there is that it should be as easy and quick as possible to get that thing out of your brain and into the trusted system.

Process

The Process stage is where these items are sorted, and the further activity needed by them is decided.

(again with 43folders)

This is where you go through what’s collected and either act on it immediately (eg, if it is < 2 minutes) or you decide what further action needs to happen. This is also called Do/Delegate/Defer.

Organize

The Organize stage takes these sorted items and puts them together in a form than can be used through the day for allocating tasks to time.

(43folders)

Personally, I don’t treat the process and organize stages as distinctly different. I’ll go into more detail on that later.

Review

The review stage is exactly that: review what’s in the system and keep it up to date. This is, for many (including me), the hardest (or least tangibly rewarding) thing to do. Luckily, there are tools to help with this.

Schedule/Plan

Over the next few weeks/days I’m going to be describing my personal flavor of productivity pr0n. I’ll be going over how I use emacs and omnifocus and what the workflow of my day/week looks like. Here is a rough outline of what I plan to go over.

omnifocus dumping grounds
omnifocus project organization
omnifocus contexts
omnifocus perspectives
daily & weekly repeating tasks
project oriented tasks
scheduling of complex and numerous projects - release, triage, daily work
weekly review
omnifocus gem - BTS integration, reviewing, scheduling, etc.

This will essentially be a detailed continuation of my workflow presentation with more of a macro view.

I’ll update these to links as they get written/published.

Disclosure: I used to work for The Omni Group but no longer have a working relationship with them.

ZenTest version 4.8.0 has been released!

2012-05-04T15:46:09-07:00

ZenTest provides 4 different tools: zentest, unit_diff, autotest, and multiruby.

zentest scans your target and unit-test code and writes your missing code based on simple naming rules, enabling XP at a much quicker pace. zentest only works with Ruby and Minitest or Test::Unit. There is enough evidence to show that this is still proving useful to users, so it stays.

unit_diff is a command-line filter to diff expected results from actual results and allow you to quickly see exactly what is wrong. Do note that minitest 2.2+ provides an enhanced assert_equal obviating the need for unit_diff

autotest is a continous testing facility meant to be used during development. As soon as you save a file, autotest will run the corresponding dependent tests.

multiruby runs anything you want on multiple versions of ruby. Great for compatibility checking! Use multiruby_setup to manage your installed versions.

Changes:

4.8.0 / 2012-05-04

1 minor enhancement:
- Added Minitest generation to zentest (use -t to generate for test/unit)
1 bug fix:
- Fixes and clarifications to Autotest#find_file. (hugh sasse)
home: https://github.com/seattlerb/zentest
rdoc: http://zentest.rubyforge.org/ZenTest

ParseTree version 3.0.9 has been released!

2012-05-01T16:39:28-07:00

ParseTree is a C extension (using RubyInline) that extracts the parse tree for an entire class or a specific method and returns it as a s-expression (aka sexp) using ruby’s arrays, strings, symbols, and integers.

As an example:

def conditional1(arg1) if arg1 == 0 then return 1 end return 0 end

becomes:

[:defn, :conditional1, [:scope, [:block, [:args, :arg1], [:if, [:call, [:lvar, :arg1], :==, [:array, [:lit, 0]]], [:return, [:lit, 1]], nil], [:return, [:lit, 0]]]]]

Changes:

3.0.9 / 2012-05-01

6 minor enhancements:
- Added a bunch of new tests from PTTC.
- Added masgn handling inside block_pass
- Added rewrite_iter to unwrap masgns w/ only 1 arg.
- Handle rewriting block_pass in iter.
- Imported RawParseTree test data from PTTC.
- Removed rewrite_masgn requirement for 4 slots.
3 bug fixes:
- Fixed dependencies to ensure they’re not going to use ruby_parser 3 and friends.
- Fixed segv for NODE_BLOCK_PASS in iter (nd_iter == 1… go boom)
- Remove nil body in iter (I think this is wrong, but whatevs).
home: https://github.com/seattlerb/parsetree
rdoc: http://docs.seattlerb.org/ParseTree/

hoe version 3.0.4 has been released!

2012-05-01T16:30:36-07:00

See class rdoc for help. Hint: ri Hoe or any of the plugins listed below.

For extra goodness, see: http://seattlerb.rubyforge.org/hoe/Hoe.pdf

Changes:

3.0.4 / 2012-05-01

1 bug fix:
- Removed rubygems/deprecated and rolled my own for users on older rubygems
code: https://github.com/seattlerb/hoe
doco: http://seattlerb.rubyforge.org/hoe/Hoe.pdf
other: http://github.com/jbarnette/hoe-plugin-examples
bugs: https://github.com/seattlerb/hoe/issues
home: http://www.zenspider.com/projects/hoe.html
rdoc: http://seattlerb.rubyforge.org/hoe/

minitest mock -- which is more important?

2012-04-27T16:13:23-07:00

Currently you can do something like this with minitest/mock:

mock = MiniTest::Mock.new

mock.expect :foo, nil

mock.foo
mock.foo
mock.foo # and so on... you can call until the cows come home

mock.verify

but you can’t do the following:

mock = MiniTest::Mock.new

mock.expect :foo, nil
mock.expect :foo, true

assert_equal nil,  mock.foo
assert_equal true, mock.foo

mock.verify

minitest/mock currently accesses mocked calls by arity and the first one wins.

I want to break the former and fix the latter. Which is more important to you?

I've got the Tpkg Blues

2012-04-19T00:00:00-07:00

Minitest Pride

2012-04-18T14:30:30-07:00

sexp_processor version 3.2.0 has been released!

2012-04-15T14:28:21-07:00

sexp_processor branches from ParseTree bringing all the generic sexp processing tools with it. Sexp, SexpProcessor, Environment, etc… all for your language processing pleasure.

Changes:

3.2.0 / 2012-04-15

5 minor enhancements:
- Added a ton of block arg tests.
- Added add19_edgecases to help refactor a bunch of tests that all have the same output.
- Added better debugging output for rewrites.
- Cleaned and added a bunch of stabby proc tests.
- Moved RawParseTree test data to ParseTree project.
2 bug fixes:
- Fixed a bunch of entries for r2r changes against edgecase parse/lex tests
- Fixes for R2R
home: https://github.com/seattlerb/sexp_processor
rdoc: http://docs.seattlerb.org/sexp_processor

minitest version 2.12.1 has been released!

2012-04-10T20:35:14-07:00

minitest provides a complete suite of testing facilities supporting TDD, BDD, mocking, and benchmarking.

"I had a class with Jim Weirich on testing last week and we were
 allowed to choose our testing frameworks. Kirk Haines and I were
 paired up and we cracked open the code for a few test
 frameworks...

 I MUST say that minitest is *very* readable / understandable
 compared to the 'other two' options we looked at. Nicely done and
 thank you for helping us keep our mental sanity."

-- Wayne E. Seguin

minitest/unit is a small and incredibly fast unit testing framework. It provides a rich set of assertions to make your tests clean and readable.

minitest/spec is a functionally complete spec engine. It hooks onto minitest/unit and seamlessly bridges test assertions over to spec expectations.

minitest/mock by Steven Baker, is a beautifully tiny mock object framework.

minitest/pride shows pride in testing and adds coloring to your test output. I guess it is an example of how to write IO pipes too. :P

"Again, I can't praise enough the idea of a testing/specing
 framework that I can actually read in full in one sitting!"

-- Piotr Szotkowski

Changes:

2.12.1 / 2012-04-10

1 minor enhancement:
- Added ruby releases to History.txt to make it easier to see what you’re missing
1 bug fix:
- Rolled my own deprecate msg to allow MT to work with rubygems < 1.7
vim: https://github.com/sunaku/vim-ruby-minitest
home: https://github.com/seattlerb/minitest
rdoc: http://docs.seattlerb.org/minitest

I don't always code

2012-04-09T17:22:39-07:00

As seen on IRC:

<WillMarshall> zenspider: I don't always code, but when I do I like to cargo-cult.

hoe version 3.0.3 has been released!

2012-04-09T17:13:31-07:00

See class rdoc for help. Hint: ri Hoe or any of the plugins listed below.

For extra goodness, see: http://seattlerb.rubyforge.org/hoe/Hoe.pdf

Changes:

3.0.3 / 2012-04-09

2 bug fixes:
- Fixed racc plugin’s gem dependency activation
- Fixed rake multi’s use of multiruby_skip.
code: https://github.com/seattlerb/hoe
doco: http://seattlerb.rubyforge.org/hoe/Hoe.pdf
other: http://github.com/jbarnette/hoe-plugin-examples
bugs: https://github.com/seattlerb/hoe/issues
home: http://www.zenspider.com/projects/hoe.html
rdoc: http://seattlerb.rubyforge.org/hoe/

zenprofile version 1.3.2 has been released!

2012-04-06T18:09:18-07:00

zenprofiler helps answer WHAT is being called the most. spy_on helps answer WHERE those calls are being made. ZenProfiler provides a faster version of the standard library ruby profiler. It is otherwise pretty much the same as before. spy_on provides a clean way to redefine a bottleneck method so you can account for and aggregate all the calls to it.

% ruby -Ilib bin/zenprofile misc/factorial.rb 50000
Total time = 3.056884
Total time = 2.390000

          total     self              self    total
% time  seconds  seconds    calls  ms/call  ms/call  name
 50.70     1.64     1.64    50000     0.03     0.05 Integer#downto
 19.63     2.27     0.63   200000     0.00     0.00 Fixnum#*
 14.19     2.73     0.46    50000     0.01     0.05 Factorial#factorial
  9.93     3.05     0.32        1   320.36  3047.10 Range#each
  5.54     3.23     0.18        2    89.40   178.79 ZenProfiler#start_hook

Once you know that Integer#downto takes 50% of the entire run, you can use spy_on to find it. (See misc/factorial.rb for the actual code):

% SPY=1 ruby -Ilib misc/factorial.rb 50000
Spying on Integer#downto

Integer.downto

50000: total
50000: ./misc/factorial.rb:6:in `factorial' via 
       ./misc/factorial.rb:6:in `factorial'

Changes:

1.3.2 / 2012-04-06

2 bug fixes:
- Fixed compile problems raised by clang
- Removed ‘self.’ from wrapped call to fix calling private methods. (joevandyk)
http://rubyforge.org/projects/seattlerb

minitest version 2.12.0 has been released!

2012-04-03T20:31:29-07:00

minitest provides a complete suite of testing facilities supporting TDD, BDD, mocking, and benchmarking.

"I had a class with Jim Weirich on testing last week and we were
 allowed to choose our testing frameworks. Kirk Haines and I were
 paired up and we cracked open the code for a few test
 frameworks...

 I MUST say that minitest is *very* readable / understandable
 compared to the 'other two' options we looked at. Nicely done and
 thank you for helping us keep our mental sanity."

-- Wayne E. Seguin

minitest/unit is a small and incredibly fast unit testing framework. It provides a rich set of assertions to make your tests clean and readable.

minitest/spec is a functionally complete spec engine. It hooks onto minitest/unit and seamlessly bridges test assertions over to spec expectations.

minitest/mock by Steven Baker, is a beautifully tiny mock object framework.

minitest/pride shows pride in testing and adds coloring to your test output. I guess it is an example of how to write IO pipes too. :P

"Again, I can't praise enough the idea of a testing/specing
 framework that I can actually read in full in one sitting!"

-- Piotr Szotkowski

Changes:

2.12.0 / 2012-04-03

4 minor enhancements:
- ::it returns test method name (wojtekmach)
- Added #record method to runner so runner subclasses can cleanly gather data.
- Added Minitest alias for MiniTest because even I forget.
- Deprecated assert_block!! Yay!!!
1 bug fix:
- Fixed warning in i_suck_and_my_tests_are_order_dependent! (phiggins)
vim: https://github.com/sunaku/vim-ruby-minitest
home: https://github.com/seattlerb/minitest
rdoc: http://docs.seattlerb.org/minitest

hoe version 3.0.2 has been released!

2012-04-03T19:57:45-07:00

See class rdoc for help. Hint: ri Hoe or any of the plugins listed below.

For extra goodness, see: http://seattlerb.rubyforge.org/hoe/Hoe.pdf

Changes:

3.0.2 / 2012-04-03

1 bug fix:
- Generate urls list properly in #announcement if you use k/v form
code: https://github.com/seattlerb/hoe
doco: http://seattlerb.rubyforge.org/hoe/Hoe.pdf
other: http://github.com/jbarnette/hoe-plugin-examples
bugs: https://github.com/seattlerb/hoe/issues
home: http://www.zenspider.com/projects/hoe.html
rdoc: http://seattlerb.rubyforge.org/hoe/

hoe version 3.0.1 has been released!

2012-03-26T17:53:32-07:00

See class rdoc for help. Hint: ri Hoe or any of the plugins listed below.

For extra goodness, see: http://seattlerb.rubyforge.org/hoe/Hoe.pdf

Changes:

3.0.1 / 2012-03-26

1 minor enhancement:
- Uniqify hoe plugins in sow Rakefile template. (evanphx)
3 bug fixes:
- Fixed have_gem? checks in the install_plugins task to match the install_gem calls.
- Fixed homepage handling when bullet list used in readme. (evanphx)
- Removed deprecated use of #url in publish plugin
code: https://github.com/seattlerb/hoe
doco: http://seattlerb.rubyforge.org/hoe/Hoe.pdf
other: http://github.com/jbarnette/hoe-plugin-examples
bugs: https://github.com/seattlerb/hoe/issues
home: http://www.zenspider.com/projects/hoe.html
rdoc: http://seattlerb.rubyforge.org/hoe/

minitest version 2.11.4 has been released!

2012-03-20T17:24:03-07:00

minitest provides a complete suite of testing facilities supporting TDD, BDD, mocking, and benchmarking.

"I had a class with Jim Weirich on testing last week and we were
 allowed to choose our testing frameworks. Kirk Haines and I were
 paired up and we cracked open the code for a few test
 frameworks...

 I MUST say that minitest is *very* readable / understandable
 compared to the 'other two' options we looked at. Nicely done and
 thank you for helping us keep our mental sanity."

-- Wayne E. Seguin

minitest/unit is a small and incredibly fast unit testing framework. It provides a rich set of assertions to make your tests clean and readable.

minitest/spec is a functionally complete spec engine. It hooks onto minitest/unit and seamlessly bridges test assertions over to spec expectations.

minitest/mock by Steven Baker, is a beautifully tiny mock object framework.

minitest/pride shows pride in testing and adds coloring to your test output. I guess it is an example of how to write IO pipes too. :P

"Again, I can't praise enough the idea of a testing/specing
 framework that I can actually read in full in one sitting!"

-- Piotr Szotkowski

Changes:

2.11.4 / 2012-03-20

2 minor enhancements:
- Updated known extensions
- You got your unicode in my tests! You got your tests in my unicode! (fl00r)
1 bug fix:
- Fixed MiniTest::Mock example in the readme. (conradwt)

hoe version 3.0.0 has been released!

2012-03-20T16:55:59-07:00

See class rdoc for help. Hint: ri Hoe or any of the plugins listed below.

For extra goodness, see: http://seattlerb.rubyforge.org/hoe/Hoe.pdf

Changes:

3.0.0 / 2012-03-20

3 major enhancements:
- Added activate_plugin_deps phase to plugin loading.
- Removed long deprecated Hoe.new { block }.
- Removed long deprecated handling of improper dependencies.
3 minor enhancements:
- Added deprecation warnings to Hoe#url and Hoe#url=. Already deprecated for 9 mo.
- Reworked all the plugins to use activate_XXX_deps, as necessary.
- Switched internal usage of #url to #urls.
2 bug fixes:
- Fixed failures in the publish_docs task when remote directory times cannot be changed (such as on rubyforge).
- Fixed isolate setup for the racc plugin

ZenTest version 4.7.0 has been released!

2012-03-15T16:49:07-07:00

ZenTest provides 4 different tools: zentest, unit_diff, autotest, and multiruby.

ZenTest scans your target and unit-test code and writes your missing code based on simple naming rules, enabling XP at a much quicker pace. ZenTest only works with Ruby and Test::Unit. Nobody uses this tool anymore but it is the package namesake, so it stays.

autotest is a continous testing facility meant to be used during development. As soon as you save a file, autotest will run the corresponding dependent tests.

multiruby runs anything you want on multiple versions of ruby. Great for compatibility checking! Use multiruby_setup to manage your installed versions.

Changes:

4.7.0 / 2012-03-15

2 minor enhancements:
- autotest/timestamp now uses ran_command hook. (bhenderson)
- run_command hook is now passed cmd. (bhenderson)
1 bug fix:
- Fixed run_command hook to only trigger when there are test files to run. (bhenderson)
https://github.com/seattlerb/zentest

assert_equal_unordered

2012-03-15T15:00:00-07:00

This new minitest assertion is up for debate on github. Will it clean up your tests? Will it clean up your tests enough to warrant addition to minitest, or should it be an add-on gem? tenderlov, drbrain, and I don’t see it cleaning up our tests all that much, but that may be specific to our design patterns.

What do you think?

diff -r old/lib/minitest/spec.rb new/lib/minitest/spec.rb
--- old/lib/minitest/spec.rb
+++ new/lib/minitest/spec.rb
@@ -312,6 +312,15 @@
   infect_an_assertion :assert_includes, :must_include, :reverse
 
   ##
+  # See MiniTest::Assertions#assert_equal_unordered
+  #
+  #    collection.must_equal_unordered other
+  #
+  # :method: must_equal_unordered
+
+  infect_an_assertion :assert_equal_unordered, :must_equal_unordered, :reverse
+
+  ##
   # See MiniTest::Assertions#assert_instance_of
   #
   #    obj.must_be_instance_of klass
diff -r old/lib/minitest/unit.rb new/lib/minitest/unit.rb
--- old/lib/minitest/unit.rb
+++ new/lib/minitest/unit.rb
@@ -248,6 +248,33 @@
     end
 
     ##
+    # Fails unless +a+ contains the same contents as +b+, regardless
+    # of order.
+    #
+    #    assert_equal_unordered %w[a a b c], %w[a b c a] # pass
+    #
+    # NOTE: This uses Hash#== to determine collection equivalence, as
+    # such, do not expect it to behave the same as +assert_equal+.
+    #
+    #    assert_equal [1], [1.0]                         # pass
+    #    assert_equal({ 1 => true }, { 1.0 => true })    # fail
+    #    assert_equal_unordered [1], [1.0]               # fail
+
+    def assert_equal_unordered a, b, msg = nil
+      msg = message(msg) {
+        "Expected #{mu_pp a} to be equivalent to #{mu_pp b}"
+      }
+
+      assert_kind_of Enumerable, a
+      assert_kind_of Enumerable, b
+
+      c = Hash.new { |h,k| h[k] = 0 }; a.each do |e| c[e] += 1 end
+      d = Hash.new { |h,k| h[k] = 0 }; b.each do |e| d[e] += 1 end
+
+      assert c == d, msg
+    end
+
+    ##
     # Fails unless +obj+ is an instance of +cls+.
 
     def assert_instance_of cls, obj, msg = nil
diff -r old/test/test_minitest_spec.rb new/test/test_minitest_spec.rb
--- old/test/test_minitest_spec.rb
+++ new/test/test_minitest_spec.rb
@@ -65,6 +65,20 @@
     end
   end
 
+  it "needs to be sensible about must_equal_unordered order" do
+    @assertion_count += 6 # must_equal_unordered is 4 assertions
+
+    [1, 2, 3].must_equal_unordered([1, 2, 3]).must_equal true
+
+    assert_triggered "Expected [1, 2] to be equivalent to [1, 2, 3]." do
+      [1, 2].must_equal_unordered [1, 2, 3]
+    end
+
+    assert_triggered "msg.\nExpected [1, 2, 4] to be equivalent to [1, 2, 3]." do
+      [1, 2, 4].must_equal_unordered [1, 2, 3], "msg"
+    end
+  end
+
   it "needs to catch an expected exception" do
     @assertion_count = 2
 
@@ -121,6 +135,7 @@
                         must_be_within_delta
                         must_be_within_epsilon
                         must_equal
+                        must_equal_unordered
                         must_include
                         must_match
                         must_output
@@ -129,7 +144,7 @@
                         must_send
                         must_throw)
 
-    bad = %w[not raise throw send output be_silent]
+    bad = %w[not raise throw send output be_silent equal_unordered]
 
     expected_wonts = expected_musts.map { |m| m.sub(/^must/, 'wont') }
     expected_wonts.reject! { |m| m =~ /wont_#{Regexp.union(*bad)}/ }
diff -r old/test/test_minitest_unit.rb new/test/test_minitest_unit.rb
--- old/test/test_minitest_unit.rb
+++ new/test/test_minitest_unit.rb
@@ -895,6 +895,69 @@
     assert_equal expected, e.message
   end
 
+  def test_assert_equal_unordered_when_comparable_elements
+    @assertion_count = 3
+
+    @tc.assert_equal_unordered [1, 2, 3], [2, 3, 1]
+  end
+
+  def test_assert_equal_unordered_when_not_comparable_elements
+    @assertion_count = 3
+
+    @tc.assert_equal_unordered [true, false, true], [true, true, false]
+  end
+
+  def test_assert_equal_unordered_when_enumerable_actual
+    @assertion_count = 3
+
+    es = Class.new do
+      include Enumerable
+
+      def initialize
+        @elems = [true, false, true]
+      end
+
+      def each
+        @elems.each { |e| yield e }
+      end
+    end.new
+
+    @tc.assert_equal_unordered es, [true, true, false]
+  end
+
+  def test_assert_equal_unordered_triggered_when_actual_has_more_elements_than_expected
+    @assertion_count = 4
+
+    e = @tc.assert_raises MiniTest::Assertion do
+      @tc.assert_equal_unordered [true, true], [true]
+    end
+
+    expected = "Expected [true, true] to be equivalent to [true]."
+    assert_equal expected, e.message
+  end
+
+  def test_assert_equal_unordered_triggered_when_actual_has_less_elements_than_expected
+    @assertion_count = 4
+
+    e = @tc.assert_raises MiniTest::Assertion do
+      @tc.assert_equal_unordered [true], [true, true]
+    end
+
+    expected = "Expected [true] to be equivalent to [true, true]."
+    assert_equal expected, e.message
+  end
+
+  def test_assert_equal_unordered_triggered_when_actual_has_different_elements_than_expected
+    @assertion_count = 4
+
+    e = @tc.assert_raises MiniTest::Assertion do
+      @tc.assert_equal_unordered [true, false, true], [false, false, true]
+    end
+
+    expected = "Expected [true, false, true] to be equivalent to [false, false, true]."
+    assert_equal expected, e.message
+  end
+
   def test_assert_instance_of
     @tc.assert_instance_of String, "blah"
   end
@@ -1272,10 +1335,11 @@
     methods = MiniTest::Assertions.public_instance_methods
     methods.map! { |m| m.to_s } if Symbol === methods.first
 
-    ignores = %w(assert_block assert_no_match assert_not_equal
-                 assert_not_nil assert_not_same assert_nothing_raised
-                 assert_nothing_thrown assert_output assert_raise
-                 assert_raises assert_send assert_silent assert_throws)
+    ignores = %w(assert_block assert_equal_unordered assert_no_match
+                 assert_not_equal assert_not_nil assert_not_same
+                 assert_nothing_raised assert_nothing_thrown
+                 assert_output assert_raise assert_raises
+                 assert_send assert_silent assert_throws)
 
     asserts = methods.grep(/^assert/).sort - ignores
     refutes = methods.grep(/^refute/).sort - ignores

image_science version 1.2.2 has been released!

2012-03-13T16:33:17-07:00

ImageScience is a clean and happy Ruby library that generates thumbnails – and kicks the living crap out of RMagick. Oh, and it doesn’t leak memory like a sieve. :)

For more information including build steps, see http://seattlerb.rubyforge.org/

Changes:

1.2.2 / 2012-03-13

1 minor enhancement:
- Extended build to look for homebrew setup (hcatlin)
2 bug fixes:
- Fixed 1.9 warnings, clang warnings, etc…
- Fixed compilation error when ruby’s config mandates C89 style decls. (nocode)
http://seattlerb.rubyforge.org/ImageScience.html
http://rubyforge.org/projects/seattlerb