If you've discovered something amazing about Perl that you just need to share with everyone, this is the right place.

This section is also used for non-question discussions about Perl, and for any discussions that are not specifically programming related. For example, if you want to share or discuss opinions on hacker culture, the job market, or Perl 6 development, this is the place. (Note, however, that discussions about the PerlMonks web site belong in PerlMonks Discussion.)

Meditations is sometimes used as a sounding-board — a place to post initial drafts of perl tutorials, code modules, book reviews, articles, quizzes, etc. — so that the author can benefit from the collective insight of the monks before publishing the finished item to its proper place (be it Tutorials, Cool Uses for Perl, Reviews, or whatever). If you do this, it is generally considered appropriate to prefix your node title with "RFC:" (for "request for comments").

User Meditations
Yak Shaving for Fun and Profit (or How I Learned to Stop Worry and Love Perl 6)
1 direct reply — Read more / Contribute
by raiph
on Dec 16, 2015 at 13:02

    »»» This post is about Perl 6, not rock solid Perl 5 «««

    Today's Perl 6 advent calendar looks like it may be of more than average interest to monks interested in the sort of thing -Ofun meant in 2015 when trying to write a non-trivial Perl 6 application: Yak Shaving for Fun and Profit (or How I Learned to Stop Worry and Love Perl 6)

    Trolls are expected to join our meditation. Herewith a collective "happy winter solstice" hug for them all from me and on behalf of a bug-eyed butterfly. I ask that those of us that prefer to don the robes of a monk rather than dress up as trolls do their very best to leave the trolls alone or just surround them with genuine unconditional love. Imagine how cool it would be if there were no attacks in this thread, or, more realistically, there were no responses to attacks no matter how personal or pernicious. Thanks for your cooperation. :)

    And finally, here's another happy (near) winter solstice greeting, this time for the whole monastery. I learn a lot about being humble and encouraging my compassionate self in posts here and I appreciate this gift that keeps giving.

What the HEY is up with the cartoon butterfly for "Perl 6" ?!
14 direct replies — Read more / Contribute
by 1nickt
on Dec 07, 2015 at 08:10

    Yes, this is a rant. I'm trying to rant less. But this is something I feel have to say, in the admittedly faint hope that it will reach the ears of someone in charge.

    Today I went to look at "Perl 6." The Perl Weekly newsletter has been turning more and more into a promotional rag for "Perl 6," and then I saw that a good deal of the London Perl Workshop has been dedicated to it. So, after 20 years more or less of programming perl, I figured I should at least swing by and see what all the distraction is about.

    Lo and behold when I get to the website of the "plucky little sister of Perl 5" (who wrote this marketing pablum, a 20-yr old Communications major?), I am greeted by a multicolored butterfly that looks like it belongs on the Disney Channel early-afternoon lineup.

    What the HEY?!

    Are you out of your MIND?

    In the interests of keeping this rant short, I'll just say that if you were trying to convince serious programmers that "Perl 6" was worth any of their time to investigate, you could not have chosen a less effective design. To me this kindergarden art symbolizes:

    • shallowness
    • infantilism
    • dumbing down to try to widen the appeal
    • the ascendency of communications-major type people over critical thinkers and engineers
    • Microsoft Windows (remember the paper clip?)
    • the complete lack of seriousness of "Perl 6" as a programming language
    and so on.

    I write Perl for a living, for companies that use it to do business and make money. It's serious stuff, and it's fun because of how challenging it is, not because of a pink and purple anthropomorphic icon.

    To the "Perl 6" people: I was already very skeptical of your project, given its debaculous history. Well, now I am convinced. You could not have done more to prove to me that, as I suspected, it is a vanity project of a handful of the brightest, most bored Perl 5 gurus, that has no application in the real world in which I live and program.

    To be clear, your butterfly has turned me off from even beginning to read the content of your site, and I would imagine that I am very far from being the only one.

    (Note: I looked for a place on the "Perl 6" website to post this as feedback, but no such link was to be found.)

    Larry Wall would be rolling in his grave. Oh, wait ...

    But for the rest of you, if you were that bored, couldn't you have just gone off quietly and tackled some new field of human endeavour if you were "over" Perl, like, for example, how tchrist became the arbiter of all aspects of the English language on Stackexchange? Why the need to try to "rebrand" Perl as a consumer product for millenial schoolgirls?

    Can't Perl users file a class-action suit or something to force the Butterfly People to pick another name for their hobby?

    The way forward always starts with a minimal test.
OO APIs and FP interfaces
3 direct replies — Read more / Contribute
by Apero
on Dec 03, 2015 at 20:05

    I'm interested in opinions on the use of FP (functional-Perl, ie: non-OO) routines exposed to consumers of an otherwise OO-module. Given that this is almost completely a style preference, I've chosen to Meditate on it. See the concept code below for an idea what's involved. While the examples are terse, the idea is to expose package-configs, possibly defaults to constructor use, or any package-wide tuning a module may support.

    As I see it, there are 3 potential options:

    1. Use FP routines, and document public API use as Ex::Mod::conf(key=>'value')
    2. Use OO-style syntax, and document public API use as Ex::Mod->conf(key=>'value')
    3. Avoid such use all-together, making the caller always list every option desired.

    #1 above is what my code samples use, and seems to best represent what the routine does. On the other hand, callers now need to remember if they're invoking an FP routine verses a method/constructor.

    #2 is basically the same, but lets consumers be lazy and use the infix operator in all cases. This might be written in the module as:

    sub conf { shift; # throw away unused class. # .. do real work here }

    #3 would make callers always provide every default option (or not have any say in configuring other package-level adjustments.) Perhaps the callers re-use lengthy/common constructor arguments like so:

    my %re_use = (name => 'Alice'); Ex::Mod->new( override=>'whatever', %re_use );
    I'm not really fond of making callers do extra work if it's considered likely that use of a particular library might wish to set sensible defaults throughout use of the module. Further, this means package-config (not used by constructors) could only be adjusted by reaching into something like $Ex::Mod::DefaultTimeout to enact changes, which also feels messy.

    Below is the example consumer, and the example Ex::Mod class:

Looking for CPAN module author: Daniel Yacob (String::LCSS)
1 direct reply — Read more / Contribute
by toolic
on Nov 30, 2015 at 21:59
    UPDATE: 2015 dec 30, I am now a co-maintainer. I was unable to contact the author, but I was granted permissions by the powers that be.


    Does anyone know of a way to contact Daniel Yacob, the author of the CPAN String::LCSS module?

    I am at step 4 of the PAUSE procedure for taking over a module ("Try posting in public places such as ... perlmonks.org").

    I have tried to contact the author by sending emails to 3 addresses. I have not received any positive replies.

Tree Structure Challenge
5 direct replies — Read more / Contribute
by choroba
on Nov 29, 2015 at 18:29
    At work, I needed to fix logging of changes in a tree structure. The language was unfortunately Java, but I started with a Perl prototype to test the approaches and border cases. The Java solution was more challenging for me, but the Perl implementation was still interesting enough to share. For those bored or interested, I present the problem below. The original domain was different, but I'm probably not allowed to speak about it outside of the firm.

    We'll use the famous animal tree:

    Reptile - Snake - Python - Cobra - Lizard - Salamander - Chameleon - Bird - Pigeon - Canary - Owl Mammal - Equine - Horse - Zebra - Pony - Canine - Dog - Fox - Wolf - Bovine - Cow - Bison

    All the leaves are on the same level.

    Let's have a module Zoo.pm which implements the following methods:


    Static method. 'Zoo'->Parent($node) returns the parent of the given node in the tree, e.g. 'Zoo'->Parent('Owl') is 'Bird', 'Zoo'->Parent('Bird') is 'Reptile'.


    The constructor. Use a list of tree leaves as arguments:

    my $zoo = 'Zoo'->new(qw( Cobra Pigeon Zebra ));


    For a given object, returns the list it was constructed from (order is not guaranteed).

    print join ' ', $zoo->get_leaves; # Cobra Pigeon Zebra

    The Task

    When comparing too different zoos, we aren't interested in the animals only, but in their categories, too. Our task is to implement a static method 'Zoo'->diff($zoo1, $zoo2) which returns two array references, $add and $delete, such that:

    1. Imagine we build trees above both of the objects, containing all their $_->get_leaves and their ancestors.
    2. If we start from the tree built above $zoo1, add all the nodes from $add and remove all nodes from $delete, we get $zoo2.
    3. Both the lists @$add and @$delete are minimal.

    For example,

    'Zoo'->diff( 'Zoo'->new('Cobra'), 'Zoo'->new('Fox') )

    should return

    ( [qw[ Fox Canine Mammal ]], [qw[ Cobra Snake Reptile ]] )


    'Zoo'->diff( 'Zoo'->new(qw( Dog Fox Wolf )), 'Zoo'->new(qw( Fox )));

    should return

    ( [], [ 'Dog', 'Wolf' ] )

    Updates: Please, use <readmore> tags for the code.

    Use only the documented API in the solution (i.e. Parent and get_leaves). The tree structure is not accessible directly (in reality, it was stored in a database).

    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
Pi Zero
5 direct replies — Read more / Contribute
by hippo
on Nov 26, 2015 at 05:22

    The Pi Zero is out today. While nobody can predict the future it is certainly a possibility that this could be a huge deal in terms of the next generation of programmers. In order to help them to get the best start possible there ought to be a big effort to allow the installation of perl on this little box of tricks in a way that is as simple and fault-tolerant as possible for the novice.

    Is this a realistic goal? I do hope so. With the demise of Java this could represent the best opportunity to avoid another single-language-fits-all monopoly over the next 20 years.

    Caveat: I know next to nothing about RaspberryPi so far and the Pi Zero may even come with perl bundled already, in which case feel free to call me a numpty. However, I would rather raise awareness and be thought foolish/ignorant than let this go by without having tried to do something to raise awareness. I will be trying to track down one of these little wonders for my own edification (as no doubt will quite a few of you) and it would be great to be able to flex Perl's muscles on such a potentially ubiquitous platform.

    If you have any good links to Perl on the Pi, please reply. Thanks, Hippo.

Something that bugs me about the Numeric class hierarchy in Perl 6
1 direct reply — Read more / Contribute
by grondilu
on Nov 24, 2015 at 03:16

    Hello Monks,

    This is something that has bugged some times to times : I have the feeling that the class hierarchy for numeric types in Perl 6 is upside down.

    Let me give you an example. The other day I wrote on rosetta code the following function to compute binomial coefficients:

    sub infix:<choose> { [*] ($^n ... 0) Z/ 1 .. $^p } say 5 choose 3;

    I was quite happy about it, until I realized that the output was of type Rat, not Int. So I had to make an explicit conversion:

    sub infix:<choose> { ([*] ($^n ... 0) Z/ 1 .. $^p).Int }

    That was a bit annoying. Frankly, I expect something like 10/5 to be an integer, not a rational. I mean, I know it is a rational, but it also is an integer. Because normally in math, all integers are rationals. Their denominator is just 1.

    Things don't work like this in Perl 6. Numeric types are more about implementation than mathematics. Yet there is a feature in Perl 6 that could be used to make things work more like in math:

    subset Int of Rat where [%%] *.nude;

    If Int was defined as such, integers would be particular cases of rationals. In the same way, real numbers would be special cases of complex numbers:

    subset Real of Complex where { $_ == .conj };

    An other possibility would be:

    role Int does Rational { method nude { self, 1 }; ... }

    Or something like that, I don't know. Neither do I know if it would be possible or desirable to rewrite the whole Numeric hierarchy. Maybe it would not be worth the effort. But I do find it annoying that an Integer is not a Rat, or a Real not a Complex.

"Indirect" object syntax?
3 direct replies — Read more / Contribute
by muba
on Nov 22, 2015 at 21:30

    Disclaimer: IANAL. I am not a lawyer linguist.

    The syntax of (for example) $cgi = new CGI; is called indirect object syntax, which is also said to be in the dative case. Are these actually the correct designations?

eval error stack
2 direct replies — Read more / Contribute
by shmem
on Nov 11, 2015 at 16:13

    There's the perl special variable $@ which is set at eval errors. It is a global variable, and it is a SCALAR type variable. It gets easily clobbered if you don't proceed with utmost care (tye wrote some nodes about that) and fails to report the really interesting thing, e.g. in nested evals. Consider:

    my $foo = eval { my $bar = baz(); if ($@) { die "baz failed!\n"; } }; die $@ if $@; sub baz { eval "1 = 2"; } __END__ baz failed!

    With that code, there's currently no way to get at the real problem, which is in the baz code, where $@ is set to

    Can't modify constant item in scalar assignment at (eval 1) line 1, at + EOF

    and gets clobbered by my $foo = eval {...} Of course, the above program would have reported the baz() error, if baz()behaved well:

    sub baz { my $result = eval "1 = 2"; die $@ if $@; $result; }

    Nonsensical assignment reported, but where is the error from my $foo = eval { };? Looks like I have to set up a die signal handler, or some such. This is all very confusing and doesn't DWIM.

    And you cannot rely on $@ being propagated properly, unless you revise any included code that uses eval, which is pretty much anything, because eval is the heart of any perl code. All perl code is somehow evaled.

    Back to $@ - a SCALAR. Why don't we have @@ as an error stack, and a builtin %@ hash keyed upon the names of the stack frames (e.g. Package::sub or 'eva123') or such?

    The variables @@ and %@ currently (well, I have perl v5.18.2) work as a regular array/hash. But *@{SCALAR} isn't related to $@ at all.


    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
Building the Right Thing (Part III): Customers
1 direct reply — Read more / Contribute
by eyepopslikeamosquito
on Nov 01, 2015 at 01:37

    After introducing Lean startup in the last episode, this installment focuses on good ways to communicate with customers.

    Don't do what customers say they want, understand their problems and solve them.

    -- Per Haug Kogstad (Tandberg founder)

    Problems, Products and Markets

    Most startups begin with a brilliant new product idea. Most startups fail. While pulling an ingenious new product idea from your lower torso may work on occasion, a more systematic approach is to perform a sober analysis of the following three aspects:

    • A problem is the reason people want your product. Is it a big enough problem for people to pay you to solve it?
    • A product is the way you solve the problem. Are you capable of solving the problem? How do you know if you've found the "best" way to solve the problem? Are there other ways to solve it?
    • A market is a group of people who might want to buy your product. Who wants the problem solved badly enough to buy your product? Can you build a sustainable business in this market?
    Perhaps the worst way to answer these questions is to ask the customer what they want.

    A more promising approach is to observe and listen to the customer, so as to gain a deep understanding of their problems. Focus on their big problems, the ones they'll be glad to pay you to solve.

    You need to differentiate between cool and interesting problems and real problems for real people. Laura Klein gives some examples:

    • Word processors solved the problem that it was tough to edit something once you've typed it.
    • GPS navigation solved the problem that we are likely to get lost when away from our homes.
    • Angry Birds solved the problem of delivering pleasure hormones to our brains while waiting for a train.
    Admittedly, this is hard to predict and there is no guarantee of success. Is playing Angry Birds while waiting for a train really a vital problem? While there is no guarantee of success, and yes, most startups fail, early validation of product ideas ensures you fail as cheaply as possible, allowing you more shots at success.

    Customer Interviews

    Justin Wilcox suggests you start by asking your customer two introductory questions:

    • How do you describe your role?
    • What does success look like for you?
    With that context clarified, ask the following five questions:
    • What's the hardest part about <your problem context>?
    • Can you tell me about the last time that happened?
    • Why was that hard?
    • What, if anything, have you done to solve that problem?
    • What don't you love about the solutions you've tried?
    Notice that we are trying to steer away from hypothetical questions, in search of genuine problems that might be used to start a new business or grow an existing one.

    After the customer interview, you need to go away and figure out if you can build a solution to any of their big problems.

    Solution Interviews

    Rather than pitch a proposed solution to the customer with a demo that ends with them saying: "Thanks very much, we'll get back to you", Wilcox recommends doing a Solution Interview instead.

    • Don't start with a demo!
    • Pick the big problems from the customer interview that you think you can solve. Restate the problem; for example, I heard about this problem you have. Is that right? You need confirmation that you've properly understood their problem.
    • Propose a potential solution. Honestly ask for feedback. What do you think about this solution? Initiate a two-way discussion.
    • Finally, now we agree we've got the right problems, and we think we can solve them together, what do we need to do to make progress? What are the next steps? Make a to-do list with the customer.
    The general idea is not to pitch your solution, rather to engage the customer, build trust, build a partnership.

    User Testing

    If the Solution Interview went well, build a prototype solution (MVP) and observe the user interacting with it. Don't fall into the trap of building a broad MVP that is crappy and unusable. Instead, build a usable, but limited, version of your product.

    Laura Klein gives some tips on how to get good feedback from customers, based on years of watching mistakes made by folks lacking a user-experience background:

    • Shut the hell up. You want their opinions, not your own. You also need to give them more time than you think to figure things out on their own.
    • Don't give a guided tour. Let the user explore a bit on his own. Then give the user as little background information as possible to complete a task.
    • Ask open-ended questions. The more broad and open-ended your questions, the less likely you are to lead the user and the more likely you are to get interesting answers.
    • Follow up. For example, if the user says "that was cool", follow up and ask precisely why that was cool. Don't assume you know what makes a product cool.
    • Let the user fail. This can be painful, especially if it's your design that's failing. You're not testing if a person can be shown how to use a product, you're testing to see if a person can figure out how to use the product.

    Quantitative vs Qualitative research

    Quantitative research, for example A/B testing or Funnel analysis, measures what real people are actually doing with your product. It's statistically significant.

    Qualitative research, for example customer interviews and observing users and understanding their behavior, gives important insights, but is not statistically significant.

    Quantitative research tells you what. Qualitative research tells you why. You need both.

    Miscellaneous Tips

    Some general tips taken from a talk by Atlassian Product Manager Sherif Mansour on Building the right thing:

    • Distill customer interviews and customer conversations into a manageable set of Personas. Make these personas visible to everyone (Atlassian even stick them in the toilets).
    • Ask why. Understand why.
    • Find the root of the problem.
    • Understand the problem.
    • Define the solution.
    • User Journey Mapping. Shows end to end flow of a persona using a feature, starting with installation.
    • Get the user journey right (e.g. map out how someone enters/exits a feature).
    • Fake it till you make it. They use a variety of Pretotyping techniques as discussed in episode one; e.g. recording videos and showing to customers to elicit feedback.
    • Get feedback before you start (fake to validate you are building the right thing).
    • Choose carefully (beware domino effect).
    • Tell your story. Before you start. Build your box (hero shot, pitch and three pillars).
    • Assume no docs. This changes how you build your solution.

    Perl Monks References

    External References

Looking for Stuart Lory, author of CPAN Text::Banner module
No replies — Read more | Post response
by toolic
on Oct 29, 2015 at 09:19
    UPDATE: Success! ambrus sent me a private message with another email address he dug up from a 2001 message on perl5porters. I sent an email, and the author responded.
    Original post:

    Does anyone know of a way to contact Stuart Lory, the author of the CPAN Text::Banner module?

    I am at step 4 of the PAUSE procedure for taking over a module ("Try posting in public places such as ... perlmonks.org").

    I have tried to contact the author by sending emails to 3 addresses: from the AUTHOR section of the POD, the Email listed on search.cpan.org, and the generic lory@cpan.org. All 3 emails bounced immediately.

    As far as I can tell, this author uploaded the module in 1999 and has never uploaded any updates to it. There are a few bugs reported on RT (the first in 2008), but the author never updated any of those reports.

OOP: A Bird's Eye View
4 direct replies — Read more / Contribute
by Arunbear
on Oct 27, 2015 at 12:04

    Most tutorials that teach Perl OOP (Object Oriented Programming) focus on the nuts and bolts (which is important), but neglect the equally important "Why" or reasons for using OOP. This is an attempt to remedy that, in the form of a story.

    A fable

    There once was a farmer who had a flock of sheep. His typical workday looked like this:
    $farmer->move_flock($pasture); $farmer->monitor_flock(); $farmer->move_flock($home);
    Eventually, due to successful wool sales, he expanded his farming activities and his day become like this:
    $farmer->move_flock($pasture); $farmer->monitor_flock(); $farmer->move_flock($home); $farmer->other_important_work();
    But now the farmer wanted to devote more time to other_important_work(), so he decided to hire a minion to handle the sheep related work, so the work was now split like this:
    $shepherd_boy->move_flock($pasture); $shepherd_boy->monitor_flock(); $shepherd_boy->move_flock($home); $farmer->other_important_work();
    This did give the farmer more time for other_important_work(), but unfortunately $shepherd_boy had a tendency to cry wolf so the farmer had to replace him with a new minion:
    $sheep_dog->move_flock($pasture); $sheep_dog->monitor_flock(); $sheep_dog->move_flock($home); $farmer->other_important_work();
    $sheep_dog was more reliable and demanded less pay than $shepherd_boy, so this was a win for the farmer.



    To handle complexity, delegate to a suitable entity e.g. the farmer delegates some of his work to $shepherd_boy.


    Tell objects what to do, rather than micro-manage e.g.
    rather than
    $sheep_dog->{brain}{task}{monitor_flock} = 1;
    At a high level, we do not particularly care what the internals of the object are. We only care what the object can do.

    But, an object becomes harder to change the more its internals are exposed.


    $sheep_dog and $shepherd_boy both understood the same commands, so replacing the latter with the former was easier than it would have been otherwise.

    I've had this in my scratchpad for a long time and I'm sure there's more that can be said, but I finally decided to post this after reading OOP's setter/getter method - is there a way to avoid them? in case anyone finds it helpful.

Building the Right Thing (Part II): Lean Startup
1 direct reply — Read more / Contribute
by eyepopslikeamosquito
on Oct 21, 2015 at 17:11

    Just like pretotyping, discussed last time, Lean startup was a love-child born from the ashes of entrepreneurial catastrophe.

    Having experienced devastating failure in his first two Startup adventures (Catalyst Recruiting and There.com), Eric Ries understandably became highly motivated to make sure that never happened to him again ... finally achieving startup glory at his third attempt, at IMVU in 2004.

    Having experienced both heady success and catastrophic failure at startups, Ries was well qualified to develop a methodology to help startups succeed: Lean startup.

    Ries was fortunate to have Steve Blank, a formidable methodologist, as his mentor at IMVU and he became Blank's star pupil. Indeed, Blank's "Customer Development" became a cornerstone of Ries' subsequent Lean Startup movement. Nowadays, Ries spends most of his time advising companies and teaching entrepreneurship.

    Ries' experiences are not atypical: most startups fail. Indeed, the world is crying out for a way to reduce the waste and misery associated with failed startups.

    Not only that, but with disruptive technologies on the rise, it's becoming more crucial than ever for established companies to innovate to survive.

    Lean Startup vs Pretotyping

    Lean Startup is an approach that is, to some extent, broader than the one put forward by "pretotyping". It's applicable before you get to the stage of having a "pretotype" (e.g. interviewing customers) and afterwards (when you're actually building and delivering live features.)

    -- Adrian Howard aka adrianh

    As usual adrianh is right on the money: Lean Startup is more ambitious than pretotyping, in that it covers all aspects of running a successful business, while pretotyping just focuses on identifying the right "it" to build. Put another way, pretotyping is a subset of Lean Startup.

    What is Lean Startup?

    After defining a Startup as:

    A human institution designed to create a new product or service under conditions of extreme uncertainty
    Ries defines Lean Startup as:
    A set of practices for helping entrepreneurs increase their odds of building a successful startup
    I think the key point here is "extreme uncertainty". Ries experienced first hand that traditional business practices, such as creating a detailed business plan, simply do not work in conditions of extreme uncertainty.

    Steve Blank gives his take on Lean Startup as based on three principles:

    1. Business model canvas. Instead of writing a detailed business plan, entrepreneurs list a series of untested hypotheses in a "business model canvas", a diagram of how a company creates value for itself and its customers.
    2. Get out of the building aka "Customer Development". Go out and ask potential users and partners for feedback on all elements of your business model. Rapidly assemble minimum viable products (MVPs) to aid in eliciting customer feedback. Based on this feedback, make further small adjustments (iterations) or big ones (pivots) to ideas that aren't working. Rinse and repeat.
    3. Use Agile software development to develop the MVPs.

    In the foreword to the Lean UX book, Ries further comments:

    Lean Startup is a big tent. It builds on established ideas from many disciplines, from lean manufacturing to design thinking.
    Clearly, there are many ideas and influences behind the Lean Startup movement, and it is constantly evolving.

    Product Features vs Business Outcomes

    Laura Klein gives a practical example that further clarifies what Lean Startup is about:

    Before Lean UX, Company X might have said, "We need to record user comments for each product and display them on the product page". The product manager would have spent time writing a spec for comments on product pages. A designer might have come in and designed a great comment experience. Engineers would then have written code that matched the spec and the design. The whole process might have taken two or three months. At the end of the process, the product pages would allow users to leave comments. But so what? Would this make users spend more money on products? Would they stick around for longer? Would users even bother to leave comments? What is the actual benefit to the company for spending those three months?

    The problem with this approach is that it starts with a feature rather than a hypothesis. It assumes that comments on product pages are necessary rather than identifying a user problem, coming up with an idea that might solve that user problem, and designing a test to see if the idea is true. A more Lean approach is:

    Based on our preliminary research, we believe that allowing users to leave comments on product pages will cause customers to become more engaged and buy more items. How can we figure out if that’s true?

    Now this has been stated in a way that allows the company to validate the hypothesis and easily change the feature if it turns out to be the wrong way to improve the metric.

    That is, we focus on Business Outcomes, not Product Features.

    Lean Startup vs Agile

    Mary Poppendieck provides an interesting comparison between Agile and Lean Startup:

    AgileLean Startup
    Product RoadmapBusiness Model Canvas
    Product VisionProduct Market Fit
    Release PlanMinimum Viable Product
    On-Site Customer"Get out of the Building"
    IterationBuild-Measure-Learn Loop
    Iteration ReviewPersevere or Pivot
    Backlog"To Learn" List
    User StoryHypothesis
    Acceptance TestSplit Test
    Definition of DoneValidated Learning
    Continuous IntegrationContinuous Deployment
    Customer FeedbackCohort-based Metrics
    Product OwnerEntrepreneur
    Certified Scrum MasterCustomer Success Manager

    The February Revolution

    In an attempt to cut through the considerable jargon and dogma from many competing methodologies, such as impact mapping, feature injection, real options, hothousing, user story mapping and similar, Gojko Adzic and others got together to try to distill the essence of these techniques into a simple set of principles. They came up with the following "february revolution".

    Great results happen when:

    • People know why they are doing their work.
    • Organizations focus on delivering outcomes and impacts rather than features.
    • Teams decide what to do next based on immediate and direct feedback from the use of their work.
    • Everyone cares.

    Departmental Silos

    How is it possible that our departmental silos are operating with agility, but our companies are hopelessly rigid and slow? From our far-off vantage point, we have missed something essential. Although our departments may value agility, the interconnections between them are still mired in an antiquated industrial past.

    -- Eric Ries (in the Foreword)

    I'm interested to learn how your company is run. What works, and what doesn't, for you?

    Perl Monks References

    External References

RFC: (Do Not) Modify the System Perl
9 direct replies — Read more / Contribute
by MidLifeXis
on Oct 16, 2015 at 14:39

    Update: Excellent points made in responses. A rewrite is in the works. Keep them coming.

    Perhaps this is a tutorial, or perhaps something that just belongs long term in Meditations, but my intent with this node is to document the arguments related to modifying the system's Perl installation, so that I don't have to lay out the argument every time it comes up in SoPW. There are some pro, and some con, but it seems to be, in my experience, that "Can't touch this", if given the choice, is the correct path to take.

    Some of the previous comments I have made on this topic can be found here: SuperSearch Preload

    So, without further ado, here are some arguments in favor of installing your own Perl (in no particular order):

    • Modifying the system Perl can break the OS.
    • Updating the OS can change the underlying Perl, breaking your application.
    • You don't necessarily have control over the system's Perl.
    • Updating the system's perl for application's needs can go against another application's needs.
    • The system's Perl may not be complete.
    • By packaging Perl with your application stack, you control the installed modules and toolchain.
    • It is easier to target a single Perl version than anything you might find on the OS.
    • Policy may disallow installing a "necessary" module on the system's Perl.
    • Your installed / updated CPAN modules may be overwritten (and downgraded) by OS updates. - Corion
    • You are (safely) limited to the module versions provided in packages by your vendor - Corion

    There are also some cons to installing your own Perl:

    • Your application distribution now requires or includes a separate Perl distribution.
    • Your packaging requirements are now more complex.

    In summary, unless you are writing an OS-level tool specifically for this platform, install a Perl version specifically for your own application's runtime stack.

    Anything else? (ed: updates tagged with author)


Crash-Test Dummies: A Few Thoughts on Website Testing
4 direct replies — Read more / Contribute
by sundialsvc4
on Oct 08, 2015 at 15:34

    In the last few days, an article was published, referenced in another thread, which made Perl look bad.   (The problem had to do with processing CGI parameters, and list vs. array context.)   But, actually, this is a very common problem with many ... dare I say, most? ... web sites.   The problem is that, when subjected to a barrage of nonsensical (or contrived) inputs, many sites fail disastrously and repeatedly.

    Many web sites (and a growing number of mobile apps, with regards to their host interfaces) are, simply, untested with regard to their ability to operate in any path that deviates, however slightly, from what the site’s designers “expected” it to do.   (Maybe) they ran through all the buttons and screens.   (Or, maybe not.)   But what they never did was to seriously beat it up.   Unfortunately, that’s exactly what rogue attackers will do.   (Yes, one of the first things that they will do is ... test your code.)

    HTTP, leave us not forget, is a completely stateless protocol.   The server receives a request consisting of a URI (including any GET parameters), a set of cookies, and possibly POST parameters.   It produces an HTML (or AJAX) result, and promptly forgets.   Everything.   Well, the thing that many developers completely overlook is that these inputs can be anything.   Although you may expect that they consist only of what the corresponding <form> would generate, you must never assume this.   The inputs to your web page ... can ... be ... anything.   Therefore, attackers (or, testers) will subject your site to URIs in unpredictable sequence with unpredictable or deliberately-altered parameters.   They will look to exploit things that you assumed.   And usually they will find them.

    Consider what happens if the rogue simply duplicates a GET string.   In many cases, the variables become multi-valued ... arrays ... since there is now more than one value for the variable.   Or, what if the rogue adds another variable to the string, such as &is_admin=1?   (You’d be shocked how often that turns you into a god ...)   Mispelin a variable-name can cause an error-dump that might include literal SQL text and server-IP addresses.   And so on.

    One of the very first things we do at Sundial, with any new web site that we are asked to evaluate, is to put it into a test-bed and “hit it with both barrels.”   I can count on the fingers of one hand how many sites survived the onslaught entirely unscathed.   And yet, the automated test-tools are readily available (or, can be built in Perl).   The builders of the site could have made the thing bulletproof ... they simply didn’t bother.

    Perl has many unique features, like “taint mode,” that if properly used can greatly strengthen your software.   But these are only as good as your ruthless and unforgiving test plans.   Don’t send your software out into the world unprepared.

Add your Meditation
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.