Robando Datos con Grease Monkey.

NOTA: Este contenido es por motivos educativos e informativos solamente.

Hace un par de días se me ocurrió que posiblemente se puede acceder a las cookies de un sitio web mediante greasemonkey. Al principio pensé que un agujero de seguridad tan grande no debió pasar por enfrente de los ojos de los desarrolladores del plugin sin ser notado, así que hice una pequeña prueba la cual consiste en crear un nuevo script que sea ejecutable en todos los sitios el cual contiene solo la siguiente instrucción:

alert(document.cookie);

Es super sencillo e inofensivo. Sin embargo, al correr un sitio web te das cuenta que en efecto greasemonkey puede acceder a las cookies de cualquier sitio web. Lo que puedes hacer con esas cookies depende mucho de tu creatividad, conocimiento y por supuesto, de la cookie en sí. Por ejemplo una cosa sencilla que hice fue simplemente redireccionar el navegador a una pagina donde la cookie se manda por correo a mi bandeja de entrada. Al probar ese script pude enviarme las cookies de twitter que mi navegador almacena. Un script bien configurado y dirigido para atacar una app especifica podría causar mucho daño, o por lo menos un buen susto. Lo mas obvio que puedes hacer con esto es robar información y ganar acceso a algunas cuentas de sitios web que usan cookies de forma irresponsable.

Redireccionar no es la forma más inteligente de robarte las cookies. Pero recordemos que greasemonkey no está sujeto a las mismas normas de seguridad que javascript corriendo directamente desde un sitio web. Digo esto por que hay que recordar que ajax no está sujeto a un solo dominio, sino que puede interactuar con documentos de distintos dominios al mismo tiempo, por lo que podemos usar el mismo script que yo hice para enviar el correo, pero en lugar de redireccionar y hacer el robo de datos demasiado obvio, podemos usar ajax y hacer la transferencia totalmente transparente al usuario.

Que se puede hacer al respecto?

La verdad es muy poco probable que te pase eso, a menos que alguien esté intencionalmente haciéndolo y ahí es donde está el problema. Por ejemplo alguien puede esconder el script malicioso dentro de algún otro script. Supongamos que quiero robar las cookies de facebook de alguna persona. Solo tendría que escribir un script que fuera útil para los usuarios de facebook y distribuirlo. El script ya tiene dentro la parte que hace el truco. Puedo disfrazarla de alguna u otra manera e incluso ofuscarla. Puedo incluso hacer que el script malicioso se active solo cuando esa persona en particular lo usa y así evitarme un montón de correos en mi bandeja que en realidad no quiero. Entonces que podemos hacer?

Una de las cosas más obvias es simplemente revisar los scripts que usas, aun que claro, eso puede ser un dolor de cabeza. Puedes por ejemplo usar un editor de textos que tenga capacidad para buscar y haces una búsqueda de ‘document.cookie’ para saber cuando un script esté accediendo a las cookies de tu navegador y ver que es lo que está haciendo con ellas. Otra cosa también es usar script confiables y como siempre investigar un poco antes de instalar un script. Pero aun así, recuerda revisarlo aun si nadie reporta nada raro. Esto por que por ejemplo, yo podría descargar un script muy popular, modificarlo y redistribuirlo asegurando que mucha más gente lo va a usar que un script que yo simplemente haya creado ayer por la tarde.

PD. Probablemnte muchos quieran ver los scripts que hice para enviarme cookies a mi correo. No lo comparto por que se que ahí afuera hay muchos script kiddies que probarán todo lo que encuentren para ‘hackear’.  Además, los scripts son tan básicos que cualquiera que tenga conocimientos mínimos los puede desarrollar por si solo.

Está Vivo!- El impacto ajax.

Hace un par de días comencé a notar una cosa. Primero fue con twitter y su nueva funcionalidad (que al parecer por el momento la han deshabilitado) de actualizar el sitio cada vez que hay twitts nuevos. Me encantaba por que solo dejaba la ventana abierta y en cualquier momento el titulo de la pestaña cambiaba para indicar cuantos twitts nuevos había. Es mucho más fácil estar al tanto de twitter (y esclavizase a él) de esa manera sin tener que tener otra app abierta. Después comencé a notarlo con otros sitios. Por ejemplo, http://scobleizer.com/ actualiza su barra lateral cada cierto tiempo. Llegó el momento que me dije a mi mismo, Gush! este sitio está vivo!. No es la primera vez que veo que un sitio se mueve por si solo. He visto cientos de rolling menus, y sitios que de una u otra forma “se mueven”, pero eso no me impresiona. Después de todo, todo eso que se mueve no es más que un loop, algo que alguien programó antes y que no cambia-un .gif programado. Sin embargo, estos sitios están no solo moviéndose, sino auto actualizándose para mostrarte el nuevo contenido y es eso precisamente lo que causa la sensación de WOW!

Como programador que soy, se que todo lo que hay detrás no es más que ajax, pero la verdad aun así me impresionó. Probablemente sea por que es una de las primeras veces que veo ajax empleado de forma usable, amigable y responsable, o quizá solo me agarró desprevenido y me sorprendió. Cualquiera que sea la razón, la verdad que por un momento me hizo sentir que estaba viendo algo vivo, algo que se movía, y me produjo la sensación que te produce ver cuando un recién nacido mueve una mano-simplemente increíble. Posiblemente esté exagerando, después de todo ajax ya está creciendo barba. Sin embargo, es agradable ver que finalmente los desarrolladores están aprendiendo a usarlo de forma benéfica y no solo para impresionar damiselas. Seguro que la web nos depara muchas sorpresas todavía. Apps como wave se abren paso y cada vez la web deja de ser ese papel lleno de formularios que proveen la única forma de interacción. En lo personal no me emociona las animaciones ni los drag and drop.  Eso lo veo más bien como simples trucos de feria. Los verdaderos avances en la materia son aquellos que no se notan, que han sido tan bien calculados, planeados y desarrollados que se introducen de forma natural de modo que el usuario nunca se da cuenta que lo está usando y por lo tanto nunca tiene que aprender algo nuevo ni adaptarse aun nuevo método de interacción. Way to go, pero la web es cada vez más excitante y nos exige a notros, lo programadores que de cierta manera somos participes en esa evolución web, cada vez mejores y más responsables metodologías para el uso y la aplicación de las nuevas tecnologías. Ahora solo tenemos dos caminos, sentarnos a esperar más avances en la materia, o se nosotros mismos quienes impulsemos eso avances. Tu cual escoges?

Introducción a la trigonometría (I)

Uno de los temas menos tocados en los blogs y foros de programación y desarrollo web es de las matemáticas. Probablemente sea por que en realidad la aplicación de las matemáticas en la programación y el desarrollo web no es ampliamente valorada, o probablemente sea por que dicha aplicación no es un requerimiento. Sin embargo, el correcto uso de la matemática puede y trae grandes beneficios al desarrollo web.

Piensa por un instante en una simple animación como puede ser desplazar un elemento de un lado a otro en la pantalla. Es un efecto relativamente simple; basta con aumentar o disminuir el valor de la posición de dicho elemento en uno o ambos ejes por unos cuantos pixeles y repetir dicha modificación en intervalos. Sin embargo, esta no es la mejor forma de hacerlo. Se puede usar una simple ecuación algebraica para poder calcular el movimiento del elemento y de esta manera poder incluso determinar y establecer el tiempo de duración de la animación así como mantener un intervalo constante y amigable al cpu del usuario (en mi experiencia he encontrado que generalmente 100 milisegundos es un tiempo relativamente amigable que evita esos odiosos saltos en las animaciones). En este post no voy a hablar sobre este efecto, ya que como dije, eso requiere una ecuación algebraica y lo que en este momento nos interesa no es el álgebra, sino la trigonometría.

La trigonometría, aparte de ser la rama de la matemática con el nombre más cool y exótico desde mi punto de vista, es la rama de la matemática (o de la geometría, según la fuente) que “se ocupa la medida de los elementos de los triángulos.”* A decir verdad, desde mi punto de vista, la trigonometría no es otra cosa que el estudio de los triángulos y la razón entre sus ángulos y sus lados, una geometría con un ego exaltado en donde solo existen los triángulos y los círculos. Es una ciencia relativamente sencilla ya que su aplicación en la vida real se puede ver a simple vista y no es tan abstracta como el álgebra o el cálculo. En este artículo veremos una breve introducción al mundo de la trigonometría que nos preparará para artículos posteriores en los que estaré tratando el uso de canvas.

La trigonometría tiene como base el triángulo rectángulo, el teorema de Pitágoras y la seis funciones trigonométricas. En esta introducción hablaremos solo del triángulo rectángulo y del teorema de Pitágoras. Las funciones trigonométricas las dejaremos para la parte dos de la introducción a la trigonometría.

El triángulo rectángulo.

El triángulo rectángulo es aquel que tiene un ángulo recto. Por si no recuerdas lo que es un ángulo recto: un ángulo recto es aquel que mide 90 grados. Justo al otro lado del ángulo de 90 grados, nos encontramos con la hipotenusa, el lado mas grande del triángulo rectángulo. Probablemente recuerdes que los ángulos de un triángulo siempre suman 180 grados, por lo que, al tener un ángulo recto, es fácil deducir que los dos ángulos restantes del triángulo son complementarios, es decir, que juntos suman 90 grados. Este es un aspecto importante de recordar, ya que muchas veces puede resultar extremadamente beneficioso si se sabe aplicar con destreza. Dentro de las muchas posibilidades del triángulo rectángulo, que ya de por si es especial por si mismo, existen triángulos rectángulos con medidas especiales, casi mágicas.

Triángulo 90-60-30

Uno de esos triángulos con medidas especiales es el triángulo de 90, 60 y 30 grados. Todos los triángulos mantiene la proporción de sus lados sin importar su tamaño. Es decir que, como dicen algunos hombres para consolarse, el tamaño no importa. Las proporciones del triángulo rectángulo son 2 para la hipotenusa, raíz de 3 para su lado mediano y 1 para su lado mas corto. El siguiente diagrama te ayudará a entender mejor.

En la práctica, esto significa que si un triángulo 90-60-30 tiene como medida 5px para su lado más corto, su hipotenusa mide 10px y su lado mediano tendrá al rededor de 8.66px. Esto es por que para poder obtener la medida de cada uno de los lados hay que mantener la proporción, por lo que si el lado más corto vale 5, podemos decir que que la hipotenusa vale 2X5 y el lado mediano vale 5X(raíz de 3).

Triángulo 90-45-45

Otro triángulo que también conviene recordar es el que tiene un ángulo de 90 grados y dos de 45. Las proporciones de este triángulo son raíz de 2 para la hipotenusa y 1 para sus dos catetos (los lados del triángulo que no son la hipotenusa).

El teorema de Pitágoras

Los pitagóricos descubrieron por ahí del 500 a.C. la relación entre los lados de un triángulo. Más concretamente, descubrieron que la suma de los cuadrados de los catetos de un triángulo igualan el cuadrado de la hipotenusa. Me acuerdo que cuando era chico escuchaba hablar del teorema de Pitágoras, y todos esos kiddies (mas grandes que yo por supuesto) hablaban de ese misterioso “teorema” como algo difícil de mascar. Para ese entonces yo no tenía ni idea de lo que era un teorema, pero recuerdo que pensaba que sería algo difícil, tanto que cuando por fin llegue al cursos escolar donde aprendí el teorema de Pitágoras me quedé “Y eso es todo???.” Y es que la verdad el teorema de Pitágoras es uno de los conceptos más sencillos de la matemática:

a² + b² = c²

donde a representa uno de los catetos y b representa al otro, mientras que c representa la hipotenusa, de modo que si quieres saber el valor de la hipotenusa y conoces el valor de ambos catetos podemos decir que:

h = raíz de (a² + b²)

en donde h representa a la hipotenusa. De igual modo la ecuación puede modificarse para obtener cualquier lado de un triángulo mientras se conozcan los otros dos lados.

Por ahora eso es todo en cuanto a trigonometría se refiere. Espero verlos en la siguiente entrega de esta nueva serie donde nos concetraremos en las seis funciones trigonométricas.

*La Biblia de las Matemáticas (p.833)

DOM: intoducción

Aprovechando que todavía falta algunos días para que sea martes, el día que he escogido para liberar los artículos sobre ajax, y que nada me impide publicar algo que no sea ajax durante los demás días, me voy a tomar el tiempo para dar una breve introducción al DOM.

El DOM, o Document Object Model, no es más que una interfaz independiente o neutral al lenguaje y la plataforma que nos da la oportunidad de acceder y modificar documentos, específicamente aquellos que han sido tratados con algún lenguaje de enmarcado como lo es (X)HTML.

Este famoso DOM nos permite acceder de forma estructural el contenido de nuestros documentos de forma dinámica. Algunos tienen la idea que el DOM es exclusivo de HTML o de Javascript. La verdad no podría ser más diferente. El DOM no es exclusivo de HTML y mucho menos de Javascript. Si bien es cierto que por un lado los documentos HTML, todos, contienen un DOM, por el otro lado, los documentos Javascript no. De hecho, la única relación entre Javascript y el DOM es la que se mantiene mediante la API de DOM de Javascript. Esta API nos permite el acceso al DOM y se conforma de métodos como getElementById() y getElementsByTagName().

Es el DOM un leguaje de programación?
No. El DOM es simplemente un modelo, un maqueta de la estructura de nuestro documento; de ahí su nombre. El DOM se representa generalmente como un árbol genealógico, con el elemento HTML a la cabeza, ya que este elemento es el antecesor de todos. No hay otro elemento más arriba de HTML (esto hablando aquí exclusivamente de documentos HTML). Analicemos un ejemplo:

<html>
   <head>
      <!-- Contenido de head -->
   </head>
   <body>
      <!-- Contenido de body -->
   </body>
</html>

Como puedes ver en ese código, el elemento html es que contiene a todos los demás (head y body junto con sus elemento internos no mostrados aquí). A cada uno de estos elementos dentro del DOM se les conoce como nodos. Todos los nodos, excepto por html, son hijos de otro nodo. En nuestro ejemplo, los nodos head y bodoy son hijos de html.

Interactuando con el DOM.
Dependiendo del lenguaje que escojas, la forma de interactuar con el DOM puede variar. Nosotros escogeremos Javascript, ya que este blog es principalmente sobre Javascript. Como ya mencioné anteriormente, Javascript nos ofrece una API (Application Programing Interface) para el uso del DOM. Una API no es más que una serie de métodos que se hacen disponibles para poder interactuar con una aplicación. De hecho, dependiendo de con quien hables, puede ser que algunos no consideren lo métodos que ofrece Javascript para interactuar con el DOM como una API ya que el DOM no es una aplicación, sino una representación del documento. Sin embargo, yo, por comodidad, he decidido llamar a este conjunto de funciones API.

Esta API se conforma de métodos como los ya mencionados getElementById() y getElementsByTagName(). Curiosamente javascript no contiene un método getElementsByClassName(), lo cual es curioso considerando que las clases son una buena forma de agrupar elementos que en determinado momento nos gustaría poder manejar todos de una sola vez. Sin embargo, Javascript si nos ofrece otra serie de métodos como appendChild() y removeChild() que sirven para agregar y remover nodos respectivamente. No voy a entrar en detalles ni a listar todos los métodos para el manejo de DOM ofrecidos por Javascript ya que solo pretendo dar una breve introducción al DOM y no al API de Javascript para el uso del DOM. En su momento ya habrá tiempo para tratar ese tema.

Los tipos de Nodos
Ya mencioné que cada elemento en HTML es representado por un nodo en el DOM. Veamos ahora los distintos tipos de nodos que hay. Específicamente tenemos:
El nodo document que es la representación de todo el documento.
Nodos de elemento, que representan un elemento como puede ser <p></p>
Nodos de texto, que representan texto como puede ser “mi texto”
Nodos de atributo, que representan un atributo como title=”hola mundo”
Nodos de comentario, que representan un comentario <!– comentario –>

Es necesario entender los diferentes tipos de nodo ya que cada uno tiene sus peculiaridades. Algo en lo que muchos novatos caen, es pensar en elementos como entidades globales, es decir que en:

<p>Mi parrafo</p>

Muchos ven a “Mi parrafo” como el valor de <p></p>. La verdad no puede estar más lejos. “Mi parrafo” no es el valor de <p></p>, más bien es un nodo completamente distinto y hasta cierto punto “independiente”. En un articulo futuro estaré hablando más sobre el DOM y explicando con código estas leves confusiones. Como dije hace un momento, mi único objetivo por ahora es poder explicar lo que el DOM es.

Por último, voy a decir que el DOM es una de las mejores cosas que le pudo pasar al mundo de la web. A través de DOM es posible modificar dinámicamente y en tiempo real muchos aspectos de una página web. En un futuro me gustaría hablar sobre DOM scripting y sobre uso responsable, amigable y degradable del DOM, pero por ahora esto es el fin de esta breve introducción.

Ajax: Introducción

Ajax es una tecnología que muchos consideran relativamente nueva. Para mí, ajax ya no tiene nada de nuevo. Su época de fama parece haber pasado, y gracias a Dios su época de abuso también, no así su tiempo de uso. Ajax sigue representando un tremendo potencial, aun que desgraciadamente son pocos los que le han sabido sacar provecho, la mayoría solo lo han abusado y jugado con él, como quien abusa de cualquier juguete. Desgraciadamente, el tremendo poder que ajax representa, se ha salido del control en las manos de unos cuantos script kiddies que no han sabido usarlo propiamente.

En esta serie voy a tratar de enseñar, no solo ajax, sino su uso correcto en base a mi experiencia como desarrollador y sobre todo como usuario consiente del verdadero potencial que la web puede alcanzar con un arma tan poderosa como ajax en nuestra bolsa de herramientas.

Empecemos por definir lo que es ajax. Para poder comprender ajax y usarlo propiamente, primero hay que entender que ajax es solo una combinación de diferentes tecnologías existentes, todas ellas unidas por un solo objeto. Ese objeto se llama XMLHttpRequest. Fue introducido por Microsoft como componente de Active X, posteriormente fue adoptado por mozilla y en la actualidad se encuentra en desarrollo una especificación por parte de la W3C. Las diferentes tecnologías que se mantiene unidas por este objeto varían dependiendo el proyecto y las preferencias del desarrollador, pero comúnmente se usan solo dos: Javascript y (X)HTML. Sin embargo, en esta ensalada de tecnologías pueden entrar en juego algunos otros componentes como puede ser PHP, XML, texto plano etc.

Mucha gente confunde ajax con DOM scripting o con el antiguo DHTML. Estos son totalmente diferentes, y por ningún motivo deben confundirse ya que eso puede traer problemas al momento de tratar de separar uno del otro para poder crear una metodología de trabajo mucho más eficiente. Por ejemplo, un buen programador querrá mantener sus mecanismos relacionados con ajax aparte de los relacionados con DOM scripting de modo que los problemas que pueda presentar puedan ser divididos a su vez en problemas más pequeños y más fáciles de solucionar. Si el programador no sabe distinguir entre ajax y DOM scripting, lo más probable es que termine mezclando ambos procesos haciendo imposible dividir el problema de la forma más eficiente y, por ende, causando que el desarrollo sea más difícil. La pregunta es, entonces, como distinguir entre uno y otro?

Ajax tiene solo un objetivo. Su principal funcionalidad está muy bien definida y teóricamente debe ser completamente sencillo poder identificar en donde empieza y termina su área de trabajo. Ajax tiene como objetivo la comunicación con el servidor de forma asíncrona. Uno de los típicos abuso de ajax es usarlo para acarrear datos del servidor al navegador por el simple hecho de no querer recargar la página, entonces terminamos con sitios que recargan todo, menos el menú, cada vez que se hace un click. El trabajo de ajax no es simplemente acarrear datos de un lado a otro, sino poder interactuar con el servidor en tiempo de ejecución y delegar tareas que han de ser ejecutadas, esperar por la respuesta y luengo entonces traer la respuesta de regreso al cliente. Solo cuando logramos entender lo que esto significa, hemos logrado entender ajax.

Para evitar su abuso, hay que considerar cada una de las tecnologías que están en juego, sus limitaciones, su desventajas y su grado de inaccesibilidad. Así también hay que poner en la balanza los beneficios que su uso puede traer y los problemas que puede causar, pero sobre todo, hay que proveer siempre de una alternativa para aquellos que por una u otra razón han de navegar si ajax.

A lo largo de esta serie vamos a hablar de formas para resolver distintos problemas. Vamos a analizar diferentes situaciones en la que podemos usar ajax y sobre todo, vamos a desarrollar una metodología de trabajo que nos permita desarrollar pensando siempre en accesibilidad para todos. Esta ha sido solo la introducción, espero poder verlos y sobre todo leer sus comentarios a lo largo de esta serie.

Next time:
La siguiente vez empezaremos con el uso de ajax y veremos algunos ejemplos prácticos de su potencial.

Formularios más inteligentes con php.

Bueno, una nota primero en cuanto al titulo del articulo. La neta que no sabía ni como llamarlo, así que el titulo igual y no sea 100% descriptivo del contenido del post.

Habiendo dicho eso, prosigamos. Hace unos días me encontraba con un dilema. Has encontrado alguna vez con un formulario que quieres que muestre una página u otra dependiendo de si la acción fue realizada con éxito o no? Bueno, pues ese era mi dilema. Es muy sencillo solucionarlo, pero yo no quería tener que cambiar la estructura de toda la aplicación (un CMS).  Explico el problema para que veas un poco más de lo que hablo:

Tengo una pagina que se llama digamos “informacion.php”. Esta pagina se encarga de tres cosas, 1)agregar información nueva, 2)editar información existente y 3)borrar información existente. Para poder hacerlo toma el valor de una variable que se le pasa por GET, de modo que si la variable tiene como valor “aInfo”, la pagina muestra un formulario para poder agregar información nueva. El formulario tiene como action ‘informacion.php?modo=aInfo’, de modo que si al hacer la validación del formulario se determina que el formulario no es valido, se muestra un error y se vuelve a mostrar el formulario con los elementos que ya habían sido introducidos. Esto es por motivos de usabilidad ya que si el action del formulario fuera solo ‘informacion.php’, la aplicación no mostraría nuevamente el formulario y al presionar el enlace que nos lleva al formulario los datos de POST se perderían dejando sin posibilidad de introducir automáticamente los datos previamente introducidos por el usuario, obligando al usuario a escribir todo de nuevo en lugar de solo editar lo que estaba mal.

Algunos pueden argumentar que se puede usar GET para enviar los datos de POST al formulario nuevamente, pero eso representa más trabajo, a demás de no representar ninguna garantía debido a las limitaciones de GET e incluso podría ser perjudicial ya que el usuario pensaría que todo esta como él lo había dejado anteriormente cuando la realidad pudiera ser que un texto muy largo no haya sido incluido en su totalidad por GET, eso solo por mencionar uno de los muchos problemas que esta ’solución’ nos podría traer. Otro método igualmente ineficiente es pensar que como se implementará validación en tiempo real mediante javascript se puede confiar en que el problema será captado por javascript y no habrá necesidad de requerir al usuario que navegue manualmente al formulario nuevamente después de haberse encontrado un error en el formulario enviado.

Ninguna de estas dos opciones me convence por completo. Para que comprendas mejor de lo que hablo, muestro aquí una estructura de como está el código:

<?php

$ok = chacarFormulario(‘info’);
//checarFormulario regresa true o false dependiendo de si el formulario es o no valido
if(!$ok){
$error=”formulario invalido”;
//La variable error es capturada después por la aplicación y mostrada al usuario
}else{
//Guardo todo en la base de datos
}

?>

Si todo está bien no necesito mostrar el formulario ya que eso puede confundir al usuario a demás de que se ve feo. Si, por el contrario, hay algún error, necesito mostrar el formulario con los campos previamente llenados con la información que el usuario introdujo antes de enviar el formulario. Esta info se encuentra en $_POST, pero no entrare en esos detalles. La cosa es que para poder mostrar esa formulario action tiene que estar como ‘informacion.php?modo=aInfo’, pero eso me trae problemas si todo estuvo bien ya que para que no se muestre el formulario la variable modo no tiene que estar presente (o seteada como dicen algunos).

En otras palabras, si el formulario está correcto su action debería ser “informacion.php” y si no, el action debería ser “informacion.php?modo=aInfo”, pero claro, es imposible cambiar el action del formulario después de haberlo enviado y no hay forma de saber si el formulario es valido y así cambiar su action antes de enviarlo. Un dilema con una solución más fácil de lo que parece.

Mientras algunos empezarían a hacer raras convinaciones entre POST y GET y a usar variables para esto y para lo otro creando una pesadilla de código. Yo preferí sentarme a analizar el tema y llegue a la conclusión de que, si el problema era la existencia de la variable modo, bastaría con borrar esa variable y todo andaría bien.

Efectivamente, basta un simple unset para solucionar el problema:

<?php

$ok = chacarFormulario(‘info’);
//checarFormulario regresa true o false dependiendo de si el formulario es o no valido
if(!$ok){
$error=”formulario invalido”;
//La variable error es capturada después por la aplicación y mostrada al usuario
}else{

//Guardo todo en la base de datos
unset($_GET['modo']);
}

?>

De esta manera, para cuando la applicación llega a la parte que decide que parte mostrar (un formulario para gregar info, un listado de la información existente o una tabla con opciones de editar y borrar), lo cual hace dependiendo del valor de modo, se da cuenta que modo no existe, aún cuando en nuestra URL siga estando. Como para php modo ha sido eliminada y por consiguiente ya no existe, la aoplicación toma el valor por defecto. Para entenderlo mejor, te muestro la estructura de la parte de la app que decide que parte mostrar:

<?php

if($_GET && isset($_GET['modo'])){
switch($_GET['modo']){
case ‘aInfo’:
//muestra formulario para agregar info
break;
case ‘eInfo’:
//muestra opciones para editar info
break;
//mas de lo mismo case break, case break…
}
}else{
//si la variable $_GET['modo'] no existe entonces:
//muestra tabla con lista de info existente y opciones de borrar y eliminar.
}

?>

En caso de que todo haya estado bien, la vaiable modo es eliminada (para eso usamos unset()) por lo que cuando se llega a la parte de código apenas mostrada arriba, se ejecuta el código dentro del else{ } como si nuestro formulario hubiera sido enviado con action=”informacion.php”, cuando en realidad ha sido enviado con action=”informacion.php?modo=aInfo”.

Bueno, espero que se haya entendido por lo menos un poco. Creí que era un buen método para compartir con los visitantes de este blog. Espero sus comentarios.

Cuando encuentres un problema en una app, arreglalo.

Uf, esto va a ser como un record de errores que he aprendido a la mala. Han sido un montón, pero apenas pensé en iniciar esta serie. Ayer estaba muy tranquilo esperando que se llegara la hora de ir al trabajo. De repente me puse a pensar el cual sería la razón por la que una de mis amigas a quien invite a mi nuevo proyecto, el xismografo, no había escrito uno a pesar de haber contestado el mio sin demora. Era una de dos, o no lo había hecho, o no me había invitado a contestarlo. Ambas eran muy improbables. Decidí ir y revisar los últimos ximografos y me di cuenta que en efecto si había creado un xismografo. Entonces pensé, por que no me invito. Revise la lista de invitados y me di cuenta que sí había intentado invitarme. El problema es que todos los correos los había encerrado en un paréntesis. Por ejemplo, (uncorreo@unsitio.com). La parte de la app que envía los correos simplemente envió las invitaciones a las direcciones tal y como estaban, con paréntesis. Como es de esperarse, esas invitaciones no son validas, y aun que lo fueran, no son las correctas.
Me tocó modificar manualmente una de las tablas en mi base de dato, algo que nunca debe hacerse, pero que esta vez no tenía otra opción. Lo peor de todo es que esa posibilidad de error yo ya la había pensado, pero preferí confiar en que el usuario haría bien las cosas.

Modificar manualmente las bases de datos me trajo otro problema que aun estoy tratando de resolver. El problema no es grabe y es solo con uno de los registros anteriores. Podría decirse que puedo simplemente olvidarme del problema y que no me afectara realmente mucho, pero esa no es una opción cuando quieres que un proyecto tenga éxito.

Otro de los problemas en lo que ya había pensado, pero que también, tontamente, preferí confiar en el usuario, es que a la hora de presionar enter en un formulario, este se envía automáticamente. Por muchos tiempo estuve pensando en cancelar esa acción por que me podría causar resultados no deseados. Por ejemplo el envío de un formulario cuando aun no está completo. Me he dado cuenta que eso fue lo que le pasó a mi amiga.

Estos dos errores me parecieron poco probables que aparecieran, pero al final son los dos errores que presenta la primera persona que intenta crear un xismografo y distribuirlo. Por eso cuando piense en una posibilidad de error en algún sitio o app en la que estés trabajando. O cuando estés organizando cualquier cosa, no te dejes convencer por ti mismo pensando que es muy poco probable que pase. Mejor ponte a trabajar en prevenir y asegurar que efectivamente no pase. Generalmente soy un programador muy negativo. Siempre pensando que mis usuarios van a tratar de hackearme el sitio, que no van a saber ni como prender una compu, que no van a tener javascript activado, que no van a tener imágenes disponibles o css disponible. Trato de prevenir cualquier disfuncionalidad en mis proyectos, pero esta ves simplemente me dejé llevar por el conformismo y un poco de flojera y ahora he tenido que pagar el precio.

Algunos apuntes sobre funciones Javascript

Pues hace ya un rato desde el último articulo. Hoy me he inspirado y he hecho algunas pruebas de funciones en Javascript. Básicamente de diferentes forma de crear funciones, he aquí mis resultados no tan científicos y no tan estudiados ^-^.

Formas de crear funciones:

Hay diferentes formas de crear funciones, y dependiendo de lo que quieras hacer quizá quieras usar una o otra. Aun que generalmente no importa como declares tu función, nada mal hace el saber.

Lo más conocido:

La forma más sencilla y conocida de declarar funciones es la siguiente:

function alertar(){
     alert('ups!');
}

De esta manera hemos creado una función, y para llamarla solo necesitamos hacer referencia a ella:

alertar();

Así que, que hay de especial con esta forma de declarar funciones? Probablemente no mucho, excepto claro que te deja llamar a la función aún antes de que esta sea declarada:

alertar();

function alertar(){
   alert('ups!');
}

Pero probablemente eso ya lo sabias. Lo que es más, probablemente pensabas que es la forma en que todas las funciones reaccionan. Sin embargo no es así.

Otro metodo:

La siguiente es otra forma también muy conocida de crear funciones, pero que se comporta de forma un poco diferente a la forma que hemos visto anteriormente.

Se puede asignar una función a una variable:

var alertar = function(){
   alert('ups!');
}

Solo que a diferencia de la forma que hemos visto anteriormente, esta no te deja llamar funciones que no hayan sido declaradas previamente. Es decir que lo siguiente:

alertar();

var alertar = fucntion(){
   alert('ups!');
}

nos tira un error. La razón de esto tienes que ver con la declaración de las variables, pero en este post no voy a entrar en detalles con respecto a ese asunto. Así que si esta forma de declarar funciones tiene ese “problema” por que querríamos usarla? bueno, hay momentos en los que esa es la forma en que queremos declarar una función. Por ejemplo, cuando agregamos métodos a un objeto como veremos más adelante, o cuando queremos crear funciones auto ejecutables.

Funciones auto ejecutables

También se pueden crear funciones que se auto ejecutan al momento de ser leídas.

var alertar = function(){
   alert('ups!');
}();

Los paréntesis al final de la función le dicen al motor de javascript que la función debe ser ejecutada tan pronto sea leída. Esto probablemente no parezca útil al principio ya que la función deja de existir al momento en que se ejecuta, pero hay ocasiones en las que eso es lo que queremos hacer. Para comprobar esa temporalidad de la función puedes intentar lo siguiente:

var alertar = function(){
   alert('ups!');
}();

alertar();

Para poder crear funciones auto ejecutables es necesario usar la sintaxis:

var variable = function(){}

ya que si queremos usar la sintaxis del primer ejemplo (function funcionName(){}) obtenemos un error. Esta es una de las ocasiones en que queremos usar esta sintaxis que parece tener una desventaja al no dejarnos llamar a las funciones antes de que sean declaradas.

Pero ya en serio, por que queríamos hacer una función que se va a perder en el limbo tan pronto sea leída, lo que quiere decir que no la podemos volver a llamar en ningún otro momento? Una de las utilidades que yo le he encontrado es para solucionar problemas con el ámbito de las variables mediante closures, pero ese es otro tema. Lo único que voy a dejar es el siguiente ejemplo:

var alertar = function(){
   return function(){
      alert('ups!');
   }
}();

alertar();

De esta manera la función auto ejecutable puede ser llamada en cualquier momento, aun que al ejecutarse al inicio, cuando es leída, no ejecutará el alert ya que esta en la función que es regresada al ejecutarse la función exterior. Este es otro ejemplo que se ve sin sentido, pero sin embargo, es muy útil en ciertas ocasiones.

Funciones anónimas

También se pueden crear funciones anónimas de la siguiente manera:

(function(){
   alert('ups!');
});

Solo que como esta función es anónima no hay forma de llamarla después, por lo que la única forma de poder usarla es haciéndola auto ejecutable:

(function(){
   alert('ups!');
})();

Esta sintaxis es especialmente útil cuando queremos crear pseudo namespaces para evitar problemas de compatibilidad cuando usamos diferentes librerías. Aún que no es la única forma de lograr esto, si es una forma elegante y que a más de un novato lo hará verse como un “pro”.

El constructor

Por último veamos la forma menos recomendable, pero probablemente más poderosa, de crear funciones. Esta función es usando el operador new para crear un objeto Function. Esta es una  bestia peligrosa y recomiendo que sea evadida, pero de cualquier modo vamos a tocarla por el simple gusto de hablar de ella.

Para declarar una función de esta manera se hace de la siguiente forma:

var alertar = new Function('arg1','arg2','alert("ups1");');

en donde arg1 y arg2 son los argumentos que le queramos pasar a la función. Se pueden pasar tantos como se desee. El motor de Js sabe que el último set de comillas es el que contiene las instrucciones a ejecutar. Esta sintaxis es especialmente útil cuando se quieren crear funciones al vuelo o dar la oportunidad al usuario de crear sus propias funciones. Como dije, esto es una bestia y es mejor alejarse de ella a menos que sepas lo que estas haciendo y no tengas otra opción.

Ys estaré escribiendo un poco más sobre funciones ya que hay un par de cosas que se quedan pegadas al teclado por el momento. Espero sus comentarios.

Calculando el tamaño de los scroll.

Muy seguido vemos efectos tipo scroll, ya sabes, los que tiene una barrita para subir y bajar el contenido

EL problema que he visto con muchos de ellos es que sin importar cuanto contendido haya en ese scroll, la barra siempre queda del mismo tamaño, eso no nos da nada de información en cuanto al contenido que ha quedado “escondido” como sucede con los verdaderos scroll del navegador. Por ejemplo, si entras a una pagina con una mini barrita de scroll, entonces al instante sabes que el contenido es, oh God, para que te cuento (eso quiere decir, muy largo, por quien no entienda la forma en que hablamos los Mexicanos).

Seguramente la razón de esto es por que no sabemos como calcular el tamaño correcto de la barra de scroll. Hace un tiempo descubrí que ese tamaño es relativo a las veces que el tamaño de la ventana cabe dentro del tamaño del contenido. Es decir que, si tienes un contenido que es en total 1000px de alto, y una ventana de 500px de alto, la ventana cabe dos veces en el contenido, por lo que el scroll debe caber dos veces en la ventana. Probablemente una imagen te ayude a entender mejor el concepto:

De modo que para poder calcular el tamaño del scroll, bastará con aplicar la siguiente formula:

S = (c/C)c

En donde:

S es el valor que queremos obtener (la medida del scroll)
C es la altura del contenido
c es la altura del contenedor.

Entonces si tuviéramos un contenido de 1000px de altura dentro de un contenedor de 500px de altura, la substitución de la formula por los valores sería la siguiente:

S = ( 500 / 1000)500;

Lo que nos da como resultado:
S = (0.5) 500

S = 250;

Y esto reflejaría exactamente la cantidad de contenido que hay ‘oculto’ en el scroll de modo que el usuario pueda hacer un calculo visual, cosa que hacemos sin darnos cuenta.

Por que es importante el tamaño de la barra de scroll? Porque esta le da una especie de feedback al usuario mediante el cual se puede dar cuenta de cuanto contenido hay oculto. Pero hay otras razones. Por ejemplo, cuando tenemos un contenido que es un 120% el tamaño del contenedor, es decir que 20% de la información queda oculta, pero nuestra barra de scroll es demasiado pequeña, al moverse esta barra, el contenido parecerá que sigue siendo estático, por el contrario, si el contenido oculto es demasiado y la barra de scroll es demasiado grande, al moverla un poquito, el contenido se moverá demasiado haciendo la barra prácticamente incontrolable.

La web verde.

En los últimos años ha habido un chispazo en el movimiento ecologista. Cada vez más gente se une a este movimiento y empieza a cambiar el rumbo que llevamos en el tema ecológico. Hemos llegado al punto en que es necesario estar conscientes de que nuestros actos afecta el medio ambiente de una forma positiva o negativa y que hasta la fecha, el efecto ha sido mayormente negativo. Curiosamente, durante años hemos estado tratando de salvar el medio ambiente si darnos cuenta que realmente quienes están en peligro somos nosotros mismos, los seres humanos. El medio ambiente seguirá estando aun cuando nosotros nos hayamos extinguido y muy seguramente la tierra podrá regenerarse y curarse a sí misma cuando nosotros ya no estemos.

Durante mucho tiempo la raza humana fue la raza dominante de este planeta, pero ahora nos hemos convertido en una enfermedad. El planeta tierra está enfermo, y su enfermedad se llama humanidad. Sin embargo, es esa misma enfermedad la que podría empezar la recuperación de nuestro único hogar. Somos nosotros quienes tenemos la llave hacia un nuevo futuro que promete un ambiente más natural y menos contaminado.

Que tiene que ver esto con la web? no mucho al primer vistazo, pero cuando miras más adentro te das cuenta que hay mucha relación, no tanto con el problema como con la solución. Todo aquel que se dedique al desarrollo web tiene entre sus manos un poder enorme de comunicación el cual puede usar para bien o para mal. No se trata de comenzar a crear sitios web dedicados al cuidado de la naturaleza y la protección ambiental. La web verde es más acerca de enviar un mensaje de forma sutil, de desarrollar sitios que consuman menos recursos, sitios que requieran menos tiempo para el logro de objetivos de modo que el tiempo de conexión sea reducido, reduciendo así el consumo de energía. La web verde es sobre el diseño de logotipos e interfaces basados en los elementos naturales. Tomemos por ejemplo el logotipo de apple, una manzana. Independientemente de que la empresa haya sido “castigada” por Greenpeace*, el mensaje, muy probablemente inconsciente, de su logotipo es totalmente orgánico. Imagina una web en la que cada sitio envía un mensaje de este tipo al usuario. Esa sería sin duda una de las contribuciones más nobles de los desarrolladores web.

Es claro que sería necesario hacer una investigación profunda sobre el impacto que la parte visual de un sitio web tiene en el subconsciente del visitante, pero no hace falta ser un experto para darte cuenta que al entrar en un sitio web en el que la primer imagen que vez es un bosque verde con toda su biodiversidad expuesta tu forma de ver la vida cambia por un instante. Un instante parece no ser mucho, pero la vida está hecha de instantes y el cambio se hace con pequeños actos conectados el uno con el otro por un corto tiempo. Es decir, pequeños instantes de buenas acciones seguidos uno tras otros.

Como un ejercicio mental, ve google y concentrate en su favicon. Ahora piensa en lo que ese favicon te sugiere. Chances hay de que a tu mente vengan imágenes relacionadas con la naturaleza. Ese es el impacto que las imágenes tienen en nuestro subconsciente. Ahora imagina una web plagada de mensajes del mismo tipo.

Alguien me dijo en un foro que muchas veces mis mensajes son utopías. Me gusta pensar que soy un soñador y tener sueños como el da la web verde porque en toda la historia los únicos que fueron capaces de dejar huella y lograr algo fueron aquellos que tuvieron un sueño. Me gustaría que te unieras a mi sueño y que la siguiente vez que estés desarrollando un sitio web lo hagas de forma más consciente sobre el mensaje que envías con tus imágenes logotipos y demás y que pensaras en reducir el tiempo necesario para el logro de objetivos así como el consumo de recursos requeridos para lograr dichos objetivos. Usemos nuestro talento y conocimiento para un fin menos egoísta que mero hecho de ganarnos la vida y empecemos a pensar en preservar la vida. No solo la nuestra, sino la de los demás seres con quienes compartimos el planeta y la de las futuras generaciones.

*http://ecomundo.servital.es/apple-apoya-la-ecologia-%C2%BF-estrategia-o-compromiso/