[DFW.pm] Homework for the list, and for Oct 08 meeting

Robert Flach robert.flach at webtooldeveloper.com
Thu Sep 11 12:42:16 PDT 2014


Yet another way to do it. Interesting.  I would have assumed that the 
unary + would have caused a numeric contextual evaluation of the 
contents of the parens, causing the string prints to print zero instead, 
but it works a charm.  Nice


Robert Flach
*Web Tools*
On 9/11/2014 2:37 PM, Tommy Butler wrote:
> You can put a unary plus sign operator on the parens to tell perl that 
> the parens don't belong to the print command.  Also comes in handy 
> when using map in certain cases.
>
> print +( ... )
>
> Cheers,
> --Tommy Butler
>
> On Sep 11, 2014, Robert Flach <robert.flach at webtooldeveloper.com> wrote:
>
>     Tommy,
>        Run the code without the STDOUT, then run it with.  It's a
>     simple trick to avoid having perl interpret the ternary grouping
>     parenthesis as print function delemiting parenthesis.  TIMTOWDI:
>     You could also wrap the entire thing in parenthesis, you could
>     skip the ternary and do your printing in an if.  You could move
>     the ternary to an assignment statement to $val just before
>     printing plain old $val (what I would probably normally do if I
>     weren't being creative), etc.  But the STDOUT is definitely
>     required for the code as is ;-)
>
>     Robert Flach
>     *Web Tools*
>     On 9/11/2014 1:37 PM, Tommy Butler wrote:
>     "print STDOUT" ???????
>
>     You did that.  On purpose?
>
>     This raises so many questions :-P
>
>     -- Tommy Butler
>
>     On Sep 11, 2014, Robert Flach <robert.flach at webtooldeveloper.com>
>     wrote:
>
>         Well, it sounds like it was a fun meeting.  I'm sorry I missed
>         it!  I personally will occasionally use the FizzBuzz test when
>         interviewing applicants though I usually use more complicated
>         coding challenges.  Maybe I could share one or more of those
>         sometime as a "more advanced" challenge.  In the meantime,
>         scroll down for my solution and for the things I look for when
>         evaluating a fizzbuzz...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>         #!/usr/bin/perl
>         use strict;
>         use warnings;
>         my $x = 0;
>         while($x++ < 100)
>         {
>           my $val = "";
>           $val .= ( $x % 3 == 0 ) ? "fizz" : "";
>           $val .= ( $x % 5 == 0 ) ? "buzz" : "";
>           print STDOUT ( $val ? $val : "$x" ) . "\n";
>         }
>         Things I look for in a fizz buzz:
>         1. (Dealbreaker) Is the code readable. (I have a pretty loose
>         definition of readable and it definitely doesn't require
>         comments, but if it's unintelligible it's a dealbreaker )
>         2. (Dealbreaker) Will it produce correct output barring any
>         minor syntax errors i.e. is the algorithm valid.
>         3. If doing a separate test for fizzbuzz have they optimized
>         to a mod 15 check.
>         4. Can they (with prompting if needed) make the leap to
>         realizing they can concat the two tests to produce the
>         combined value without a separate test
>         5. If using real code: will it compile.
>         6. If using real code: will it compile without errors or
>         warnings (e.g. for perl can I stick a use strict;use warnings;
>         at the top of it.
>
>         Things I never care about in a fizzbuzz:
>         1. Do they know the correct operator for modulus (as long as
>         they know modulus is possible)
>         2. while vs for vs. foreach, variable initialization, ternary
>         vs. if, perl vs c vs (insert your favorite language argument here)
>         3. correct formatting of output (e.g. I don't mind if they
>         forget to newline it, nor do I give extra points for printf )
>         4. error handling, supporting input arguments, etc. (this is
>         an algorithm test, not a coding practices test and a coding
>         practices test is unsuitable for the time available)
>
>         Things somewhat unrelated to fizzbuzz but discernible in some
>         way related to the fizzbuzz tests that I definitely care
>         about/give extra credit for.
>         1. Do they confirm or clarify the requirements with me in some
>         way e.g. "When you say instead prints fizz buzz or fizzbuzz do
>         you mean that you don't want it to print those numbers at all
>         and only print the alternate text, or would you like it to
>         always print the numbers and print that in addition for those
>         meeting the requirements?"  It doesn't matter if their
>         question is clearly answered in the requirements as written,
>         restating the requirements as a question is a hugely valuable
>         (and often undervalued) developer skill.
>         2. Similarly to number 1, do they ask questions about what I
>         want in the solution (e.g. all those things in numbers 2-4
>         under things I never care about above) I don't care about
>         those things (for the test; very different standard for "real"
>         code), but many people do, and I DO care about your ability to
>         realize that and your willingness to adjust your style
>         accordingly.
>         3. I will always ask for some modification of the code
>         afterwards.  I care a lot about how they respond to that
>         request, whether it is a request to make it do something
>         different, to change the styling, to comment it, etc.
>         4. If using pseudo code does their pseudo code look like a
>         human language construction or is it just code with invalid
>         syntax.  (Either way, once they are done I will almost always
>         ask for something that would compile/interpret correctly in
>         some language.
>
>
>
>
>         Robert Flach
>         *Web Tools*
>         On 9/11/2014 12:15 PM, Lisa Cloutier wrote:
>>         Solution below:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>         my $x = 1;
>>
>>         while ($x <= 100)
>>         {
>>             if (($x % 3 == 0) && ($x % 5 == 0))
>>           {
>>            print "FizzBuzz\n";
>>           }
>>           elsif ($x % 3 == 0)
>>           {
>>            print "Fizz\n";
>>           }
>>           elsif ($x % 5 == 0)
>>           {
>>            print "Buzz\n";
>>           }
>>           else
>>           {
>>            print "$x\n";
>>           }
>>           $x++;
>>         }
>>
>>         I minorly "cheated" in that I didn't know the sign in Perl
>>         for "mod" but had read Bob's email previously (before
>>         learning about the challenge) and realized what he was doing
>>         with the % sign.   Had I been in an interview I probably
>>         would have used every special character in turn until I
>>         figured out the symbol for mod.
>>
>>         So I guess I can "program my way out of a wet paper bag" as
>>         this website <http://c2.com/cgi/wiki?FizzBuzzTest> proclaimed
>>         about the FizzBuzz test.
>>
>>         On Thu, Sep 11, 2014 at 11:42 AM, John Fields
>>         <wigthft at gmail.com <mailto:wigthft at gmail.com>> wrote:
>>
>>             Firstly,  I want to thank John Dexter for his Docker
>>             presentation, showing how to encapsulate a Mojolicious
>>             Web server and application for easy deployment. He got
>>             what all presenters get, a free dinner and that warm
>>             afterglow from making the world a better place (with more
>>             Perl in it).  :)
>>
>>             I challenged the attendees last night to do the FizzBuzz
>>             program.  We even had one programmer in attendance that
>>             had been asked to do it on a job interview the previous
>>             day!  We were one day late for him, but hopefully not for
>>             you..
>>
>>             Http://rosettecode.org/wiki/FizzBuzz
>>
>>             Don't cheat.. Yourself.  Do it from scratch before
>>             looking at other's solutions.  We will pick 2 more, with
>>             increasing difficulty with one per week.  Also new member
>>             Andy Sohn will offer a short challenge and demonstrate
>>             answers live at the next Mongers.
>>
>>             So send in your code, and be as creative as you can! 
>>             TIMTOWTDI is a strength after all.  :)
>>
>>             Cheers,
>>             John and Tommy
>>
>>
>>             _______________________________________________
>>             Dfw-pm mailing list
>>             Dfw-pm at pm.org <mailto:Dfw-pm at pm.org>
>>             http://mail.pm.org/mailman/listinfo/dfw-pm
>>
>>
>>
>>
>>         _______________________________________________
>>         Dfw-pm mailing list
>>         Dfw-pm at pm.org
>>         http://mail.pm.org/mailman/listinfo/dfw-pm
>
>         ------------------------------------------------------------------------
>
>         Dfw-pm mailing list
>         Dfw-pm at pm.org
>         http://mail.pm.org/mailman/listinfo/dfw-pm
>
>
>     -- Sent with *K-@ Mail
>     <https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2>*
>     - the evolution of emailing.
>
>
>     _______________________________________________
>     Dfw-pm mailing list
>     Dfw-pm at pm.org
>     http://mail.pm.org/mailman/listinfo/dfw-pm
>
>
>     ------------------------------------------------------------------------
>
>     Dfw-pm mailing list
>     Dfw-pm at pm.org
>     http://mail.pm.org/mailman/listinfo/dfw-pm
>
>
> -- Sent with *K-@ Mail 
> <https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2>* 
> - the evolution of emailing.
>
>
> _______________________________________________
> Dfw-pm mailing list
> Dfw-pm at pm.org
> http://mail.pm.org/mailman/listinfo/dfw-pm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/dfw-pm/attachments/20140911/ac3c5faf/attachment-0001.html>


More information about the Dfw-pm mailing list