In a discussion on #moose-dev today, ether made the following distinction: author tests are expected to pass on every commit; release tests only need to pass just before release I think this is a good distinction. It also means that almost every single “xt” type test you might think of should probably be an author test. The only one we came up with in #moose-dev that was obviously a release test was a test to check that Changes has content for the release.
During my Introduction to Go class last Thursday at YAPC::NA::2015, one of the class attendees, David Adler, asked a question along the lines of “why use Go?” That’s a good question, so here is my answer. Let’s start by first talking about why we use Perl (or Ruby, Python, PHP, JS, etc.). Why use a dynamic language? There are a lot of reasons, but the basic answer is that these languages make it easy to get a system up and running quickly.
I’ll be offering my new Introduction to Go class here in Minneapolis on Saturday, May 30. The cost is just $30 and I have 15 spots available. I’m offering this class at such a low cost because I want to get some feedback on it before I give it at YAPC::NA::2015. If this goes well, I plan to give this class in Minneapolis again, but I’ll be charging more, so now’s your chance to take the class for as cheaply as it’ll ever be offered!
Ok, that alliteration is a stretch, but it’s the best I could do. This blog post is a public announcement to say that my tuits for CPAN-related work will be in very short supply until after YAPC. I’m basically devoting all of my FOSS programming time to creating the slides and exercises for my Introduction to Go YAPC master class. As you might imagine, creating a one day class is a lot of work.
This year at YAPC I’ll be giving two master classes. Why am I doing this? I don’t know, I think I may be insane. But that aside, here’s some info about said classes. My first class is Introduction to Moose. I’ve been giving this class for a number of years, and it’s always been well-received. The class will take place on Sunday, June 7, the day before the conference proper begins.
Somehow people seem to keep breaking into my Netflix account. Calling Netflix achieves little. Their go to answer is to have me change my password and sign out all devices. In theory, this should keep hackers out. I’ve done this a number of times to no avail. Last night I changed the email associated with the account, as well as the password, and they’re back in tonight. Edit: Someone on HackerNews asked how I know that the account was hacked.
Assuming that the failure happens more than once every few thousand test runs, here’s a handy shell snippet: while prove -bv t/MaxMind/DB/Writer/Tree-freeze-thaw.t ; do reset; done This will run the relevant test in a loop over and over, stopping at the first failure. The reset in between each run makes it easy to hit Ctrl-Up in the terminal and go to the beginning of the test run that failed, rather than having a monster scrollback buffer.
About a million years ago (ok, more like 6 months) a kind soul by the name of Polina Shubina reported a small bug in my Markdent module. She was even kind enough to submit a PR that fixed the issue, which was that the HTML generated for Markdown tables (via a Markdown extension) always used </th> to close table cells. However, there was one problem, there was no test for the bug.
A little while back I asked people to test Params::Validate 1.14. Judging by the lack of bug reports I’m sure that many people tested it and it worked fine. Ok, just kidding. I strongly suspect almost no one tested it and that someone will yell at me for breaking their software. But hey, I tried. Now I’m asking folks to try out MooseX::Params::Validate 0.20. This release makes a rather major change to the exception thrown when a type constraint rejects a value.
I’ve just released a new version of Params::Validate that allows validation callbacks to die in order to provide a custom error message or exception object. This was a long-needed feature, and will enable me to make Moose::Params::Validate support the error messages provided by type objects, which has also been long-needed. However, I’m a little nervous about any changes to Params::Validate, since it’s used a rather large chunk of CPAN. It has c.