#!/bin/sh
type=`basename $0`
[ $type = nt ] && type='' || type="$type "
echo "$( date +%Y-%m-%dT%H:%M:%S ) $type$@" \
    >> ~/time/$( date +%Y-%m-%d )

One of great things about cwm is the "exec" menu. Type Meta+Shift+/ brings up a command-line where you can run anything.

I happen to have two symlinks to a shell script, "sta" and "sto". Lets me log time without switching contexts.

Other folks tell me of their solutions and it involves clicking menus and boxes popping up to ask questions. Not for me, but it suits them.

Something less terrible from other people.

We use Test::Class for our test infrastructure.
I'm hoping to move a to Exodist's new Test2 stuff, but we'll still need something like this.
Turns out I'm too lazy to copy and paste. I've recently added several utility methods to our Test::Class subclass.

Test::MockObject

• mock_now Overrides our internal "what time is it" method to return a DateTime so we can time travel.
  Bids need to happen at the same time, or different times. Guaranteeing that is hard, and adding `sleep` is ugly.
• mock_send_email stops us from actually sending email, but we can check that we tried to send the right thing with the mock.
• mock_c_log Returns a mock object that traps calls to Catalyst's $c->log.
  As Ovid says, your test suite should run quietly, warnings have meaning. For example the amazingly helpful: "Possible precedence issue with control flow operator" So trapping these messages is surprisingly important.

# This auction will end in an hour
my $auction = My::Model::DB::Auction->create_with_defaults(
    { start => $now->clone->subtract( hours => 1 ) } );

# This auction will start in five hours
my $auction = My::Model::DB::Auction->create_with_defaults(
    { end => $now->clone->add( hours => 7 ) } );

# Now, this auction starts ten minutes after it ended
my $auction = My::Model::DB::Auction->create_with_defaults(
    {   start => $now->clone->add(      minutes => 5 ),
        end   => $now->clone->subtract( minutes => 5 ) } );
    

In this case, Ovid's solution isn't quite the same. Test::Class method `->setup_$foo`, for example `->setup_auction`. Backed by a Role applied to a DBIx::Class subclass that provides a ->create_with_defaults method. The important thing is `My::Model::DB::Foo` will hit a My::Model::Defaults::Foo and ask for the parameters to pass to ->new. Smart enough to know what settings effect the other values. Takes some work to give smarts, but worth it. ask for an auction that starts tomorrow and get it.

• Model:::Defaults::Auction - col_data - for_web
• Role::Model::Defaults - Apply the Role to your Model::DB::Foo
  • defaults_class (defaults to s/Model::DB::/Model::Defaults::/)
  • adds new_with_defaults / create_with_defaults
  • ->create_with_defaults that calls $class->create( $class->defaults_class->col_data(\%params) );

How did this end up in production?

Customer wanted a bidders to be comfortable with bidding by practicing in a trial auction.

Bidder picks from a subset of settings. We need to provide reasonable values for everything else.

Hmm. This sounds familiar.

Model::Defaults became the Auction Simulator creation.

Back to the simulator, which, it turns out, was pretty boring.

I created "bid bots" that bid in the simulator.

Configurable to bid in different manners. Not an advanced game engine, but good enough, tho very deterministic.

Not yet live so no demo. Even though it's really cool.

Due to making it testable, it's also reusable.

Remember that we needed to load test the site? We didn't have to outsource. Bots are cheaper.

Went from talking to the Model to using WWW::Mechanize.

Was able to generate a *lot* of load and that made the bottlenecks obvious.

Run the benchmark like normal, and profile like normal, and you get one profile with all the runs in a long time.

added a wrapper function that would either benchmark or profile depending on how you ran it.

which made it amazingly easy to see how the code was performing and figure out where to look at what to improve.

Haven't had time to make it reusable yet, but could.

my $profile_dir;
BEGIN {
    if (%Devel::NYTProf::) {
        DB::disable_profile(); # $ENV{NYTPROF} = 'start=no'
        $profile_dir = "./nytprof";
        mkdir($profile_dir) or die "Couldn't mkdir $profile_dir: $!"
            unless -e $profile_dir;
    } else {
        require Benchmark;
        Benchmark->import( qw( timethese :hireswallclock ) );
    }
}

sub profile_or_timethese {
    my ( $count, $tests ) = @_;
    return $profile_dir
        ? profilethese($tests)
        : timethese( $count, $tests );
}

sub profilethese {
    my ($tests) = @_
    foreach my $name (keys %{ $tests }) {
        ( my $safe_name = $name ) =~ s/\W+/_/g;
        my $dir = "$profile_dir/$safe_name";
        mkdir($dir) or die "Couldn't mkdir $dir: $!";
        warn "Profiling to $dir";

        DB::enable_profile("$dir/nytprof.out");
        $tests->{$name}->();
        DB::disable_profile(); # otherwise we get it in the report
        DB::finish_profile();
    }
}

profile_or_timethese( 10, {
    "foo" => sub { foo() },
    "bar" => sub { bar() },
    "baz" => sub { baz() },
} );

I don't expect you to read this, but it's all the code I needed.

Chooses whether to benchmark or profile based on whether you had -d:NYTProf

profile_or_timethese is just like timethese from Benchmark

writes separate profile for each test.

oohh, ahhh, flame graphs. Brendan Gregg++

Catalyst profilng is a pain. Sure you can stop it, enable profiling in single threaded mode and make a request, but I'm too lazy for that.

Added a NYTProf bundle that sets everything up.

"Bundles" are an internal extension, kinda like Catalyst roles, can have all Catalyst components and get "injected" into your app. Wish we didn't have so much customization so I could share it.

Start app with a `-DNYTPROF` flag and it adds the bundle. Each request is slow but writes an nytprof.$request_id.out file. Plus "/nytprofile" action listing all the requests.

Automatically generates the HTML profile on demand.

A lot of what has been annoying me recently is testing. So my tools have been for that. Here's one you can use. I treat it as "re-prove", but it does look on you reprovingly when you're unable to get things working. What it does is re-run prove whenever a file changes. Not a real project, no time yet. Demo!

During all this development, the one thing that makes me happy is that I don't just open a browser and click "reload" over and over. Even just running "prove" was fairly annoying. I saw this Ruby TDD video and in the spirit of stealing great ideas, "reprove" was born.

Writing more tests means longer test suite runs. reprove will run a subset of tests. While reprove helps by running a subset of tests, soon I hope to work on making the tests fasterer.

Normally if it spots something that isn't a test, it runs prove with whatever arguments you originally passed, which could be just a subset of tests. If it notices a change to a test file it will just re-run the tests found in that file. I have ideas to add support for looking at test coverage results and in conjunction with `git diff` re-running the tests that seem like they'd exercise the code you've changed. But so far it works well enough and is in a gist on github.