Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

notbenh (7967)

notbenh
  (email not shown publicly)
Yahoo! ID: ben_hengst (Add User, Send Message)
Jabber: ben.hengst@gmail.com

just a guy, living in portland OR... doing things.
+ -

  Comment: RabbitMQ (Score 1) on 2010.03.12 17:20

by notbenh on 2010.03.12 17:20 (#71776)
Attached to: Job queues

I have no experience but I've considered it a few times. If I remember correctly it speaks HTTP/JSON like CouchDB so accessing via perl (or anything) is easy.

Read More 8 comments
Comments: 8
+ -

  Comment: Spec's welcome (Score 1) on 2009.09.08 14:29

a few members of pdx.pm (including me) are working on a benchmarking framework with the intent of being able to build nice charts and graphs to show rakudo getting faster and to compare it to perl5. We're using the euler problem set just as an example for now but if you have specific specs that you would like us to hit I would love to hear them.

http://github.com/notbenh/euler_bench/tree/master

Read More 10 comments
Comments: 10
+ -

  Comment: care to contribute to the euler_bench program? (Score 1) on 2009.07.29 15:06

by notbenh on 2009.07.29 15:06 (#69761)
Attached to: My take on Euler #52 in Perl 6

{after some poking from Eric Wilhelm I'll post this here as well}

I'm part of PDX.pm and we've started a project to collect solutions to euler problems as a way to benchmark rakudo. We would love to have you join in the fun. Currently everything is up on github (http://github.com/notbenh/euler_bench/tree/master).

Read More 6 comments
Comments: 6
+ -

  Comment: care to contribute to the euler_bench program? (Score 1) on 2009.07.29 14:40

by notbenh on 2009.07.29 14:40 (#69760)
Attached to: Project Euler Problem #8 Script

I'm part of PDX.pm and we've started a project to collect solutions to euler problems as a way to benchmark rakudo. We would love to have you join in the fun. Currently everything is up on github (http://github.com/notbenh/euler_bench/tree/master).

Read More 1 comments
Comments: 1
+ -

  Comment: easy, be more strict. (Score 1) on 2009.04.17 16:02

by notbenh on 2009.04.17 16:02 (#68161)
Attached to: What Should You Test And Why?

You can simply enforce typing:

use Carp::Assert::More;

sub recip {
      my ($num) = @_;
      assert_nonzero($num);
      return 1/$num;
}

Then write one test to make sure that it works:

is( recip(2), .5 );

one to show that it dies correctly:

dies_ok sub{recip(0)};

and your done, any bugs that come up later can be tested then.

Read More 6 comments
Comments: 6
+ -

  Comment: moose? (Score 1) on 2008.12.17 17:50

by notbenh on 2008.12.17 17:50 (#66531)
Attached to: How Dare You Mock Me!


      package My::Map;
      #stuff

      package My::City;
      use Moose;
      has [qw{longitude latitude}] => (
            is => 'rw',
            #could make your own type, though for consistency
            isa => 'Num',
      );
      has name => (
            is => 'rw',
            isa => 'Str',
      );
      has map => (
            is => 'rw',
            isa => 'My::Map',
            default => sub {
                  use My::Map;
                  My::Map->new;
            },
      );

      #needless, but here for consistency
      sub setMap { shift->map(@_) };
      sub routeTo {
            my ($self, $targetCity) = @_;
            #stuff
      }

So the code is not that much different, Though you gain one big plus, type checking for setMap.

Read More 2 comments
Comments: 2
+ -

  Comment: is it possible to change workflow? (Score 1) on 2008.12.15 17:51

by notbenh on 2008.12.15 17:51 (#66482)
Attached to: Idealism Versus Reality: Reality Wins
Our work setup is that everything runs thru a QA branch (trunk -> QA -> branch ). This is a patch for us not having a proper path to live so we just have a branch for stage. But this affords us a single path to trunk. So it would be feasible to merge to QA, run the fast tests on QA, if I feel good enough about my changes and I'm lazy then you can have a process that runs at night that:
  • locks the QA repo (no more commits)
  • runs the long tests
  • if all passes then merge to trunk
  • else email all the developers the output of the tests.

This doesn't make the wrong things wrong-er but it does make the right thing easier.

Read More 7 comments
Comments: 7
+ -

  Comment: ok, but how to fix this? (Score 1) on 2008.12.12 16:15

by notbenh on 2008.12.12 16:15 (#66448)
Attached to: for file in @frack!
I think that my most common 'non-perl-ism' would be 'elseif', easily fixable but still annoying, though that said I think that perl is a flexible enough base that we ~could~ address most of these (though ~should~ is a very different point). So, whats the next step? Do we write a bunch of editor hacks that clean up our fingers output? Do we start writing modules that allow for such errors to become valid?
Read More 13 comments
Comments: 13