I wanted my default diff options in bazaar to be for side-by-side comparisons. This worked by editting my $HOME/.bazaar/bazaar.conf.
[ALIASES] diff=diff --diff-options "--width=200 --side-by-side"
18 Jan 2013
20 Nov 2012
Mojolicious One-liners
Posted by niczero under mojo | Tags: commandline, mojo, mojolicious, ojo |Leave a Comment
From Sebastian Riedel
perl -Mojo -E'say g("mojolicio.us")->dom("*")->pluck("type")->uniq'
perl -Mojo -E'g("metacpan.org/search?q=mojo")->dom("big a")
->pluck("text")->join("\n")->spurt("m.txt")'
perl -Mojo -E'say g("reddit.com")->dom("*")->pluck(attrs => "href")
->grep(qr/^http/)->uniq'
perl -Mojo -E'say r g("search.twitter.com/search.json?q=perl")->json'
perl -Mojo -E'a({json => {foo => ["bar"]}})->start' get / /foo/0
perl -Mojo -E'g("mojolicio.us")->dom("h1, h2, h3")->map(sub { $_->text })
->shuffle->join("\n")->say'
mojo get www.reddit.com/r/perl/ 'p.title > a.title' text
perl -Mojo -E'say a->text_field("foo", value => "bar")'
perl -Mojo -E'a("/:name" => {inline => "Hi !"})->start' get -v /foo
perl -Mojo -E 'a(sub { shift->render(json => {time => time}) })
->start' daemon
(See mojolicio.us/perldoc/ojo for more, and also the mailing list archives.)
20 Nov 2012
Authenticate user
From Ben van Staveren
validate_user => sub {
my ($c, $username, $password, $extra) = (@_);
if(MyUsers->login($username, $password) == 1) {
return $username;
} else {
$c->stash(login_error_message => 'Invalid credentials');
return undef;
}
};
load_user => sub {
my ($c, $uid) = (@_);
return MyUsers->get_user_data_for_username($uid);
};
And then you want to:
my $r = $self->routes->bridge('/')->to('login#check');
$r->get('/protected')->to('....');
The 'check' method in login can simply do this:
sub check {
my $self = shift;
return 1 if $self->is_user_authenticated;
$self->render('login_form') and return 0;
}
Anything now routed under $r goes through the login check. If you want "public" and "private" bits, do it like this:
my $public = $self->routes->any('/')->to('public_site#index);
my $private = $public->bridge('/')->to('login#check');
$private->get('/')->to('private_site#index');
Async page prep
From s at bykov.odessa.ua
$app->hook(
around_dispatch => sub {
my ($next, $c) = @_;
# grab a title from mojolicio.us
$c->ua->get(
'http://mojolicio.us' => sub {
my ($ua, $tx) = @_;
my $res = $tx->success;
my $mytitle = $res ? $res->dom->at("title")->text : "Error";
# stash
$c->stash(mytitle => $mytitle);
# Now we are ready
$next->();
}
);
}
);
Render pdf from memory
From Pavel Goloborodko
$self->res->headers
->content_disposition("attachment;filename=${name}.pdf");
$self->res->headers->content_type('application/pdf');
$self->render_data( $pdf );
03 Oct 2012
The workings of a Mojo::Base attribute
Posted by niczero under mojo | Tags: attribute, mojo, mojolicious, perl |Leave a Comment
When debugging code that uses attributes, as provided by Mojo::Base, it sometimes helps to visualise what its getter/setter actually looks like.
A getter/setter with defined default.
{
package MyClass;
sub my_attr {
if (@_ == 1) {
return $_[0]{'my_attr'} if exists $_[0]{'my_attr'};
return $_[0]{'my_attr'} = $default->($_[0]);
}
$_[0]{'my_attr'} = $_[1];
$_[0];
}
1;
}
A getter/setter without default.
{
package MyClass;
sub my_attr {
if (@_ == 1) {
return $_[0]{'my_attr'};
}
$_[0]{'my_attr'} = $_[1];
$_[0];
}
1;
}
You can see your own attribute definitions via
export MOJO_BASE_DEBUG=1 ./my_script eval 1 unset MOJO_BASE_DEBUG
20 Sep 2012
Mojolicious advocacy
Posted by niczero under mojo | Tags: advocacy, mojolicious, security |Leave a Comment
Obviously there is a lot of advocacy at mojocasts and mojolicio.us, but there are a lot of useful posts outside those channels, for example in PerlMonks and StackOverflow.
Security
Beginner apps with database
- Joel Berger illustrates powerful beginnings
- Joel Berger builds on that with a neat websocket example
When a director gives you a line reading that doesn’t feel right for your character, nod and agree with him or her, then do it the way you know your character would do it. If you’re an actor, always be true to your character; if you’re not an actor, have character, and always be true to yourself… Whatever you do, wherever you go, do something real, make a real product, provide a real service, do something of value. Create something of beauty. — Robert De Niro at Bates
13 Sep 2012
Create a debian chroot jail for testing
Posted by niczero under debian | Tags: chroot, debian, debootstrap, test |Leave a Comment
It is very handy to have a chroot jail for testing code snippets, packages, releases. This is on your (Debian) dev box, where you may have multiple installed versions of related libs. Before promoting your new code to Test or Staging, it can be a time saver to first test it in a pristine environment that can’t be affected by files outside the ‘jail’. For example, I have several versions of Perl installed on my dev box and several versions of EV around the place. When testing something against EV I want to be sure I haven’t omitted any dependencies and to be sure I’m testing against exactly the version I’m expecting. You should treat the jail as throw-away; keep in mind that you can (and should) delete and build a fresh one whenever the mood takes you. There are many online notes about creating one, but it is still hard to find any that tell you how to get it ironed out easily, eg to avoid confusing sessions that are inside/outside the jail.
Install packages
mkdir -p /opt/jail/mojo debootstrap wheezy /opt/jail/mojo
(and then wait a few mins while it downloads and installs). Then install locales.
chroot /opt/jail/mojo dpkg-reconfigure debconf # setting priority to 'medium' vi /etc/apt/sources apt-get update apt-get install locales less vim rsync locale-gen en_GB.UTF-8
That last line is to generate any locales that the previous line reported as missing; if you don’t see any such warnings (on the commandline) then none are needed.
Make it clear you are in jail
vi /etc/debian_chroot
giving it the jail name as content, in this example ‘Mojo’.
vi /etc/skel/.bashrc vi /etc/bash.bashrc
removing all instances of “@\h“, eg by doing “:%s/@\\h//gc” with repeated presses of y
adduser --ingroup users --disabled-password --gecos 'test user,,,' tester su - tester
and check that your commandline prompt shows the jail name and not the (parent) hostname. If you’re using an xterm you should also see its title change to something similar when you ‘sub user’ to ‘tester’. The remaining step for this section is to do likewise for ‘root’. The simplest way to do that is to copy the xterm lines from /etc/skel/.bashrc so that /root/.bashrc now has
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u: \w\a\]$PS1"
;;
*)
;;
esac
Now open a new xterm and test both user envs
chroot /opt/jail/mojo su - tester
checking that in both cases the xterm title and the commandline prompt are clearly different from those of the (parent) host.
(The rest of these notes are standard fodder for getting processes to work nicely.)
Mount Parts of Host System
Before installing more packages or running processes, you’ll need to integrate /proc
In /etc/fstab of the host box, I have a section for each jail
/dev/pts /opt/jail/mojo/dev/pts none bind 0 4 proc /opt/jail/mojo/proc proc defaults 0 4 sysfs /opt/jail/mojo/sys sysfs defaults 0 4
and then mount them manually (again as ‘root’ in the host box)
mount /opt/jail/mojo/dev/pts mount /opt/jail/mojo/proc mount /opt/jail/mojo/sys
Fake your mtab
You’ll find that df fails because the chroot has no /etc/mtab. Some people are advocating cat /proc/mounts >/etc/mtab but that is wrong, the partitions inside the chroot are in general completely different to those outside. In my case I give the missing file just one line
rootfs / rootfs rw 0 0
which does all that I want.
Set your timezone
You can manipulate /etc/timezone and /etc/localtime yourself, but the easiest way is to
dpkg-reconfigure tzdata
13 Sep 2012
… or living without perlbrew.
There are several advantages to building perl locally, my top five being
- Ensure you are using unthreaded perl
- Control where (this version of) perl is installed (with short paths)
- Customise the @INC path (with fewer components, simplifying debugging)
- Easily switch to test releases under different versions
- Stop pondering if you are getting best performance
These notes give a reliable route to getting what you always wanted (if what you always wanted was a customised perl). If all you want is a default build of perl redirect yourself to Perl README where you will find things are even simpler (even if you want to customise where perl is installed). These notes are for people who want to customise more than that (eg @INC), especially if they want to do that on more than one machine or for more than one version of perl.
The notes assume you’re on linux and using bash as your shell, but I’m confident it won’t be difficult to translate them to your environment. I have used them to build v5.12.4—v5.17.4 on different (linux) architectures without troubles (but it didn’t work on v5.10.1 and below). The sneaky bit is it helps if you have a couple of files from here.
where “x86-64″ is replaced by the arch identifier for perl (that one is for amd64). The most reliable way to produce it if you don’t have one is to
./Configure -es -Dprefix=/opt/perl/5.16.1
and manually answer each question. (You won’t have to do this again, unless new options are added in a future version of perl.) Then save the resulting Policy.sh to a filename like above and edit the file till it’s exactly what you want, then proceed as below.
A quick alternative to answering all those questions is to run it on ‘auto’ and then edit the resulting Policy.sh.
./Configure -des -Dprefix=/opt/perl/5.16.1 rm -f config.sh vi Policy.sh ./Configure -des -Dprefix=/opt/perl/5.16.1
Grab the wget line from Get Perl and unpack the archive into /opt/perl/build.
apt-get install build-essential cd /opt/perl/build/perl-5.16.1 cp /tmp/Policy.sh_x86-64_5.16.1 Policy.sh ./Configure -des -Dprefix=/opt/perl/5.16.1 diff /tmp/Policy.sh_x86-64_5.16.1 Policy.sh
If the paths in that diff are the same then you’re safe to proceed. But sometimes Configure fails to pick up Policy and the diff shows the paths still disagree. In that case
rm -f config.sh
then repeat the cp line and the lines that follow it.
Once the diff shows no disagreement about configuration, you’re safe to proceed.
make && make test && make install env -i /opt/perl/5.16.1/bin/perl -V
Then create an env var file
mkdir -p /etc/perl vi /etc/perl/perl.env
with the contents
p=/opt/perl/5.16.1
export PERL_MB_OPT="--install_base $p"
export PERL_MM_OPT="INSTALL_BASE=$p"
if ! which perl5.16.1; then
if [ "$(id -u)" -eq 0 ]; then
PATH=/usr/local/sbin:/usr/local/bin:$p/bin:/usr/sbin:/usr/bin:/sbin:/bin
else
PATH=/usr/local/bin:$p/bin:/usr/bin:/bin
fi
export PATH
fi
That works nicely in an environment where you have one ‘active’ perl at a time, and you only need to edit that file at upgrade time. If you test against multiple versions of perl, you’ll want to call that file /etc/perl/perl-5.16.1.env.
(That file is quite naive because it assumes perl is the only ‘special’ package on your box. You might want to use PATH=$p/bin:$PATH or something smarter.)
Then install a corresponding cpanm.
. /etc/perl/perl.env which cpan cpan App::cpanminus
Scripts then optionally pick up this new perl via
. /etc/perl/perl.env
which you should test with
which perl perl -V
You might want to edit your profile so that all new interactive shells automatically include perl.env. (I choose not to do that.)
At the head of scripts that should use this perl, you can use
#!/opt/perl/5.16.1/bin/perl
or probably better (more conventional and requiring less maintenance but relies on your PATH being set correctly)
#!/usr/bin/env perl
Once you’re happy with your new perl you might want to save disk space by deleting the .tar.gz file and doing make clean inside the build dir. You’ll certainly want to preserve your Polic.sh for posterity.
A couple of warnings:
- That /etc/perl/perl.env assumes you only have one instance of each version. If you have two instances, eg one threaded, one non-threaded, the if-clause will need to be made smarter.
- Watch out for $HOME/.cpan or $HOME/.cpanm growing overly big. It’s not something you want to include accidentally in your backups.
- I don’t follow the convention of having a redundant ‘perl5′ dir at the end of each path. My horrible workaround is to install with cpanm as usual and then run my unperl5 script which moves the contents of lib/perl5 to lib. If you don’t want to use that, the simpler option is to build perl with “/perl5” appended to each non-core library path. (eg /usr/local/lib/site_perl/perl5)
