As I mentioned recently, I’m working on an update to my Perl Myths talk. (Which is really a review of the state of the art, state of the community, resources, and best practices. You could even call it marketing.)
In recent months, and especially while researching for this update, it’s become clear to me that the Perl community is both functioning well and growing more conscious of its own role and value.
But are the various components of “the community” sufficiently visible? Continue reading
Here’s an extract from a treemap generated by the perl Devel::NYTProf profiler:
Notice the shading on the boxes? Continue reading
I’m going to be speaking at the OSS BarCamp in Dublin in September. Given the likely audience I think my Perl Myths talk would be a good fit.
It needs updating though, and that’s where you can help… Continue reading
I’ve had a great week at OSCON. The talks are excellent but the real value is in the relationships formed and renewed in the “hallway track”. I’m honoured and humbled to be able to call many great people my friends.
My talk on Devel::NYTProf seemed to go well. This year I covered not just NYTProf and the new features in v3 (not yet released) but also added a section on how to use NYTProf to optimize your perl code.
Here’s a quick summary, with links to the slides and screen-cast, and outline what’s still to be done before v3 gets released (getting closer by the day). Continue reading
I’m looking for a CRM system implemented in Perl. As it turns out, so are the Perl Foundation.
So I thought I’d summarize my interpretation of the comments on that thread, as much for my own benefit as yours, and see if this post flushes out any further information.
We’ll start with the smaller/personal projects and work up from there…
I recall other bloggers complaining of unattributed redistribution of their work. Now a site called rapid-dev.net has started redistributing Plant Perl posts, including mine, with an advert at the top.
I wouldn’t mind if the page had clear attribution, but it doesn’t. In fact, at the bottom it says “Author: hoanatwho”.
That doesn’t feel right. Especially as many of my posts, and probably many others from Planet Perl, use the first-person pronoun “I”.
Why does this matter? A couple of months ago Merlin Mann wrote a long but excellent piece that explains why far better than I could.
Nobody but me is allowed to decide why I make things. And — if and when I choose to give away the things that I make — nobody but me is allowed to define how or where I’ll do it. I am independent.
Merlin discusses, with his typical style, the motivations of those who make their work available for free, and the perils of presuming to understand their motives. Although written mostly about bloggers it seems very applicable to authors of Open Source software. For me it echoes how I feel about coding and, to an extent, the freedom that Perl give me to express my thoughts.
Looking at the Planet Perl page I see it has no licence. Perhaps that should be fixed — even if only to say that the license of the feeds being aggregated must be respected.
At OSCON this year1 I’m giving a “State-of-the-art Profiling with Devel::NYTProf” talk. It’ll be an update of the one I gave last year, including coverage of new features added since then (including, hopefully, two significant new features that are in development).
This year I’d like to spend some time talking about how interpret the raw information and using it to guide code changes. Approaches like common sub-expression elimination and moving invariant code out of loops are straight-forward. They’re ‘low hanging fruit’ with no API changes involved. Good for a first-pass through the code.
Moving loops down into lower-level code is an example of a deeper change I’ve found useful. There are many more. I’d like to collect them to add to the talk and the NYTProf documentation.
So here’s a question for you: after looking at the NYTProf report, how did you identify what you needed to do to fix the problems?
I’m interested in your experiences. How you used NYTProf, how you interpreted the raw information NYTProf presented, and then, critically, how you decided what code changes to make to improve performance. What worked, what didn’t. The practice, not the theory.
Could you to take a moment to think back over the times you’ve used NYTProf, the testing strategy you’ve used, and the code changes you’ve made as a result? Ideally go back and review the diffs and commit comments.
Then send me an email — tell me your story!
The more detail the better! Ideally with actual code (or pseudo-code) snippets2.
- OSCON is in San Jose this year, July 20-24th. You can use the code ‘os09fos’ to get a 20% discount.
- Annotated diff’s would be greatly appreciated. I’ll give credit for any examples used, naturally, and I’ll happily anonymize any code snippets that aren’t open source.