Wednesday 24 August 2011

LaTeX: Included graphics resolution

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!

Saturday 2 April 2011

Implement Ajax actions using page slices [Part 2]

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!

Monday 21 February 2011

Slice your HTML to Ajax anything. [Part 1]

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">
<!-- This is the slice '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>
<!-- End of slice -->
</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' &>
  <!-- This is the slice 'result_id' -->
% # Output the right results
% ...
  <a class="page" href="page_url?page=<% $next_page %>">Go to page <% $next_page %></a>
  <!-- End of slice -->
 </&>
</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

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.

Monday 7 February 2011

Some say MySQL does not have any sequences

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);

Tuesday 1 February 2011

A few difficult things in application development

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!

Friday 7 January 2011

Fonts: Find font files by font family name

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:

Thursday 6 January 2011

Perl: Avoiding the HTML::Mason/TemplateToolkit schism

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.