If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
Here is article (in Polish language, but you will surely understand the first bar graph) http://interaktywnie.com/biznes/newsy/raporty-i-badania/tak-w-polsce-placi-sie-pracownikom-it-12414 that shows that Perl developers earn the highest salaries in Poland (50% more than PHP coders) 
The numbers on graph means: length of bar – monthly salary in polish złoty (currency) – divde by 4 to get values in Euro, percentage in pink box – percentage of that language users (perl – 5%)
I’m reading now a book by Dan Brown, author of “DaVinci code”, titled “Lost symbol”. It is mostly about masons. And it quite resemble the previous books by this author. Anyway, it is riveting.
This seemingly off-topic introduction leads to the on-topic perl thing: the mason. It is a “High-performance, dynamic web site authoring system” and “solves the common problems of site development: caching, debugging, templating, maintaining development and production sites, and more.” and “you can embed Perl code in your HTML and construct pages from shared, reusable components.”. Well, sound nice. How it looks? Like this:
(there was something wrong here. I removed it 
)
Sadly, the FAQ on the official page seems to be neglected and is spammed by merchants of medications made to make your weenie harder. On the other hand, newest version is 1.44 form Jan 4, 2010 - so it is still developed.
Assuming that I would like to learn something new, like "something big, modern, to easy make web applications - with templates, cache, scalability, quick development" should I dive into mason, or better look for something else?
So, I have question, asking YOU for an insight about this like:
- mason is cool, and at least better to do the same by your own from scratch
- forget it, it is so 1990's, learn catalyst instead
- forget mason and catalyst, learn PHP symphony (- no problem for me, I know PHP - more or less )
- ruby on rails is the real thing (no, I will not learn ruby - at least now )
- the best is framework .... (something not mentioned above)
Please write your opinion below. Thank you.
How to easily resize images (jpg) in perl? Use Image::resize
use Image::Resize; use autodie; $src = "bigimage.jpg"; my $old = Image::Resize->new($src); my $new = $old->resize(200, 300); # max dimensions $jpegdata = $new->jpeg(95); # jpeg quality open OUT, ">./smaller/$src"; print OUT $jpegdata; close OUT;
New version of perl – 5.11.3 was released. The next version will be (as they hope) 5.12
Waht is new in perl 5.11.3?
- Perl is shipped with Unicode version 5.2, itself released in October 2009.
- Perl can now handle every Unicode character property.
- The experimental ‘legacy’ pragma, introduced with Perl 5.11.2 has been removed. Its functionality has been replaced with the ‘feature’ pragma.
- Numerous CPAN “toolchain” modules have been updated to what we hope are the final release versions for Perl 5.12.0.
- Many crashing bugs or regressions from earlier releases of Perl were fixed for this release.
In my opinion is is very good, that perl 5 is still developed, as version 6 have still a long way to go, before it may be used (first, by enthusiasts, then by coders, next by big companies that need reliability and stability)
Here is a nice tool to convert for example different characters to percent encoding for URIs, 0x notation, decimal code points etc; (by Richard Ishida):
http://rishida.net/tools/conversion/
Ok, it is not strictly related to perl , but I guess it may be handy for people that were interested in the “utf at LAMP horror” cycle.
Continuing the never ending saga of perl / utf horror:
<form method=”post” accept-charset=”utf-8″ action=”…”>
Well, I never used it… and my web app works.
Is this accept-charset really needed? Do you know?
Horror with utf8 and LAMP ( perl ) web application contiunued:
We need to take care of mysql connection, so it is ut8 – ready:
if (my $dbh = DBI->connect(“DBI:mysql:database=”.$name.’;host=’.$hostname, $user, $password,
{
RaiseError => $raise,
# AutoCommit => 1,
mysql_enable_utf8 => 1,
on_connect_do => [ "SET NAMES 'utf8'", "SET CHARACTER SET +'utf8'" ],
})) {$dbh->{‘mysql_enable_utf8′} = 1;
return $dbh; # DBI database handler
}
We also must make sure that our tables are unicode:
CREATE TABLE `foo` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
….) DEFAULT CHARSET=utf8
And remember, that utf8 chars may take more space than normal – so prepare longer varchars in tables and be prepared for problem with indexes, like this: Specified key was too long; max key length is 1000 bytes – see http://bugs.mysql.com/bug.php?id=4541
After wrestling with perl encoding, we need to make sure the pages of website we create are displayed in utf8.
This means we need to have proper header in pages, for example:
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>
<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>
…
…
…
</head>
<body>
and/or:
Content-Type: text/html; charset=utf-8
Second step, is to set binmode on STDOUT (if we print our dynamically generated webpages)
binmode STDOUT, “:utf8″;
to get rid of
Wide character in print at …
warnings.
The data we get from outside (like STDIN) is usually binary data.
Command like uc, lc wants text strings.
Here is how to change binary data to text strings:
use Encode ;
$foo = Encode::decode_utf8($foo);
you can also convert from other encodings:
$data = decode(“iso-8859-2″, $data);
To check whether a string have utf flag turned on:
use Encode qw(is_utf8);
print is_utf8($foo) ? “utf8″ : “not utf8″
If you do not know what encoding is the data, use perl module:
use Encode::Guess;
my $enc = guess_encoding($data, qw/euc-jp shiftjis 7bit-jis/);
You need to tell explicitly which encodings are suspected, because
by default, it checks only ascii, utf8 and UTF-16/32 with BOM.
Encode::Guess->set_suspects(qw/euc-jp shiftjis 7bit-jis/);
But remember, that the guessing is not magic, and it likely to fail.
For example it may fail to recognize whether data are in is-8859-1 or iso-8859-2
Because:
The reason is that Encode::Guess guesses encoding by trial and error. It first splits $data into lines and tries to decode the line for each suspect. It keeps it going until all but one encoding is eliminated out of suspects list. ISO-8859 series is just too successful for most cases (because it fills almost all code points in \x00-\xff).
Making a correct utf8 web application in LAMP (Perl) is not easy. There are lots of dangerous traps along the way.
We need to take care of source code encoding, web forms data – inputed by user - encoding, mysql encoding, displaying data (writing) encoding, and perhaps also take care of data taken from disk files.
First, we need to take care of source code, if we want to write there something like
$var = “zażółć gęślą jaźń”
we need to use utf8
The use utf8 pragma tells the Perl parser to allow UTF-8 in the program text in the current lexical scope
Do not use this pragma for anything else than telling Perl that your script is written in UTF-8.
use utf8 is not a magical trick to fix all problems with utf8, just a beginning of the journey…
We must have a good code editor or IDE that understands utf8. It will be also nice to have possibility to open files with other other encodings and convert them to utf8. For unix/linux there is for example KDevelop, and many other tools. For windows, there are many editors too. See: http://en.wikipedia.org/wiki/Comparison_of_text_editors#Unicode_and_other_character_encodings and http://www.alanwood.net/unicode/utilities_editors.html
When using use utf8 remember to save code in utf8 encoding!
To be continued…
