A piggy bank of commands, fixes, succinct reviews, some mini articles and technical opinions from a (mostly) Perl developer.

How to transfer files between Windows 7 and Android 4

Settings | Storage | (three dots in top-right) | USB computer connection | Camera (PTP)

Then go to Developer Options (read elsewhere how to get this), and tick 'USB debugging'.

Voila - your device will appear in My Computer | Portable Devices.

Copy the files to a subdirectory of the Android Camera device in Windows, and move them into the right place from within Android. e.g. using ES File Explorer

Good enough software

There's so much software available these days, it's difficult to find which is the best without laboriously downloading, installing, configuring and testing, which I don't often have time for. Unfortunately a large proportion of software is simply not good enough, or its features are poorly described.

Here is some "good enough" software I've found for Windows:
  • To diff directories, e.g. sync music or photos: FreeFileSync 6.3
  • To diff the content of files, e.g. source code: WinMerge
  • Windows Explorer alternative: xplorer 2
  • To encode mp3s: LAME
  • To see where your disk space is being used: Treesize
  • To remove spyware: Spybot: Search & Destroy
  • Torrents: qBittorrent
  • N64 emulator: project64
  • Programmer's text editor: Notepad++
  • ebook management: Calibre
  • Manage iPhone music outside iTunes: Media Monkey
  • Graphics maniplation: GIMP
  • Rename files: Bulk Rename Utility
  • Macro recorder: Autohotkey
  • Media player: VLC, or MPC-HC (not tried)
  • Music player: Winamp
  • Documents and spreadsheets: Microsoft Office
    • (LibreOffice and OpenOffice are NOT good enough)

Why shouldn't you put logic in the template?

The overall reason for keeping business logic separate from presentation is well known, see MVC.

Here are the practical reasons why putting business logic in the template is a really bad idea:
  • You can't re-use it
  • You can't unit test it
  • You can't log
  • You can't validate parameters to subroutines
  • You often can't create subroutines at all (and you shouldn't)
  • You can't use an IDE to look up method definitions
  • You can't "use strict"
  • You can't run a code tidier
  • You can't validate syntax
  • Error messages are different
  • Keyword behaviour can be subtly different, leading to the worst kind of bug - the one you don't notice until it's too late.
  • Now you have two languages to maintain instead of one
Logic which relates directly to the display of the page is borderline okay, although for the reasons stated above it's better to put as much of that as possible in a class/module, which could be called a View Model.

Corollary - don't pass the entire model to the template, only stash what is needed. Reasons for this:

  • Separation of concerns - the template should be editable by a front-end dev without any knowledge of syntax to specify models
  • Performance may be poor - for example if the model opens a new database connection each time it's called


This article was written with Perl and Template Toolkit in mind.

Make it easy to review your code

tldr; It's difficult to arrange for a whole team of developers to follow and participate in code reviews, but if you use dedicated code review software then it's easy.

Of course you want a wide audience reading your code - in order to improve the quality of the code being produced by your team. You don't have anything to hide, do you? ;-)

Problem: Say you're not the "designated reviewer", and you want to see your team mates' code before it's merged to trunk, perhaps the following things have to happen:
    - Configure your email filters to pick out reviews from the hundreds of other update emails
    - Check out the code in your environment
    - Wait some time for the checkout to complete
    - Run a diff command to see the changes
    - Hope that your team is using version control tools which make it easy/possible to see only the commits they made, without mixing them up with all the code that was pulled from trunk/master along the way
    - Read the code
    - Copy and paste the lines of code you want to comment on (for context) into a message to the developer. As it's often easier and faster to use email, instant chat or a face to face meeting than adding comments to a bug tracking system, the rest of the team isn't part of the conversation and is denied the chance to learn about technique, see how to conform to house policy, etc.
    - Write the comments
    - The developer reads the comments and may or not make changes, you don't always know, and the rest of the team certainly doesn't know.
    - In a team where developers are expected to designate a single person to review each feature, attempting to give feedback on someone else's code out of turn could be seen as interfering and a distraction.

Solution: A better arrangement could be:
    - Use a code review tool: ReviewBoard, Stash or something similar
    - Click on a URL in the review notification email
    -  Read the code
    - Click on the line you want to comment on
    - Write the comments. The whole team gets notification emails of comments, so they can effortlessly follow along with conversations about the code.
    - The developer replies to the comments publicly, everyone is now aware of what technical decisions were made and why
    - Everyone is expected to review all code - it's not distracting because it becomes part of the general work of the team to ensure high code quality.

How to work around certificate errors in Perl

PERL_LWP_SSL_VERIFY_HOSTNAME=0 perl script.pl

or

my $mech = WWW::Mechanize->new(
    ssl_opts => { SSL_verify_mode => 'SSL_VERIFY_NONE'},
);