Al Newkirk

Please build this for me, yesterday, also!

2013-02-25T06:00:45Z

use Port::Authority;

Port::Authority would be a module which assigns and tracks ports for use with multiple application servers running on the same box. It would need an algorithm, capable of generating reproducible results, to generate port numbers in which are available, maybe it could be based on a namespace or random string + current user (etc), or maybe you could be able to specify the type of algorithm (e.g. UUID).

I need this yesterday for a variety of reason, what do you guys think?

Please build this for me, yesterday!

2013-02-20T09:38:44Z

#!/usr/bin/env perl

=head1 NAME

App-sourcery

=head1 USAGE

# loads all @assets within $path and reports any not referenced in at-least one of the @sources
./sourcery --path=/var/www --asset=*.css --asset=*.js --asset=*.png --source=*.html

=head1 DESCRIPTION

Often times I'll find myself mucking around with an old webapp codebase that has had assets (css, js, images, etc) added to it over and over throughout its life, and being the neat-freak that I am I like to keep my codebase clean.

This (potentially) is a program that finds all files that match the specified asset and source patterns, puts them in their respective buckets, and then report the assets that are no longer being referenced anywhere.

=cut

# your contribution here please, thanks.

The Power of the Sun, in the Palm of your Hand

2013-02-05T01:26:33Z

Over the weekend I worked on a new Perl library, MongoDB::QueryBuilder, a tool which is designed to simplify composing complex and dynamic queries for MongoDB in a chainable and object-oriented fashion.

Seldomly do we see examples of querying a MongoDB datastore of significant size and complexity, however, as your application grows and your data evolves, the questions you’ll want to ask your datastore will become more intricate.

For example. Let’s suppose we have an inventory management application that tracks equipment used in our business. Over time the business grows as does the database and (for whatever reason) we want to ask the database to “give us the (serial number, asset type, and the location manager’s name and phone number) closest to one-of-the-three latitude/longitude coordinates we will provide where the asset has been inspected and placed in a bin-location”. Oh, and limit that result-set by 100 documents.

Using MongoDB::QueryBuilder, the abstraction might resemble the following:

use MongoDB::QueryBuilder;

my $query = MongoDB::QueryBuilder->new(
    only => [
        'serial_number',
        'asset.type.name',
        'asset.location.phone',
        'asset.location.manager.name'
    ],
    and_where => [
        'asset.location.bin$ne' => undef,
        '$or' => [ # this condition will short-circuit
            {'asset.location.latlng$near' => [$a, $b]},
            {'asset.location.latlng$near' => [$c, $d]},
            {'asset.location.latlng$near' => [$e, $f]}
        ]
    ],
    limit => 100
);

Needless to say, manually producing the code to query the database would be a bit more involved. Another noteworthy feature is that the query-builder object is chainable which allows you to create classes that will return a result-set.

For example. Considering the aforementioned scenario.

package MyApp::Inventory::Assets;

use MongoDB::QueryBuilder;

has 'query';
sub _build_query { MongoDB::QueryBuilder->new }

sub has_been_inspected {
    my $self = shift;
    $self->query->and_where('asset.location.bin$ne' => undef);
    return $self;
}

sub is_located_near {
    my $self = shift;
    $self->query->and_where('asset.location.latlng$near' => [@_]);
    return $self;
}

sub limit {
    my $self = shift;
    $self->query->limit($_[0] || 100);
    return $self;
}

package main;

my $assets = MyApp::Inventory::Assets->new;

my $cursor = $assets->limit(25)->has_been_inspected;

while (my $asset = $cursor->next) {
    say $asset->{serial_number};
}

.. I rushed through the demonstration, sorry. I’m extremely busy these days. I hope this module will be of as-much use to others as it is to me (at-the-moment).

The end.

Form Rendering: Why Do We Even Bother?

2013-01-02T12:27:01Z

Over the holiday I decided to do some development work even-though I had promised myself I wouldn't work on any open-source projects until all my commercial projects were completed.

I was bored, and since the alcohol and party-favors had lost there seductiveness, I thought I might revisit my super-secret-open-source-software-todo-list (we've all got one). I was looking for something complex enough to hold my interest yet simple enough to implement or at-least get a proof-of-concept out.

Since I've been doing a bunch of work on Validation::Class lately, I decided to work on an idea for a form field rendering plugin. First I'd like to exclaim, "I hate all-inclusive-html-form-handling-libraries", maybe not hate them but I strongly disagree with the premise upon which they are built.

Validation::Class::Plugin::FormFields is a plugin for Validation::Class which can leverage your validation class field definitions to render HTML form elements. Currently, the plugin is intentionally lacking in sophistication in an attempt to take as few liberties as possible (taking liberties is what makes most form renders suck).

Validation::Class::Plugin::FormFields is not an HTML form handler, nor is it an HTML form builder, renderer, construction kit, or framework. It merely renders a single HTML element at-a-time with as-little-markup-as-possible using the state of the associated validation class to maintain the state of the HTML form field.

Why render fields individually and not the entire form? HTML form handling is a heavily opinionated subject and the following reflects my opinion. HTML form rendering (done literally) has too many constraints and considerations to ever be ideally implemented. Consider the following; It's been tried many many times before and there are many different libraries as a result; It's never done quite right; There are too many conflicting contexts (e.g. css, js, security and identification, etc), i.e., CSS wants the form configured a certain way for styling purposes, JS wants the form configured a certain way for introspection purposes, the APP (and possibly the form renderer) wants the form configured a certain way for processing purposes, etc.

So why do we continue to try? "HTML forms are like werewolves and developers love silver bullets"(tm), but bullets are actually made out of lead, not silver. So how do you kill werewolves with lead? Protip, not by shooting them, obviously. I'd argue that we never really wanted complete form rendering anyway, what we actually wanted was a simple way to reduce the tedium and repetitiveness that comes with creating HTML form elements and handling submission and validation of the resulting data. We keep getting it wrong because we keep trying to build on top of the same misconceptions.

An HTML form is predominantly a UI by-product, and in large organizations (especially those which have segmented UI/ENG development teams) an HTML form and it's structure, layout, and markup are typically determined by the UI developers. Many HTML form renders are not viable simply because they impose UI decisions or require to much engineering to conform to the UI specifications.

So maybe we should backup a bit and try something different. In my opinion, the generating of HTML elements individually is much less constrained and definitely much easier to implement.

A Killer Feature for Mojolicious

2012-12-23T17:52:06Z

I just thought of a truly killer feature for Mojolicious. You are undoubtedly asking yourself why I don't just share this with the Mojolicious team on IRC or GitHub, etc. Most of you undoubtedly already know the answer to that, but I digress.

Many shops that I've worked with have this concept generally referred to as content-injection or template filtering depending on how you go about it. It is basically a means of hooking into template rendering after the template has been rendered but before it has been output (or otherwise used by the application).

The problem this solves is that some things are best left to be handled by the template, while other things are best done by using regex or a DOM parser.

I believe Mojolicious is at a unique advantage to offer something like this out-of-the-box because it has it's own templating system -and- it's own DOM parser. An example of a mojolicious template using the technique I'm describing could be as follows:

__DATA__

@@ alter_me.html.ep


  
    Alter me!
  
  You've been altered.


% filter begin
% my ($c, $dom) = @_; # is passed the DOM parser using rendered template
  $dom->at('title')->replace_content('because I can');
% end

@@ further_convince_me.html.ep


  
    Convince me!
  
  
    
  


% filter begin
% my ($c, $dom) = @_;
  $dom->at('#industry option[value*="'. $c->param('industry') .'"]')->attrs(selected => 'selected');
% end

Say it once, Don't Repeat It

2012-12-08T11:19:56Z

The following is a story about me (you can call me "guy") who was working as a
consultant on-location (we can refer to as heaven) where he had an interesting
conversation with one of the lead system architects (herein after referred
to as God).

One day, Guy explained to God that the webapp has many parameters hitting it,
some of which are actually the same types of parameters but with varying and
arbitrary names, and that while there's is no realistic way to stop the Angels
from creating templates with parameters named however they choose, Guy suggested
to God that he use Validation::Class to help organize/standardize the
handling of parameters in the webapp and specifically leverage it's automatic
handling of parameter aliases. God chuckles, "but that would suggest that we
would need to create two definitions describing the same piece of data" said God
referring to the existing Moose attribute definitions, and the proposed
Validation::Class field definitions. I tried to talk to God about context and
how different rules apply at different layers but god is ... well God. The
following is much of what was discussed when I last talked to God.

Before I begin, I'd first like to regurgitate a statement from the Validation::Class
whitepaper which reads, "A data validation framework exists to handle failures,
it is its main function and purpose, in-fact, the difference between a validation
framework and a type-constraint system is how it responds to errors. There are
generally two types of errors that occur in an application, user-errors which
are expected and should be handled and reported so that a user can correct the
problem, and system-errors which are unexpected and should cause the application
to terminate and/or handling the exception. Exception handling is the process of
responding to the occurrence, during computation, of exceptions (anomalous or
exceptional situations).".

For the readers that may not already be aware, your OO system is NOT a
user-input validation mechanism nor should it be used as such.

The following is just one of many cases to be made about why you shouldn't use
your OO system for user-input validation.

A "field" in Validation::Class is not the same as an attribute in an OO system,
i.e. in Validation::Class fields are never required to be present. This means
that any field in a class can be validated individually or in concert with any
other field(s) which is very useful. In order to achieve this with an OO system
you would need to either make all attributes optional or make required attributes
able to accept undefined values. Both choices leave you making a poor design
decision. Consider the following OO configuration:

# has 'a'
# isa 'maybe|Str'
# required

# has 'b'
# isa 'maybe|Str'
# required

In order to validate (a or b) independently I would be forced to declare
both attributes as optional or (if undef values are accepted) have the calling
class determine which arguments are missing and fake them as both would need to
be present at the time of instantiation, even if as undef. There are a few more
approaches I can think of, none of them ideal. Needless to say that by making
all attributes optional you've effectively bypass the single point-of-validation;
I hope that statement is self-explanitory.

Alternatively, and I imagine more commonly, you could define your class
normally, throw in some coercions, trap and massage exceptions, then report
those "exceptions" to your users (poor saps), and hopefully you app is only
localized for one language or your could design your exception traps to be aware
of the end-users language and throw localized exceptions. And if you're doing
all that then you're basically rolling your own validation framework and that's
just awesome, .. and I'm sure you've covered every nuance and consideration :}

Consider the following V:C configuration:

# field 'a'
# required

# field 'b'
# required

No field is required to be present and there is no single point-of-validation,
i.e. the validation logic is not in the constructor and because it is separate
and accessible as a function on the class we can validate and re-validate at-will.

For the sake of clarity, I use the phrase single-point-of-validation to mean
that, in an OO system, technically once you get pass the constructor each method
assumes the data remains valid, even if the data has passed through multiple
methods which manipulates the data, and there is no way to recall the validation
logic in the constructor (afaik).

... So that was a long-winded explanation of the obvious, OO-type-contraint
systems are not practical for user-input validation and definitely not as practical
as a "real" validation library, like Validation::Class. But you already knew that.

Just the other day, Mithaldu explained to me that re-usability of Validation::Class
is one of it's greatest strengths but he didn't think I touched on it enough in
the documentation, especially in the form of an example.

I explained to him that Validation::Class was created around the philosophy of
"Say it Once", i.e. to declare validation rules once, use them anywhere/everywhere.
I told him that once your defined a validation class using the keywords (sugar),
you could use the single class to validate data in your webapp controller,
model, command-line scripts and even on the client via JavaScript, and anytime
the validation rules change, so will these affected areas. He said, "Next time
lead with that", and then he challenged me to put together a small program that
showcased my claims.

So here it is, the following is a minimalistic example of a micro webapp using
Validation::Class on the client and server.

github: https://github.com/alnewkirk/dry.cgi/blob/master/dry.cgi
demo: http://sandbox.anewkirk.dev.ana.io/

* dry.cgi uses a single validation class to validate a mojolicious-lite app
parameters on both client-side and server-side. We could also use the validation
class as a buffer for our data model.

Candy-Coated Data Validation; Codename: ShuhgaBear

2012-12-05T03:10:36Z

2-CENTS

This week, in the intertubes, I came across a Node.js validation library which seemed to be popular amongst "those people". At-a-glance, as far as validation libraries go, I didn't think it was that well done, but I must admit to noticing a certain appeal in the expressiveness of the design which I suppose is due largely to that fact that its a JavaScript library.

Anyway, I decided that it would be cool to try and mimic the expressiveness while using Validation::Class as the foundation. It started as a feature-branch on Github but I was amazed at how quickly the concept came to fruition. The results is a module called Validation::Class::Simple::Streamer which has been added to the master-branch on Github as an optional experimental addition to the distribution.

Why? Validation::Class is design for a codebase that desires to be optimized and take advantage of compartmentalization and reusability, etc., though it requires some forethought and configuration. Validation::Class::Simple was added to provide a "container-class" to allow developers to use Validation::Class they way they would a traditional data validation library, in an ad-hoc fashion not interested in the advanced setup, etc. Validation::Class::Simple::Streamer was created because its a simple, maybe even fun, way of validating data and offers a low barrier-to-entry for people that don't care to configure the full framework.

SYNOPSIS

use Validation::Class::Simple::Streamer;

my $params = Validation::Class::Simple::Streamer->new($parameters);

unless ($params->check('email_address')->length(3)->email) {
    # validated login, password and email_address
}

unless ($params->check('home_phone')->telephone) {
    # validated login, password, email_address and home_phone
}

$params->check('password');

# be as expressive as you like
ok() if
    # validates login, password, email_address and home_phone
    $params->max_length(15) &&
    $params->min_symbols(1) &&
    $params->matches('password2')
;

# using your own workflow
$params->check($_)->filters('trim, strip') for qw(login password);

# are you of legal age?
if ($params->check('user_age')->between('18-75')) {
    # access to explicit content approved
    # validated login, password, email_address, home_phone and user_age
}

# validate like a boss
# THE END

DESCRIPTION

Validation::Class::Simple::Streamer is a simple streaming validation module that makes data validation fun. It is built around the powerful Validation::Class data validation framework via Validation::Class::Simple.

This module is/was inspired by the simplicity and expressiveness of the Node.js validator library, https://github.com/chriso/node-validator, but built on top of the ever-awesome Validation::Class framework, which is designed to be modular and extensible, i.e. whatever custom directives you create and install will become methods on this class which you can then use to enforce policies.

GITHUB LINK

http://goo.gl/2sZvu

MISC BANTER

[19:55] * Now talking to ironcamel
[20:49] anewkirk: speaking of Validation::Class, I just added a new feature called simple-streamer
[20:58] ironcamel: can you give me a summary of what it does
[20:59] anewkirk: sure, it allows you to define rules as-you-go and in boolean-context it calls validate for you automatically
[21:00] anewkirk: imagine a dancer plugin
[21:00] anewkirk: that exports a method named check()
[21:00] anewkirk: ... and then in your route handler you simply say
[21:01] anewkirk: return '/dashboard' if check('login')->required->min_length(5)
[21:01] anewkirk: you're not pre-declaring rules at this point
[21:01] anewkirk: and that code actually works
[21:01] ironcamel: unless ($params->check('home_phone')->telephone) {
[21:02] ironcamel: what is ->telephone() and who defines it?
[21:02] anewkirk: telephone is the directive
[21:02] anewkirk: as in ....
[21:02] ironcamel: it is a built in thing?
[21:03] anewkirk: field home_phone => { telephone => 1 };
[21:03] ironcamel: what?
[21:03] anewkirk: check out https://github.com/chriso/node-validator
[21:04] anewkirk: it node.js validation library
[21:05] anewkirk: I was inspired by HTML::Zoom also -- https://metacpan.org/module/HTML::Zoom
[21:06] anewkirk: which mst calls a streaming template engine because you're not really manipulating the template until its rendered
[21:06] anewkirk: basically the functions build-up instructions which all get executed once you call render
[21:09] anewkirk: its a play on the literal definition of streaming
[21:09] anewkirk: ok, so check('foobar')->required->min_symbols doesn't do any validation, those functions simply queue-up instructions
[21:09] anewkirk: so its kinda streaming the validation event
[21:09] ironcamel: maybe Validation::Class::Simple::Sugar would be better
[21:10] ironcamel: i don't get it
[21:10] anewkirk: but its not really sugar
[21:10] ironcamel: are you thinking it is streaming because you are chaining method calls?
[21:10] anewkirk: the chainable nature of the functions makes it stream-like, yes
[21:10] ironcamel: it kind of is sugar
[21:10] anewkirk: well ...
[21:10] anewkirk: maybe
[21:11] ironcamel: because ->length(3) is sugar for (length($foo) eq 3)
[21:11] ironcamel: *==
[21:11] anewkirk: yes and no
[21:11] ironcamel: chaining functions has nothing to do with streaming
[21:12] anewkirk: i know, its a play on the concept of streaming
[21:23] ironcamel: i would probably use Validation::Class::Simple for most of my own personal projects
[21:24] ironcamel: so it almost seams like the streamer thing should be Validation::Nodeish
[21:24] ironcamel: Validator::Node
[21:24] ironcamel: yes
[21:24] anewkirk: oh god no hahaha

Validation::Class: Released version 7.900001

2012-12-02T17:26:31Z

I wanted to formally annouce the release of Validation::Class, as of version 7.900001 the codebase is dramatically different though it maintains backwards compatibility at about 95%. The following is the current complete list of core directives (validation rules). As stated in the documentation, the purpose of the core directives is merely to provide a reasonable layer of protection against bad/malformed data and validators are not very sophisticated. e.g. the email directive does not perform a host lookup, etc:

alias           - handles parameter aliases
between         - handles numeric range validation
city            - handles city/area validation for cities in the USA
creditcard      - handles validation for credit cards
date            - handles validation of simple date formats
decimal         - handles validation of floating point integers
default         - hold the value used if no parameter exists
depends_on      - validates the existence of dependent parameters
email           - checks the validity of email addresses
error           - holds the error message that will supersede other errors
errors          - used internally
filtering       - specifies pre-or-post filtering per field
filters         - specifies list of filters per field
hostname        - handles validatation of server hostnames
label           - holds a user-friendly string (name) representing the field
length          - validates the exact length
matches         - validates that dependent parameter values match
max_alpha       - validates the length of alphabetic characters
max_digits      - validates the length of numeric characters
max_length      - validates the length of all characters
max_sum         - validates the numeric value
max_symbols     - validates the length of non-alphanumeric characters
messages        - holds error message which will supersede class-level messages
min_alpha       - validates the length of alphabetic characters
min_digits      - validates the length of numeric characters
min_length      - validates the length of all characters
min_sum         - validates the numeric value
min_symbols     - validates the length of non-alphanumeric characters
mixin           - specifies list of mixins to merge
mixin_field     - specifies list of fields to merge
multiples       - validates whether multi-value parameters are expected
name            - used internally
options         - enumerated list of values to be validated against
pattern         - handles validation of simple patterns and complex regular expressions
readonly        - ignore parameter values
required        - validation of supply and demand
ssn             - validation of social security numbers in the USA
state           - handles state validation for states in the USA
telephone       - handles telephone number validation for the USA and North America
time            - handles validation for standard time formats
toggle          - used internally
uuid            - handles validation of globally/universally unique identifiers
validation      - execute user-defined validation routines
value           - hold the absolute value
zipcode         - handles postal-code validation for areas in the USA and North America

Check it out on MetaCPAN.

If you like it, like it, follow it, etc. If you hate it, let me know why, please.

Thanks.

If you are interested in helping me extend the library by creating your own directive classes, contact me socially, IRC (anewkirk|anaio), or checkout the directives base class.

Operate with Impunity

2012-11-26T08:38:27Z

I am 99.9999% done with a complete rewrite of Validation::Class. I have also written a decent amount of documentation on how you should use the library and why you should use the library.

Within the documentation you can also find a whitepaper that offers insight into the rational behind the framework and why it was created. This project has become a fascination of mine over the past year as I've used it in many personal projects and client projects and have been inspired to continuously innovate.

Currently, the core feature-set consist of self-validating methods, validation profiles, reusable validation rules and templates, pre and post input filtering, class inheritance, automatic array handling, and extensibility (e.g. overriding default error messages, creating custom validators, creating custom input filters and much more). Additionally, I hope to present some of my plans for the future of this project at one of the upcoming conferences (though I'm not as plugged-in as I'd like to be).

For those of you that don't know, lately I've been contracting with Rent.com which is (IMHO) one of the nicest Perl shops around. They have really cool and intelligent people there (this is a non-biased statement, honest). Anyway, I just wanted to mention that during my last trip there (Santa Monica, CA), I had the pleasure of attending a local Perl mongers meetup where I talked-shop with a great group of guys that share my passion for Perl programming, ... which was really cool.

Anyway, I've become a bit of a data validation nut (obviously) and I've been letting it drive app development, and I haven't been disappointed. One of my near-future plans for Validation::Class is to ship with the ability to allow parameters to propagate objects (I'm talking about coercion for you Moose-heads). Validation::Class could effectively become a sweet coercion framework for Moose-based classes (and other object systems).

The following is an excerpt from the whitepaper which you can view here on github for the full-paper. For a simpler introduction with less-fluff, checkout the markdown for Validation::Class::Simple here.

INTRODUCTION

This whitepaper will serves as a guide to help readers understand the common data validation issues as well as the the rationale and various usage scenarios for Validation::Class.

Data validation is an important aspect of every application yet it is often overlooked or neglected. Data validation should be thought of as your data input firewall, a layer that exist between the user of your application and the application's business objects.

DATA VALIDATION PROBLEMS

The most common application security weakness is the failure to properly validate input from the client or environment. Data validation is important because it provides security, it allows you to ensure user supplied data is formatted properly, is within length boundaries, contains permitted characters and adheres to business rules.

To understand the problem domain we need to first understand:

what is meant by data validation
what the standard validation types are
what the common use-cases are were validation applies

First, data validation is the process of auditing a piece of data to ensure it fits a specific criteria. Common data validation checks are:

existence checking
range checking
type checking
list-lookup checking
dependency checking
pattern checking
custom validation checking

Typically when designing an application we tend to name input parameters in an arbitrarily fashion and validate the same data at various stages during a program's execution (duplicating logic and validation routines) in various places in the application stack. This approach is inefficient and prone to bugs, inconsistencies and security problems.

Data can be submitted to an application in various formats and it is not always ideal, and the option to pre-format the data is not always ideal or even possible. A few common use-cases were validation is required and often fails (in a big big way) are as follows:

handling arbitrarily and/or dynamically-named parameters
handling input for batch-processing
handling multi-type parameters (array or scalar depending on context)
handling complex conditional validation logic
handling multi-variant parameter names (aliases)
handling parameter dependencies
handling errors (reporting messages, localization, etc)

A DATA VALIDATION SOLUTION

A better approach to data validation is to first consider each parameter hitting your application as a transmission fitting a very specific criteria and construct a data validation layer that operates with that in mind (e.g. exactly like a network firewall). Your data validation rules should act as filters which will accept or reject and format the transmission for use within your application.

A proper validation framework should allow you to model data and construct validation objects with a focus on structuring rules, reusing common declarations, defining input filters and validating data. Its main purpose should be to properly handle data input errors. It's ulterior motive should be to ensure consistency and promote reuse of data validation rules.

Sexual Harassment?

2012-09-13T22:57:05Z

package Company::Connection;

use Moose;

...

sub connection {

my ($self, @args) = @_;

# @Linda: I hope this isn't creepy but if you're reading this I just
# want to say I think you're awesome and we should go out on a date
# sometime soon. Do you agree [Yes/No] -- Matt

# ps. do not commit this class to the master branch!!!

...

return $self;

}

Les Misérables

2012-09-09T13:45:21Z

09:41 < alnewkirk> sooo fucking frustrated
09:41 < alnewkirk> but actually ....
09:41 < alnewkirk> this line just save-my-sanity -- https://metacpan.org/source/XSAWYERX/Dancer-1.3100/lib/Dancer/Template/TemplateToolkit.pm#L37
09:42 < alnewkirk> I couldn't figure out why my TT rendering engine was outputting nonsense (1hr of head-scratching elapsed), so I figured I'd see how Dancer was doing it
09:42 < alnewkirk> I missed the problem a few times because I didn't pay attention to the comment in the code

Better, Faster, Funner - Part 1

2012-06-28T23:40:41Z

I've recently started working on a new web app project using all sorts of latest-and-greatest techniques and libraries, needless to say I choose Perl to build it out. The architecture of this application is different from what I'm used to but I like the direction I'm headed, everything seems to be in order, so I'd like to share my thoughts, struggles and accomplishments.

The WAF (web app framework) I choose to develop around this project is Dancer, although I've been away from Dancer and its community since before version 1 was officially released I decided to use it because, quite-frankly, it has nice and robust documentation, sensible defaults, and does exactly what I need it to with minimal code. You may have noticed that I neglected to mention the framework's plugin ecosystem, which IMHO is not preferred for large/growing projects.

The Hub

I've designed the application main module (root class) to be "the source of truth" for the entire application. This means that the root class is responsible for providing access to configuration options in an object-oriented fashion, allows switching between configuration profiles, writing to disk and providing absolute path information using Self::Dir. Some hackery and caching is needed to convince Dancer to switch configuration profiles during runtime.

The 2-Step (Not the Dance)

Like many other wishful thinkers I wanted the app to be completely self-contained and deploy-able with minimal fuss. After days of tinkering and rethinking botched deployments I came up with a simple 2-step system for deploying the app based on my typical work-flow.

I created two Perl scripts in the app root, setup-server and setup-application, both of which should be self-explanatory but allow me to elaborate. The requirements for the scripts are as follows:

The setup-server script should be executed first in the install process, it only requires that Perl 5.8+ be installed. I stringifies lists (arrays) of dependencies (system dependencies (build-essential, cpanm, etc), system cpan dependencies, local dependencies, system commands, etc) to be installed/executed in a particular order. This ensures that the server has the requirements need to run the next script, setup-application.

The setup-application script creates config files for various servers (web servers, databases, etc) and installs them in the assigned locations then starts/restarts the respective daemons. The magic CPAN library that makes creating, starting, stopping, and restarting services fun and stress-free is Ubic (especially when ran as root). Ubic is just pure awesome, it allows me easily add services to my application during a development iteration and have it just work when I re-deploy the app. I install each service to be executed via Ubic::Service::SimpleDaemon which has the added benefit of being automatically restarted on failure.

Stuck Between a Rock and a Hard Place

I've recently started evaluating libraries to provide form rendering, validation, general OO, and data storage.

Because I like using Validation::Class (which I authored) so much, for me the obvious choice was Validation::Class::Plugin::FormFields (which I also authored) though it has a sort of rigidness and inflexible to it, the type rigidness that can be found in all form rendering tools that rely on templating system like Template::Toolkit.

So I decided to use Validation::Class with ::Plugin::FormFields anyway and refactor it to make it better. I came to the conclusion some time ago that rendering forms in their entirety is too complex and specific to get right for all or even most use-cases, and an admirable compromise would be to provide an easy and intuitive interface to process and render form elements/fields individually.

So what does a better HTML form rendering engine look like? The following are code samples of the refactored V::C plugin I'm working on:

# $model is your V::C class instance

my $form = Validation::Class::FastForm->new(
    model => $model
);

# renders the login field as an HTML5 form input
# with data-minlength/maxlength, placeholder, etc
# and output the result

$form->render('login', 'text');
$form->render('login', 'email');
$form->render('login', 'date');
$form->render('login', 'number');

# alter you form field using css/xpath selectors
# and output the result

$form->process('login', 'text')
->change('input@type'  => 'password')
->change('input@title' => 'Please enter something here')
->data;

$form->dataset('user_type', [
    { text => 'Buyer',  value => 'buyer' },
    { text => 'Seller', value => 'seller'},
]);

$form->render('user_type', 'radio');
$form->render('user_type', 'checkbox');
$form->render('user_type', 'select');

$form->process('user_type', 'radio')
->change('select@multiple' => 'Yes')
->data;

These are working examples (currently) and hopefully give you a visual of the direction I'm heading in. If you feel the API for this form rendering engine is simple and easy-to-use, thanks, this simplicity was born out of frustration and providing this simplicity is bringing even more frustration.

I knew from the start I wanted to inline the templates and allow them to be extended and overridden per instance. I started out using HTML::Zoom which is nice but has some limitation that I wasn't willing to patch to move forward. Some of those limitations were failure to parse simple xpaths/css-selectors, failure to handle null and undef in a DWIM fashion, and constantly blowing-up with difficult to trace error messages.

I then refactored the code to use Template::Semantic which requires XML::LibXML which is not always the easiest to install via CPAN. Template::Semantic is great at handling null and undef in a DWIM fashion but lacks the chainable goodness once utilized in HTML::Zoom. Template::Semantic also doesn't die with roaming error messages. One thing that is extremely annoying is that it doesn't automatically append pushable attributes (like class, etc), and it doesn't create missing attribute nodes on-the-fly either. ARGGGHHH.

So I wrote Validation::Class::FastForm as a subclass of Template::Semantic which uses a role that provides a chainable API and formats selectors and vars so that they append pushable attributes and create non-existent attribute nodes. YAYYY.

The only problem now is every transformer is a coderef (like HTML::Zoom) which makes processing slower.

-Al

Haven't Blogged in a While...

2012-04-12T00:56:37Z

... anyway, .. so today, this 11th day of the month of showers, April, 2012 the year of our Lord (take your pick), ... I've released my latest Kracken on the world.

World, meet Command::Do!

Idea: Untitled - "Free Meetup Service for Software Developers"

2012-03-26T06:47:24Z

Hi, I've been thinking of developing a free meetup for developers, if interested please take this survey - http://www.surveybuilder.com/s/LKbJsWGcgAA

CPAN as a Source for Startup Ideas

2012-03-22T17:24:58Z

I've been wanting to write this post for quite some time, while this doesn't explore the topic in detail it at-least gets it out of my head an into yours (hopefully).

CPAN (the comprehensive Perl archive network) is arguably the best thing about the Perl programming language. CPAN is a repository of Perl software libraries. CPAN is also a great source for startup ideas and has the benefit of providing pre-developed (and usually pre-tested) code to back the venture. The following is a quick mashup of modules and SaaS ideas, some of which already exist and some of which are waiting to be created.

Email-as-a-Service:
This is becoming increasing popular, the concept of outsourcing email delivery. I myself have had a similar epiphany and thus created Email::Sender::Server. With a little effort, wrapping this library with a RESTful API, you too could sell subscriptions to your very own Email-as-a-Service platform and compete with http://www.critsend.com/, http://www.postmarkapp.com/ and others. Also, see ironcamel's PostMail (Perl Email REST API) at https://github.com/ironcamel/postmail.

Shipping-as-a-Service:
Last year I helped a Canadian develop (helped release more than code) a cross-courier shipping API aptly named Shipment. Having previously worked for a company who needed to ship different things via different couriers from a single app, and having been charged with the responsibility of finding a software solution (preferably an web service) which could handle this integration (failed), I see an opportunity for a much needed service. The ability to create an app (e.g. e-commerce, etc) and outsourcing the shipping (cost calculation, labels, etc) is wonderful IMHO. Does this already exist?

There are other ideas I see/have but I don't have the time to really dig-in. Maybe we can fill-in the blanks commenting.

-Al