miércoles, 10 de abril de 2013

Creando mapas de google usando jQuery


Extensión jQuery para crear mapas de google basados en direcciones.

Esta es una extensión para jQuery que sirve para crear mapas de google basados en una dirección humanamente legible.

Es muy simple de implementar:

1. copia este script jquery en alguna parte:


  1. <script>
  2. $.fn.googlemap = function(){
  3.         // author: Christian Salazar <christiansalazarh@gmail.com>
  4.         var src='';
  5.         $(this).each(function(){
  6.         var z = $(this);
  7.         var address = jQuery.trim(z.attr('streetnumber'))
  8.                 +'+'+jQuery.trim(z.attr('streetname'))
  9.                 +'+'+jQuery.trim(z.attr('cityname'))
  10.                 +'+'+jQuery.trim(z.attr('statecode'))
  11.                 +'+'+jQuery.trim(z.attr('zipcode'))
  12.         ;
  13.         src="https://maps.google.com/maps?"
  14.                 +"client=safari"
  15.                 +"&q="+address
  16.                 +"&oe=UTF-8&ie=UTF8&hq="
  17.                 +"&hnear="+address
  18.                 +"&gl=us"
  19.                 +"&z="+z.attr('zoom')
  20.                 +"&output=embed";
  21.                 z.html("<iframe src='"+src+"' width="+z.attr('width')+" height="
  22.                 +z.attr('height')+"></iframe>");
  23.         });
  24.         return src;
  25. }
  26. </script>


2. en alguna parte donde quieras mostrar un Mapa de Google pones este script:


  1. <div id='mapa' streetnumber='946' streetname='LAKE+DESTINY+RD'
  2.         cityname='ALTAMONTE+SPRINGS' statecode='FL' zipcode='32714'
  3.         zoom=18 width=500 height=300>
  4. </div>


3. Puedes poner varios mapas, con distintas direcciones, es decir, repitiendo el paso 2 por cada dirección que quieras mostrar,  en este ejemplo usé solo una, pero pudiera ser una lista, ahora usamos jQuery de nuevo para convertir esa cosa en un mapa:

<script>$('#mapa').googlemap();</script>

4. El resultado será:



Múltiples Direcciones

Si fuesen varias direcciones, como este caso que muestro (debajo de este texto), notarás que no uso "id='mapa'", sino un identificador de clase: "class='mapas'", eso es con el objeto de que el script de jquery pueda ser usado asi:

$(".mapas").googlemap();   // notas el punto antes de "mapas"  ? es importante.

lo que hará será que a todos los elementos que tengan la clase "mapas" los convertira en un mapa de google independiente.


  1. <div class='mapas' streetnumber='946' streetname='LAKE+DESTINY+RD'
  2.         cityname='ALTAMONTE+SPRINGS' statecode='FL' zipcode='32714'
  3.         zoom=18 width=500 height=300>
  4. </div>

    <div class='mapas' streetnumber='946' streetname='LAKE+DESTINY+RD'....bla

    <div class='mapas' streetnumber='946' streetname='LAKE+DESTINY+RD'....bla


Otra forma es crear los mapas mediante un elemento UL:


  1. <ul id='mymaps'>
    <li streetnumber='946' streetname='LAKE+DESTINY+RD'
  2.         cityname='ALTAMONTE+SPRINGS' statecode='FL' zipcode='32714'
  3.         zoom=18 width=500 height=300>
  4. </li>
    <li streetnumber='1002' ....bla....</li>
    <li streetnumber='9005' ....bla....</li>

    </ul>

    SIMPLEMENTE:

    $('#mymaps li').googlemap();



Extensión jQuery

La función $.fn.googlemap() es una extensión para jQuery. se denomina así por el uso de "$.fn", lo cual hace que podamos pedirle a un DIV que se convierta en un google map al ser reconocida la extensión.

Extras

var url = $("#mapa").googlemap();   // retorna la URL generada

podria ser usada para crear un vinculo de agrandamiento de mapa:

$("#mapa").parent().append("<a href="+url+">agrandar este mapa</a>");




    lunes, 8 de abril de 2013

    El Issue y el Commit

    (Orientado a quienes usan a diario o no tanto al sistema de "Issues" de git, o mercurial, etc.)

    "Issues" no significa BUG.  "Issues" hace referencia a un "asunto a resolver". Un asunto puede ser: un bug, una tarea pendiente, una mejora. Cuando se hace un sistema, no es sano hacer un "commit" con 300 modificaciones, se pierde la escencia del uso de GIT.

    Descripción del Issue y clarificación del asunto (issue) a ser resuelto:

    Es sano analizar primero "cual es la falla, o mejora o tarea a realizar".  Una vez clara y firme la idea es, entonces: (lo que siempre insisto) escribirla en texto simple:  "mejora que resuelve el problema xyz".

    Solo al intentar hacer esto (describir el issue) se aclaran ideas internas de uno mismo, se fuerza a discernir entre que es lo objetivo y que es basura. Reto a cualquiera a que lo haga, cuando lo logran han logrado el paso #1 de la ley de UML: "palabras simples que describan un asunto".  Parece simple, pero no lo es. Tras esto, todo lo que sigue es simple...

    Una vez descrito el problema en palabras simples, veran que el problema se resuelve solo: se sabe de antemano que hacer, donde tocar y donde no..y, si hay equipos de desarrolladores involucrados se sabe de antemano a quién se le debe dar la responsabilidad de tal "issue", incluso, a veces se quien debe hacer exactamente qué cosa.  Normalmente, una sola persona es la encargada de tal issue. Síntoma: cuando dos personas son responsables de un mismo issue estamos posiblemente ante la presencia de dos issues distintos.

    Finalmente, el trabajo sucio: El issue se crea, se detalla y se procede a resolverlo (cambios en código), se aplican los cambios que afectan exclusivamente "al issue" y no a toda la sarta de asuntos que nos econtramos en el camino, estos requerirán de su propio análisis, si es que no afectan o contribuyen al issue.

    "Ruido de Commit" (commit-noise)

    Ruido de Commit es toda aquella sarta de basura que quedo en el camino de resolución, que solo produce ruido, no resuelve y solo agranda el commit.

    Por ejemplo, resolviendo un problema "XYZ" hemos hallado que hay un error ortográfico: es un issue independiente, por qué ? porque al reparar ese error ni afectamos ni resolvemos el issue. Quiza hayan 10 errores (no vas a hacer un issue por cada error) simplemente haces un nuevo issue que refleje que tu estás "reparando errores ortograficos" y en éste commit haces "solo correcciones ortograficas"...no correcciones "de paso".

    Qué sucede si hemos resuelto un issue y mas tarde detectamos que quedó mal hecho ?

    No vas a hacer otro issue...porque entonces tendrás un mismo issue en dos partes, lo que si habrá obviamente será un nuevo commit, con los cambios que resuelven el BUG. Al hacer el commit entonces lo etiquetas asi:
    git commit -a -m "FIX ISSUE #77 (reopened)"
    Luego, vas al issue #77, lo reabres y anotas en él al commit nuevo que se ha generado, con su respectiva documentación.

    Qué sucede si hemos resuelto un issue, y dejamos tareas pendientes (TODO: xxx)

    Es un nuevo issue. Tipo TASK o ENHANCEMENT. Detallarás en ese nuevo issue el asunto que quieres mejorar.

    Los comandos "git diff", "git checkout"

    Al hacer el "commit" que resuelve a un determinado "issue", se hace así, en este orden militar:

    "git diff"  
    previamente una revisión. Descartar con "git checkout" a todo aquel archivo que contiene cambios que no tienen nada que ver con el issue, esto es para limpiar el commit de "ruido de commit".
    Por ejemplo, si resolviendo un issue determinado modificamos un archivo "libro.php" que no tenia pito que tocar, pero que en el proceso de resolución del issue ha sido modificado por la razón que fuere, pues simplemente lo descartamos:
    "git checkout ruta/abc/libro.php"
    se han descartado todos los cambios en "libro.php", quedando el commit libre de: "ruido de commit"

    "git commit -a -m 'FIX ISSUE #99' "si, el issue 99 previamente creado y descrito.

    "git push"

    hemos enviado la criatura al repositorio.

    Es limpio. ayuda a quienes tengan que lidiar con el codigo que hemos creado y nos ayuda a nosotros mismos a hacer buen software.