On this page
Posted in perl
Sun, 25 Jan 2009 20:53:00 GMT
Byrne Reese, the product manager behind MT 4.0, and Aaron Stone, both formerly of Six Apart, recently discussed their project, mod_perlite, with chromatic in the article CGI is Dead; mod_perlite is Alive! mod_perlite is designed to bring some of the ease of use of mod_php to Perl. For where this can help, think of WordPress and their Famous 5-Minute Install. Now imagine having the same thing for MovableType and other Perl apps. To catch up on mod_perlite, follow the article comments and the PerlMonks thread.
no comments
Posted in perl
Sun, 25 Jan 2009 08:51:00 GMT
Continuing the thread of useful projects for Perl, I think it would be very beneficial to enhance Perl's relatively unstructured documentation system (POD) to bring it up to par with other languages today, e.g. Java and possibly others. Structured documentation should enable many benefits to speed development that I've long been a fan of including the following:
- ability to generate standardized docs listing params, results, exceptions, etc. like Javadoc,
- ability to auto-generate lists of files, classes and methods like rdoc, and
- ability to auto-display required parameters like in Visual Studio 2008.
I recently used C# and Visual Studio 2008 for the first time and the auto-display of parameters in the IDE made development much more efficient with a new and unfamiliar language / API. It's something I'd like to see integrated into a Perl IDE, e.g. Eclipse/EPIC, Padre, ActiveState Komodo, etc.
A new documentation system like this for Perl may be easier to build off of Moose which could make it attractive as a Tim Toady Bicarbonate project. Some of the benefits of Javadoc and lessons from C# XML doc can be seen in this thread: C# documentation comments: useless?
Ideally, this effort could be headed up by a TPF or EPO working group consisting of multiple people and organizations including people with interest in documentation and IDEs, e.g. developers or product managers from the various Perl IDE products.
7 comments
Posted in perl
Sat, 24 Jan 2009 16:45:00 GMT
I decided to see if there was any EPO chatter on use.perl.org after Larard mentioned it here. A quick search pulled up chromatic's Jan 16, 2009 article on a new book proposal for modern Perl programming. I was curious to see if chromatic was going to endorse the Enlightened Perl Organization and focus on their module list for his book but it doesn't seem to be the case. After reading the article, I couldn't help but get the feeling that it would be "Yet Another Way To Do It" which raised questions about how it would be received by the Perl community, one that seems to resist coalescing around new ideas. TIMTOWTDI is often cited as a strength but, taken to an extreme, it is also seen as a weakness by many.
I'd like to see chromatic's book come to reality but I'd also like to see it on conjunction with a larger effort of recommended Perl practices, either through EPO or a new TPF working group working with some of the same ideas of EPO. I've been participating in some technology working groups and I think working groups are a good way to move ideas forward. Getting more participants and participating organizations involved so the recommendations can be vetted by more people and have hopefully authority behind them can hopefully generate more adoption. I think leveraging these types of groups would be a more ideal way to move Perl coding forward with more widespread and visible endorsements than to have more individual, isolated books and articles on programming styles.
3 comments
Posted in perl
Wed, 14 Jan 2009 07:21:00 GMT
A number of people I know through the Perl community have come together to form The Enlightened Perl Organization (EPO). The goal is to modernize Perl 5 and make it competitive with new developments in programming languages, given that it's unknown when Christmas (the delivery date for Perl 6) will arrive.
My take on this is that while other organizations focus on ongoing development of Perl 6, EPO will seek to enhance Perl 5 and take it out of "maintenance mode." Enhancing Perl 5 will hopefully bring much needed modernization to the Perl 5 core that people can use sooner rather than later. One of the most exciting developments in the Perl community, which addresses some of the core criticism of Perl 5, is Moose, an object system that modernizes Perl 5. Unlike previous efforts efforts to enhance Perl 5's object system, this one seems to have gained a lot of traction with 136 current logins on the #moose IRC channel. Moose is different enough that some have even claimed that it is not Perl; however, this is clearly not the case as Moose and non-Moose objects and be freely intermingled within Perl projects. For some information Moose, check out this article by Jon Rockway. In addition to Moose, check out KiokuDB an interface for schema-less databases like Amazon SimpleDB and CouchDB as well as more traditional DBI for RDBMs. In addition to supporting projects, ideally Perl 5's core module list can be modernized so more people will be able to take advantage of and feel comfortable recommending modern approaches to Perl development.
At the same time, I'd also like to see them tackle a few more persistent issues, the most important of which is CPAN usability. There is no doubt the Perl community and the CPAN are very compelling; however, installing CPAN dependencies is more difficult than it needs to be. Installation often requires many interactive prompts and can take a long time for applications with many dependencies. There are typically no 5 minute installs like exist for WordPress, PHPbb, and MediaWiki. Some exceptions include qpsmtpd and Catalyst using Matt Trout's cat-install script.
I welcome EPO as another organization in the Perl community to keep Perl modern and vibrant.
4 comments
Posted in yui, perl
Fri, 09 Nov 2007 06:09:00 GMT
There is a lot of choice on the CPAN for open source Perl libraries and sometimes it's difficult to get an idea of how modules compare to each other. CPAN Ratings is a good source of reviews but it's not convenient to compare one module with another. To provide a partial solution, I whipped up a quick CPAN Compare page which will pull the CPAN Ratings from a number of modules and summarize them for you.
Read more...
4 comments
Posted in postgresql, catalyst, activerecord, perl, mysql, typo, php
Wed, 05 Sep 2007 04:38:00 GMT
I've worked on a number of database-driven projects and no matter how much people want database abstraction, it was always difficult to code and maintain. I was recently reminded of this when I read this Drupal article on dropping PostgreSQL support. Not only can it be difficult to maintain support for multiple databases, but it may be difficult to find developers.
One solution of modern programming is to move database abstraction from the code to the infrastructure using a ORM (Object-Relational Mapper) or Data Mapper. A ORM and Data Mapper abstracts the database for you so you no longer have to do tie db abstraction to each app. Not only does it let you code once for multiple databases it lets your users migrate their data from one database to another. This blog runs Typo which is based on Ruby on Rails and ActiveRecord. I've been contemplating migrating Typo from MySQL to PostgreSQL and I've been told that it would be as simple as exporting the data with YAML, updating the database.yml file and importing the data. I haven't gotten around to doing it yet but it is a powerful idea. ActiveRecord is a data mapper and isn't as flexible as a full blown ORM but it gets the job done for the most part. For a full-blown ORM, I think of Perl's DBIx::Class which provides a full OO interface to the RDBMS allowing you to code just once for multiple DBs without limiting you when you want to use some esoteric database-specific SQL. DBIx::Class is often used with the Catalyst Framework but is also used by itself.
There are PHP frameworks out there like Symfony and Cake but do any of them have stand-alone ORMs? If so, could Drupal move to something like that and solve their maintainership problems once and for all? Drupal is part of the Go PHP5 effort so there should be no issue using PHP 5 OO. Something to think about for the Drupal folks if a PHP ORM is available.
6 comments
Posted in perl, mysql, unicode, orm
Mon, 02 Oct 2006 15:35:00 GMT
One of the mysteries of Perl to me is that why, as of yet, is there no UTF-8 support in DBD::mysql although this issue has been discussed on the msql-mysql-modules list since at least 2003 (using the MARC archives). This is also given that MySQL does have UTF-8 support itself.
Read more...
8 comments
Posted in perl, mysql, xapian
Mon, 02 Oct 2006 08:08:00 GMT
I recently looked at using various encodings for hashed UIDs, e.g. UIDs generated by a crytographic hash algorithm such as SHA-1 or MD5. These are often useful when the UID does not need to have human meaning but should exhibit some uniformity, such as character set and length. I considered Base64 and hexadecimal first because they are commonly used by crypto libraries and then decided on Base64 and Base32 where appropriate. Base36 is actually the most compact case insensitive encoding (using Arabic numbers and Roman letters) but is not an option for me at the moment because there's no Perl module for it that will take arbitrary text and binary input at the moment. Math::Base36 exists but only handles numbers.
Read more...
no comments
Posted in postgresql, perl, unicode
Fri, 29 Sep 2006 18:21:00 GMT
Perl has two UTF-8 encodings, utf8 which is Perl's liberal version and UTF-8 which is a strict interpretation, aka utf-8-strict. The liberal version allows for encoded characters outside the UTF-8 character set, however you can run into problems when interoperating with applications that expect utf-8-strict, such as PostgreSQL. Here's a function I wrote to strictify utf8 to UTF-8 using the Encode core module:
use Encode;
sub strictify_utf8 {
my $data = shift;
if (Encode::is_utf8($data) && !Encode::is_utf8($data,1)) {
Encode::_utf8_off($data);
Encode::from_to($data, 'utf8', 'UTF-8');
Encode::_utf8_on($data);
}
return $data;
}
no comments
Posted in perl, unicode
Fri, 29 Sep 2006 18:00:00 GMT
I recently responded to someone asking how to get a Unicode hex codepoint from a Unicode literal on DevShed Forums. Since I think it may be more generally useful, here's my solution. The following function takes a unicode literal, converts it to a decimal representation using unpack and then converts it to hex usning sprintf:
sub codepoint_hex {
if (my $char = shift) {
return sprintf '%2.2x', unpack('U0U*', $char);
}
}
my $cp = codepoint_hex('カ'); # eq '30ab'
Read more...
2 comments