No todo lo grátis es bueno!

Desde que trabajo de manera independiente he tenido que ser más paciente e incisivo sobre las preferencias de los clientes, sobre todo cuando hay diseño gráfico involucrado, la mayoría de las veces no saben por cual muestra decidirse o escogen la que menos me gusta, irónico pero cierto. Aveces llega lo que defino como “clientes celestiales” estos ya saben lo que quieren, tienen bastante tiempo con el concepto en su cabeza y son muy decididos, la mayoría del tiempo ya poseen algunas muestras de lo que quieren o intentos hechos por otros freelancers que han fallado en completar el proyecto.

Hace semanas me contactaron para diseñar/desarrollar un sitio web completo, lastimosamente no puedo divulgar mucho sobre la finalidad del mismo, solo puedo decir que si todo va bien podría ser Trend Topic en twitter muy pronto, lo curioso es que fue uno de esos “clientes celestiales”, decidido y bien centrado en lo que quiere, tan atento que me proporciono algunas plantillas a modo de inspiración, estas plantillas para WordPress las había descargado de un sitio famoso, lo mejor de todo es que como el refirió, la plantilla “es gratis”.

Luego de examinar la plantilla en cuestión, me encontré con una linea bastante “diferente”, check this out:

La linea que me llamo la atención
Linea malvada!


WTF!, eso no parece un código común de una plantilla de WordPress, luego de decodificar varias veces esa linea me encuentro con esto:

Código Verdadero
Lo que escondia la linea en base64


Examinando el código observamos que no es tan grave, no están tratando de explotar una vulnerabilidad o algo parecido, solo están colocando publicidad, pero creo que a mi cliente no le hubiese gustado tener esa publicidad en su sitio. Moraleja… no todo lo gratis es bueno, siempre debemos al menos pasarle un antivirus al contenido que descargamos por la web, saludos.

Manejando Fechas al Programar (PHP)

La manera más facil y efectiva de manejar las fechas cuando estas desarrollando una aplicación (en este caso usando PHP) es usar fechas en formato “UNIX timestamp“. Podemos definir a las fechas en formato UNIX timestamp como la cantidad de segundos que han pasado desde 1 Enero, 1970 a las 00:00:00 GMT, lo que nos permite facilmente ejecutar calculos para transformar valores de fecha y tiempo.

Pero este formato no es perfecto, tiene características que pueden afectar tanto su uso como el funcionamiento, una de ellas es que no es leible por humanos normales (a menos de que seas Sheldon Cooper), por ejemplo si me preguntaras ¿Qué día es hoy? y te respondo 1309666385 ¿Estarías en capacidad de interpretar el numero y obtener la fecha en que necesitas?, seriamente lo dudo.

El otro inconveniente es que este formato solo puede usarse en un rango limitado dependiendo del Sistema Operativo. En sistemas basados en GNU/Linux puedes retroceder hasta el año 1902 y avanzar hasta el año 2037. En Windows el limite menor es “Enero 1, 1970” debido al tamaño del numero en UNIX timestamp. Cualquier Sistema Operativo puede manejar enteros hasta un tamaño especifico (2 levado a la 32, o 4.249.967.296 para 32 bits) despues de esta cifra se necesita más trabajo para manejar numeros grandes. Por materia de eficiencia este “maximo” es impuesto para valores importantes como horas y fechas. Linux permite tener valores negativos para ambos y por ende puedes obtener fechas anteriores al limite menor. Algunos se preocupan por estos limites, inclusive acuñan al problema como un segundo Y2K, yo tengo la confianza de que para el 2038 ya todos los Sistemas Operativos de 32 bits habran sido reemplazados y no esto no será un problema.

Lo anterior deberia preocuparte si estas pensando desarrollar una aplicación que necesite planificar tanto para el futuro como para el pasado o que simplemente permita el registro de personas donde uno de sus campos sea la fecha de nacimiento, pero para todo existe una solución. Existe otra razón para estar pendientes y es debido a la presentación de las fechas en numeros enteros, por ejemplo si tenemos la fecha Enero 2, 1970 en formato UNIX sera mucho mas corta en digitos que Mayo 13, 2009. Si vas a almacenar fechas o horas en formato UNIX timestamp en una base de datos asegúrate de que el campo tenga una longitud de 10 digitos y eso bastara para almacenar fechas lo suficientemente largas para mantener tu sistema ejecutandose unos cuantos años.

MySQL tiene su propio formato de timestamps y es mas sencillo de usar, su formato es “YYYY-MM-DD HH:MM:SS” y normalmente es almacenado en su propio tipo de columna llamado “datetime”. Si necesitamos usar comparaciones y ordenamiento simple este formato funciona muy bien usando las funciones internas del RDBMS; adicionalmente tienen la ventaja de ser legible por humanos y su longitud es predecible lo que lo hace más fácil para validar, pero si necesitamos que nuestra aplicación sea flexible a la hora de cambiar de manejador de base de datos y no dependa tanto de funciones internas de MySQL es preferible usar UNIX timestamps.

A la hora de hacer operaciones complicadas relacionadas con fechas u horas terminaras convirtiendo todo a UNIX timestamps, haciendo tantas conversiones manejando grandes porciones de datos probablemente caigas en el uso excesivo de recursos de Hardware altamente valiosos que pueden aminorar la velocidad de tu aplicación. Yo era estricto al usar MySQL timestamps y casi todas mis aplicaciones “viejas” las usan pero luego de estudiar más el tema comprendí la ventaja de usar UNIX timestamps.

La epifania llega al momento de hacer operaciones con intervalos de tiempo, es mucho mas facil usar UNIX timestamps a la hora de hacer ordenamiento, adiciones, substraciones y comparaciones entre dos fechas, ayuda a mantener consultas mas simples y a no comprometer la compatibilidad de tu aplicación si Oracle decide cambiar alguna funcionalidad de MySQL. En PHP tal facilidad viene de mano de la función “mktime()” que nos permite construir Unix timestamps usando segundos, minutos, horas, meses, dias y años de la fecha/hora necesaria. Imaginandonos que tenemos un sistema con millones de usuarios (Facebook, twitter, etc.) y donde cada bit de información es importante yo seguiria usando UNIX timestamps dado a que los campos “date” y “datetime” ocupan más espacio que uno “INT(10)”, quizas les paresca descabellado pero cuando tenemos 500 millones de usuarios cada bit (termina acumulandose y formando petabytes) de información que se almacena o se transmite a traves de DataCenters localizados en distintas partes del mundo es muy importante que esa data sea la más depurada y liviana posible, tal principio parece innecesario para una pequeña aplicación, pero su uso ahora puede ser un salvavidas mañana.

Finalmente es tema de opinion, MySQL también ha incluido funciones internas que hacen el manejo de UNIX timestamps más sencillo y flexible, eres libre de estudiar el tema y opinar al respecto en la sección de comentarios. Saludos.

Diferencia entre Clases Abstractas e Interfaces (PHP)

Como siempre hay amigos, familia, amigos de la familia, entusiastas del SL y de la Programación que encuentran mi correo por internet o me conocen por referencia y aprovechan la oportunidad para hacerme preguntas sobre temas diversos, en esta oportunidad 3 personas diferentes que estan comenzando a programar en PHP y estan estudiando el paradigma de la Programación Orientada a Objetos se han estado confundiendo mucho con las definiciones de Clases Abastractas e Interfaces proporcionadas en la documentación oficial de php.net y esta publicación es un intento para diluir esas dudas adicionalmente aprovecho esta oportunidad para disculparme con ellos pues prometí escalercer las dudas antes, pero esta semana los problemas terrenales me alcanzaron y tuve que lidiar con las diligencias/molestias/atenciones que conlleva una operación de emergencia, dando gracias porque todo salio bien y no hubo inconvenientes mayores.

¿Qué son las Clases Abstractas?

Las clases abstractas son clases normales con super poderes capacidades especiales, dado a que sus propiedades y metodos que pueden ser implementados o no dependiendo a las reglas del juego, pero, como sucede esto?, no hay mejor manera de explicarlo que con un ejemplo extraido de la documentación de php.net


class Fruta {
private $color;

public function comer() {
//Masticar
}

public function setColor($c) {
$this->color = $c;
}
}

class Manzana extends Fruta {
public function comer() {
//Masticar hasta llegar al Centro
}
}

class Naranja extends Fruta {
public function comer() {
//Pelar la Naranja
//Masticar
}
}

Instanciamos la clase, es decir, te doy una manzana y tu te la comes.


$manzana = new Manzana();
$manzana->comer();

Al finalizar el metodo “comer()”, podrías decir a que te supo la fruta, la respuesta sería a Manzana pues fue lo que te di y si te diera una fruta de manera generica…


$fruta = new Fruta();
$fruta->comer();

A que te supo la fruta?, no tiene mucho sentido ya que no deberias haber podido comerte la fruta pues no deberia funcionar de esa manera, en algun punto deberia de existir una restricción en la implementación de metodos y propiedades, por eso es que deberia declarar la Clase Fruta como abstracta y a su vez el metodo “comer()” que esta contiene.

Ejemplo:


abstract class Fruta {
private $color;

abstract public function comer()

public function setColor($c) {
$this->color = $c;
}
}

¿Que son las Interfaces?

Pensemos en las interfaces como declaraciones de metodos que objetos en comun pueden compartir, inclusive si esos objetos no guardan relación ninguna. Digamos que tenemos una serie de objetos que mediante la herencia no pueden conectarse o no pueden heredar metodos de un objeto padre ya que no tendria sentido, aqui es donde la interfaz juega un papel muy importante, por supuesto no hay mejor manera de explicar esto que con un ejemplo:


interface interaccion {
public function encender() {
//Procedimiento para encender
}

public function apagar() {
//Procedimiento para apagar
}
}

class lampara implements interaccion {
//Heredada de la Interfaz
public function encender() {
}
//Heredada de la Interfaz
public function apagar() {
}
}

class automobil implements interaccion {
//Heredada de la Interfaz
public function encender() {
}
//Heredada de la Interfaz
public function apagar() {
}
}

Espero que los ejemplos hallan sido suficientes para lograr su comprensión sobre el tema y en palabras finales podemos resumir que la diferencia entre las clases abstractas y las interfaces es que cada una se utiliza para disgregar y discernir limites en la estructura de la aplicacion que se quiere construir usando el paradigma de “Programación Orientada a Objeos”. Las interfaces nos permiten compartir comportamientos entre objetos no relacionados mientras que las clases abstractas nos permiten limitar y/o definir con precisión las capacidades de cada objeto.