Language Community Litmus Test: Database Placeholders

2014-03-04

Search for “[language] database tutorial”. Out of the top 5 results, how many of them show how to use safe practices (preferably placeholders, but safe quoting functions are OK, too) at the earliest available opportunity?

I award a score of 5 points for the first result, 4 for the second, and so on. A perfect score would be 15. If the first INSERT or SELECT statement has simple static data, I give it a pass and find the first statement that’s filling in data from variables.

• Haskell: 15
• Python: 12
• Perl: 11
• Ruby: 11
• Node.js: 4
• PHP: 4

There are some caveats with the judging of this data:

• Haskell’s interfaces seem to use declarative functions to build the SQL statement rather than concatenating strings. I’m presuming these libraries quote things safely.
• The third result for Python was to a wiki page that linked to various database-related info. Many of the links had placeholders and quoting mentioned early on, so I gave it points for this one.
• The last two results on Python were to a Stack Overflow question without many direct examples, and a YouTube vid that has no dynamic statement usage. No points for these.
• Perl’s second link was to an About.com (??!) tutorial with no placeholders/quote functions shown. I think we in the Perl community might need to fix our SEO on this one.
• Ruby’s second result was to a general Rails tutorial without much direct SQL access. No points here, but like Perl’s About.com result, this may be more of a case of bad SEO.
• Tempted not to give points to Ruby’s third result, which took a while to get to a statement with any dynamic data. But when you got there, it did do it safely, so I gave it a pass.
• Edit: I initially didn’t give Ruby points for the fourth link. It was a short page that had no complex SQL statements. I see now that it’s one part of a larger document, and the subsequent link does use Ruby ActiveRecords. Ruby now gets points for this.
• Fifth Ruby result was a link to the Ruby/DBI homepage. Clicked on “tutorial” sidebar link, which did show best practices, so I gave it points.
• This test is perhaps unfair towards Node.js, because most of its top results covered MongoDB rather than an SQL database. While I have mean things to say about NoSQL, critiquing it wasn’t the intent of this test. The second link does use SQL, and does things correctly, so points awarded there.
• All but the second PHP result concatenates $_POST[‘…’] or $_GET[‘…’] directly into statements in its earliest examples. The second result is trying desperately to show how things should be done, and is the only one to get points. One bad result can be passed off as an SEO issue. All but one is a real problem.

The Horror. The Pure, Unbridled Horror.

2014-02-26

welcome to my websight Please sign my guestbook if you click the image below, it takes you to a java applet i wrote that sets bill clinton on fire

For Mustache Templates in Perl, use Text::Caml

2014-02-21

I like Mustache templates. Unfortunately, the obvious Mustache parser in Perl (Template::Mustache) is under-documented, over-documented, and not worth documenting. It has little example code and doesn’t make it at all clear that you basically have to subclass it for any real use.

Fortunately, this problem has been solved in Text::Caml. My one issue is that it’s too sensitive to whitespace. It’s good to give your eyes a resting place for sections and partials, like this:

{{# section}}
    {{> partial}}
{{/ section}}

But Text::Caml will consider the leading whitespace as part of the name. Looking over the main Mustache docs, none of the examples show leading whitespace, and it’s never specified what to do with whitespace. So I guess Text::Caml isn’t technically wrong. I just don’t like it this way.

Other than that, it’s great.

Edit: Turns out the Mustache spec does say that partials and sections should be insensitive to whitespace:

https://github.com/mustache/spec/blob/master/specs/partials.yml (starting line 104) https://github.com/mustache/spec/blob/master/specs/sections.yml (starting line 252)

Edit 2: I reported the whitespace issue to the author’s github issue tracker, expecting it to be a fairly low priority. He ended up fixing it the next day :)

Review: Perl One-Liners

2014-02-19

Full Disclosure: I received a free review copy of this book

I’m primarily a backend web programmer. I try to write in an object-oriented way with test-driven development practices, with each object having a well-defined purpose. I do this primarily in Perl, a language that causes many developers to get a twitch. The reason is that Perl has an old reputation as being messy line noise. Part of the reason for that reputation is because of the one-liner obfuscation games that used to be quite popular.

So when I first heard of this book, I was naturally inclined to avoid it. In a way, it’s perpetuating an aspect of Perl that’s best left as part of history. Besides, as a web developer, what did this book have to offer me?

What I found was that one-liners offer a different perspective, and it’s a useful perspective to have. Converting a text document to double-spaced lines isn’t a problem I have every day, but maybe I will at some point. When that or one of the many other problems this book addresses comes up, I’ll have something within easy reach.

Perhaps more importantly than any specific problem is the attitude that programming in this fashion doesn’t have to be inscrutable. Every one-liner here comes with a detailed explanation, and many come with alternative solutions with their own explanations. If we can document our concise solution in less space than a more “well-developed” solution would take, what’s the problem?

Donald Knuth had attempted a system called “Literate Programming”, where documentation and code are carefully interleaved. Jon Bentley, writer of the Programming Pearls column in Communications of the ACM, challenged Knuth to write a Literate Program for the following problem: read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies.

Knuth wrote a 10-page program. Bentley then turned around and wrote a 6-command shell pipeline to do the same thing, which also happened to miss a few bugs that Knuth had stumbled over. The entire shell script and its documentation fit on a post-it note.*

One-liners can look like inscrutable line noise. But if we can otherwise document them in a succinct way, does it really matter?

That’s what this book does: provides solid explanations for extremely concise code. No matter what you do in Perl or your skill level, there’s something in here for everyone.

* See: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/

Announcing: The Great UAV::Pilot Split

2014-02-18

The main UAV::Pilot distro was getting too big. The WumpusRover server had already been spun off into its own distribution, and now the same is happening for many other portions of the system.

Reasons:

• UAV::Pilot hasn’t been passing CPAN smoke testing because of the ffmpeg dependency. Splitting that off means the main distro can still be tested.
• There’s no reason to get the WumpusRover stuff if you just want to play with the AR.Drone
• General aim towards making UAV::Pilot into the DBI of Drones

UAV::Pilot itself will contain all the basic roles used to build UAV clients and servers, as well as what video handling we can do in pure Perl.

UAV::Pilot::Video::Ffmpeg will have the non-pure Perl video decoding.

UAV::Pilot::SDL will take the current SDL handling, such as for joysticks and video display.

UAV::Pilot::ARDrone and UAV::Pilot::WumpusRover will take the client end of things for thier respective drones.

I expect the first release to have interdependency issues. I’ve tested things out on a clean install, but I still might have missed something. I’m going to be watching the CPAN smoke test reports closely and filling in fixes as they come.

Aren't we supposed to be better than this?

2014-01-22

From the recent blogs.perl.org hacking:

The password is salted and encrypted (with crypt)

This is what I expect out of the PHP community.

Parallel Perl with MCE

2014-01-21

Noted: http://perltricks.com/article/61/2014/1/21/Make-your-code-run-faster-with-Perl-s-secret-turbo-module

Announcing UAV::Pilot::WumpusRover::Server v0.1

2014-01-13

The original server code for the WumpusRover was bundled up with UAV::Pilot in version 0.8. That meant that the HiPi modules were recommended for UAV::Pilot, even though that doesn’t make sense if you were installing outside of the Raspberry Pi.

So the server modules have been spun off into their own CPAN distro. The modules will be removed from the main UAV::Pilot distro in version 0.9.

On CPAN now

UAV::Pilot v0.8 Released -- Now Supports WumpusRover

2013-12-28

At long last, UAV::Pilot v0.8 has been released. This is a big update with lots of API improvements. Most of those improvements were decoupling the code to support my own WumpusRover in addition to the Parrot AR.Drone. That means a big goal has been reached, where UAV::Pilot can support multiple types of automated vehicles. It also means UAV::Pilot is a major component of the code running on board a UAV, in addition to running the client side.

The WumpusRover is a project I’ve been working on for a while. It’s an old RC car I had laying around, retrofitted with a brushless motor controller, an Arduino, and a Raspberry Pi.

Update: Video of the WumpusRover will be up at http://youtu.be/yeDwb-6ASxw. Going to be leaving soon out of town, but wanted to make sure this gets up before I go out the door.

UAV::Pilot runs on the Raspberry Pi as a server, taking packets from the client and passing turning and throttle data to the Arduino. The reason for the split between Rapsberry Pi and Arduino is:

1. The Arduino has better support for the communication pulses used by RC servos and ESCs
2. The Raspberry Pi with Linux is not a real-time OS–that means a carefully timed signal to the servo could be interrupted by the OS
3. The Raspberry Pi can run Perl, support any WiFi adaptor that Linux does, and has an excelent camera module

(The camera module is not yet implemented directly with Perl support. This is one of my upcoming projects, which will give the WumpusRover a video stream, among other things.)

As you can see, the two complement each other’s strengths. In the future, we might see cheap boards that can combine these two uses; the recently announced Arduino Tre looks promising.

I’ll be posting more detailed instructions later. If you’d like to get started on your own rover, you can start with the Arduino code here:

https://github.com/frezik/wumpus-rover

There are also some improvements to the older AR.Drone code. While making changes to the joystick API to support the WumpusRover, I found a case in the AR.Drone where its navdata sends a floating point -NaN. (More evidence that they shouldn’t have been using floating point for this purpose, and that the AR.Drone was badly implemented in general). UAV::Pilot was crashing in this case, but now handles it gracefully.

Also, the nav data will now be sent over ol’ fashioned unicast IP by default instead of multicast. This should make Mac users happy, as multicast isn’t setup out of the box on OSX.

Why I Don't Like Perl State Variables

2013-12-16

State variables work something like C static vars. It’s a forgivable feature in C, because C doesn’t have lexical scoping.

Here’s an example of Perl’s state variables, taken from Learning Perl, 6th Ed.:

use 5.010;

sub running_sum
{
    state $sum = 0;
    state @numbers;

    foreach my $number ( @_ ) {
        push @numbers, $number;
        $sum += $number;
    }

    say "The sum of (@numbers) is $sum";
}

running_sum( 5, 6 ); # "The sum of (5 6) is 11"
running_sum( 1..3 ); # "The sum of (5 6 1 2 3) is 17"
running_sum( 4 );    # "The sum of (5 6 1 2 3 4) is 21"

This could be implemented with lexical scoping like this:

use strict;

{
    my $sum = 0;
    my @numbers;

    sub running_sum
    {
        foreach my $number ( @_ ) {
            push @numbers, $number;
            $sum += $number;
        }

        print "The sum of (@numbers) is $sum\n";
    }
}

running_sum( 5, 6 ); # "The sum of (5 6) is 11"
running_sum( 1..3 ); # "The sum of (5 6 1 2 3) is 17"
running_sum( 4 );    # "The sum of (5 6 1 2 3 4) is 21"

Is this uglier? Yes, absolutely it is. That extra indent level is not pretty at all. So what’s the advantage?

With lexical variables, you learn a general feature that’s applicable to a wide range of situations. It is something you ought to know in order to program in anything like Modern Perl. State variables, on the other hand, are applicable to a specific case. While I’m sure someone who encounters them regularly would be able to intuitively reason about them, it’s not obvious to the rest of us without sitting down and working it out for a while.

(And if you’re in the position of being able to intuitively reason about complex functions involving state variables, I wonder about the Bus Factor of your code.)