Object-Relational Mappers (ORMs) are awesome if you think about your database a collection of objects. They're awful if you think about your database as a database. My primary client right now is ZipRecruiter and my work involves rewriting one of their internal systems to be more flexible. However, it involves tons of reporting. For example, I have this SQL:
SELECT var.name, ce.event_type, count(*) as total
FROM tracking_conversion_event ce JOIN tracking_visitor visitor ON visitor.tracking_visitor_id = ce.tracking_visitor_id
JOIN tracking_version_variant curr ON curr.tracking_version_variant_id = visitor.tracking_version_variant_id
JOIN tracking_version ver ON ver.tracking_version_id = curr.tracking_version_id
JOIN tracking_variant var ON var.tracking_variant_id = curr.tracking_variant_id
WHERE ver.tracking_id = ?
AND ver.version = ?
GROUP BY 1, 2
What you can't see in that SQL is that there are many subtleties in it:
count(*) as total sometimes needs to be replaced by
sum(ce.num_events) as total
- Sometimes I need different sets of fields returned (and that impacts the
GROUP BY, too)
- One of those
JOIN statements sometimes needs to be a
Do you want Test-* to be released with only one pair of eyes spending any significant time looking at it? No? Me either!
This blog post is a cry out for review. Test-Builder/More/Simple are being seriously reworked. From my perspective as the author of these changes everything looks fine, but that is just one set of eyes.
How can you help?
The git history on master does not lend itself well to review. This is a harder problem to solve. I have been urged by a couple people to rewrite history to make things more clear. I will take the time to make a cleaner branch where history is easier to read. Assuming the new branch works out, and accurately represents history, I will rename master to something else (but always keep it so that people can see it)
The perlxs man page recommends to define the PERL_NO_GET_CONTEXT macro before including EXTERN.h, perl.h, and XSUB.h. If this macro is defined, it is assumed that the interpreter context is passed as a parameter to every function. If it's undefined, the context will typically be fetched from thread-local storage when calling the Perl API, which incurs a performance overhead.
Unfortunately, many XS modules still ship without defining PERL_NO_GET_CONTEXT. This is probably due to the fact that for most modules, setting this macro involves additional changes to the XS code. For example, if your XS file has static functions that call into the Perl API, you'll get somewhat cryptic error messages like the following:
Last year I shared an article about how You Can Help MetaCPAN by Helping the QA Hackathon. A year later, you can still help MetaCPAN by helping the QA Hackathon. As one of the core MetaCPAN developers, I'm planning to attend this event next month. It's still the best chance that I get to sit down and focus on MetaCPAN. MetaCPAN has had the good fortune of having multiple interns working on code since the Hackathon last year and we've made a lot of headway, but there's a lot of heavy lifting which still needs to be done, particularly around how we use Elasticsearch. This is also a good chance for me to be in the same room with folks who work on the toolchain and to get a better feel for how MetaCPAN can help them.
Just to summarize the much more eloquent posts which have preceded mine, Mr. Neil Bowers of White Camel fame shared a very good summary of what goes on at a QA Hackathon.
A couple weeks ago I asked how you "join the conversation" but based on feedback I got, I don't think I communicated well. I think people thought I meant "which blogs do you read?" What I really meant was: when you write a blog entry, where do you post the link so that it's seen by people who are interested in that subject?
I read comments everywhere. Comment here, or if you prefer, at Blogger.
While being blocked from p5p I had to read a new outragious statement by a porter. Who is in reality not a porter like me, just some developer who happens to have no idea what he is talking about.
He struggles with his new super-op OP_SIGNATURE which is at second thought a better idea then the old way to assign lexical values from the call stack at the begin of subroutines, just that it cannot take the stack values, it has to go through an intermediate @_ copy, but that is just an implementation detail which can be optimized away, and goes then on like this:
Greetings Perl community,
i will give in a week a Talk about Perl - at a German Linux Conference. It will be part technical but in part also giving the people a realistic insight into our community. Slides will be as always on lichtkind.de and slideshare.
So but the reason i tell you this now is because i want to make sure i don't miss the major recent trends. So if you have this cool Perl project / tool / module/ API which is not that often talked about but should - please let me know and post below.
Thank you very much.