Skip to main content

Posts

Book review: 390+ Python Interview Questions and Answers

I downloaded a preview portion of 390+ Python MCQs from Anazon, thinking reading through it would help me advance my Python skills beyond what I have learned from Harvard’s online CS50P (Python) course. I’m an experienced program looking to add a new skill to my repertoire, and while the course covered many significant aspects of Python programming, there are many other details to perfect, such as best practices, developing packages, and so on. The book is written by Manish Dnyandeo Salunke, who claims 15 years experience in IT,  but it is not clear who published it. It is obvious no one edited it, or verified the correctness of the questions, answers and explanations. Amazon allowed me to download a sample of (I think) 57 questions. Roughly half of these were wrong, and some of the others struck me as irrelevant. The maximum allowed length for an identifier, apparently, is 79 characters. Anything over 20 characters should be considered unusual, so sufficient to say the limit is severa
Recent posts

Making a Re-Saw Saw

I made a framing saw from a kit at a Lee Valley workshop, and it was fabulous. It's great as a coping saw, cutting curves, but the thin blade makes it hard to cut a straight line. So I made another one on my own, using a chunk of bandsaw blade, and this was better for straight cuts. But trying to resaw a 1" thick boards into two 1/2" inch boards was impossible. The cut would wander all over the place. I would practically wind up with veneer. I saw a number of articles and YouTube videos about making a re-sawing saw, and I decided to make one. But I'm not keen on kits. For one thing I'm stingy, and don't like giving away the profit. Besides, it doesn't feel like I made it, if someone else provided the challenging parts. So I made my own. The saw blade is cut from one of three rusty handsaw blades I got for $10 off Facebook Marketplace. I used an angle grinder to cut it out, a little over two inches wide, and to grind three-to-the-inch teeth

Implementing the Game with Perl & Moxie

I've been creating classes relating to playing cards using the new Moxie module for the Perl programming language. The objective is to implement the card game Go Fish! as specified at Rosetta Code . The Outside-In View An actual program file should be simple; all the real code should be in testable modules. In this case, play_go_fish.pl takes this to an extreme. #!/usr/bin/env perl use warnings; use strict; use 5.026; use lib '.'; use Game; Game->new()->play(); As of Perl 5.26, the current directory is not automatically part of @INC, the search path for modules, so it is necessary to include it manually. That makes it possible to load the Game module, to instantiate an instance, and play a game. package Game; use Moxie; use lib '.'; use Deck; use Computer; use Human; use Const::Fast; extends 'Moxie::Object'; const my @PLAYERS => qw( human computer ); const my $INITIAL_DEAL_COUNT => 9; A Game.pm object begins like most ot

Best of Seven Series

Mathematician Rob Bradley posted that the expected length of a best-of-seven series should be about 5 3/4 games, on which basis he expected the New York Yankees to win. Or maybe living close to New York has warped his sense of reality. As a programmer, I felt a compulsion to verify his claim. I could figure out a formula, or list the possibilities (70 possible ways to win or lose 4 games out of 7), but I decided to write a simulation, using the Perl programming language. This explanation may be overly-detailed for programmers, but I want facebook friends with limited programming experience to understand. sub count_games_in_series { my ( $max ) = @_; $max //= 7; my ( $won, $lost) = (0, 0); for my $games ( 1..7) { if ( int rand 2 ) { $won++; } else { $lost++; } say "won $won; lost $lost; total $games" if $VERBOSE>1; return $games if $won == 4 || $lost == 4;

Creating Perl5 Objects with Moxie

Having in the previous article prepared data types for car suits and card ranks, I can now combine them to provide a playing card class, using Stevan Little's Moxie module (version 0.04, so definitely early days.) The goal is to provide an object-oriented paradigm to the Perl 5 programming language which is more sophisticated, more powerful and less verbose than manually bless() -ing hashes. To achieve that goal it needs to be faster and light-weight compared to Moose. Currently, Moxie.pm and and MOP.pm are add-on modules, but eventually, when they are more complete, when the wrinkles have been ironed out, and when they have gained acceptance and a community of users, they might be merged into the Perl core. One significant feature of Moxie is that it reduces boilerplate code. You don't have to specify warnigns or strict . As well, the features or the perl you are using are enabled, among them say , state , signatures , and post_deref . A Simple Moxie Class packag

Perl5, Moxie and Enumurated Data Types

Moxie - a new object system for Perl5 Stevan Little created the Moose multiverse to upgrade the Perl 5 programming language's object-oriented system more in line with the wonderfull world of Perl 6. Unfortunately, it's grown into a bloated giant, which has inspired light-weight alternatives Moos, Moo, Mo, and others. Now he's trying to create a modern, efficient OO system that can become built into the language. I've seen a few of his presentations at YAPC (Yet Another Perl Conference, now known as TPC, The Perl Conference), among them ‎p5 mop final final v5 this is the last one i promise tar gz <. So I was delighted to recently see an announcement of the module Moxie, and decided to try implementing a card game. While the package provides some POD documentation about the main module, Moxie, it doesn't actually explain the enum package, Moxie::Enum. But delving into the tests directory reveals its secrets. Creating an Enum package Ranks { use

Adventures in Autovivification

Having recently started a new job, I was exposed to old code with multi-step tests against autovivification in multi-level hashes. You get used to the code you have seen, but in a new environment it‘s irritating and jarring. Moose does not generally have the problem, first because class structure is pre-declared, because values are accessed using accessor functions rather than directly, and because responsibility is delegated down to attributes, avoiding long chains. On the other hand, Moose has it's own overhead, so hand-rolled objects, and bare structures still have their use. If you don‘t protect against autovivification, then mis-spelling a key, or referencing keys which haven‘t been instantiated in this instance, causes those keys to instantly come into existence. #!/usr/bin/perl use warnings; use strict; use Data::Dump 'dump'; use 5.024; my $var = {key1 => {key2 => {key3 => 'a'}}}; say dump $var; if ( $var->{key1}{key2}{key3b}[13]{foo