Jul 30, 2010

Creating new projects with dzil new and templates

Here I talked about creating a new catalyst project using a minting profile for Dist::Zilla. If you don't know how to create a minting profile read that first. I'm sure once you've tried that you'll agree that having a little bit more than the basics in a newly minted dist would be a good thing.

first we need to create our profile.ini correctly (note: if you've got [DistINI] plugin loaded you'll probably want to remove it) Now you can put any file in the subdirectory repo of your profile (if you leave out 'include_dotfiles = 1' then anything beginning with a . won't be included), and it can be a template using Text::Template. Dist::Zilla uses {{ }} for Text::Template Delimiters.

Let's start with adding a .gitignore file (if you're using git) we can create {profile}/repo/.gitignore the {{$dist->name}}* will exclude the directories and archives dzil creates on release and .build will of course ignore the .build dirctory.

Now for a more complex issue, creating a Changes file that has the the {{$NEXT}} variable in it to insert the date and such on build. Obviously you can format your Changes file however you want.

Now we want to create a much more complicated dist.ini All of the stuff between the first set of {{ }} is boilerplate mostly taken from the DistINI plugin so that we can use our settings from our config.ini, I really wish there were some convenience accessors for this. I also wish we had an arbitrary stash we could use in config.ini so I wouldn't have had to hardcode my username in this. I think it's all fairly self explanatory beyond that. Of course you can set up your dist.ini anyway you want. Also if you use this format you have to have your module's repo name on GitHub in camel case like it is on CPAN.

Jul 26, 2010

Don't Use Big Words

Next time, in promulgating your esoteric cogitations, or articulating your superficial sentimentalities and amicable, philosophical or psychological observations, beware of platitudinous ponderosity. Let your conversational communications possess a clarified conciseness, a compacted comprehensibleness, coalescent consistency, and a concatenated cogency. Eschew all conglomerations of flatulent garrulity, jejune babblement, and asinine affectations.

Let your extemporaneous descantings and unpremeditated expatiations have intelligibility and veracious vivacity, without rodomontade or thrasonical bombast. Sedulously avoid all polysyllabic profundity, pompous prolixity, psittaceous vacuity ventriloquial verbosity, and vaniloquent vapidity. Shun double-entendres, prurient jocosity, and pestiferous profanity, obscurant or apparent!!

** ** In other words, talk plainly, briefly, naturally, sensibly, truthfully, purely. Keep from slang; don't put on airs; say what you mean; mean what you say. And, don't use big words!"
I don't know where this came from originally, but I should also say... cut the technical jargon to a minimum. Not everyone knows everything you do and even if they know all the words laymans terms may be a better way of explaining it. Give an analogy, if they don't get it; Reduce it to the simplest possible terms.

P.S. I pissed someone off because I told them it wasn't my understanding that was the problem it was there ability to explain things simply, and then gave them a link to this. I did eventually get why X was a good thing in spite of the overcomplicated explanations.

Jul 25, 2010

Making re.pl usable

For starters I'm not a super fan of interactive shell's for non-system shells. I don't see the point as much. When I first tried Devel::REPL I didn't like it at all, compared to every other interactive shell I've used (with the notable exception of Oracle's SQLPLUS, which is the worst shell ever) it was an unfriendly toy not worthy of mention. I couldn't go up in history, there was no tab completion, and all in all the default output was ugly no colors or formatting. I noticed in the docs
By default the re.pl program looks for (all of the following code goes in this file)$HOME/.re.pl/repl.rc, and runs whatever code is in there as if you had entered it at the REPL shell yourself.
and that re.pl has plugins, I also noticed some strange syntax and what seemed to be overly complicated code for just getting a few things working. Sure the file supports perl, but do I really want to write full perl programs in an RC file just to use plugins?

Well fortunately it's not as complex as all that. First thing you want to do is set some good perl defaults. Since this is our private shell might as well get all the current features of perl. Of course if you want to have other modules always accessible load them here to.

Now lets get some sanity into the shell by using plugins for REPL. It's really much simpler than the docs say. Wow that's way easier than what any of the documentation describes.

Ok let's look at some plugins. First if your typing isn't perfect you've probably noticed that you can't use your up arrow to go back in history, to fix this you can enable Readline support by loading Devel::REPL::Plugin::ReadlineHistory like so, This will allow you to up arrow to go back through lines you've previously typed, which you can then edit just like your normal *nix shell prompt. This one thing makes re.pl about 100x less annoying.

But I wish I had some kind of tab completion so I didn't have to type so much. Hey there's a whole set of completion plugins, lets enable those too.

So the Keywords Driver allows you to type pri< tab > and it'll complete print plus showing you printf just like your *nix shell. LexEnv will allow you to auto-complete your variable names and so on. There are a few more besides what I mentioned here.

Next I'll mention the Colors plugin. You may have noticed when you enter code such as my $var = 'blah'; say $var; you get the output
blah
1
or the output text and return code. well if you enable colors the return code is now in green making it easy to distinguish between output and extra info.

Last but not least I'll mention DumpHistory, enabling DumpHistory allows you to Dump your input history to the screen or to a file.

Now we have a fully functioning, 'user' friendly, perl shell.

For your convenience here's my current file

Jul 23, 2010

Making secure recoverable Passwords (Part 2)

This has been prompted by Dave Jacoby's post on generating passwords and the fact that I've learned a new trick since my my first article in 2008; which you should read first (it's a prereq).

Some might point out that using a hex digest limits the characters that will be generated too much, do this then.

echo -n "date" | sum | base64

So let's say you have to change your password every month. Pick a day, let's say the second Tuesday of the month. Since your memory sucks write this down "Pipes on second Tuesday @ 5:08!". Sounds like an event reminder right? Here's your actual password algorithm for this month. First you want to has the 'second Tuesday of the month'.

echo -n "2010/07/12" | sha1sum | base64

which outputs

NTFhMTY4NmJkNWQyZmIzNWJlZTlmYmQxYzEwN2FjNGE1MjUyYjI1OCAgLQo=

So what was the rest of that reminder for? Now you're going to make it as good as random, take the first 8 characters 'NTFhMTY4' and insert a pipe '|' at the 5th character, resulting in 'NTFh|MTY4'. Now you have a 'good as random, but recoverable' 9 character password.

Given if you work with really clever people they might be able to figure it out if they know you use this kind of process. But I'm sure having read this article and my previous one you'll come up with something even better, but just as reproducible.

UPDATE:

I do not believe that anyone can seriously prove (after having read both articles) that you could crack this with anything less than a brute force attack. Because I've suggested inserting 1 or more characters into the final outcome, chances are those are anything in the 94 printable characters of ASCII. Yes you might limit the end possibilities but after seeing passwords that most people have... this makes you a hard enough target that no one is going to bother. Basically all assumptions that using this is bad revolves around someone knowing exactly what you do (so in reality it's probably only bad for me).

I should also note that my personal system encrypts passwords with a salted sha512 and I'm having trouble find a password cracking tool that can even try to brute force that.

UPDATE:

oh and just in case you forgot... no one is trying to brute force your password. Remeber this XKCD

Jul 21, 2010

Annoucing Template::Plugin::Haml

A few months ago we had an assignment in Web Server Admin to create a CGI page, of course the perl was just to print text not actually do anything more, but I decided to use CGI.pm just because I never had. The whole thing was nothing more than hello world.
and I thought, wow I can write all that html with just that? why can't I use that syntax as a templating language. Of course when I asked I got imbecilic responses of how bad CGI.pm was or how it used function calls is stupid. And I was put on to Template::Declare and another which I don't recall. Template Declare would be nice if it didn't require the templates to be in a Perl file.

At some point I discovered Haml, simple and shorter than writing out the full HTML, unfortunately it was still longer than the CGI syntax and whitespace sensitive. But I kept looking through it. it has variables, but no loops, conditionals, or includes. So for a templating language it's simplistic or immature. I got around to googling "Haml Perl" and found this on StackOverflow (of course without my post). I thought well, shouldn't be too hard to make Text::Haml into a Catalyst View or ... better yet a Plugin to Template Toolkit so we can get all the goodies Haml is missing.

After some bumps in the road, I managed to make a finished product.

Here's some code and its output

Since Haml is whitespace sensitive you have to be careful about how you strip (or don't strip) whitespace from TT code. Obviously this is a simple example, I have no idea how well this works in a larger codebase, and since there's no XS module for Text::Haml I don't know how well it performs. I hope it's useful for someone though.

Jul 16, 2010

A page for Perl WebHosts?

We need a page linked from Perl.org that says 'Get Hosted' (or something like that). The page will have a list of the top 10 Perl friendly web hosts on it. The top 10 will be determined by people with CPAN ID's voting it up or down (the use of CPAN ID's should prevent spammers from gaming the system like digg get's gamed). It could have in the listing, rank, # of positive votes, business name, site uri, technologies supported (e.g. cgi, fastcgi, mod_perl, plack, etc), and maybe starting price. Of course you should have a link to the complete list. Companies should be able to register themselves without getting a CPAN ID.

Just an idea for making it easier to find great Perl hosting.

Jul 10, 2010

I wish my would go away

I been thinking about it for a few days, and of course consider I know nothing about grammar parsing or how any of this works. I wish the my $var; syntax would go away... or at least be less necessary. In almost all cases you want a lexical variable and use strict; doesn't allow you to use $var anyways. So what'd I'd like to see is my become a mostly unnecessary reserved word, make $var a lexical variable by default, e.g. my $var; be the same as $var. my would only be needed for redeclaration's and back compat. It could be enabled with a pragma or something like use feature 'lexical';. There might be some reason I'm completely wrong or stupid, but this doesn't seem like a bad idea, and of course our, state, local would still need to exist.

UPDATE: the point of this would be to make variables lexically scoped by default as opposed to there current global default.

Jul 2, 2010

git workflows

If you use git and you're past the tutorial and using it for an actual project, I suggest you take a look at the workflows manpage as well. It will give you ideas on how to branch, merge, rebase and cherry-pick.

This has been a public service announcement, that is all.