Results tagged “libraries”

Not too long ago Amazon made some important changes to its API to improve security, but this change had the unfortunate result of breaking Media Manager. My knee-jerk reaction was to just go into my code and implement the API change directly in my custom built Amazon API library -- because hey, it would fix the problem and allow me to go about my day. But working on Melody has been a reminder to me about how important it is to drop proprietary code in favor of third party libraries when they emerge. It is not always the easy thing to do, because it often requires a huge effort to rewire your code to a new library, but in most cases it is the right thing to do because in the long run it will:

• Consolidate development around a library that more people will benefit from.
• Bring more features to your users faster.
• Allow you to leverage documentation written and maintained by someone else.
• Increase the size of your support community.

And that is what I did with Media Manager. I dropped all of my old proprietary Amazon API code in favor of a widely used, well supported CPAN module called Net::Amazon. In the process I dramatically simplified my code base, I incorporated more features that have emerged from Amazon's API since I initially wrote Media Manager, and made the framework easier to extend and use. All in all, it is proving to be a great change for the plugin that brings more features and capabilities to Media Manager users.

However, this change may also mean changes for its users. For a lot of Media Manager users, this new version may mean that your template code will no longer work. This change which breaks backwards compability was unfortunate, but to a great extent unavoidable, especially if I wanted to maximize the end-user benefits for shifting to Net::Amazon. So if you are an existing user of Media Manager and are anxious to restore interoperability with Amazon, then please consult Media Manager's new documentation with its many template code samples to see what changes you might need to update your blog's templates.

You can download Media Manager 2.1 from github, and file support tickets and bug reports in lighthouse. Please, if you have problems, let me know so that I fix them as soon as possible.

Javascript

Byrne is an experienced Javascript developer and has developed large scale applications that depend entirely upon either YUI or jQuery. See also:

• Tag Control for YUI - A simple widget to make the addition and removal of tags simple and intuitive.


• Filter Control for YUI - A widget, or UI control that automates the creation of a progressive filtering mechanism.

PHP

In addition to being an experienced Perl developer, Byrne is also incredibly versed in PHP. He has developed numerous large scale web applications build upon PHP as well as numerous open source libraries in use by sites across the Internet. See also:

• Test Run - A large scale test case management solution written entirely in PHP serving thousands of customers.


• MyPHPGoogleCheckout - An open source library for integrating with Google Checkout.


• PHP Paginator - A simple open source library that makes generating links to pages within a result set almost too easy.


Perl

Byrne is an experienced Perl programmer having served as the lead developer of the popular SOAP::Lite toolkit, and continuing to be one of the Movable Type's leading plugin developers and contributors.

How many times have you had to implement some kind of pagination control? You know the whole, next, previous, page 1, page 2, page 3 links you place at the bottom of a list? Ten times? a hundred times? Whatever the number, it is probably a lot. So why are there not libraries out there that make generation of these links a breeze?

Now there is.

Screenshot

How it Works

The pagination model is based upon three key values that you pass into the main pagination routine:

• the current offset in the list (how many items from the beginning of the list are you?
• the number of items on each page, or "limit"
• the total number of items in the result set

From these three key values one can generate a complete pagination control.

Functions/Methods

There is one static function in this class called paginate. It takes four parameters:

Parameters

• offset - This indicates to the control what is the current page you are on. The value is the number of items you are from the beginning of the list.
• limit - The number of items per page.
• total - The total number of items in the list. This is used to compute the last page in the list.
• base_url - This is the URL that is used for generating all the other URLs and links in the pagination control. Paginator will append to the end of this URL a number corresponding to the offset for that particular page.

Example Code

<?php
include("Paginator.php");
Paginator::paginate(0,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(11,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(21,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(31,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(41,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(51,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(61,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(71,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(81,100,10,"foo.php?bar=2&baz=3&offset=");
Paginator::paginate(91,100,10,"foo.php?bar=2&baz=3&offset=");
?>

Download

• phppaginator 1.02

Resources

• Google Code Project Homepage
• Announcement

License

This code is licensed under the Free BSD license

Acknowledgments

Thanks to Logan Hansen for his contributions that made 1.01 possible. Thanks to Doichin Dokov for his bug fixes that made 1.02 possible.

Over the many years of their coexistence, the terms CGI and Perl have become virtually synonymous. This perception that CGI and Perl are one and the same has contributed to some small degree to the perception that Perl is outdated and an inappropriate language for web programming - unlike its more modern counterparts like Ruby or PHP.

I of course know this to be a complete fallacy. First of all, the company I work for is a devout Perl shop and our products, all written in Perl, are collectively some of the largest and most scalable on the Internet. Few other companies in fact present more widely attended seminars and tutorials about scaling for the Web then ours do at conferences like eTech and OSCON.

But perhaps the more significant fallacy is that CGI and Perl are synonymous. In actuality, they technically have very little to do with one another, and there is technically no reason one should be hampered by the other, despite all evidence to the contrary.

A little history and background

CGI stands for "Common Gateway Interface" and was invented to allow any script, written in any scripting language, to also act as a web based application. In the early days of the Internet this was incredibly helpful to the first Web programmers (a.k.a. system administrators) proficient in sh, bash, csh, tcsh and perl because it allowed them to quickly deploy simple web based automation tools based on scripts and libraries they had already written. Cool.

But the inherent flexibility of language agnosticism is also CGI's greatest liability, and also by association, Perl's as well. You see, CGI is based upon the principle that when the web server receives a request, it does not know what scripting language will interpret that request. Therefore, it defers processing directly to the operative system, and so must do something geeks call "forking and exec'ing" - or in other words, the web server must start up an entirely new process on your server to handle the request. This may not sound like a big deal, but it sometimes can be as each forked process holds the entire Perl interpreter in memory. And that is a big deal. First it can consume a lot of your server's memory, and depending upon the size of your application, it can be slow to initialize. It works - and works well by virtue of working, but it by no means ideal.

More modern languages have been designed to avoid this. Let's take PHP for instance. PHP is a language that was designed for web programming exclusively. Therefore its architects made a critical (perhaps even obvious) decision early on: if the web server is going to handle a lot of PHP scripts, why bother forking a process to determine what scripting language will handle the request (this is expensive) - why not just load the PHP interpreter into memory once and interpret the request within the web server (which is much cheaper)?

So when it comes to CGI vs PHP, it is not really about Perl vs. PHP at all. It is really about understanding two solutions to two different problems - one operating under the assumption that every request will be processed by the same interpreter and the other designed to execute any script via the web.

The solution as it stands today

In the Perl world, there are actually two Apache modules that attempt to do what PHP does inherently: load the Perl interpreter into memory so that you no longer have to spawn a new process each and every time your web server receives a CGI request. Those two modules are mod_perl and mod_fastcgi.

However, these two modules have a critical flaw: they are incredibly complex because they attempt to solve a huge problem set having to do creating a persistent and stateful execution context. The result are two modules that are not only too heavy weight for the average user but also incredibly difficult to install - even for myself.

How to actually fix the problem

The more I have thought of this problem, the more I have come to believe that there is little standing in Perl's way to have all of the benefits that PHP has gained from being a language designed exclusively for the Web.

In theory, one should be able to take the source code of mod_php (the Apache module that dispatches web requests to a PHP interpreter) and swap out the component responsible for dispatching a request to PHP for one that dispatches the request to Perl. In theory it should just work (more or less). The result would be an Apache module that would be easy to install, and be much more efficient in handling and processing requests online.

Granted, this solution would not be stateful and persistent the way mod_perl and mod_fastcgi are, but that is not a problem this solution is engineered to solve.

Introducing mod_perlite

All of this is a really long-winded setup for what is a very quick conclusion.

I shared this hypothesis with an engineer at work, Aaron Stone, who shares a passion for Perl with me, but who also has a passion for operations. He took on this challenge and devoted part of his 20% time to testing this hypothesis.

The output of his work is called mod_perlite. It is largely derivative of PHP and is capable of processing Perl scripts quickly and efficiently. The next step of the project is to make it compatible with the CGI protocol, which can be done by gutting parts mod_cgi and dropping them into mod_perlite.

So far our results are promising, and it is possible that with a little hacking we may have just made Perl faster on the web and easier to deploy for everyone.

If you are interested in helping or participating in this project please let me know -- we could certainly use the help.

The Filter control provides a front end component that can be used on websites to manage the specification of a multi-faceted filter. It was inspired by the filtering capabilties found in Fog Bugz, and utilizes the Yahoo UI Widgets Javascript framework, a set of free and open source Javascript libraries that make creating Ajax applications very easy.

Disclaimer: This widget and website is not affiliated with Yahoo in any way.

Live Demo

Getting Started

To use the Filter widget/component, include the following source files in your web page with the script tag:

Your Filter Widget implementation will consist of one instantiatiable object:

• FilterWidget - when bound to an HTML div, this object will render and handle all user interface interactions. It also provides several events that one can subscribe to in order to handle specific key events.

Instantiating the Filter Widget

The Filter Widget constructor has one required parameter:

• the ID of the HTML object to which the widget will be bound and rendered.

Using the Filter Widget

Adding Constraints

For each "constraint" or value you want to filter your results by, you will need to instantiate and add a Constraint object to the Filter widget. Each constraint allows a user to specify a set of possible values to filter by, the label for the constraint, the HTML input element name and whether the constraint is "active" by default.

Setting a constraint to active by default

Unless otherwise specified, the filter widget will not apply any constraints to the filter, but will set all constraints in an 'inactive' state so that a user can apply them manually one-by-one. But if a user needs to have a constraints applied to a filter by default, say when the page is initially rendered, then they would set the "selected" property to 1, like so:

Subscribing to Filter Events

The Filter Widget has a custom event that one can subscribe to. This event is fired whe the user clicks the "Filter" button.

Support

If you have questions or problems using this widget/code, please visit the majordojo discussion forums.

For questions and issues with using the Yahoo UI Framework, please visit Yahoo's developer web site.

The Tags control provides a front end component that can be used on websites to manage the entry of and editing of tags. This widget is based upon the Yahoo UI Widgets Javascript framework, a set of free and open source Javascript libraries that make creating Ajax applications very easy.

Disclaimer: This widget and website is not affiliated with Yahoo in any way.

Live Demo

Getting Started

To use the Tags widget/component, include the following source files in your web page with the script tag:

Your Tags Widget implementation will consist of one instantiatiable object:

• TagsWidget - when bound to an HTML div, this object will render and handle all user interface interactions. It also provides several events that one can subscribe to in order to handle specific key events.

Instantiating the Tags Widget

The Tags Widget constructor has one required parameter:

• the ID of the HTML object to which the widget will be bound and rendered.

Using Tags Widget

Adding Tags

One can manually add tags to the list of tags by making calls to the addTag() function. This is especially useful for initializing the widget with a set of tags prior to rendering the widget or page. The code sample below shows how to initialize a Tag Widget with three tags 'foo,' 'bar' and 'baz.'

Changing the Links for Tags

The Tag Widget builds a list of tags. Each of those tags is capable of being a link to some user-specified URL. The URL can be customized via the TAG_LINK_FORMAT property. The complete URL will be formed by appending the tag name to the end of this property. For example, suppose an intranet wanted to link all tags on the site to some internal URL such as:

http://intranet.somedomain.com/?p=2&q=tag+goes+here&limit=10

Then you would ensure that query string parameters are ordered properly such that the "tag" is the last parameter in the query string. For example:

http://intranet.somedomain.com/?p=2&limit=10&q=tag+goes+here

Then suppose user entered "kittens" for the tag. Then the resulting URL, given the example above, would be:

http://intranet.somedomain.com/?p=2&limit=10&q=kittens

For example:

Subscribing to Add and Delete Events

The Tag Widget has two custom events: one for handling the addition of tags to the list, and the second for removing tags from the list. These events can listened for and then in response make calls to user specified functions (or "callbacks"). The code sample below illustrates how one would subscribe to both add and delete tag events.

Customizing the display

The following properties allow users to control aspects of the Tag Widget's appearance.

• TagList.DELETE_HTML - This is the HTML that will be wrapped by the "delete tag" link. This can be used to specify an image to be used, or text to be used.
• TagWidget.LINK_LABEL - This property contains the text that will be wrapped by the link that shows and hides the Add Form. Default value is "Add Tags".
• TagWidget.LIST_LABEL - This is the text that appears immediately in front of the list of tags. Default is "Tags:".
• TagWidget.FORM_LABEL - This is the text that appears immediately in front of the Add Form's text input field. Default is "Add Tag(s):".
• TagWidget.ALWAYS_SHOW_FORM - Some may not wish to hide the Add Form (the tag text input, and the "Add" and "Done" buttons. To ensure that there are always visible, set this property to 1. (Default is 0)

Support

If you have questions or problems using this widget/code, please visit the majordojo discussion forums.

For questions and issues with using the Yahoo UI Framework, please visit Yahoo's developer web site.

Six Apart often speaks of how its technology and contributions to open source help many of the most popular Internet applications scale to unprecedented levels. One of these tools is memcached, yet as important and ubiquitous as it is, it surprisingly lacks the documentation necessary to help beginners in realizing its power and ease of use. Memcached is not for priests and gurus, despite how technical its homepage may appear. Memcache is a tool that can be easily installed and used by almost any developer on almost any platform.

This guide was written in an attempt to give developers out there an introduction to this incredibly powerful tool, and hopefully equip them with enough information to actually get started in building applications on the Internet that are faster and more reliable.

There are few cities I have visited where I leave feeling, "now this is a city I could live in." There are even fewer that have captured the appreciation of my wife and I such that we routinely return to Seattle in our minds as a place we might seriously consider moving to.

One of the ways in which Seattle impresses me is that it is a city that seems to truly understand and appreciate space. I can think of so many development projects in San Francisco that focus almost exclusively upon function to the complete neglect of form. Now I am sure die-hard San Franciscans could point to a number of buildings and projects in San Francisco that run counter to this argument, but in the last decade Seattle has attracted the world's leading architects and designers to help transform the city into a beacon of modernity.

Granted, the Experience Music Project was privately funded by Paul Allen, but San Francisco has no shortage of millionaires who could throw money at architects like Frank Gehry to design and build their little pet projects.

Sure, some could argue that a city has no business spending the money necessary to attract top tier architects to design things like libraries. Just put the books in a building and let the public check them out for crying out loud!

Anyone who feels that way should visit the Seattle Public Library, designed by Rem Koolhaus. Now I appreciate architecture, perhaps more then the average Joe, but Seattle's Public Library remains the only building in which I can state that I was sincerely and profoundly moved when I entered it. No doubt, if you are a Seattle resident you are filled with pride when you visit that space. And if you are visitor, well then, you are in state of awe and envy and leave asking yourself, "why doesn't my city have a library like that?"

And now Seattle just opened the latest gift to the public domain: Olympic Sculpture Park, which is not only an amazing space in an of itself, but serves as an outdoor museum for some of the world's most renown sculptors, like Alexander Calder, whose "Eagle" sculpture will be a center piece in the park.

Of course, Architecture alone is not enough of a reason for me to move to a city. But if this trend continues Seattle will only become more and more attractive to me as it attracts more and more businesses, intellectuals, wealth and prosperity to the region.

Tim Bray offers a wonderful analysis of the three most popular programming languages out there right now: PHP, Ruby on Rails and Java. Here are some highlights and some thoughts.

Good apps, once built, tend to be in production for an astonishingly long time. Which means that they have to be maintained for an astonishingly long time. Which means that maintainability is important. There are a lot of things that go into maintainability, but I suggest that the biggies are object-orientation, MVC architecture, code readability, and code size (less is more, a lot more). This is PHP’s Achilles’ heel, of course. Yes, it is possible to write clean, object-oriented, modular, MVC-style PHP applications. But most people don’t; the majority of apps that I’ve seen have spaghetti PHP code wrapped around spaghetti SQL embedded in spaghetti HTML. Also, a lot of the people who really understand O-O and MVC and maintainability would rather work in Java or Rails.

This observation couldn't come at a better time - especially after I spent an evening mashing at the keyboard sharing in my experience trying to get some PHP sample code to work.

I am not a PHP-hater by any account. Hell, I choose PHP for a lot of my web work. But there is no getting around the fact that the incredibly flat learning curve for the language naturally leads to a lot of code written by amateurs. That code then gets contributed to open source directories, promoted on blogs, and/or in Pear and then gets included in other people's applications because it is generally the case that most developers will just integrate carte blanche any open source code into their application if it solves their problem. If you are a developer reading this, let me ask you, when was the last time you audited the code you downloaded from Pear or CPAN or Sourceforge?

This is of course at the heart of why PHP has developed such a bad reputation among security experts. Amateur developers by their very nature don't have the experience or knowledge of how to write solid code #, and thus tend to write code that does not conform to best practices and often has a number of security issues within it.

In recent years things like PHP and Rails have taught us that development speed is more important than we thought it was. On top of the obvious business value of delivering functions faster, there’s the Agile/XP view that you really don’t understand a feature till you’ve built it, so the faster you can build them the faster you understand them.

I couldn't agree more. I think the debate of which language is better as Tim rightly points out, is a red herring. The answer depends upon too many variables, and I really don't think there is a right or wrong answer. The only wrong thing to do is write crappy code that you later have to completely rewrite and re-architecture. But even that is inevitable in a way.

But I agree - if there is one thing I have learned in two years is the importance shipping. If you can whip together an app in PHP in half the time you can in Java, then that should, no - it must heavily influence your decision.

On Perl

I am sad that Tim didn't profile Perl, but then again he didn't profile .NET or Python either. For me, it is a toss up between PHP and Perl every time. What keeps me in PHP at all is inertia. I have a lot of personal libraries I have written in PHP that make me more productive there. But I am aching to make the switch to 100% Perl. Why? Because Six Apart has shown me just how scalable a language it is. With Catalyst, Data::ObjectDriver, Perlbal and memcached (not all of which are written in Perl BTW) it is actually not difficult to write some of the most scalable applications on the Internet.

Dev Tools

I would argue that all you really need to work on Perl is emacs or vi. But to be fair and consistent with Tim's appraisal, I think it is important to consider the lack of really well integrated developer tools for Perl. Granted, there is Active State, but that is for Windows only and thus doesn't score a lot of points with me.

What Perl has going for it is probably one of the largest repositories of open source libraries for any programming language. And these are perhaps the most valuable tools at a developer's disposal because it allows them to build on the shoulders of giants as opposed to re-inventing the wheel over and over.

Maintainability

This is both Perl's strength and weakness. Perl's has a lot of the same challenges as PHP in regards to the accessibility of the language. But it also has the opposite problem that there are a lot of ubersmart people out there writing Perl code, and their code is often quite obscure to say the least. A perfect example is SOAP::Lite. I dare anyone to try and make heads or tails of that code. Granted, Paul is a genius, but every time I have to get into that code I feel like I am unraveling some long unsolved mathematical proof. It hurts.

But there are also coders out there that write incredibly solid code. But in the end, this complaint is true about every language, that there exists a spectrum of good and bad code, and that maintainability is not a function of the language, but a function of the developer at hand.