After the fun I had at OSCON last year, it was no effort at all for pjf to convince me to spend June and July in the USA this year, conferencing.
Portland, Oregon
South Australia is about to have its state elections. The incumbents have already attempted to ban anonymous public comment on the elections and now are making a big deal about computer gamers.
Mattel ran a competition for the public to pick Barbie's next career. There were about 5 options to choose from. Barbie's career as selected by girls around the world was News Anchor; however the popular vote was for Computer Engineer so they've done both.
A good write up with links to more has been done on the Geek Feminism Wiki.
I think your boss wants you to give a special to your customers who have given the business less than 15 pound ever. Yet you're grouping by order_date. Thus if your customer has purchased something for 10 pound last week and 10 pounds yesterday I would expect them to show up twice in the output:
John, Smith, 2009-11-30, 10
John, Smith, 2009-12-06, 10
I'm not much of a Stackoverflow user. However it doesn't strike me as a place designed to handle opinion-based questions. chaos' suggested rewrite:
what reasons are there to use protected members and/or to avoid them?
seems a little better, but I think the question still needs to be more detailed. Perhaps something along the lines of:
I have a class (X) and its child class (X::Y). X has a variable Z for some purpose. It doesn't make sense (for some reason) to make Z an attribute of X::Y but X::Y still needs to be able to access Z. I could implement it as a protected member, or I could expose it some other way. What is the correct approach in this situation and why?
I think the problem with your original question is that it is scope-less. Protected variables have some advantages and some disadvantages. However it's difficult to answer with something that would be relevant to the question because it's too hard to guess what you were thinking when you wrote it.
Despite loving programming, I don't find much opportunity to do much of it at the moment. Sure there are short-term consulting contracts and endless re-writes of our course answers, but that hardly counts. I'm also finding it a challenge to be inspired by a few things that I kind of should do but which aren't essential. For example how we handle bookings could be better automated, but until we quadruple the number of courses we run, the parts which are manual aren't really much of a probl
Those who know me will know that I'm not a stranger to conferences. I've been to all of the OSDCs, a few LCAs, a few SAGE-AU conferences and now an OSCON and YAPC::EU. Until YAPC::EU; the OSDCs and OSCON were my favourites as I identify myself far more with being a developer than a free software geek or system administrator. But I'd never been to a conference specifically aimed just at Perl developers.
Just want to say that this looks awesome. I hope you'll be giving a talk on this at some conference we're both at soon.
You make a good point. I think "good enough" backwards compatibility would still work fine though. My main concern is the addition of new pragmas that might be added to be loaded on default.
When I write use 5.010; I want to get given, when, say, and all the rest. But I don't expect autodie, strict, warnings and other such things to be turned on for me automatically. That could seriously break my code. I really like autodie, but I have some legacy code that does its own error handling. autodie does not allow for such code, unless you turn off autodie, it'll trump your error handling with its own. chromatic and others are arguing that these pragmas should come on by default in some future version of Perl. Which is an idea I also feel has much merit.
I'm merely suggesting that perhaps we can use the version number as a signal as to which of these pragmas should be loaded. I think these are much more likely to cause problems for the monoliths than new operators and similar features.
I agree with chromatic that it would be really nice to get a whole bunch of "Modern" features turned on in later versions of Perl by default. However, I also accept that this is probably a bad idea.
That's what I expected, thanks for the clarification.
By the way, I agree entirely. Although I did not see it, Hoss' talk is by far the most offensive and juvenile I've heard of (and well beyond what I would like to think I'd stay in a room to watch). I think it'd be difficult to make a more misogynistic-sounding, yet still sort of technical talk; but I won't say that it'd be impossible lest someone take it as a challenge.
I'm planning to role-play the situation a few times so that should I ever been in such a situation, I won't sit back in horror to watch the train-wreck but will feel some confidence in objecting loudly and asking that the speaker end their presentation; or at the very least objecting loudly and leaving.
I think the role-playing is necessary, as this doesn't seem to be an action most people are comfortable taking. Again and again, this kind of thing happens and the programme committee just sits by and watches it go wrong without getting up and booting the speaker off stage. I was guilty of it, Matt's room coordinator was guilty of it and Dave (the flashbelt organiser) appears to have been guilty of it too. I only know of one talk along these lines that was interrupted by the organiser, and that was at the Sydney Linux Users' Group last year.
Most of us are pretty good at not interrupting even when we feel that the material ought to be interrupted. I'm thinking of writing a brief training course on this topic to give something programme committees can practice with.
The example I referenced, at the conference I organised, was tame relative to Matt's talk too.
I'm not sure how to read your response. If you're alerting me to what happened this past week at the flashbelt conference; thank you. It's a shame this kind of thing could happen in such close time proximity. I was reading about it earlier today, and have yet to see if Hoss Gifford is going to apologise or if he'll leave his twitter comment as good enough. Fortunately I haven't (yet) seen people suggesting that if Hoss Gifford were to have included some more "female friendly" images it would have been okay (which was one of the focuses of the original post).
However I initially read your comment as if you were almost saying "Well this guy over here made an even bigger ass of himself and so Matt's talk wasn't so bad." I hope this isn't what you meant, as I feel it would be similar to arguing that it's okay to be very racist so long as there's someone else who's being extremely racist. Surely we accept that being racist (or in this case misogynistic) is a bad thing, no matter whether it's just very or extremely so.
I agree with the sentiment of the committer, but I also agree that the commit has thrown out useful information. Removing comments which at least give the reader an understanding of what's the author was thinking, just seems weird. Rewriting them would have been fine (and is what happened for most of them). As an example, the code goes from having the following:
if (pmi == NULL) {
/* Server response is *really* f*****d up,
I guess we just pretend it never happened? */
continue;
}
which at least tells the reader why continue is called at that point, to being:
if (pmi == NULL) {
continue;
}
Which looks bizarre... why do we continue? Why would pmi be NULL?
