Time |
Nick |
Message |
10:13 |
|
Dyrcona joined #evergreen |
10:14 |
Dyrcona |
I'm becoming discouraged with programming communities in general and the Perl community in particular. |
10:15 |
Dyrcona |
In the documentation for Perl 5.20, there seems to be a real emphasis on using "magical" packages from CPAN and not really understanding what goes on under the hood of those classes or being able to implement your own. |
10:15 |
Dyrcona |
For instance perltoot was replaced perlootut. |
10:15 |
Dyrcona |
perltoot explained is some detail how typical OO packages work. |
10:16 |
Dyrcona |
perlootut can be summed up as use Moose. |
10:19 |
Dyrcona |
Oh, and GET OFF MY LAWN! :) |
10:25 |
|
jwoodard joined #evergreen |
10:39 |
jcamins |
Dyrcona: perlootut should be perfect for you! It's pronounced "Perl-o, oh tut." |
10:41 |
Dyrcona |
I think that was meant to be funny, so I'll take it that way. :) |
10:41 |
jcamins |
Dyrcona: there's a reason I'm a programmer and not a comedian. |
10:41 |
Dyrcona |
:) |
10:41 |
* jcamins |
thought it was funny. |
10:42 |
Dyrcona |
Maybe I didn't read that with the right cadence or inflection. :) |
10:42 |
Dyrcona |
tut, tut. :) |
10:44 |
csharp |
@who is tut-ing their own horn? |
10:44 |
pinesol_green |
csharp is tut-ing their own horn. |
10:44 |
csharp |
ha! |
10:52 |
eeevil |
Dyrcona: I blame the ruby and (to a lesser degree) python communities for the dumbing down of perl docs, actually. also, I'll just stick with my third camel and be happy |
10:53 |
eeevil |
oh, and get off my lawn |
10:54 |
Dyrcona |
heh. |
10:54 |
Dyrcona |
Explains a lot about ruby in that case. :) |
10:59 |
Dyrcona |
I think I have the 2nd edition on a shelf some where. |
11:28 |
jeff |
pfft. you kids and your blue perl books. |
11:31 |
jeff |
:-) |
11:40 |
Dyrcona |
To have separate classes for NCIP::Address:StructuredAddress and NCIP::Address:UnstructuredAddress and whether or not *both* forms of StructuredAddress should be supported, and if so, is it in one class, or in subclasses. |
11:40 |
Dyrcona |
That is the question! |
11:41 |
Dyrcona |
Think I'll chuck it and say we only support 1 form of StructuredAddress and if you want something else, patches welcome! ;) |
11:42 |
jcamins |
Dyrcona: sounds good to me. |
11:42 |
* Dyrcona |
feels like he's making lasagna. :) |
11:46 |
Dyrcona |
The lasagna bit comes in because the different address types in NCIP can have different metadata wrapped around the StructuredAddress or UnstructuredAddress elements. |
11:48 |
Dyrcona |
One thing: I've decided not to use AUTOLOAD, 'cause that messes with UNIVERSAL->can. |
11:49 |
Dyrcona |
So, lasagna: NCIP::User, has a NCIP::User::Address,is a NCIP::Address, has a NCIP::Address::StructuredAddress |
11:51 |
Dyrcona |
Because NCIP::Agency::Address (AgencyAddressInformation) *must* be different. |
11:51 |
* Dyrcona |
mumbles "standards..." |
11:57 |
Dyrcona |
Gah! That decomposition doesn't make so much sense, but then neither do these parts of the NCIP standard and schema. |
12:01 |
Dyrcona |
I love when ambiguous terms are used as if they have meaning: "indicates whether the physical address is a street address or a postal address." |
12:07 |
Dyrcona |
Or, I could just be cheap and not worry about decomposing everything into objects and just make the address fields members of the User class. |
12:07 |
Dyrcona |
Grr. |
12:07 |
Dyrcona |
This is the hardest part. |
12:41 |
jeff |
mailing/billing/physical... :-P |
12:54 |
|
gsams joined #evergreen |
12:55 |
Dyrcona |
jeff: The standard (at least version 2.02) distinguishes physical from electronic address. |
13:27 |
jeff |
huh. i guess nagios doesn't re-notify on an ACK'd problem even if the problem goes from WARN to CRIT. |
13:33 |
csharp |
jeff: that's in the config somewhere, I'm pretty sure |
13:33 |
csharp |
oh - ACK'd |
13:33 |
csharp |
maybe not then |
13:34 |
jeff |
i'm sure it can be configured one way or the other. the apparent default (or at least how it was configured on this instance) surprised me. |
13:34 |
csharp |
http://support.nagios.com/forum/viewtopic.php?t=22114&p=78539 |
13:36 |
|
zerick2 joined #evergreen |
13:38 |
jeff |
csharp: looks it was ack'd with sticky = 2, so that's what happened. |
13:39 |
jeff |
" If the "sticky" option is set to two (2), the acknowledgement will remain until the service returns to an OK state." |
13:39 |
jeff |
and that's the default in the ack UI, as mentioned in that thread. |
13:44 |
* csharp |
notes that for future reference ;-) |
13:47 |
jeff |
at least, with the version that we're using on this host. |
15:39 |
|
shadowspar joined #evergreen |
18:26 |
|
gsams joined #evergreen |
18:43 |
|
geoffsams joined #evergreen |
21:18 |
|
_zerick_ joined #evergreen |
23:39 |
bshum |
Well, apparently the 3.13 kernel that comes with linux-generic-lts-trusty does not play nice in an Ubuntu 12.04 KVM. Or at least it's not consistently booting anymore :( |