Chris @ 46: Tatyana @ 21 – at best its a stop gap measure...
Re: Vibram FiveFingers FTW
Hats off to whoever wrote this up and potesd it....
Re: A little more detail on using a new model
百度
[url=http://www.sina.com]sina[/url]
...
Re: Catching up through week 7
testing video ...
Re: Porting a non-Moose object to Moose
Wow, look what I found,
greedy genius ...
Re: Porting a non-Moose object to Moose
Kevin,
You're right, that does seem a little confusing. ...
Re: Porting a non-Moose object to Moose
Wait. I'm confused. Moose isn't the tool to reach for. So...
Re: Porting a non-Moose object to Moose
You should switch to MooseX::Types to declare your Typed and...
Porting a non-Moose object to Moose
I'm currently working with a lot of legacy code in an envi...
Testing strategy for mocking code
I keep finding myself using the following idiom for writing ...
weblog | `web·lôg -läg |
noun
Another term for BLOG
ORIGIN 1990s: from web in the sense [World Wide Web] and log in the sense [regular record of incidents.]
blog | bläg |
noun
A web site on which an individual or group of users produces an ongoing narrative.
ORIGIN a shortening of WEBLOG.
Slide slight of hand
Posted by
on Tuesday, December 18 2007, 9:02am
If you've already downloaded a copy of the slides from my first talk (Testing Code and Assuring Quality) then this update is for you.
By popular demand, I've added the lolcats back into the presentation in the appropriate places.
But more importantly, I'm no longer at the company for which I created this testing infrastructure. As such, I've updated the company name and technology name(s) to anonymize them a bit.
Just in case.
The biggest thing this means is that I need to re-record the screencasts before I can release those as well, being sure to remove any non-anonymous and non-proprietary information that may or may not already be in the recordings.
Which will take some time. :(
The good news is that the other talk I've prepared (and presented) on "Simple Photo Processing and Web Display" has never had any such information in it, so once I've got it in its final polished state, the publishing of the slides will be that much quicker.
My mom sent us a nice christmas gift, including a dog toy for Spike, and two catnip scented toys for Shadow and Butterscotch. Turns out that shipping catnip toys in a box with another plush toy will pretty much make it smell like catnip, too.
We were wondering why the cats were so interested in the dog toy, but then we noticed that Spike was a little more interested in the toy than normal. Turns out Spike enjoys the scent of catnip too.
So, I finally decided to stop putting it off and upload the slides from my testing talk onto slideshare.net. Click here to view these slides, as well as any future slides I make public.
Unfortunately, this presentation/slide set was heavy with screencasts, which don't survive the transition to PDFs very well. I'm considering hosting the screencasts elsewhere.
After Lisa and I got back from Thanksgiving dinner, we decided to take a few pictures of how well Spike was balancing in order to earn some tasty morsels of smoked turkey.
So I'm working on a new presentation for my local Perl Mongers group, and (indirectly) thanks to Ricardo Signes, I've got a cool way to get properly syntax colored code into my slides.
Ricardo has been working on an easy way to get syntax colored code into Keynote presentations. I wondered why he was bothering to convert the syntax colored code to RTF - then I realized why - I think because TextEdit.app on Mac OSX is a cocoa application, the font coloring is preserved through copying and pasting the code into Keynote, another cocoa application.
A little later on, I was creating some other presentation, and was copying some code out of my blog and happened to notice that the code I copied and pasted from Safari, my web browser, also retained its coloring information.
Problem solved, right? Anything I want to put into a Keynote slide, I should blog about first. Right?
Wrong.
That's too much blogging.
Instead, I wrote a teeny tiny little CGI to post up the syntax colored source of anything sitting around on my server, using the same Text::VimColor module on the backend.
This is that CGI:
#!/usr/bin/perl -T
use strict; use warnings; use Text::VimColor; use CGI qw/:standard/; use CGI::Carp qw/fatalsToBrowser/;
... and then a little HTML to display it in the right font, font size, and using my standard code stylesheet - which is left as an exercise for the reader.
I'm really not understanding something. I've run into a module for which I had a lot of difficulty writing the first few tests. This usually happens when the module under scrutiny does something a little weird, so I'm used to it by now.
But this one is a lot weird.
The code for the module I'm looking at is structured exactly like this:
package foo;
use strict; use warnings;
sub firstSub { my$string_orig = shift;
# in the production code, this # somehow works and doesn't die my$string = secondSub $string_orig;
What's strange is that when I use the module and try to call "firstSub", I get a Can't locate method object secondSub via package VALUE_PASSED at line blah, of course substituting VALUE_PASSED for whatever value I actually pass :) But the module - as is - works on the development server, and has worked on the production server for years with this exact structure and syntax.
So for this example, this code (reduced to the smallest example that still exhibits the behavior, but essentially the same structure) tries to call the modules' subroutine via:
use foo;
my%q = foo::firstSub( 'MTFNPY' );
print"$_: $q{$_}"forkeys%q;
And the output I get is:
Can't locate object method "secondSub" via package "MTFNPY" (perhaps you forgot to load "MTFNPY"?) at foo.pm line 13.
A little boggling. I tried a few things, including this ugliness:
{ no warnings'once';
*MTFNPY::secondSub = \&foo::secondSub;
}
... but of course that will only work as long as I'm passing the value of "MTFNPY".
Running the code through B::Deparse confirms that line is interpreted as my $string = $string_orig->secondSub.
I see I've got a couple of options:
Fix the code minimally - re-order the subroutines inside the module so the second subroutine is defined first, so it will be correctly interpreted as a function call.
Fix the code a little less minimally - add parens around the argument to secondSub.
Fix* my tests and don't touch the original code until my tests are complete so I am 100% certain I don't break anything else. (I'm fairly sure either of these changes won't, but "fairly" isn't 100%).
* By which I mean 'just make it work'
So, I add this near the top of my test file:
BEGIN { package foo; use subs'secondSub';
}
use_ok( 'foo' );
... which basically tells the interpreter that package foo will be defining a subroutine called secondSub, which is to say predeclaring them - before the foo module has a chance to load, by taking place inside a BEGIN block.
And lo, testing successful.
But what I still don't understand is how exactly the code in the original module works at all! I'm testing on the same box where the code lives - where the code runs day in and day out without bringing the test server down to a screeching halt. I know - I added trace debugging statements all around, thinking that perhaps the code has always been silently failing and the failure was just dealt with. But no, the code was making it through that step and doing exactly what my predecessor(s) expected it to do. It's just doing it wrong.
Shortly after complaining about how long my main page was taking to load, I started thinking up ways to make it go faster. As far as I could see, one option would be to try to parse the perl with perl - but just borrow all the ideas and regexes from the perl.vim vim syntax file. Easy enough - just figure out what the metacharacters in vim map to in perl, etc etc and so forth.
About a third of the way through my translation, I realized it was going to be harder than I was expecting/hoping, because there are some conventions in vim's syntax files that makes that sort of thing somewhat easy.
Plus, I wasn't even sure how good the translations were, or whether or not they'd even do anything useful:
I toyed with the idea of doing something with PPI, but quickly dismissed that.
I then thought I might've remembered reading something about creating some kind of "vim server" with Text::VimColor - so a quick read of that yielded nothing. But I noticed the link in SEE ALSO to Apache::VimColor, which thank goodness mentions Cache::Cache (and sibling Cache::FileCache).
What was I thinking?
So the solution was exceedingly simple:
use Cache::FileCache;
# to create a key for the cache use Digest::MD5;
sub vimformat { my( $self, $text ) = @_; my$key = Digest::MD5::md5_hex( $text ); my$cache = new Cache::FileCache; my$return = $cache->get( $key ); if( ! defined$return ){ # do hugely time-expensive formatting, set # the value of $return to desired text # set the cache key at the end $cache->set( $key, $return );
} return$return;
And just like that, the page is back to being under 2 tenths of a second to create. Even with (as of this post) more than 10 hunks of syntax colored code.
It's called Perl::Critic::Nits, which at this point only has one policy module, one that discourages accessing what appears to be private member data of a class. Feel free to have a look. Though if you're reading this post significantly after the date I'm posting it, that version may no longer be the most recent release.
It pretty much looks for anything that accesses a hashref subscript or an arrayref subscript. And in case you can't guess - that can be a problem if you're not dealing with an object. Like if, for instance, you have a regular old hash reference.
Drat.
Elliot Shank reminded me that the code being examined isn't compiled, so it's a little tough to figure out whether or not something isa blessed object, or just a plain hashref. D'oh.
At least it's easy enough to disable a policy. :/
However, it will definitely catch attempts to access an object's member data directly, so I don't feel so bad about that. So long as the pseudo convention of assigning $_[0] to a variable called at least either $self, $package, or $class.
Please enjoy, and let me know if you run into any bugs.
