Programming

Simpler API for Zend’s built-in Firebug Logger

 

Zend Framework has functionality to send messages to the Firebug console (via Firefox’s FirePHP addon), but if you’re not using the ZF front controller, the API is a bit of a pain. Besides your instance of Zend_Log, you must keep track of a few additional objects just to manually flush the headers after all your logging calls. Since I knew the old FirePHP class didn’t need this follow-up step, I figured I could just flush the headers after each send.

The result is FireLog. On the FireLog instance, calls to methods like log(), info(), warn(), etc. are proxied to an internal Zend_Log instance, while the methods send(), group(), and groupEnd() are proxied to the static methods on Zend_Wildfire_Plugin_FirePhp. In both cases the headers are set immediately using some simple ZF subclassing. Continue reading  

Gainesville: PHP/Javascript Developer Position Open

 

The Office of Distance Learning is seeking a web programmer with considerable experience with PHP, Javascript, and SQL to aid in the creation of and maintenance of several web and mobile applications.

The person we’re seeking will need a strong understanding of and experience with:

  • PHP5
  • Javascript
  • object-oriented and functional programming styles
  • related technologies such as SQL, CSS, the HTML DOM, Apache, and HTTP

Preferred applicants will be able to demonstrate:

  • sites/projects worked on, including open source projects
  • code created that is highly extensible, loosely coupled, testable, etc.
  • ability to create APIs/frameworks to be used by others
  • intuition of impact of code on underlying systems and client-side experience
  • ability to communicate well with teammates and end users

The applicant must be comfortable:

  • coding with third party libraries like Zend, jQuery, YUI, etc.
  • customizing third party applications like WordPress
  • using source control and documenting code

The Office of Distance Learning is an exciting, creative environment where we manage and customize applications like WordPress, Moodle, and Elgg, and serve thousands of users.

Search jobs.ufl.edu for Requisition number: 0806823

Closure Compiler is smarter than you

 

I’ve known about Google’s Javascript minifier, Closure Compiler, for awhile, but after sending a couple snippets through it today I realized it’s a pretty impressive piece of work.

Input:

function howManyMatch(arr, pattern) {
   var l = arr.length;
   var total = 0;
   var i = 0;
   for (; i < l; i++) {
       if (pattern.test(arr[i])) {
           total++;
       }
   }
   return total;
}

Output: 

function howManyMatch(b,d){for(var e=b.length,c=0,a=0;a<e;a++)d.test(b[a])&&c++;return c};

Or with whitespace re-added:

function howManyMatch(b, d) {
    for (var e = b.length, c = 0, a = 0; a < e; a++)
        d.test(b[a]) && c++;
    return c
}

Optimizations:

  • shortened parameter names and removed unneeded semicolons (YUI Compressor already did this much)
  • combined multiple var statements into one declaration
  • moved that declaration into the first section of the for loop (to save one semicolon!)
  • removed brackets around blocks with only one statement
  • replaced if statement with && operator (to save two bytes)

Several of these are often done by JS devs by hand. With closure compiler on tap, we no longer have to. Just concentrate on readability and maintainability and let CC worry about size optimization.

?YouWontSeeMe

 

In beta 11, Opera’s going to hide all “http(s)://”, and also all querystrings (until you focus the addressbar). Opera’s devs are right that users consider them mostly “gibberish”, but I think this change could cause a ton of problems and confusion for people, especially support staff, and there are plenty of sites/apps still out there with URLs based on querystrings. I can see this setting as short-lived.

We need a frontend design tool for live web pages

 

It’s quite frequently that an HTML/CSS designer might want to make changes to a live web page. Maybe she doesn’t have write access, or maybe the fixes needed aren’t worth the start-up cost of copying the page locally and working on it there, or multiple designers want to work up ideas on a given page simultaneously. The “Inspect Element” capabilities of most modern browsers will let you make HTML/CSS changes to a live page, but navigating or refreshing causes those changes to be lost, and they’re hard to keep track of.

Here’s a feature wishlist:

  1. keep track of “Inspect Element” user changes with the ability to save them locally
  2. keep changes in discrete “changesets” that can be re-applied, or saved as a unified patch of the original files, or at least as the modified original files
  3. allow swapping page CSS files with user-controlled CSS files (e.g. file:/// or htttp://localhost/)
  4. allow swapped CSS files to be periodically “refreshed” so the user wouldn’t have to switch between CSS editor and browser.

Firefox’s Stylish extension looks to come close to (3), allowing you to add user styles to a page/site, like Greasemonkey does for Javascript. It doesn’t look like the editing experience is great, though.

You can manually do (3) and use the CSS Reload Every bookmarklet, but it reloads all CSS, which is kinda of jarring.

A bookmarklet could implement (3) and (4) and persist its settings in a cookie.

Other ideas?

Update: Here’s a bookmarklet that let’s you swap CSS files and stores its settings in a cookie for the current page. Next step is for it to allow adding files and controlling the cookie path.

You must enable Javascript! (right-click, add to favorites or bookmarks)

(CSSswap source).

Email Address Munging Still Mitigates Harvesting

 

At least a decade into the use of simple email munging on web pages (my own solution here) there’s a growing consensus—and it seems like common sense with the advancement of the web in general—that this surely can’t still work on modern harvesters. While trying to look up some old research I’d read about this, I came across this January 2010 post by a Project Honey Pot admin:

We’ve run tests on different munging techniques and find that they are still surprisingly effective. We have a page that has a set of differently munged addresses. The ones protected by Javascript have yet to receive a single message. Even simple things like using ASCII character encoding to hide the @ sign, or adding spaces to the addresses, is surprisingly effective at stopping harvesting.

Whether to munge or not is kind of a religious war, but I see this as pretty convincing evidence that munging isn’t obsolete just yet. Of course this or any other single prevention strategy isn’t a “solution”, but mitigation of the inevitable is still arguably worthwhile, especially for people without the luxury of having top notch admins run their mail server.

Using jQuery Before It’s Loaded

 

It’s better to include scripts like jQuery at the end of the BODY, but this makes its methods inaccessible earlier in the page (e.g. inside a WordPress post). What you can do is use a script like the one below to queue DOMReady functions before jQuery loads.

(function (w) {
    if (w.$) // jQuery already loaded, we don't need this script
        return;
    var _funcs = [];
    w.$ = function (f) { // add functions to a queue
        _funcs.push(f);
    };
    w.defer$ = function () { // move the queue to jQuery's DOMReady
        while (f = _funcs.shift())
            $(f);
    };
})(window);

Minified:

Setup

  1. Link to the script in the HEAD or at least before your typical page content area
  2. Link to jQuery at the end of BODY
  3. Below jQuery, include: <script>defer$()</script>

Now in the BODY you can use $(function(){ ... }); to queue up a function as if jQuery were already loaded. And, thanks to the fact that Javascript identifiers are referenced at run-time, you can call any other jQuery functions inside your queued function.

With some modifications you can use this pattern for any library with a similar DOMReady implementation.

Tiny Email Munging Script

 

I’ve seen a lot of these that are bloated/less effective/inaccessible, so I might as well put this out there. It’s simple enough to modify if you’re comfortable with Javascript.

Markup: <a href="mailto:john{@}example{.}org">john{@}example{.}org</a>

(function(){
  var a, i = 0, o = this.onload;
  onload = function(){
    o && o(); // run the old window.onload if existed
    while (a = document.getElementsByTagName("a").item(i++))
      if (0 == a.href.indexOf("mailto:")) {
        a.href = a.href.replace(/[{}]/g, "");
        a.innerHTML = a.innerHTML.replace(/{(.)}/g, "$1");
      }
  };
})();

Minified 234B:

for jQuery 150B:

Perks of Life in the Kingdom of Nouns

 

Execution in the Kingdom of Nouns is one of Steve Yegge’s most entertaining posts about the verbosity and noun-centricity of Java (and other strongly typed languages without first-class functions). His post paints a picture of life outside JavaLand, where things are simpler and more straightforward:

There’s rarely any need in these kingdoms to create wrapper nouns to swaddle the verbs. They don’t have GarbageDisposalStrategy nouns, nor GarbageDisposalDestinationLocator nouns for finding your way to the garage, nor PostGarbageActionCallback nouns for putting you back on your couch. They just write the verbs to operate on the nouns lying around, and then have a master verb, take_out_garbage(), that springs the subtasks to action in just the right order.

With simplicity, there’s always a tradeoff. How does one test that take_out_garbage() actually works? You’ll need a full environment with real nouns lying around and all you can do is check the environment after completion. In the Kingdom of Nouns, you can pass in mock nouns and carefully watch what the function does with them. Maybe it’s important that the recycling gets separated, but if you only check the end environment, you won’t be able to tell it wasn’t.

What if trash day is moved to a different day? You might need a new take_out_garbage_wednesday(). As ridiculous as it seems, passing in a GarbageDestination makes the chore more flexible and testable. During testing I can pass in a destination of “right here”, saving me the hassle of creating an environment that includes the walkway out to the curb.

Whether you’re executing global/static functions or class methods, being able to pass dependencies in (where to find the trash, where it goes, when is it supposed to be there) not only makes your function more flexible, but more testable to boot.

This is not to suggest that Steve’s post was anti-dependency injection. I get the impression it was more a frustration of the expressive limitations of Java (when he wrote it—I think it has lambdas now). You can do dependency injection just fine without concrete classes, of course, but you wouldn’t want someone to pass in an array of GPS coordinates when you really need an object that you could call getStreetAddress() on. Type hinting an AddressProvider in the argument would let end users know exactly what to pass in and let the compiler/runtime know not to even bother executing the function, because we don’t have what we need. Also type hinted arguments allow good IDEs to prevent you from making mistakes, or to autocomplete existing variables in scope matching that type.