Monday, 25 March 2013

Run Postgresql pg_dump from your scripts

If you use Postgresql, you probably noticed that the command line tools who come with it don't accept passwords on the command line.

That's a good thing, as it prevents other users of the system from spying your command line via ps and see your password.

Ok, but what if you want to run let's say pg_dump from your script? Easy, just export an environment variable PGPASSFILE that points to a file that contains your credentials. Note that this file MUST be in mode 0600, to prevent other users to look into it.

If you use Perl, and File::Temp, that's exactly what it does, so here's a Perl snippet that uses pg_dump:

my ( $cf, $cf_name ) = File::Temp::tempfile();
print $cf '*:*:*:*:'.$password."\n";
system('export PGPASSFILE='.$cf_name.'; pg_dump  etc...');
## Don't forget to unlink cf_name to avoid disk pollution.
unlink $cf_name;

Also, don't forget to run in taint mode and sanitise everything you use to build your command. Managing correctly the returned value of the system call is left as an exercise to the reader :)

Happy coding!


Thursday, 21 March 2013

Good old days Javascript

Good old days Javascript:

if( confirm('Are you sure?') ){ ... do stuff ... }

Modern days fancy Ecma script (abridged):

  1. Think a lot
  2. Write 100KB of untestable code
  3. Instanciate a factory.
  4. Build an anonymous function.
  5. Don't forget to hoist your variables.
  6. Fire a dozen async events in two different frameworks
  7. Don't forget to use .promise()
  8. Catch your events in a completely remote and random other place.
  9. Build a jQuery UI modal dialog with appropriate call backs
  10. Oh no, it's too slow in IE :(
  11. Go back to step 1.

Wednesday, 13 March 2013

Mason - A Template system for us programmers

Templating Modules are a bit like editors. Every web application developer has a favourite one. And every template system is someone's favorite.

Mine is Mason. But not because the Perl MVC tutorials are full of examples using Mason. Not because it's the fastest (use xSlate if you want to trade speed for flexibility). Not because it's the most popular. It's my favourite for a very plain reason: It makes me more productive and allows me to develop web GUIs using all the powerful features a programmer should biterly miss if they are taken away. That includes writing Perl code :P

I never heard of a business that went down because they didn't have fast enough CPUs, so I'm not fussy about trading a few CPU cycles for elegance, ease and speed of development.

Enough talking. Here's my contribution to the template holy war and Mason lobbying presentation:

Tuesday, 5 March 2013

One more (good?) reason to consider NoSQL solutions

Btw, if you're convinced by this video - I know this is very unlikely - , Seven Databases in Seven Weeks is the book you'll like to read. It's very well written and gives you just the right amount of information so you can build yourself a broad and clear vision of what major NoSQL technologies can and cannot do for you.

Saturday, 2 March 2013

The only bad thing about Mason

At the moment, I'm writing a presentation about Mason2. The goal is to somehow convince my colleagues to consider using Mason. Instead of Template Toolkit.
As part of it, I thought I'd do a bit of performance benchmarking against Template Toolkit. So I put together a reasonably complex mini set of templates using both systems. Well, as complex as TT can take in reality. Which is not very much.

But anyway, let's jump straight to the bad news.

        Rate Mason    TT
Mason  901/s    --  -51%
TT    1852/s  106%    --

As you can see, with similar settings (code caching enabled) and over 10000 runs of two pages, Mason2 is twice as slow as Template Toolkit. Mason2 is still below the millisecond per page in my benchmark, but still that's quite a big difference.

As the common wisdom goes, CPU time is cheaper than programmer time, so it shouldn't be a big deal, given the huge gains of productivity you should get by using Mason2's very cool and powerful features.

Stay tuned for the full presentation to come!

PS: To follow up on the comments, feel free to have a look at the benchmark source