Slash Boxes
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 ]

kaare (663)

  (email not shown publicly)

Journal of kaare (663)

Wednesday May 02, 2007
02:00 AM

After lunch, before Christmas

[ #33176 ]
I guess this journal should have been out Sunday at the end of NPW07, but I will adhere to The New Perl Catchphrase (See Subject). I think about using it for my contract work, but on the other hand I'm afraid that my clients will use it afainst me when I ask for the paycheck.

Like everybody else, I'm anxious about the frontline development in Perl. So I attended

  • Leon Brocard (acme) - What's new in Perl 5.10?
  • brian d foy - Learning Perl 6
  • Jonathan Worthington - Classes, Roles and Constraints in Perl 6
  • Nelson Ferraz - Adventures in Perl6

All very, very nice presentations. Just like the first time I read the Apocalypses, I will say: "Gimme now!"

Can't wait for Christmas...

I also attended

  • brian d foy - Flexible Business Rules with Brick

I still can't really figure out which problem domain Brick is solving. Brian talked about Business Rules, but in reality described a Next Generation Input Validator. For me Business Rules are all about computing taxes, deciding how to do the accounting for your automatic invoicing etc. Perhaps the validator is only first step?

If I weren't so tired Sunday afternoon, I would have bugged Brian, but at that time I could think of nothing more than my nice, soft couch.

I guess I'll try to catch Brian another time, perhaps there is a mailing list or an IRC channel.

There were a lot of other very fine talks, and the event went really, really smooth. Hard to top next time!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • In 30 minutes, I didn't really have time to get into depth with Brick. Oh well.

    It's about a lot more than input validation. User input is only part of the problem, which is why Brick isn't built around it. The rules can be about anything and isn't tied to input fields or anything else. You figure out what constrains the system and build the rule set from that. You then use Brick to see if the current situation obeys the rules, and Brick tells you where it doesn't.

    The use cases you describe (computing taxes,
    • What I like about it is that it seems to provide a bridge between business types and coding types with its clear language. I think that is a really, really important advancement that has been ignored. It is a pity since with more understanding from those who pay for programming, more and better programming could be done, IMHO.