Here we go again!
Thankfully, my employer thought that this year's YAPC::Europe (Corporate Perl) could be relevant for me, and so I'm going, hoping to learn yet more from all the excellent minds present there (modulo swine flu, I suppose ...).
The schedule contains way too many interesting subjects at the same time, but I'm happy to say that there's plenty of breathing room and time for socializing.
And this time, I'm bringing a computer, so that I can pretend to be doing something useful. Haha.
See you there!
Friday, July 31, 2009
Monday, July 27, 2009
Perl, open source and gender bias
Recently, I have been reading a discussion regarding gender bias in the tech industry.
I realize it is a problem, but for the past years, it has been more of an intellectual realization than something that hit me in the gut. Perhaps it has something to do with the work place culture where I have been working, combined with the informal technical fora I have seen, as well as the general state of things here in Norway.
However, these things are perhaps not talked about quite as much as they should, and today I re-learned that although things may seem mostly rosy, they are not necessarily so.
Kirrily "Skud" Robert has been active in various open source contexts for years, and should be no stranger to the Perl community. She recently held a presentation at OSCON -- Standing Out in the Crowd -- where she discussed some of the challenges when women are in minority, and experiences with open source projects where they are in majority.
What kicked me in the gut this time was the rather low percentage of women involved in Perl. While better than open source in general, it seems excessively low.
But Skud does not sling mud at the Perl community. Instead -- if I understand her correctly -- she aims to help open source communities -- and I suppose particularly new projects -- to utilize the resourcefulness of women in development, to reduce the gender bias by increasing the overall activity.
I can only recommend that you read the presentation, and contemplate the issue for yourself.
It certainly made me think. Again.
I realize it is a problem, but for the past years, it has been more of an intellectual realization than something that hit me in the gut. Perhaps it has something to do with the work place culture where I have been working, combined with the informal technical fora I have seen, as well as the general state of things here in Norway.
However, these things are perhaps not talked about quite as much as they should, and today I re-learned that although things may seem mostly rosy, they are not necessarily so.
Kirrily "Skud" Robert has been active in various open source contexts for years, and should be no stranger to the Perl community. She recently held a presentation at OSCON -- Standing Out in the Crowd -- where she discussed some of the challenges when women are in minority, and experiences with open source projects where they are in majority.
What kicked me in the gut this time was the rather low percentage of women involved in Perl. While better than open source in general, it seems excessively low.
But Skud does not sling mud at the Perl community. Instead -- if I understand her correctly -- she aims to help open source communities -- and I suppose particularly new projects -- to utilize the resourcefulness of women in development, to reduce the gender bias by increasing the overall activity.
I can only recommend that you read the presentation, and contemplate the issue for yourself.
It certainly made me think. Again.
Tuesday, July 21, 2009
A comment on sandboxing and web security
In "What I Want In Firefox (Parrot)", Ovid expresses his desire for Perl 6 scripting functionality, with the caveat "if the sandbox is secure enough".
Aha, there's your problem.
The Firefox developers clearly didn't have sandboxing in mind when they designed the browser, scripts are essentially free to do what they wish at least with the DOM, as well as access many central browser functions, plus a bunch of things that we really don't want security vulnerabilities for.
Another problem is that JavaScript is fundamentally entrenched in Firefox; too much of Firefox internals are based on JavaScript, and I suspect that a Perl 6 addition would only work so-so at best, even if that hypothetical secure sandbox existed.
Oh, and BTW: the example commits one of the great no-nos of web programming: pushing server side security into the browser, which essentially is no security at all, as seen form the server's point of view.
Why am I being so negative all of a sudden? Well, it might be sudden for this blog, but I've been working with security related cleanup and detection in the context of Linux system administration for a few years now. It's not enjoyable, I can tell you, and it definitely colours my perception of these things. Also, I've had a fair bit to do with thinking about security earlier.
Recommended reading (that should be required) for web programmers:
Innocent Code by Sverre H. Huseby (a buddy of mine), ISBN: 978-0470857441
Aha, there's your problem.
The Firefox developers clearly didn't have sandboxing in mind when they designed the browser, scripts are essentially free to do what they wish at least with the DOM, as well as access many central browser functions, plus a bunch of things that we really don't want security vulnerabilities for.
Another problem is that JavaScript is fundamentally entrenched in Firefox; too much of Firefox internals are based on JavaScript, and I suspect that a Perl 6 addition would only work so-so at best, even if that hypothetical secure sandbox existed.
Oh, and BTW: the example commits one of the great no-nos of web programming: pushing server side security into the browser, which essentially is no security at all, as seen form the server's point of view.
Why am I being so negative all of a sudden? Well, it might be sudden for this blog, but I've been working with security related cleanup and detection in the context of Linux system administration for a few years now. It's not enjoyable, I can tell you, and it definitely colours my perception of these things. Also, I've had a fair bit to do with thinking about security earlier.
Recommended reading (that should be required) for web programmers:
Innocent Code by Sverre H. Huseby (a buddy of mine), ISBN: 978-0470857441
Friday, July 17, 2009
Iron Man going strong
90 days on ...
English, German, Hebrew, Japanese, Magyar, Perl 5, Perl 6, Russian, ...
We're positively flourishing here!
When mst announced the Iron Man concept in his lightning talk at NPW 2009, I felt inspired, but I didn't expect it to work this well.
There are many extremely interesting blogs out there, sharing knowledge and experience at a level I definitely didn't expect.
It feels unique, it's wonderful, and I hope this will continue snowballing!
Thanks, guys!
English, German, Hebrew, Japanese, Magyar, Perl 5, Perl 6, Russian, ...
We're positively flourishing here!
When mst announced the Iron Man concept in his lightning talk at NPW 2009, I felt inspired, but I didn't expect it to work this well.
There are many extremely interesting blogs out there, sharing knowledge and experience at a level I definitely didn't expect.
It feels unique, it's wonderful, and I hope this will continue snowballing!
Thanks, guys!
Wednesday, July 8, 2009
Coding styles that make me twitch, part 3
Today's twitchiness is sponsored by ... no, wait, I don't have sponsors. Ah, well.
I have an issue with people who insist on using <"> as a string delimiter when the (static) string itself contains that very character. It gets fugly all too soon:
It's so easy to avoid having to quote the <"> while still allowing variable interpolation:
Since the example is HTML (and could be e.g. SQL), and it might be multi-line, why not ...
That wasn't so hard? Or fugly?
I have an issue with people who insist on using <"> as a string delimiter when the (static) string itself contains that very character. It gets fugly all too soon:
my $html_output = "<a href=\"http://www.example.com/foobar/$pagename.html\" title=\"Oh, a link to $pagename\"> ...\n";It's so easy to avoid having to quote the <"> while still allowing variable interpolation:
my $html_output = qq(<a href="http://www.example.com/foobar/$pagename.html" title="Oh, a link to $pagename"> ...\n);Since the example is HTML (and could be e.g. SQL), and it might be multi-line, why not ...
my $html_output = <<EOL;
<a href="http://www.example.com/foobar/$pagename.html"
title="Oh, a link to $pagename>
EOL
That wasn't so hard? Or fugly?
Thursday, July 2, 2009
Ruby users anonymous
Last weekend, I visited a couple of friends -- Ina and Stig -- and being nerdy geeks, we (well, Stig and I, anyway) ended up chatting about programming and stuff.
Stig has just started programming Perl again, after a long period where he'd probably claim to be apostate.
Everybody, meet Stig. Stig used to program Ruby, but now he's recovering.
Edit: Stig's blog address injected.
I hope this shows that there's hope for the ones who got lost.
Stig has just started programming Perl again, after a long period where he'd probably claim to be apostate.
Everybody, meet Stig. Stig used to program Ruby, but now he's recovering.
Edit: Stig's blog address injected.
I hope this shows that there's hope for the ones who got lost.
Subscribe to:
Posts (Atom)
