Joe McMahontag:blogs.perl.org,2009-11-03:/users/joe_mcmahon1//13622014-06-04T16:48:04ZA blog about the Perl programming languageMovable Type Pro 4.38What I learned in college because I had to use mainframestag:blogs.perl.org,2014:/users/joe_mcmahon1//1362.60832014-06-04T15:55:54Z2014-06-04T16:48:04ZAndy Lester's got a great article over at the New Relic site which makes me realize how lucky I was in college. I graduated in 1979; our computing platform was a 360/75, late upgraded to a 370/145 (I think) still...Joe McMahonhttps://pemungkah.com
Andy Lester's got a great article over at the New Relic site which makes me realize how lucky I was in college.

I graduated in 1979; our computing platform was a 360/75, late upgraded to a 370/145 (I think) still running OS/360 in a VM under VM/360. This meant that for our own projects, we actually ended up doing a number of the things that Andy talks about as a matter of survival.

We did not have a version control system at all; we ended up using generation data sets and meticulous tape backups to manage our source code. A tool that just made that work would have been a miracle. (I remember well having to write and use programs to recover "deleted" partitioned data set members when one realized that it would have been a good idea to back that member up but didn't.)

We did indeed learn to write in the "weeder" class, assembly language programming. It had a professor who had a very specific idea as to what was good style and what was not - and a meaningful comment on every instruction was a key part of that style. One learned to write a good description of the algorithm one was implementing in the comments, as each "bad" or missing comment was 5% off your grade!

We didn't have full-up Perl style regular expressions in every language, but there was SNOBOL, with its first cut at a regular-expression driven language, and a few interesting wrinkles that Perl doesn't have. That was an eye-opening experience into just how powerful regular expressions were, and SNOBOL remained my go-to text and data munging language until I left mainframes.

Understanding libraries was key when one was writing primarily in assembler (it was fastest to compile and used the least resources to run, very important on a not-very-large timeshared machine); the more code you could reuse, whether IBM's or someone else's, the less time you spent waiting for a job to turn around and come back, so building libraries (both macro libraries - sequences of configurable assembler code that expanded inline - and binaries) was key to becoming productive and staying that way, simply because the more code you had that you didn't have to debug each time, the less time you wasted on waiting around for runs to finish. This also explained why a lot of us became nocturnal and adept at finding our way into locked buildings overnight - no one else was running anything on the machine then; if you could find a terminal after 9 PM, you got nearly instant turnaround on jobs.

The first implementations of SQL available for IBM mainframes weren't out until after 1979, and those were quite expensive. I was working at NASA, infamous for having absolutely no money, so SQL databases weren't something we had for quite a while, and even then they were limited to very specific projects. A miss on that one, and definitely something that held me back somewhat until my current job, where I've really had to learn to use it well.

Tools were few and far between in 1979; editing was via WYLBUR, a line-oriented editor. Still very important to learn how to use it well, when the maximum speed you were getting out of your terminal was 30 characters per second (or 11, if you were on a Selectric terminal). Not knowing how to do global changes and finds would mean either sending your file to print, waiting for the turnaround, and then hand-editing, or many, many 'list' commands, and failed jobs because you missed a change you needed to make.

Assembler was fantastic for teaching defensive programming because almost nothing could be taken for granted. If you needed bounds checking, exception handling, error checking, anything - you had to code it. As an object lesson, there were some very interesting, and exploitable, bugs in OS/360 caused by bad bounds checking in the logical equivalent of system calls, like the one that took an offset into a dispatch table to call code in privileged mode - but didn't verify that the offset was actually valid...

I very, very luckily fell in with some very talented programmers; simply because the programming environment was so primitive, we were impelled to build a hack that would let us run a job and communicate to it via a shared file - essentially we built a one-lung version of TSO to help get our work done faster.

We had to work with the existing conversational programming language implementation (CPS, a PL/1 variant adapted to be sort of like BASIC) to figure out how to make the connection between it and the batch job (we eventually ended up using a keyed-access dataset, using one record for the command line, another for a "go-ahead/break" semaphore, and another for returning output from the batch job). This required us to work with what features we had available in CPS, as we couldn't extend it, and to collaborate to add and update features.

This was not a typical experience; I was astoundingly lucky to have had the caliber of classmates that I did, and as forgiving a systems group as we had. We were pretty sure that they had figured out we had created a clandestine time-sharing system, but they were kind enough to let us run it - and we were careful to not abuse their trust.

See that third goto fail? The first two take advantage of the fact that in C, you can have a single statement following an if, or you can use a curly-brace-delimited block. That third goto, positioned as it is, becomes an unconditional branch.

So the SSL signature verification never happens - the session is happily accepted and off we go to who knows where. If the block syntax had been used, there would simply have been a second unreachable goto in the block (and if -Wall was on there'd have been a warning about that) - and there would have been no security bug!

]]>
Interview tools: "Walk me through this"tag:blogs.perl.org,2014:/users/joe_mcmahon1//1362.56832014-02-18T22:54:26Z2014-02-19T00:10:37ZI've been experimenting with something in the interviews I've been doing most recently. Turns out it works quite well, so I'm sharing this in the hope that it will help you as much as it has me. One of the...Joe McMahonhttps://pemungkah.com
I've been experimenting with something in the interviews I've been doing most recently. Turns out it works quite well, so I'm sharing this in the hope that it will help you as much as it has me.

One of the most important things on a software team is code reading comprehension and communication: the ability to read code, whether yours or someone else's, and walk through it, explaining to someone else what it does. Sometimes you'll be reading your code and explaining it to someone else; sometimes you'll be reading someone else's code and explaining it to yourself, sometimes you'll be looking at something brand-new to everyone and trying to puzzle it out.

One way to test this is to ask the interviewee if they have any code on GitHub or BitBucket or anywhere else they're proud of and that they'd like to walk you through. This is valuable for two reasons: one, you get a chance to see what the interviewee thinks is their best code, and two, you get to see if they're any good at communicating what they know.

They might say, "well, I don't have any Perl code, but I have this other thing I wrote." This is even better, If they do a good job of explaining it! One candidate, explained some Arduino real-time code, monitoring USB connections to reverse engineer protocols in painstaking and magnificently precise detail. They did such a good job that I could have easily pitched in and worked on the code after a half-hour walkthrough. (We made an offer and they accepted, and we have hugely benefited from this person's talent.)

If they don't have anything available, the next best thing is to fall back on "what's your favorite CPAN module?" and then go through that. This can be highly instructive. If the interviewee says, "well, it's Moose, but that's going to be hard to explain without a lot of context," you learn that the interviewee does indeed have an instinct for complexity and how long it will take to do something complex. If they go ahead and succeed, it's even better yet!

If they pick Data::Dumper, and then realize that the code is pretty complex, but forge ahead and do a good job anyway despite its somewhat idiosyncratic way of dealing with things, you've learned that they're persistent, willing to work though difficult code, and don't fluster easily, in addition to their being fluent.

Understandably, not everyone is really good at this, nor do they have a pet module they feel familiar with. In those cases, I usually use my Acme::Geo::Whitwell::Name module as a sample thing to walk through, because it's a relatively small module which none the less uses a fair number of Perl features. Also, since not everyone is good at grokking code they've just now laid eyes on, it's sometimes necessary to do some hand-holding and "let's skip that for now and come back later"; in those cases, you just want to make sure that they get the flow of control, they understand the idioms they're looking at (or say, "I've not seen that before, what do these lines do?").

This technique is very useful in phone interviews where it would be tough on everyone to do code samples on the logical whiteboard. (You can of course do those with Google Docs and the like.) It's real strength is in the things it tells you other "this person has written some Perl." It gives you an idea of how well the interviewee is likely to do when handed a chunk of your code - or the whole codebase - and told, "I need you to find and fix this bug". Being able to read code and understand it well enough to communicate your understanding helps immensely with the most basic kinds of jobs it's always necessary to do when writing code: what does this do? what is is supposed to be doing? why is it not doing that?

This does not have to be a pressure technique. Your job is to walk through the code cooperatively, and help them over stuck places. If you hit something neither of you is comfortable with, you can move the conversation to, "so how would we write a test to figure out how this works? is it even possible to write a test? where should we look to see if this is tested?".

If they get stuck on something, like a complex regex that's not in /x format, or a hash slice, or something else new to them, be prepared to fill in information to see if they can take it from there. Note what they did and didn't know, and explain it - but also note where the gaps are in their knowledge - they may or may not be in places that matter; knowing every kind of zero-length assertion is great, but not everyone does. (Not knowing them at all is a point to be noted, especially if they're common in your codebase.) Ask "where should we go look to find out what that does?" and see if, once you've assisted them over the bump, they get back to smooth sailing again.

Overall, this has been a useful tool to me, and has resulted a couple of very good hires. Give it a try if you want to get away from the "write some code to do this in five minutes" kind of interview. (Of course that should still be covered; if you're the sole interviewer, you'll want to have at least a little coding happen.)

I'd love to hear what people think of this idea, and let me know if you try it.

]]>
"You and your ilk are a tiny minority trying to impose your opinion upon the majority who actively and vocally disagree with you."tag:blogs.perl.org,2014:/users/joe_mcmahon1//1362.56392014-02-10T17:40:07Z2014-02-10T18:37:23ZI will no longer be participating at Perlmonks....Joe McMahonhttps://pemungkah.com
I will no longer be participating at Perlmonks.]]>
Better interviews and better hiringtag:blogs.perl.org,2013:/users/joe_mcmahon1//1362.48212013-06-23T01:52:08Z2013-06-23T01:57:07ZSo the tech interview is starting to change. I am very glad to see the end of the "puzzle palace" interview. Had a number of those and never did very well at them. To quote the meat of the article:...Joe McMahonhttps://pemungkah.com
So the tech interview is starting to change. I am very glad to see the end of the "puzzle palace" interview. Had a number of those and never did very well at them.

To quote the meat of the article:

Quickly filter out the technically inept by asking half a dozen basic technical questions – Atwood calls this “the FizzBuzz filter.” Ideally you can do this online. You’ll be amazed how many people fail. (If they’ve been recommended to you, you can skip this step.)

Talk to them–in person if they’re local, voice-only if they’re not–about technical problems they’ve faced, tools they use, decisions they’ve made, pet peeves, etc. This is the “behavioral interviewing” that Google’s data shows to be actually useful. Note, however, that while you’re discussing technical concepts, you are not grilling them with technical questions that must be answered correctly.

Above all, discuss their past projects, how they got them done, and the decisions they made en route. Maybe have them talk you through some of their code on Github. To reiterate my own line: Don’t hire anyone who hasn’t accomplished anything. Ever. If a developer doesn’t have a portfolio they can talk to you about, not even any side or pet projects…then don’t waste your time talking to them at all.

Try to establish “cultural fit” … although be very careful that you’re just talking about work culture, eg enterprise vs. startup, and that this doesn’t lead to “subconsciously excluding people who aren’t just like you.” Don’t become a frat full of brogrammers.

Finally, if they’ve gotten this far, give them an audition project. Something relatively bite-sized, self-contained, and off-critical-path, but a real project, one that will actually ship if successful. Hire them on a paid basis for a week or so to build it, and keep a close eye on their code and progress. (If you do pair programming, have them pair with your existing team.)

Hire them. Or don’t.

I think a) this is much more likely to get you good programmers, and b) is much more likely to be a path to success for good programmers who don't have The Resume but have the talent. I know a lot of folks who would totally shine at this but can't write "code on the board" worth crap.

I do like to do a "so how would you design this? how would you test it? what might you do to deploy it?" section; it's nice to see if someone actually has experience with getting stuff off their desk and out in the world.

]]>
What exactly is going on at Perlmonks?tag:blogs.perl.org,2013:/users/joe_mcmahon1//1362.44952013-04-04T00:13:05Z2013-04-04T01:33:41ZI went back to Perlmonks for the first time in quite some time, and was greeted with by a poll titled "How many man-hours would you estimate you have invested in learning Perl?" - okay, could have been hours, not...Joe McMahonhttps://pemungkah.com
I went back to Perlmonks for the first time in quite some time, and was greeted with by a poll titled "How many man-hours would you estimate you have invested in learning Perl?" - okay, could have been hours, not enough to make a big deal of, I'm trying not to make every interaction on the site about male privilege...aw, dammit:

None - I refuse to acknowledge the term man hours, you patriarchical pig. But I have many person-hours. And let me tell you...

Oh, COME ON.

This is going from microaggression ("man-hours") straight into pure jackassery. Straw feminists are just as much a stereotype as any other. Making jokes that require me to be complicit with a stereotyped view of the world really gets up my nose.

It sends the message that "we here at Perlmonks think this kind of thing is really funny and we don't care what you think. We especially don't care if you're the kind of person we're enjoying making fun of."

What happened to trying to be inclusive? Did you guys (and I specifically mean the men) not watch Schwern's keynote? (If you didn't watch it, there's the link - you have no excuse.)

Did I miss the memo where Perlmonks was officially declared a boys-only club, where he Internet equivalent of farting and catcalls is the dominant paradigm? Or is this just an attempt to claim of "we don't have to be civilized if we don't want to" to see if anyone will notice?

Yes, do let me tell you: I noticed. And I think it's ugly and disgusting.

Feminism does not require you to be female.

]]>
]]>
"White knight", a meditationtag:blogs.perl.org,2012:/users/joe_mcmahon1//1362.37932012-09-05T21:24:17Z2012-09-06T17:16:15ZIf you think "white knight" is a crap term, a convenient argument-by-dismissal tactic, then you probably already know all this, but there may be some useful ideas for the next time someone attempts to spring this on you. On the...Joe McMahonhttps://pemungkah.com
If you think "white knight" is a crap term, a convenient argument-by-dismissal tactic, then you probably already know all this, but there may be some useful ideas for the next time someone attempts to spring this on you.

On the other hand, if you're one of those who think it's the scored-the-touchdown-high-five-we're-done-here way out of any situation where you've said or done something crappy and then been called on it, you're probably not going to read this anyway, but I shall go ahead and write it so you will have to waste energy making up increasingly vituperative denials which I will pointedly ignore.

I have heard this term used both explicitly and implicitly multiple times recently because I decided to speak out on something that I didn't like and that mattered to me, despite the fact that it wasn't about me. "White knight" supposedly means that I spoke out solely to impress somebody with how noble and great a person I am, and that I otherwise wouldn't have made the effort, and that it was all about what I could get out of it.

First: if you really think people only do things to for their own benefit, like the Grinch, your heart is several sizes too small.

Second, I have no need to do this, thanks - I've actually learned social skills and things, and can actually manage to communicate with people other than by waving metaphorical "SEE I'M A NICE GUY OH GOD I'M SO ALONE" signal flags across the Internet. People who know me personally know I do things because I'm genuinely decent, as opposed to someone who's "nice" and expecting a payback. That is what is known as "manipulation".

Third, despite the fact that I am indeed heterosexual and male, I have no desire to have sex with random people simply because they are female and breathing.

Last, nice try at making it about me rather than the stunningly ill-bred, bad-mannered, and probably stupid thing you just said.

Moving on, let's talk about Perl and CPAN.

Perl exists because Larry Wall decided that this tool he put together for his own purposes would help people - would "make the easy things easy and the hard things possible." He wrote it, and gave it away for free. Many other people found it, used it, thought it good, and offered their own time and effort to make it better, with the only thing they got directly being recognition. Perl and the Perl Porters made people happier.

CPAN exists because many people, most of whom don't know each other at all, decided to give away something they made to anyone who wanted it, without regard for reward. the only reason it happened at all was because one person, Jarkko Hietianiemi, created CPAN itself and said, "Here's a gift. It was needed, so I made it. I want nothing for it. Please use it if you want it." (Note: this is not a quote, but a paraphrase I've constructed out of seeing what Jarkko has done over the years I've known him and known of him. Yes, I admire the hell out of him and think he's a mensch. Fanboy moment over. Let's forge onward.)

Many others built upon this gift, extending the network and adding new modules to it, to the point that Perl is not so much a language but an incredible collection of software that happens to have one language that can run it.

The participants all wrote software, or set up nodes in the network, because their hearts (or ethics, as you prefer) told them "this is the right, good, and joyful thing for me to do". It was not free; it cost them each time and effort; but year by year it created a great and glorious thing. It made Perl into a great force for making things happen. It made them happy.

So, we have people voluntarily doing something for the good of others they don't even know personally. Doing it because it was, in their eyes, the right thing to do. Doing it for nothing other than perhaps the admiration of others, though that wasn't guaranteed. Sometimes they even did it to help others - for people who didn't even know they'd done it. Doing it to increase joy, whether they knew it or not. It made them happy.

Does this not make them all "white knights"? Shall we sneer at them all now because we all "know" that they wrote all that software to impress someone?

Does this get across how incredibly small-souled, short-sighted, and just plain dumb this is?

To reduce it to its most basic: actions which are termed "white knighting" are those meant to help make more joy by pointing out that trying to reduce joy is wrong. Joy, like software, is not a zero-sum game. You don't have to make someone else less happy to be more happy. You don't make Perl better by talking about how horrible Python is. They both stay the same. You're just substituting schadenfreude for true joy.

Trying to remove something from the world that would decrease someone else's joy by saying, "that's not right," is a good thing to do. Even if it doesn't work, you've still said, "Not everyone thinks you should be less joyful. Someone else in the group this came from thinks it's wrong." That won't undo the nasty thing, but it might help take the sting away a little.

So the white knight is the CPAN author of the heart.

I believe in creating joy however I can. I've released a fair amount of free software. I also believe in trying to create joy through words and the truth, and not tolerating things that are wrong. I can't write every module on this metaphorical CPAN, but I can try to write the ones that apply to the things I do.

Please, do call me a white knight. From now on I think I'll say, "Hey, thanks for noticing! Like to help?"

]]>
Social diagnosticstag:blogs.perl.org,2012:/users/joe_mcmahon1//1362.37862012-09-04T18:20:37Z2012-09-04T19:13:48ZFirst, a huge thank-you to all the folks who have commented on my post (whether they agree with it or not) and who have followed up on Perlmonks to say "well, I think this might be correct" - or not,...Joe McMahonhttps://pemungkah.com
First, a huge thank-you to all the folks who have commented on my post (whether they agree with it or not) and who have followed up on Perlmonks to say "well, I think this might be correct" - or not, as long as it's not about me, but about the topic. I think it's important to talk about what happened, even if no one's mind is directly changed.

I'm afraid that at least one of the participants feels singled out, which was not my intention. I am truly sorry that this person feels attacked. This was totally not what I wanted or was trying to do.

To try to clarify this social thing for folks who normally ignore it or don't see the point, I'm going to invoke an extended metaphor here.

All I wanted to do, to go all technical about it, was to issue a social diagnostic: a warning, not an error message, that said "I think Perkmonks needs to be inclusive, and sexualizing software doesn't do that".

At no time did I want to say or imply anyone was a bad person, nor did I want anyone else to say so (If you did, please follow along here to see what I was really after). Nor did I want to say, "this social interaction, large and small-scale, cannot proceed unless this changes."

That's not what warnings are for. They are meant to inform - to communicate that there were perhaps unintended consequences. They are not telling you "you are a terrible, terrible programmer and should now walk away and start digging ditches". They are meant to say, "you've made a choice that may have consequences other than you planned, and you should consider correcting this," and "when you run this, it may not do exactly what you intend it to do."

I believe, that originally, the impulse was to share something that brought lightness to the original poster's day. It ran on his internal mental architecture and made him smile or laugh. Running on his internal mental processor, there was no diagnostic that said "this may have unintended consequences on other architectures". The idea is to internalize that other architectures exist, and that you may need to adjust code released ostensibly to run on all of them.

It's the difference between getting an OS-X-only diagnostic and saying, "oh, right, I should change that so it runs properly there" and saying "well, you ought to be running a decent OS and then you wouldn't have this problem". Or even saying, "I really don't have a way to make that work on a Mac. I should consider whether that feature should go in to the main release - or if I should release it in a way that Mac users know it's not for them".

We have been guilty, to a certain extent, of dismissing Windows in the Perl community. Having that attitude doesn't make Windows folks say, "my heavens, you're right - I have seen the light and shall abandon this OS and the years of investment in it right away!" Instead, it makes them say, "man, what a bunch of prejudiced, blinkered idiots! Why am I bothering with this?"

A social diagnostic is meant to provide information. You can decide that it's not worth bothering with and ignore it, or take it to heart and try to make a change. Attacking the source of the diagnostic is counter-productive. If you get a warning that you've reused a 'my' variable, you don't say, "well, this verion of Perl is complete garbage, because I want to do that, and therefore it should change to allow me to do so."

You either tell the compiler "I know that I'm doing this and I want to; please turn off that diagnostic here", or you look at the code and say, "Hm, okay, I can change that".

You don't, however, complain "the Perl interpreter isn't accepting and running this perfectly good Python code; there must be something wrong with the compiler that it would tell me that it thinks my program shouldn't run here". You can either fix it so the Perl interpreter can run it, or you go use the Python compiler for that particular bit of code. (If that was too esoteric a parallel: there are places where posting that cartoon wouldn't have offended anyone in that place, and if you want to hang out in those places, I'm not going to say you shouldn't. I may think so, but I don't have the right to tell you where you can go and who you should hang out with. I will tell you if you do something that i dislike; it is up to you to decide if you want to not do it where I can see it - and if you want to keep doing it at all once I've mentioned it.)

There has been quite a bit of black-and-whiting in this discussion: "oh, you obviously think you're perfect and that I'm terrible". As I said on Perlmonks, I screw social things up all the time - even with close friends. Maybe especially with close friends.

I badly hurt a close friend this weekend because I didn't think it through before I said something (not in a gender-related discussion, though). I am totally not saying "I know better about what all women think than you do." Women whom I know and admire - and who are very accepting people, and whose ability to think in a straight line I deeply respect - have said to me, "someone posted this? Seriously?". So I transmit the diagnostic because I'm there, and playing on the lowest difficulty setting and am therefore sufficiently sure of myself in the community that a bad reaction isn't going to make me think, "jeez, do I really belong here at all?".

Again, I'm sorry it got and felt personal. It was never intended to be, beyond saying, "here's a place where by saying, 'whoops, I guess that wasn't as appropriate as I thought', you personally can do something to help Perl's image as a boy's club, and I would admire you a lot for doing so, though I admit I'll be disappointed if you don't."

]]>
Why I'm considering dropping Perlmonkstag:blogs.perl.org,2012:/users/joe_mcmahon1//1362.37602012-08-28T18:38:28Z2012-08-29T09:23:06ZA couple days ago, a comic strip was posted to Perlmonks that really got up my nose. For those of you who don’t want to bother linking through, the strip compares Perl with Moose to Perl having a “boob job”,...Joe McMahonhttps://pemungkah.com
A couple days ago, a comic strip was posted to Perlmonks that really got up my nose. For those of you who don’t want to bother linking through, the strip compares Perl with Moose to Perl having a “boob job”, then wanders off into creepy territory because sexualization and creepiness are really, really funny, right?

This bothers me, as it’s not friendly to the women in our community – and I said so. You can read the response I’ve gotten so far. They’re all pretty much ignoring the fact that sexualizing a computer program (with the added implication of large breasts being equivalent to personal value) is exactly the kind of thing that makes women feel unwelcome by focusing on “well, ‘boob job’ is a perfectly fine term” and “I bet you do feel uncomfortable imagining you’re female!”. (By the way, no, I don’t. This is that funny thing called “empathy”.)

I’ve mentioned the atmosphere of disrespect toward women previously in other threads and gotten solidly downvoted for it – and had to repeatedly defend the idea that maybe everyone ought to consider whether the boys’ club atmosphere isn’t something we ought to change.

This depresses me. Perlmonks can be tremendously valuable, but it seems to me that the loudest voices are not listening to things they really need to hear. It’s not all about the tech; it’s about helping people, whoever they are, get more out of Perl.

]]>
git svn vs. svn2git (vs. "svn2git")tag:blogs.perl.org,2012:/users/joe_mcmahon1//1362.35182012-07-11T20:11:38Z2012-07-11T20:20:57ZIf you're ever in the position of needing to convert a large (in our case around 32000 revisions) Subversion repository to a Git repository, you should know git svn is agonizingly slow, and falls over at regular intervals (apparently memory...Joe McMahonhttps://pemungkah.com
If you're ever in the position of needing to convert a large (in our case around 32000 revisions) Subversion repository to a Git repository, you should know

git svn is agonizingly slow, and falls over at regular intervals (apparently memory problems; symptom is "git svn died with signal 13")

The KDE version of "git2svn" is written in C++, requires that QT4 be installed (so you have "qmake"), and requires a local copy of the SVN repository. If you have it, it is apparently blindingly fast - in my case I didn't have direct access to download the whole SVN repository.

So for my conversion I used the "svn2git" Ruby gem. It works very well indeed, and is screamingly fast. My current import has been running for 12 hours and is about halfway done - this may seem slow, but the "git svn" version, even wrapped with a Perl program to restart it when it fell over, ran for over three weeks before hitting a situation where it couldn't continue, with the import imcomplete.

I'll update the post once the import completes - or if it doesn't!

]]>
I Want My Objective-Ctag:blogs.perl.org,2012:/users/joe_mcmahon1//1362.34382012-06-28T05:14:40Z2012-06-28T05:47:57ZThe other day, as they idea of the defined-dereference operator (~> is the favorite at the moment), I proposed the idea of implementing a pragma that changed what Perl does when it's faced with a dereference of, or a message...Joe McMahonhttps://pemungkah.com
The other day, as they idea of the defined-dereference operator (~> is the favorite at the moment), I proposed the idea of implementing a pragma that changed what Perl does when it's faced with a dereference of, or a message sent to, undef. Right now, of course, it dies.

This bit me hard this evening as we put up some new code; I have a Mason template that calls a series of methods to get a particular piece of status information to be shown to the user. I had bullet proofed it, or so I thought.

Yep, $barthing->baz came back undef, and an error page instead of my actual page.

Now, in the Objective-C world, nil, the Objective-C equivalent of undef has a special property: it accepts any message, and returns nil. So a lot of the boilerplate code (Get an object. Did I get it? Call a method. Did I get another object? Call a method. Did I...and so on) goes away - you don't need it at all. In the case of my code, if I had Objective-C-like undef-as-nil:

Much less code, and I don't have to remember to check each step, unless I specifically want to do something if a given step is undef. If I do, I can use defined-or to set the value I want instead.

So now I have an excuse to work on this pragma - I actually do need it for work!

]]>
MIME::Base64 and pearlclutchingtag:blogs.perl.org,2012:/users/joe_mcmahon1//1362.33922012-06-14T18:23:13Z2012-06-14T18:47:16ZI've been working on WhiteHat's new sourcecode scanner, and one of the things we need to do is transmit snippets of source code around inside of XML. Since many XML parseres are notoriously sensitive to non-ASCII characters, even in CDATA,...Joe McMahonhttps://pemungkah.com
I've been working on WhiteHat's new sourcecode scanner, and one of the things we need to do is transmit snippets of source code around inside of XML. Since many XML parseres are notoriously sensitive to non-ASCII characters, even in CDATA, we decided that the simplest thing to do was Base64-encode them. This shouldn't be a problem, right?

Well, no. Turns out that MIME::Base64 is very picky itself about encoding things properly. If you hand it UTF-8, it screeches, "Characters with more than 8 bits?! Heavens!" and falls over. There's an incantation noted it its documentation that will let you handle it, but it didn't, at least for me, work all that dependably.

A little poking around turned up Encode::Encoder, which works like a charm, and is very clean:

Pretty sweet. Only one thing to note, which is probably unique to my application: the result returned from an encoder()->base64() call (and the corresponding ->utf8() call) is an object, not a string. If you're going to want to hand those off to the standard JSON module, be aware that it does not like this, and will die with the error encountered object 'Point=HASH(0x40017288)', but neither allow_blessed nor convert_blessed.

It's easy enough to get around this: just interpolate the output from the base64() method into a double-quoted string. This invokes the object's qq() overload and gives you a plain old string:

$actual_string = qq($encoded);

If you want to do that all in one operation without a separate variable, you can use this trick to interpolate an evaluated expression into a string:

$actual_string = qqbase64]}>;

That's evaluate the expression, make it the only element in an anonymous array, then dereference that array in the string to force the value of the element to be interpolated.]]>
Look, I Just Paid the Billtag:blogs.perl.org,2012:/users/joe_mcmahon1//1362.33872012-06-13T23:48:57Z2012-06-13T23:59:01ZIf you visit the Silicon Valley Perl Mongers Meetup site, you'll see that I'm now listed as the organizer. This is not strictly true - Ian Kluft is still our primary organizer, but due to the fact that Meetup sends...Joe McMahonhttps://pemungkah.com
If you visit the Silicon Valley Perl Mongers Meetup site, you'll see that I'm now listed as the organizer. This is not strictly true - Ian Kluft is still our primary organizer, but due to the fact that Meetup sends out a metric buttload of mail - I have now witnessed this as organizer - he missed the "OMG SVPERL GONNA DIE" message that got sent, repeatedly, to all the SVPerl members when the Meetup bill was due in a week.

Everyone was getting nervous, so I jumped in and paid the bill, partly because everyone was getting nervous we hadn't heard from Ian, and partly because WhiteHat Security, my current employer (who I love, and you should come work here if you are a good Perl programmer - heck, if you're a good Python or Ruby programmer, come and we'll teach you Perl) said they'd pick up the tab.

So, woo, I'm an organizer. I just like having an excuse to give talks!