SIGSTP

LaTeX: Included graphics resolution

2011-08-24T22:18:00.002+01:00

While most graphic files on the internet have a resolution of 72pixel/inch, you need to keep in mind that this resolution is often not suitable for printing. To illustrate that, let's take two images that have the same number of pixels (348 x 350):

One is set at 72pixels/inch:

And the other one is set at 144pixels/inch:

As you can see here, there's no way to tell the difference between them on the screen because your browser displays these images according to their sizes in pixels, regardless of their resolution.

Now if you write a LaTeX document that includes them both:

\documentclass{article}

\usepackage{graphicx}

\begin{document}

\includegraphics{lowres.png}

\includegraphics{highres.png}

\end{document}

Here's what you get as the resulting pdf:

As you can see, the original 72px/in image will appear 'too big', pixelized and blurry on your piece of paper, whereas the 144px/in one will be twice as small and keep its sharpness.

So don't hesitate to experiment with resolution when making LaTeX based documents.

That's all for today!

Implement Ajax actions using page slices [Part 2]

2011-04-02T14:09:00.000+01:00

Last time I discussed how to implement Ajax browsing using page slices] generated
at server side. If you haven't read that yet, I strongly encourage you to do so, cause there's little chance the rest of this post will make sense to you.

Read Part 1- Implement Ajax browsing using page slices.

This time we're going to apply the same technique, but we'll implement some actions. By actions I mean simple interactions for instance 'vote a comment up', or 'follow a member', 'delete an item' etc.. Any kind of interaction that does not require more than a click from the user in an Ajax interface.

For instance, on libsquare.net, if you are logged in, you can vote up or down any review that appear on the jQuery page:

So how do we implement that?

The pure HTML flow

First let's remember that page slicing is designed to allow us to implement things without JavaScript, so let's just do that. Here's the work flow of the vote up feature without any JavaScript:

The user clicks on vote up, he arrives on a page where the vote up is pre-selected, clicks submit and is redirected to the page review with the vote count updated.

Let's Ajax this!

First let's give a class 'do_vote_up' to our vote up link:

<a href=".../review/111/vote_up" class="do_vote_up">Vote up</a>

Then we need to give an ID and slice the container that contains the voting unit:

<div class="slice_container" id="review_vote_111">
<& /slice.mas , id => 'review_vote_111' &>
... Your vote display html code ...
<a href=".../review/111/vote_up" class="do_vote_up">Vote up</a>
...
</&>
</div>

Let's assume /review/111 is a page that always display the review with it's voting part.

Now we're only a small bit of Javascript away from the full Ajaxed feature:

$('a.do_vote_up').live('click', function(event){
event.preventDefault();
var a = $(event.target);
var container = a.closest('.slice_container');
var target_url = a.attr('href');
var result_url = target_url; result_url.replace('\/vote_up','');
// Post a vote up query to the voting URL.
$.ajax({
    type: 'POST',
    url: target_url,
    data: { vote: 1 , vote_submit : 1 },
    success: function(){
       // On success, reload the voting slice that now contains the updated vote.
       container.load(result_url,{ page_slice: container.attr('id') });
    }
});
});

Et voila, the vote up action is now Ajaxed. Implementing the same thing for the vote down is left as an exercise for the reader :P

Next time I'll be speaking about submitting forms and dealing with redirections in Ajax. Stay tuned and thanks for reading!

Slice your HTML to Ajax anything. [Part 1]

2011-02-21T20:20:00.002Z

There's roughly two ways of addressing Ajax on your website:

Designing your pages with Ajax in mind. This usually means you'll have a growing number of features that require JavaScript to work. The W3C recommendation specifies that you should provide JavaScript-less versions of your features. So it means you will have to develop your features twice to maintain accessibility. Sounds a painful thing to do.
Designing your pages without Ajax in mind. This means you design only good old pure html/params & forms techniques to animate your features. This is good for accessibility, this is good for testability, this is good for search engines because all your features are accessible via plain links. The only problem is... well there's no Ajax coolness.

But we're going to fix that, and it's not going to be painful at all providing you:

have got zero business logic in your rendering layer. Meaning each part of it is idempotent. This is hopefully the case when you use a MVC model for your application.
use a rendering layer that's capable of manipulating its buffer, and renders the whole page in this buffer before sending it.

For this post, I'll be using Catalyst as the MVC and HTML::Mason as the View layer. We'll focus on implementing Ajax results paging. (Other ajax aspects will be dealt with in later posts).

Principle of ajax page slices.

The idea of page slices came to me when I was looking at jQuery's load function. It's got a very convenient trick called 'load page fragments' that allows you to do stuff like:

$('#container').load('page_url?offset=2 #result_id');

It will look for an element having the id 'result_id' in the returned document and replace the content of #container with it. Here's a full example of html/javascript that implements this:

<div class="container">
<div class="result" id="result_id">
   <p>This is page 1</p>
   <p>item 1</p>
   <p>item 2</p>
   <a class="page" href="page_url?page=2">Go to page 2</a>
</div>
</div>
<script>
$(document).ready(function(){
   $('a.page').live('click',function(e){
   var a = $(e.target);
   var result = a.closest('.result');
   var container = result.closest('.container');
   container.load(a.attr('href') + ' #' + result.attr('id'));
   });
});
</script>

This does the trick on the client size but it doesn't save much time on the server side.
Plus it requires DOM parsing of the whole document to find the result_id element. Altogether, chances are that your ajax paging will be slower that a simple whole page reload. To fix that, we're going make the server output only the required slice for us.

Let the server do the work.

First let's have a look first at the intended client side code:

<div class="container" id="result_id">

  <p>This is page 1</p>
  <p>item 1</p>
  <p>item 2</p>
  <a class="page" href="page_url?page=2">Go to page 2</a>

</div>
<script>
$(document).ready(function(){
   $('a.page').live('click',function(e){
   var a = $(e.target);
   var container = result.closest('.container');
   container.load(a.attr('href'), { page_slice: container.attr('id') });
   });
});
</script>

On the server side, we need a technique to output only the required slice, discarding any previously generated HTML, and aborting the rendering so no more subsequent HMTL is rendered. In Mason, this is easily done by implementing a content wrapping component.
Here's how it looks in under Catalyst (the $c bit):

Component page_slice.mas:
<%args>
$slice_id
</%args>
<%init>
  my $requested_slice = $c->req->param('page_slice');
  if( ( $requested_slice // '' ) eq $slice_id ){
   # Discard any previously generated content,
   # output the content and finish rendering
   $m->clear_buffer();
   $m->out_method->($m->content);
   $m->abort();
}else{
   # This component is transparent
   $m->out_method->($m->content);
}
</%init>

Here's how to use this component in your page.mas:

% deal with param('page') to compute results and next page.
<div class="container" id="result_id">
<&| /page_slice.mas , slice_id => 'result_id' &>
  
% # Output the right results
% ...
  <a class="page" href="page_url?page=<% $next_page %>">Go to page <% $next_page %></a>
  
</&>
</div>
<script>
$(document).ready(function(){
   $('a.page').live('click',function(e){
   var a = $(e.target);
   var container = result.closest('.container');
   // Use the container ID as the slice ID.
   container.load(a.attr('href'), { page_slice: container.attr('id') });
   });
});
</script>

When clicking a '.page' link, a request will be sent with the param 'page_slice'. Thanks to this, the component page_slice.mas will output only the requested page slice, and this will populate the container.

Your paging will obviously works without JavaScript. There's no Ajax specific code at server side. This is:

Good for accessibility. Try using your paging with lynx. It just works.
Good for SEO. Our beloved search engines will crawl these links, even if they don't do Ajax.
Good for testing. Because Ajax is not needed to use your application, you can easily unit test your features from your web test suite.
Good for reliability. If for some reason your JavaScript is broken, the feature will still be available.

Of course this technique can be applied to any kind of browsing features: sorting, faceting etc..
Next time we'll discuss performing an action in Ajax, and managing Ajax redirections.

I hope you enjoyed this post, thanks for reading!

Avoiding encoding headache

2011-02-21T14:15:00.002Z

David Wheeler recently posted about encoding headaches. I'm not going to copy/paste my reply here, but the crux of it is:

Encoding is for i/o; in the Perl space, text must be Perl character strings.

I repeat:

Encoding is for i/o; in the Perl space, text must be Perl character strings.

Write that 100 times, display it next to your monitor(s), record it and play it whilst sleeping on your ipod for one week, have it tattooed on your fingers, and in no time you'll be known as the encoding guru in your company.

Some say MySQL does not have any sequences

2011-02-07T17:51:00.002Z

Not true, it's got only one, and it's per session:

select last_insert_id(last_insert_id() + 1);

To be reset like that:

select last_insert_id(0);

A few difficult things in application development

2011-02-01T12:01:00.063Z

Here are some thoughts I had about developing applications over the last months.

Maintaining documentation

Yeah I know what you think: nobody reads it, waste of time. People just click everywhere and see what it does. This is probably true for most of the geeks, but observing my parents using a computer taught me you need to document your application features. At least the less obvious ones.

Error reporting

The same way you can judge a restaurant by the look of its toilets, you can judge an application by the way it deals with errors. It's often a taboo subject, but every single customer will use it sooner or later (sooner in general). Give your application a first class feel: Implement error catching/reporting sensibly.

Making stuff contextual

This is an empirical law of application development: Whatever the complexity of the system is, there will always be a client saying 'Nice but if <a potentially always false large predicate)>, then the behaviour should be <something crazy no one will understand in one month time>'. At this point, this is an occasion to:
- Add nasty 'if' statements to the appropriate palces and slowly but surely f***-up your beautiful codebase. The client will be happy.
- Or refactor your application to implement this new stuff in an elegant way. This will take longer. The client will be happy - eventually.

In short: You're doomed.

Moving from single to multiple

Another empirical law of application development: Whatever you think should be unique will eventually need to be multiple. If you think about it, in nature there's no absolute 1-1 relationships between entities but only probabilities differences. For instance the likelihood of you having one nose is higher than the likelihood of you having one arm. Design for multiple stuff from the beginning to save you some pain in the future.

Complying with unicode.

Complying with unicode is at heart a simple matter of understanding that 'an encoding of the data', 'the data itself' and the 'glyphs to represent it on a piece of screen|paper' are different things. Unfortunately this is still challenging to get for a lot of P* language programmers. If you're used to "print whatever" assuming it "just works" in your english language environment, it's very likely you're wrong.

More thoughts to come in the future!

Fonts: Find font files by font family name

2011-01-07T17:11:00.001Z

Sometime you want to use a piece of software or a library, such as Imager Graph are not linked to the fontconfig lib. Because of that, you can't specify fonts by simply using their family name (Like 'FreeSerif' for instance).

So you need a way to resolve a font's family name to the full path of the font files on disk. Here's how to do it for the FreeSerif one:

$ fc-list -f "%{family} %{style[0]} %{file}\n" 'FreeSerif'
FreeSerif Bold /usr/share/fonts/truetype/freefont/FreeSerifBold.ttf
FreeSerif Medium /usr/share/fonts/truetype/freefont/FreeSerif.ttf
FreeSerif Italic /usr/share/fonts/truetype/freefont/FreeSerifItalic.ttf
FreeSerif BoldItalic /usr/share/fonts/truetype/freefont/FreeSerifBoldItalic.ttf

Maybe one day there will be a Perl module bound to the libfontconfig. Until there, a simple system call will probably do for me :)

EDIT 31st Jan 2011:

There's no -f option in older systems, you can also use

$ fc-list 'FreeSerif' file
/usr/share/fonts/truetype/freefont/FreeSerifBoldItalic.ttf:
/usr/share/fonts/truetype/freefont/FreeSerif.ttf:
/usr/share/fonts/truetype/freefont/FreeSerifBold.ttf:
/usr/share/fonts/truetype/freefont/FreeSerifItalic.ttf:

Perl: Avoiding the HTML::Mason/TemplateToolkit schism

2011-01-06T11:13:00.000Z

As a Perl web developer, I've been using HTML::Mason intensely for many projects. Over the past year, I've also been working with Template Toolkit as a rendering layer for a web application.

As always, choosing between two similar technologies seems to be mainly a matter of taste and yet another occasion for an holy war. To pacify the situation, let's try to figure out what are these beasts good at.

TT feels more simple.

Consider the following code:

[% IF customer.is_in('GB') %]
We'll ship your order by Royal Mail
[% ELSE %]
Sorry [% customer.firstname %], delivery will take a while.
[% END %]

It's much easier to understand for a non-programmer than the Mason equivalent:

% if ( $customer->is_in('GB') ) {
We'll ship your order by Royal Mail
% } else {
Sorry <% $customer->firstname() %> ...
% }

So here clearly, TT wins, although as a programmer, and specially as a Perl programmer, Mason also feels just fine. However, a designer or a configuration person will feel more at home with TT, as it resembles infamous visual basic excel macros.

Mason simplifies page composition.

Let's implement a set of pages, each with a specific title and content, but with the same structure (here just a navigation box). In fact the common bread of web development

Let's do it in HTML::Mason:

autohandler:
<html>
<head>
  <title><& SELF:title &></title>
</head>
<body>
  <div id="nav_box">...</div>
  <div id="payload">
% $m->call_next();
  </div>
</body>
</html>
<%method title>A default title</%method>

content1.html:
  <p>content 1</p>
  <%method title>Page Content 1</%method>

content2.html
  <p>content 2</p>
  <%method title>Page Content 2</%method>

etc..

Now let's do it TT:

page:
<html>
<head>
   <title>[% title || 'A default title' %]</title>
</head>
<body>
<div id="nav_box">...</div>
<div id="payload">
  [% content %]
</div>
</body>
</html>

content1.html:
[%WRAPPER page
   title = 'Page content 1'
%]
<p>content 1</p>
[%END%]

content2.html:

[%WRAPPER page

title = 'Page content 2'

<p>content 2</p>

[%END%]

From a programmer's point of view, HTML::Mason wins, as its inheritance mechanism allows much better simplicity, elegance and flexibility in page composition. In this example, I only considered a simple example that's possible to implement both in Mason and in TT, but for more advance use, the inheritance mechanisms (with call to PARENT (super) methods), and other Mason-isms largely beat the TT WRAPPER directive.

❧

From these two simple examples, it appears that HTML::Mason has got much more to offer to programmers, as it allows them to use Perl natively, use a fairly complete inheritance mechanism, and much more. On the other hand, what TT has to offer is definitely an easier and simpler solution for simple templating jobs.

To sum up:

- Use Mason where you need elegance and simplicity to build complex things.

- Use TT where the 'easier than Perl' feel is important, with a restricted set of directive to build simple things.

Perl: Separating the persistence and the business model layers - Part 1

2010-11-30T10:03:00.000Z

Today, thanks to modern Perl technologies a growing number of Perl project use DBIx::Class to access the database, and a MVC engine, such as Catalyst or other frameworks and a nice template engine to expose the application on the web. Usually, the framework tutorial assumes that you will use DBIx::Class to access and store your objects from your MVC controller. I think this approach is wrong for the following reasons:

- DBIx::Class is a perfectly fine ORM mapper but it's not a business model framework. You can add business code to the result Classes but what happens if you want to migrate some of your stuff to a NoSQL storage? Or change the way some stuff is stored in the DB. Things can and will get ugly.

- Dbic objects do not provide the flexibility you would need to implement common object oriented patterns. What if you want to use Roles, enforce interfaces, implement your own search facility? You'll eventually get so much application business code in your Dbic object that they will no longer look like dbic objects.

- Your web framework is directly fed with the ORM model, and because you want to code things quickly, you start putting business code in your controller, and this business code assumes you're using this or that ORM. And the rest will come. Web applications are difficult to test for regressions, especially if they use Ajax. Things will break without being detected before release, you will fix them quickly in your controller, and as time goes on, your shiny new application using modern Perl technologies will end up being as difficult to maintain as a good old CGI mud-ball.

- What if you want to turn your application into an API? Or if you want to make command line tools for quick administration, or for asynchronous runs? Well you can't. Because the your business logic is scattered everywhere, in all the layers of the application.

What we end up with this approach is our persistence layer and our MVC layer (and in the worst case our template layer) become polluted with a blob of sloppy hard to maintain business model code. Also the sad thing is that your business code IS your business' added value, so it shouldn't be considered polluting something else. I don't think MVC's and ORM's are designed to be the natural container of your business code. I think they should be kept, and loved, and used for what they are: an easy and fast way of making non-business related code thin and minimalistic.

Blob of business code longing for a home on its own

For the development of libsquare.net, I've designed a reasonably fast and easy solution to this problem. I'll be talking about it in the next part of this sequence.

XeTeX: Breaking long lines of Japanese (and Chinese) text.

2010-11-05T11:30:00.002Z

While LaTeX/XeTeX is very good at hyphenating Latin words, I recently came across the problem of overflowing boxes when attempting to typeset a long paragraph consisting exclusively of Japanese characters:

母親が育児を放棄した末、大阪市西区のマンションで幼い姉弟が亡くなった事件。多くの住民が異変に気づきながら、児童相談所（児相）に通報したのは１人だけだった。複数の人が通報していれば、児相の危機感も強まったかもしれない。なぜ通報をためらった

When you render this with XeTeX, you've got a warning that your hbox is overfull, and the rendered result shows an awful truncated Japanese line:

Rendering of an non hyphen-able Japanese line

We clearly need to fix this, because most of the time your data will be in the form of a long paragraph without any linebreaks.

In XeTeX-notes.pdf, we learn that we can activate the line-breaking in XeTeX by using:

\XeTeXlinebreaklocale"en"

The locale used doesn't matter much, the important thing is that it activates line breaking for too long lines where the hyphenation mechanism cannot do its job (a long Japanese/Chinese line for instance).

By adding this to your preamble, here's what you get:

A Japanese paragraph with line breaks.

Et voilà, lines are broken so all the characters fit in the page width!

Ps: Thanks to Google news Japan for providing example data.

Perl Postgresql Test Harness

2010-10-07T11:19:00.000+01:00

These days, I'm developing pg_cryobit, a piece of software that'll allow you to manage your PostgreSQL continuous backup strategy with ease.

I stumbled upon Test::postgresql, and at first I was a bit suspicious about it, given the fact the latest version is not recent and that there's no debian build of it.

I decided to give it a go anyway. I installed it manually, and only one dependency needed another manual install. The other ones come as a debian packages (This is one reason why I don't quite like to use the cpan shell).

The tests went smoothly, and in no time I had instances of PostgreSQL ready to test with my own software.

I definitely recommend using it if you're writing PostgreSQL dependent software.

Has anyone has experience with the MySQL flavour of it?

Bugs: Importance classification

2010-10-06T13:55:00.003+01:00

Dave Child recently posted his thoughts about bug/feature priorities and asked for contributions, here's mine :)

- Blocker: Prevent any operation on the system to happen.

For instance, your app server conf file is wrong, so it won't even start. Or there's a syntax error in one of your top template. This should never pass your test phase (if it does, you've got a problem).

- Critical: A major feature of the system is broken (or missing in case it's a feature ticket) and prevent the business from operating normally. This should never pass the test phase neither.

Example: If you've got an e-commerce website, the cart does not work, or the checkout is broken.

- Normal: A minor feature of the system does not work, or a major feature doesn't work in a particular case. This could pass the test phase, but it will hurt your reputation.

For instance, your 'share with a friend' link is broken, or the contact us page doesn't work.

- Minor: A subfeature does not work, or a minor feature is broken in a particular case. For instance, redimensioning a textarea doesn't work, failing to provide a valid email in the contact page voids your avatar photo. This could pass the test phase, but only a few of your clients will notice.

- Trivial: Do not prevent anything from working correctly, but still cam harm your reputation.

Example: No feedback to confirm a user has saved its preferences, spelling mistakes, weird ordering etc..

Using this classification, and if you've got an appropriate test plan, your clients should never be exposed to any bugs more important than Normal, ideally only Minor.

MySQL: Changing the order of a table column

2010-09-23T10:26:00.000+01:00

In an ideal purely standard SQL world, one should never have to care about the order of a table's columns. But we're not in an ideal world, and sometime we want to change the position of a table column. Here's how to do it:

ALTER TABLE mytable MODIFY column_move <WHATEVER TYPE IT IS> AFTER another_column

Note that you need to MODIFY the column with its exact type not to loose any data. Copy/Pasting is your friend here. You can also use BEFORE instead of after.

Version names brainstorming

2010-09-18T14:02:00.000+01:00

Recently we had a brainstorming session in the office to find ubuntu-style version names for our product. Here's my list of suggestions:

Anemic Antelope

Blistering Barnacle

Crying Crocodile

Dubious Donkey

Emotive Elephant

Fiddling Fugu

Grumpy Giraffe

Hairy Haddock

Introvert Impala

Jolly Jellyfish

Kitschy Kitten

Lubricious Lama

Mystical Magpie

Nyctalopic Nautilus

Operatic Oppossum

Persistant Pinguin

Quantitative Quahog

Refreshing Rodent

Suspicious Salamander

Tickling Tiger

Ultramarine Unicorn

Voluptuous Vixen

Witty Wapiti

Xenomorphic Xenopus

Yummy Yeti

Zooming Zebu

Sometime, software engineering requires a bit of poetry :)

Perl: How to release a developer only version to CPAN

2010-09-14T11:32:00.000+01:00

If you're about to release a new module and have some beta testers, it's probably a good idea to release a developer only version first and then switch it to a final version number after your beta testers (that includes you :) ) are happy with it.

To do that, simply appends the release candidate number at the end of your version number. To release the first dev RC version of version 0.07, simply do:

our $VERSION = '0.07_01';

In your main package.

The CPAN will detect it and make your release a dev release only.

LaTeX: Hyphenate single long words in narrow tabular columns

2010-09-13T18:14:00.001+01:00

Consider the following LaTeX code:

\documentclass{article}
\usepackage[english]{babel}
\begin{document}
\begin{center}
   \begin{tabular}{ | p{2cm} | l | l | p{5cm} |}
   \hline
   Incredibilidable & foo & bar & baz \\
   \hline
   \end{tabular}
\end{center}
\end{document}

When you render it, the first column overflows on the second one because 'Incredibilidable' is considered to be the first word of a paragraph, and LaTeX does not hyphenate first words of paragraphs. So here's what you get:

And this doesn't look nice.

To fix this, we're going to tell LaTeX our word is no longer the first of the paragraph. To do that, we insert a zero length horizontal space before it:

\hspace{0pt}Incredibilidable & foo & bar & baz \\

The rendering now turns into:

Et voila!