php

You are currently browsing articles tagged php.

What I am up to at the moment

2009 March 08 in computer programming, location-based by corprew | No comments

This is more or less a good guide to what I am up to at the moment, although it should be noted that I’ve written this same code fragment in three languages in the last while (this is ruby, the others were PHP and Java, although the Java one was a festival of reflection due to type wackiness.)

I actually have another version of the same code that puts a URL in the debug log that can be used to click directly to google maps. Why? I don’t know. I’m beginning to value Aptana Studio’s remix of Eclipse more and more as time goes on though because I now have Java, PHP, and Ruby/Rails all in the same highly (mostly) performing IDE. The alleged iPhone mode doesn’t work on my computer but I have CRAZY LIBERRIES installed at the moment and I suspect that that’s in large part my own fault — the apple tools still work.

  def geo_desc ( geo_loc, extended = false)
     #
     #  specialized pretty printer for address types.
     #  note that there is pretty much a standard mixin for geo stuff and
     #  this works across all the geocoding packages and model types.
     #
     return "[nil location]" if geo_loc.nil?
     desc = "[" 
     desc < < geo_loc.country_code.downcase unless geo_loc.country_code.nil?
     desc << "." + geo_loc.state.downcase unless geo_loc.state.nil?
     desc << "." + geo_loc.city.downcase unless geo_loc.city.nil?
     desc << "." + geo_loc.zip unless geo_loc.zip.nil?
     desc << "] "
     desc << "["
     desc << geo_loc.lat.to_s unless geo_loc.lat.nil?
     desc << ","
     desc << geo_loc.lng.to_s unless geo_loc.lng.nil?
     unless geo_loc.precision.nil? or geo_loc.precision == "unknown"
       desc << " (" + geo_loc.precision + ")" 
     else
       desc << " ?"
     end
     desc << "]"
     if extended
       desc << " " + geo_loc.full_address unless geo_loc.full_address.nil?
     end
     return desc
  end

Tags: , , , , , , ,

being liberal in what you accept — implementation interoperability semantics

2008 April 04 in general by corprew | 2 comments

I’ve been working for the scientists over at the North Atlantic Bloom 08 as part o the team making their collaboratory. This project has mostly been based on Drupal, which is a content management system (in the web sense, not the ECM sense) based largely on PHP.

One part of this is taking a lot of content over email — the scientists creating a lot of the content on the site are in the middle of the North Atlantic. Because of this, I’ve been using the drupal module mailhandler for a lot of things that would normally be done directly through the site.

Basically, changing the comparison from $data[0]=='taxonomy' to a case-insenstive comparison:

 if ((0==strcasecmp($data[0],'taxonomy')) && !is_numeric($data[1][0])) {

allows users to send in messages and have their mostly unambiguous intention followed. This is, in general, a good thing, and reflects the general net protocol practice of “be conservative in what you send, be liberal in what you accept.’ This is a general guide to good behavior and successful implementation and is generally called the Robustness Principle. I advise everyone to check out RFC 1122, because it has many entertaining things to say about the nature of the Internet at the protocol level.

Anyway, so when you can actually figure out what the person meant to be doing, you should probably accept it. This is a generic problem that pops up every now and then with computers. Surprisingly often, it pops up with case sensitivity at the protocol level. Here’s another moment for me with that same issue from about 7 years ago in Apache SOAP:

I proposed changing it to:

for (int i = 0; i < pds.length; i++) 
{ 
    if (0 == propertyName.compareToIgnoreCase(pds[i].getName())) 
      { 
        return pds[i].getWriteMethod(); 
      } 
}

from:

for (int i = 0; i < pds.length; i++) 
{ 
    if (propertyName.equals(pds[i].getName())) 
      { 
        return pds[i].getWriteMethod(); 
      } 
}

This does more or less the same thing, but is in Java. This was a case where the apache implementation wasn't interoperating with the Microsoft implementation because the MSFT implementation had a different valid interpretation of the SOAP specification than the Apache server did. Both implementations had completely reasonable behavior, but when the MS SOAP implementation responded to Apache, it did so with its own capitalization semantics (based on COM -- PropertyName) instead of the Apache SOAP capitalization semantics (based on Java -- propertyName). So, this is an ongoing problem that keeps showing up again and again.

I appear to be destined to run into it and advocate for the robustness principle in every technology i use, apparently. Either that, or it's just a slow day and I'm rambling.

Tags: , , , , , , , , , , , , , , ,