Este es rapidito y fácil, pero muchas veces cuando maquetas algo con columnas tienes el problemilla de los fondos… que no sabes el contenido que meterán en cada una de las columnas y resulta complicado que queden de la misma altura… pues bien, como de momento CSS3 está un poco lejano en este aspecto (algunos navegadores nos traerán problemas con ello), con un rápido jquery lo solucionamos, bueno bonito barato, aquí tenéis, tiene poco secreto pero es útil, os dejo el código:

$(document).ready(function() {
    var altMax = 0;
    ajustarAlturas(altMax, '.contenedor div');
});
function ajustarAlturas(altMax, elemento) {
    $(elemento).each(function(i) {
        var xL = $(this).height();
        if (xL > altMax) {
            altMax = xL;
        }
    });
    $(elemento).css('height', altMax);
}

HTML y CSS simplemente para resaltar las columnas y ver que está correcto:

<div class="contenedor">
    <div class="ajustable">lorem ipsum lorem lorem</div>
    <div class="ajustable">lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem</div>
    <div class="ajustable">lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem lorem ipsum lorem lorem</div>
</div>

.contenedor{
    position:relative;
    overflow:hidden;
    border:1px solid #DDD;
    background-color:#EFEFEF;
}
.ajustable{
    position:Relative;
    float:left;
    padding:1%;
    margin:1%;
    width:29.3%;
    background-color:#FAFAFA;
    font-size:13px;
}

Podéis ver el ejemplo funcionando aquí.

Un saludo, espero que vayamos subiendo más experimientos :-)

Hoy  se trata de geolocalización mediante el Api de Google Maps (con sensor true).

Esta sí que no tiene secreto ninguno, como veréis no es más que activar el sensor (true) y un pequeño método de unas líneas.

var map;
function initialize() {
    var myOptions = {
        zoom: 6,
        center: new google.maps.LatLng(38.977029166667,1.5129795833333),
        mapTypeId: google.maps.MapTypeId.ROADMAP
    };
    var map = new google.maps.Map(document.getElementById('mapa'), myOptions);
    if(navigator.geolocation) {
        navigator.geolocation.getCurrentPosition(function(position) {
            var posicion = new google.maps.LatLng(position.coords.latitude,
                position.coords.longitude);
            map.setCenter(posicion);
            var marker = new google.maps.Marker({
                position: posicion,
                map: map,
                icon: "http://negociosenibiza.com/web_img/red.png"
            });
        }, function() { handleNoGeolocation(true); });
    } else {
        handleNoGeolocation(false);
    }
}
function handleNoGeolocation(errorFlag) {
    if (errorFlag) { alert("El servicio de Geolocalización ha fallado"); }
    else { alert("Tu navegador no soporta Geolocalización"); }
}
google.maps.event.addDomListener(window, 'load', initialize);

Podéis ver el ejemplo funcionando aquí.

Un saludo, espero que vayamos subiendo más experimientos :-)

Son entradas muy breves, de distinta índole (Estructura, Elementos, etc…) que luego podremos ir recuperando y crear un gran tutorial, pero paralelamente a eso, vamos a empezar a hacer algunos pequeños scripts y publicarlos.

La verdad es que en local tenemos miles de pruebas que vamos haciendo cuando sale algo nuevo, y el otro día pensamos… ya que igualmente lo hacemos en local, porque no subirlo y lo compartimos, siempre podemos ganar algo más (comentarios, mejoras, etc…).

El primero que voy a subir, se trata de subir ficheros con la ayuda de la API de HTML5.

El ejemplo está en PHP, pero podéis pasarlo rápidamente al lenguaje que os haga falta, realmente la forma de recibir los ficheros y subirlos es lo de menos, lo interesante es ver cómo los almacena el cliente y los pasa al fichero de servidor.

En realidad el código no tiene demasiado secreto, el HTML es simplemente un formulario con un input file

<form method="post" enctype="multipart/form-data"  action="upload.php">
    <input type="file" name="imgs" id="imgs" multiple />
</form>
<div id="ajax"></div>
<div id="imagenes"></div>

Y el javascript, también es bastante claro, únicamente utilizamos FormData(), añadimos un evento y vamos añadiendo ficheros, leyéndolos con FileReader(), al final un ajax para mandar todo al PHP, pero también es irrelevante para mostrar esto…

var formdata = new FormData();
document.getElementById("imgs").addEventListener("change", function (evt) {
    $("#ajax").html("Subiendo");
    var i = 0, len = this.files.length, img, reader, file;
    for ( ; i < len; i++ ) {
        file = this.files[i];
        if (!!file.type.match(/image.*/)) {
            if ( window.FileReader ) {
                reader = new FileReader();
                reader.onloadend = function (e) {
                    $('#imagenes').append('<img src="' +e.target.result+ '" />');
                };
                reader.readAsDataURL(file);
            }
            formdata.append("imgs[]", file);
        }
    }
}, false);

El PHP en realidad da igual, simplemente recibe los ficheros y los copia en el servidor.

La idea me vino de este experimento de mozilla.

Un saludo, espero que vayamos subiendo más experimientos :-)

Debo reconocer que hace un tiempo jamás hubiera pensado así. Ni por asomo…

Pero también debo reconocer, que en algunos casos, creo que no hay otro modo de avanzar. Y no solo de avanzar en el trabajo, o de avanzar tú, individualmente como desarrollador… Hablo de avanzar en general, de avanzar todos los desarrolladores, los estándares, la web como parte de un todo.

Puede que unos ya hayáis llegado a esta conclusión, puede que otros no, o que simplemente alguna vez os hagáis una serie de preguntas.

Pues bien, esas preguntas para mi ya tienen respuesta.

No hay modo alguno de trabajar, y sacar adelante los proyectos, y a la vez estudiar y practicar las novedades que trae el mundo web, pulirlos y luego aplicarlos, que, parece el procedimiento lógico… el problema empieza a ser realmente serio cuando cada semana hay nuevos cambios y novedades, que tienes que probar y aprender si no te quieres quedar cada vez más descolgado, cosa que te mataría profesionalmente, pero no solo eso… si no que a la vez, los clientes que tienes pasarían a estar todos desactualizados… y en el fondo, ya no serías el desarrollador que quieres ser, que está a la última, que aprende cada día, etc…

Yo antes, sin ninguna duda era de esos de aprender, probar, dominar totalmente, y luego ejecutar en clientes, ejecutarlo primero en los nuevos, aprovechando desarrollos desde 0, y luego poco a poco, ir reemplazando los antiguos hasta que más o menos todo estaba controlado.

Pero claro, ¿ahora cómo lo haces?, si estás puesto en el html5 y lo sigues, verás como cada día hay novedades, en el mundo css3 también, en las compatibilidades de navegadores… ya es que ni lo menciono, pero es uno de los quebraderos de cabeza que parecía que tarde o temprano se arreglaría, y lo único que sucede es que se agrava ese problema.

Y claro está, el mundo móvil ;-) Que aquí sí que es para darles de comer aparte… porque si básicamente te centras en apple/android, aún te salvas, pero como quieras llegar más allá… ya puedes empezar a prepararte cafés.

Por tanto, ¿solución? No queda otra que los proyectos de tus clientes pasen a ser tu campo de aprendizaje, si no lo haces así, amigo… estás jodido.

A la larga, también tus clientes, porque no puedes darles ese plus de innovación, o de estar totalmente a la última, por tanto no les costará entenderlo… siempre que tengas un buen sistema de tickets o de control de proyectos y puedas monitorizar todos los errores y solucionarlos, es decir, organízate, o estás vendido.

Ah, y luego viene lo peor de todo… mirar atrás. Una vez que has pasado a NodeJS este proyecto (o JADE, o STYLUS), HTML5 bien trabajado… ahora mira atrás, a los otros proyectos, y llora ;-)

En resumen, que si estás en esto porque te gusta, porque es tu vocación, porque te apasiona y vives el día a día como más te gusta… que es programando y aprendiendo: ENHORABUENA, y si no es así… ESTÁS JODIDO, cambia de trabajo YA. Os lo dice alguien del primer grupo ;-)

Un saludo!

Imagen de Flickr (konch)

¿Quién, a día de hoy, no tiene instalada alguna app en su smartphone?

Una de las cosas que me cuesta entender en la mayoría de ocasiones (hay otras en las que sí lo entiendo), es el porque molestarse en programar una App para móvil, pudiendo adaptar la web. Es más, no solo porque molestarse en programarla, si no también el usuario en instalarla… Si te lías a instalar Apps, te quedas solo, no termino de entender el propósito, exceptuando algunas que realmente si son útiles.

Desde el punto de vista del desarrollador, pasa un poco lo mismo, ya que tienes que programar específicamente con determinados lenguajes en función del móvil para el que vas a desarrollar la aplicación.

Por poner un ejemplo sencillo… ¿Para qué una app móvil que busca hoteles según tus preferencias de búsqueda, si tuya tienes una web de búsqueda de hoteles?… ¿No es má sencillo (tanto para tí como para el usuario) utilizar la web, y prepararla para la versión móvil? ;-)

Conclusión

Desde mi punto de vista, y siempre que puedo, prefiero desarrollar web para dispositivo móvil antes que app para el móvil, así se aprovecha más la infraestctura montada.

Es más, lo veo mejor desde 3 puntos de vista:

• El usuario, que no se va a instalar cientos y cientos de aplicaciones.
• El desarrollador, que “simplemente” (que también tiene trabajo…) tendrá que adaptar el visionado de la web o aplicación web.
• La marca y/o web, que compartirá bases de datos y funcionalidades, y centralizará un poco el control (al dispersar más, siempre pierdes algo de control y dependes de más factores)

PS: Ojo, estoy hablando siempre desde el punto de vista en que el app pertenece a una web o similar pudiendo compartir funcionalidades, bases de datos, llamadas, etc… Es decir, no veo extraño programar y utilizar una app para jugar al ajedrez, por poner un ejemplo :-)

Por ejemplo, vamos a crear una vista de un listado con el controlador index:

En “application/controllers/” tenemos nuestro “indexController.php”, no vamos a crear otros controladores de momento, vamos a ir a lo básico.
En “application/views/scripts/index/” tenemos “index.phtml” y vamos a crear “lista.phtml” de momento vacío, más abajo le metemos mano.
Luego, en  ”application/layouts/scripts/” tenemos nuestro “layout.phtml”, que puede quedarse igual de momento.

Let’s go:

application/controllers/indexController.php

Dentro de esta clase, meteríamos este método:

public function listaAction()
    {
		$this->view->listado = "Listado...";
		$this->render();
    }

Evidentemente cuando hacemos el “$this->view->listado” ya nos ocuparíamos de recoger ese listado de base de datos, o de sesión, etc… pero por ahora vamos con lo básico.

Si os fijáis simplemente renderizamos.

application/views/scripts/index/lista.phtml

echo $this->listado;

Y en la vista (“lista.phtml”) no hay más historia que pintar el listado que le pasamos desde el controlador.

Desde el controlador, más adelante, accederemos a la base de datos, sesión, etc… lo único que nos tiene que preocupar ahora mismo, es entender que al ejecutar en el navegador:

http://localhost/nombredelaaplicacion/index/lista

Se ejecutará dentro del indexController.php el método listaAction() y sacará su resultado (si lo tiene, renderizado…) en la vista index/lista.phtml

Si ejecutáramos:

http://localhost/nombredelaaplicacion/index/test

Se ejecutará dentro del indexController.php el método testAction() y sacará su resultado (si lo tiene, renderizado…) en la vista index/test.phtml, como no tenemos ni uno ni otro, saltaría error (que también aprenderemos a atraparlos y configurarlos)

Estas últimas semanas he estado leyendo muchas opiniones en la red acerca de diferentes lenguajes de programación, y frameworks. Es un tema del que se habla hace años, pero parece que ahora está muy en auge, y eso me ha animado a pensar en ello un poco más, y dejarlo a modo de opinión.

No deja de ser curioso la forma que tienen muchos de defender “lo suyo”. Sea un sistema operativo, un lenguaje de programación, o un framework. A veces nos ponemos de un tonto que no veas, y me incluyo, porque con el tema “GNU/Linux Vs Windows Vs Mac” siempre acabo dando la brasa, y en ocasiones me convierto en un auténtico talibán, cosa que por otra parte odio. Curioso, ¿no? :-)

Me he dado cuenta que este defecto muchas veces no nos deja ver más allá, y entender que motiva a otra gente a utilizar algo que a tí no te gusta, o que no es tu predilecta. Y “cosa” puede ser, como he dicho antes, un sistema operativo, una marca de ordenadores, un lenguaje de programación, librería, framework… Lo que queráis.

Cuando necesitas elegir algo de lo anteriormente citado, en que puntos basarse para la elección:

• 1. Lo que tu necesitas del mismo, es decir, para que vas a utilizarlo
• 2. Las características que tiene
• 3. El conocimiento/comunidad que hay en la red, para poder consultar, preguntar, etc…
• 4. Tu conocimiento del mismo (esta opción, es evidente que al inicio de la elección es nulo, pero cuando has probado varios, tus conocimientos del mismo son importantes)
• 5. Gustirrinín (Tu sensación al utilizarlo)

¿Por qué? Pues muy simple, analizando sobretodo los puntos 1 y 2, te das cuenta de que muchas elecciones jamás se darían, porque habría muchos “empates” (elecciones que cumplen ambos puntos porque tienen lo que necesitas). Ahí ya entra el criterio personal de cada uno, lo a gusto que se siente uno eligiendo esa opción (El “gustirrinín”)

Yo puedo sentirme más cómodo con GNU/Linux y otro con Windows, y en realidad, que cada uno tenga lo que quiere del mismo. Si, es muy raro que defienda la elección de windows, pero qué coño… pensadlo fríamente, si alguien necesita el word, un navegador y el msn messenger, tampoco le va a hundir utilizar windows.

¿Que si lo probara con ubuntu (por la facilidad de uso comparada a windows) acabaría haciéndose con ello? Pues si, pero tiene que querer hacerlo, no a todos nos gusta cacharrear, probar, cambiar… (Ojo, el tema de windows es solo un ejemplo).

Con un lenguaje y/o framework pasa igual, puedes probar varios y cuando das con uno que te gusta y cumple tus necesidades lo acabas adoptando, y al final, ¡defendiendo!

Hace un tiempo, pidiendo consejo a alguien que considero de los mejores programadores a mi alcance sobre que opción elegir, me acabó diciendo… Muchos de ellos tienen ventajas similares, al final, “decídete por el que te parezca más sexy”.

Interesante forma de decirlo, pero no deja de ser la verdad, siéntete cómodo, es tu herramienta.

Advertencia: A la hora de instalar el Zend Framework (para instalarlo debería bastar con un aptitude, os recuerdo las diferencias entre apt-get y aptitude) os daréis cuenta de que las librerías se pueden llamar desde diferentes sitios. Podéis optar por duplicarlas en todas vuestras aplicaciones, y tenerlas en la carpeta “library” dentro de “application” o podéis nutriros de las librerías en un directorio común, es muy sencillo y no os dará ningún problema.

Lo siguiente que yo haría sería un alias apuntando al Zend Framework  en mi máquina queda así:

$> alias zf=’/usr/share/php/ZendFramework-1.10.0/bin/zf.sh’

Para que al pulsar “zf” en vuestra shell se ejecute el comando directamente, para saber si está bien instalado, bastaría con hacer un:

$> zf

De este modo os debería salir una ayuda de Zend en la que os explica los comandos que podéis utilizar, etcétera.

Una vez instalado el Zend Framework os váis a vuestro directorio donde tengáis localhost y hacéis:

$> cd /var/www/
$> zf create project aplicacion
$> ls aplicacion

Al hacer el “ls” veréis como Zend ya os crea la estructura básica de Zend Framework:
application/
—— configs/
—— controllers/
—— models/
—— views/
library/
—— Zend/
public/
tests /

Bien, vamos por buen camino, para que lo sepáis, el navegador tiene que apuntar a “public” para que se ejecute la aplicación web, por tanto, id a vuestro navegador (explorer no lo es) y teclead:

http://localhost/aplicacion/public/

Debería saliros el hello world de Zend, si no os saliera y obtuviérais un error en el que os dice que no encuentra “Zend/Application.php” es porque no encuentra las librerías (las que os expliqué al inicio), en ese caso o las ponéis dentro de “library” (y os quedaría library/Zend) o cambiáis las rutas.

En el próximo apunte destriparemos un poco la aplicación y haremos un layout (por ejemplo).

Objetivo del apunte:

• 1. Refrescar la memoria con el patrón MVC.
• 2. Mostrar el Árbol de archivos en una aplicación básica de Zend Framework.

1. Patrón MVC

Para quien no haya trabajado con el patrón MVC (modelo vista controlador) lo explicaré un poco por encima, y así a partir de aquí será más sencillo entenderlo todo.

La lógica a la hora de programar nos dice que el interfaz de usuario cambia con más frecuencia que los almacenamientos de datos y la lógica de negocio, por tanto si mezclamos en nuestras aplicaciones los componentes de interfaz, los de negocio y los de almacenamiento tendremos como consecuencia las famosísimas ñapas[1] ya que cuando queramos cambiar la interfaz tendremos que modificar muchos componentes de negocio (o todos!).

El patrón MVC se basa en la reusabilidad y la facilidad de cambios (mantenimiento del software) y separa los datos, la interfaz y la lógica de negocio en tres componentes: Modelos, Vistas y Controladores.

• Modelo: El modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. En el caso de Zend Framework se compone básicamente de archivos .phtml que se podrán reutilizar a modo de plantillas (o no, a gusto del consumidor)
• Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

2. Árbol de archivos en una aplicación básica de Zend Framework.

Os dejo la estructura básica de archivos que se utiliza en el Zend Framework:

Aplicación
application/
—— configs/
—— controllers/
—— forms/
—— layouts/
—— models/
—— modules/
—— views/
library/
—— Zend/
public/
tests /

Como podéis apreciar, a primera vista ya se ve el MVC: controllers, models, views.
Más adelante explico detalladamente el corazón de una aplicación.

En el próximo post de Zend Framework haremos nuestro “hello world” ;p

[1] Que si, que también hay y habrá ñapas con el patrón MVC, pero os aseguro que os facilitará la vida a la hora de detectar errores.

Horrorosa.

Pero este post va dedicado a ello, a la involución que suele tener un proyecto. Digo suele, pero tampoco hay que ser pesimista, simplemente me gusta más ser duro en mis palabras, aunque sea para esforzarme más en que no suceda…

Sé que en estos tiempos que corren, se vende mucho “humo” (quien no lo entienda otro día lo explico), y no es muy habitual encontrar empresas de software serias que no intenten venderle la moto al primero que pasa por su lado.

Aún así, vamos a presuponer que un cliente contacta con una empresa de software competente. ¿Qué sucede?

Bien, voy a intentar explicar que es lo que suele pasar, y que hay que evitar, claro… Lo explicaré desde mi experiencia personal, de lo que veo a diario, de lo que oigo, me cuentan, leo, etcétera, y evidentemente no es el abecedario, ni pretende serlo, simplemente me gusta contar la experiencia, a veces hasta ayuda, otras simplemente te ríes, y algunas otras, pierdes el tiempo por leerme ;-p

En ocasiones lo que sucede es que al inicio hay mucha alegría por parte de la empresa de desarrollo y del cliente, todo es entusiasmo, ilusión en el proyecto que va a salir. Unos pensando en hacer un buen trabajo y los otros pensando en los resultados.

El problema, es cuando la creación se está gestando, y el empresario por X razonas hace cosas tipo…

• “Es que a mí me gustaría más la barra lateral aquí” (Ya tenemos a míster usabilidad que sabe dónde están mejor las cosas)
• “Es que se lo enseñé a mi tía del pueblo y dice que es muy gris, que no le termina de gustar” (me gustaría saber que llevaba puesto… Y no, no va por ahí ;p)
• “Es que creo que deberíamos meter más imágenes” (vamos, ahora resulta que quieres un flickr)
• “Es que no quiero que salga scroll” (el scroll te va a matar)
• “Es que en mi pantalla se ve un poco vacío” (no me extraña, tienes un pedazo pantallón)
• Lo contrario… “Es que no quiero que salga esta barra (scroll)” (no me extraña, tienes la resolución a 800… Ahora explícale que cada persona tiene una diferente)
• “Es que he leído que…” (el listo de turno)

Aquí ya empezamos el declive, lo que era magnífico y entusiasmaba a ambas partes una de las partes empieza a verle pegas y la otra (tu) empieza a cuestionarse si el proyecto va a salir bien, porque como tengas que hacer todos los cambios que quiere lo que saldrá será un “myspace” (fantásticos algunos de ellos… supongo que sabéis a qué me refiero, la antiweb).

Todo esto, puede suceder por muchas razones:

1. El aburrido. Se aburre, y quiere “colaborar”. Te aseguro que no termina de comprender el significado de “colaborar”.
2. El de “tengo un amigo que me ha dicho”. Tiene el típico amigo que lo sabe todo, le ha enseñado las demos y ha “opinado”. Obviamente te vas a tragar su opinión lo quieras o no.
3. El/Los CEO. Si es una empresa mediana/grande la has cagado, porque no sólamente tratarás con 1 persona, tratarás con 20 cargos intermedios, y todas ellas pagadas por hacer algo, por tanto, todas querrán opinar. Si, he dicho opinar. Tienen que justificar su trabajo de algún modo, y te aseguro que “su modo” es teniendo ideas… Tómate una tila el día de las reuniones (que habrá, y muchas) porque vas a salir de ellas tirándote de los pelos.
4. Don amigos. Si es una empresa pequeña, tendrá muchos amigos “que saben del tema”, y cada 5 minutos lo enseñará a alguien, y cada 10, te llamará por teléfono. “¿Te acuerdas la barra de la derecha? Es que mehan dicho que…”. En este caso harás pocas reuniones, en lugar de ello te llamará cuando y como quiera, eres su esclavo, esto es así. (No sé que es peor)
5. Culo veo, culo quiero. Danger… Este es especialmente difícil, porque se dedica 8 horas al día a mirar webs, especialmente competencias directas, y entonces viene y te dice, quiero que sea más una mezcla entre facebook y flikr, pero que sea muy rápida y fácil, tipo google. (Luego le dices el precio y el tiempo que necesitas y tienes que recojer sus ojos del suelo, porque se le salen de las órbitas…)
6. El indeciso. ¡Cuidado! Este especímen realmente te hará trabajar mucho. Nunca le hagas caso a la primera, madura su idea, habla con el 20 veces antes de cambiar nada, nunca hagas nada a la primera, en serio… Cúidate de este o te retirarás en unos meses del negocio.
7. El “Ya que”. Otro peligroso. “Ya que dijimos que haríamos un buscador en esta página, porque no ponemos tal, tal, tal…”. “Ya que dijimos de cambiar de lado este botón, porque no ponemos 20 más que hagan tal y tal y tal”. Nunca, nunca, nunca, pero nunca digas delante de esta persona que algo es fácil, o que algo te va a llevar poco tiempo en hacerlo, porque a partir de ahí vas a oír “ya que” miles de veces…
8. El yo no sé que quiero, pero esto no. Uf… He llegado a oír cosas increíbles. Una de las últimas ha sido un (literal) “Es que tiene que ser un banner pero sin serlo”. Apaga el ordenador y vete a dormir, en serio… Porque no vas a entender lo que quiere ni hoy ni mañana. ¿Por qué? Porque no lo sabe ni el. Esta persona jamás te dará argumentos, simplemente verá lo que le has preparado y dirá… “Uhmmm, no termina de ser lo que quiero”… Pero, ¿Qué quieres? No lo sabe, pero esto no xD

En fin… De todos los colores y sabores, un par de consejillos:

• Dejad siempre claro quien es el que sabe del tema, no irá al cirujano a decirle, mueva el bisturí más a la izquierda, es que me han dicho que…
• Dejad claro que su empresa, es su empresa, no es la del vecino. No facturan lo que factura Amazon, ni pagarán lo mismo por su sistema. Por tanto, que no quieran ser Amazon.
• No le déis nada a probar si no está realmente probado por vosotros y aprobado (y firmado) que tiene que ser así, porque trabajaréis doble, triple…
• Si hace propuetas, jamás digás “vale”, discutidlas, pensadlas, no digas que si, vete a tu casa y valóralo, luego en la siguiente reunión/email/tfn/wave/loquesea le dices lo que piensas
• No actúes en caliente. Nunca.
• Si utilizáis trac (o cualquier sistema de tiquets) enseñadle bien qué se pone y porque. O encontraréis cosas del tipo “Incidencia, la cabecera no me gusta”.
• Todo es complicado, pero tu sabes hacerlo. Nunca menciones que algo es fácil. El interpretará que estás a su merced, y que es igual de fácil cambiar un color que hacer una funcionalidad entera. Todo se valora, Todo se estima en horas, si no lo haces así vas a entrar en una espiral muy fea.
• Advertidle que la web es para los usuarios que la van a visitar, no es su jueguete en el que pone el color morado porque le gusta ese color… No. Cuando lo que el quiere es vender más, la web tiene que gustar al cliente potencial, no a el (este punto a veces es verdaderamente complicado explicarlo).

Seguiría horas y horas, pero tampoco es plan… Creo que se capta bien así.

En fín, ¡otro día sigo!

Saludos, y ¡feliz año!

Vayamos por partes (como dijo Jack El Destripador :-))

¿Qué es un Widget?: Pequeña aplicación o programa, usualmente presentado en archivos o ficheros pequeños que son ejecutados por un motor de widgets o Widget Engine. Entre sus objetivos están los de dar fácil acceso a funciones frecuentemente usadas y proveer de información visual.

WordPress: ¿Todavía alguien no sabe qué es WordPress? Es un sistema de gestión de contenido enfocado a la creación de blogs (sitios web periódicamente actualizados).

Como todos sabéis, su desarrollo se basa principalmente en PHP y MySQL, vayamos pues a montar un widget.

Atención a este Widget para WordPress:

/*
Plugin Name: Test Plugin
Plugin URI: http://www.widgetifyr.com
Description: Test Plugin
Author: widgetifyr.com
Version: 0.01
Author URI: http://www.widgetifyr.com

*/

// We're putting the plugin's functions inside the init function to ensure the
// required Sidebar Widget functions are available.

  function widget_test_init()
	  {
	  /* Your custom code starts here */
	  /* ---------------------------- */

	  /* Your Function */
	  function test()
	  {

		  /* Your Code ----------------- */ 

		  echo 'hello world';

		  /* End of Your Code ---------- */

	  }

	  /* -------------------------- */
	  /* Your custom code ends here */

	  function widget_test($args)
	  {

	  	  // Collect our widget's options, or define their defaults.
		  $options = get_option('widget_test');
		  $title = empty($options['title']) ? __('test') : $options['title'];

		  extract($args);
		  echo $before_widget;
		  echo $before_title;
		  echo $title;
		  echo $after_title;
		  test();
		  echo $after_widget;
	  }  

	  // This is the function that outputs the form to let users edit
	  // the widget's title. It's an optional feature, but were're doing
	  // it all for you so why not!

	  function widget_test_control()
	  {

		// Collect our widget options.
		$options = $newoptions = get_option('widget_test');

		// This is for handing the control form submission.
		if ( $_POST['widget_test-submit'] )
		{
			// Clean up control form submission options
			$newoptions['title'] = strip_tags(stripslashes($_POST['widget_test-title']));
		}

		// If original widget options do not match control form
		// submission options, update them.
		if ( $options != $newoptions )
		{
			$options = $newoptions;
			update_option('widget_test', $options);
		}

		$title = attribute_escape($options['title']);

		echo '
		<label for="test-title">';
		echo 'Title: <input id="widget_test-title" style="width: 250px;" name="widget_test-title" type="text" value="';
		echo $title;
		echo '" />';
		echo '
		';
		echo '<input id="widget_test-submit" name="widget_test-submit" type="hidden" value="1" />';
	  }

	// This registers the widget.
    register_sidebar_widget('test', 'widget_test');

	// This registers the (optional!) widget control form.
    register_widget_control('test', 'widget_test_control');

  }

  add_action('plugins_loaded', 'widget_test_init');

?>

Interesante, ¿verdad?

Ahora me vendrá alguien y dirá… ¡pero si eso sólamente hace un “Hello world”!

Cierto.

Hace unos días estuve ojeando http://widgetifyr.com, en esta web nos ayudan a generar Widgets a partir de código nuestro. No está nada mal, hice un par de cosillas y funcionaron bastante bien. Sin duda ahorras algo de tiempo :-)

Os animo a montar los vuestros, yo llevo unos días montando algunos (ahora los estoy testeando) y es bastante interesante.

Espero que os sirva la URL de referencia :-)

Antes que nada, todo esto es personal, es “my way”, que como siempre, no tiene porque coincidir nadie, es más, espero que nadie coincida, porque si alguien lo hace tiene un grave y serio problema ;-

Horas

Durante el día tengo “rachas” de productividad, y poco a poco me voy dando cuenta de qué me funciona, y cuándo me funciona.

Tengo una franja de unas 4 horas por la mañana, sobretodo cuando estoy en la oficina (algunos días trabajo desde casa, en función de n parámetros que un día ya contaré), digamos que de 9 a 13 soy absolutamente productivo, mis dedos van solos, jeje, antes de eso me informo de qué ha pasado el día anterior vía Google Reader y etiqueto las noticias que me interesa seguir luego más detenidamente y los enlaces que creo convenientes los meto en mi delicious.

Otra cosa que me activa, es mi twitter, normalmente me marco con el iphone unas franjas de trabajo, por ejemplo 30/5, así me suena una alarma cada 30 minutos, y me obligo a tener 5 minutos de twitter, links, beber agua, etc… Estos 30/5 pueden ir variando en función de tí mismo, claro.

Por la tarde también tengo mi racha buena, pero cuando realmente rindo, y no puedo evitarlo, es por la noche, no sé que pasa que cuando dan las 22.00 (aprox) y hasta las 3, 4, 5, 6, 7… Rindo triple por hora, es algo increíble y sorprendente la cantidad de código que puedo crear a esas horas.

Ayudas Externas

Como menciono arriba, hay cosas que necesito como el agua para poder programar tranquilo. Necesito estar conectado para motivarme, ver cosas, ver enlaces, posts interesantes sobre las cosas en las que trabajo, comentarios… Y para ello es imprescindible mi Google Reader, mi Twitter y sobretodo Delicious. Delicious es una fuente enorme de información para mí, y la reviso a diario muchas veces (me encanta su sistema de tags :-))

Música

El 90% de tiempo que estoy trabajando tengo música puesta. En la oficina hay un subwoofer para escuchar bien los bajos (soy bajista, faltaría más xD) y en casa cascos, qué remedio…

Os pongo unos grupos así a bote pronto, normalmente los divido por intensidades, en función de lo que tengo que hacer… Si tengo que picar como un cabrón o tengo que pensar más.

Muse, Interpol, Incubus, Coldplay, a perfect circle, tool, Radiohead, U2, The cure, Vetusta morla, Queen.

Bebida

No puede faltar cola light con hielo al lado del ordenador, en su defecto una botella de agua, pero necesito hidratarme cada X tiempo, y para evitar “paseítos”, lo mejor es tenerlo a mano nada más empezar.

En referencia al título, y resumiendo, ¿Cuándo y cómo eres más productivo?

De noche, con música y marcándome intervalos de unos 50/10 (50 de programación de 1 tarea concreta y 10 de descanso obligado de esa tarea concreta).

¿Y tú qué? ¿Cómo te lo montas?

• I+D = Investigación + Desarrollo
• I+D+I = Investigación + Desarrollo + Innovación tecnológica
• Investigación = búsqueda intencionada de conocimientos o de soluciones a problemas de carácter científico. También existe la investigación tecnológica, que es la utilización del conocimiento científico para el desarrollo de “Tecnologías blandas o duras”.
• Desarrollo = La que me parece más acertada para el caso: Llevar a cabo, realizar una idea, proyecto…
• Innovación = aplicación de nuevas ideas, conceptos, productos, servicios y prácticas, con la intención de ser útiles para el incremento de la productividad. Un elemento esencial de la innovación es su aplicación exitosa de forma comercial. No solo hay que inventar algo, sino, por ejemplo, introducirlo en el mercado para que la gente pueda disfrutar de ello.

Lo que veo actualmente, es que se menciona demasiado la frase “es que eso ya está hecho”, es que “todo está pensado”, “no se puede sorprender”, etc… No sé muy bien la solución de todo esto, es decir, este no es un post para solucionar nada (o intenar hacerlo), simplemente es una reflexión a casos con los que me encuentro a diario.

Proyectos como SoopBook, por ejemplo, me parecen sorprendentemente innovadores (suerte chicos ;-)).

Creo que también se puede obtener cierta innovación completando otros proyectos, o complementándolos. Día a día nacen nuevas herramientas, webs, servicios, y quizá alguno de los que se utiliza normalmente se está quedando algo desfasado, o no avance lo rápido que avanza la tecnología, por tanto… me sigue pareciendo innovador “resucitar” algunos servicios añadiendo algo actual, haciéndolos más “usables”, etcétera…

De hecho, esto sucede mucho en internet, y normalmente se le tacha de “copia”. No niego que muchas veces es una copia burda, con algún añadido evidente, pero no me refería estos casos en mi anterior párrafo.

En fín… que parece que se nos han “secado” las ideas a los desarrolladores, y que existiendo google, facebook, etcétera… se nos agotaron las ideas! ¿Por qué? ¿Porque todo está hecho? Venga ya! ;p

PS: Oh… se me olvidaba, ahora con google wave tendremos ocupadas otro tiempo las mentes para integrar websites con wave… como este último tiempo con Facebook ;pppp

Ánimo chic@s ;-)

Desde la wikipedia: “Un huevo de pascua virtual es un mensaje oculto, o una capacidad escondida, contenido en un objeto, como una película, un disco compacto, DVD, programa informático, o videojuego [...]el videojuego de Atari: Adventure de 1978, contenía el primer huevo de pascua virtual que se conoce [...] Entre los programadores, parece haber una motivación en dejar una marca personal, casi un toque artístico sobre un producto intelectual, el cual es por naturaleza estándar y funcional.[...]”

En Google Reader tenemos un huevo de pascua muy interesante, y divertido :-)

El NINJA!!!! jajaja

Entrad en vuestro GReader y teclead:

arriba, arriba, abajo, abajo, izquierda, derecha, izquierda, derecha, b, a

Abrid la página de google, teclead este listado en la caja de búsqueda y presionad “Voy a tener suerte” ;-)

• Mecánico serio y fiable
• Un aparcamiento
• Trabajo digno con un sueldo decente
• Vivienda a precio razonable
• Encontrar a Wally
• Candidato convincente
• Encontrar a Bin Laden
• Una razón para esta barbarie
• Responsables del desastre del Prestige
• Armas de destrucción masiva

En yahoo! parece que han quitado su huevo de pascua

Hasta hace “relativamente” poco, al clickar sobre el punto de la exclamación, salía un sonido.

Era interesante :-)

Si disponéis de una Debian o de Ubuntu, podéis abrir la shell y teclear:”apt-get moo” si no, os digo lo que sale, aunque “spoileo a quién lo tenga ;p

[02:31:38] embat@~ > apt-get moo
(__)
(oo)
/——/
/ |    ||
*  /—/
~~   ~~
….”Have you mooed today?”…

Vamos… una vaca! :D

Por tanto a partir de esta noche, voy a empezar a investigar sus entrañas y practicar un poco con este framework (symfony).

De primeras hay muchos frameworks, y en realidad, si te pones a leer sus descripciones todos hacen lo mismo, o quieren hacerlo. Supongo que las diferencias entre ellos estriban en:

• Facilidad de aprendizaje
• Rapidez de uso
• Modularidad para meter otros componentes
• Rendimientos en el servidor

Como siempre, sólamente puedes opinar “desde dentro”, es decir, sabiendo de verdad como actúa, y en resumen, eso haremos, investigarlo desde dentro :)

Os iré informando, a medida que vaya terminando los pasos del tutorial miraré de montar un post con las dificultades o facilidades que me he ido encontrando.

Este patrón realmente es bastante sencillo, y sería fácil imaginar situaciones.

Evidentemente, habrá que vigilar si el programa crea hilos de ejecución, ya que sólo uno de los hilos logrará crear el objeto…

Vamos con un ejemplo sencillito en php (5):

<?php

class Ejemplo
{
    private static $instance;
    // privado, para prevenir la creacion de objetos via "new"
    private function __construct()
    {
        echo 'Soy el constructor';
    } 

    public static function singleton()
    {
        // Se chequea que no haya instancia del objeto antes
        if (!isset(self::$instance)) {
            $c = __CLASS__;
            self::$instance = new $c;
        }

        return self::$instance;
    }

    // Clone no permitido
    public function __clone()
    {
        trigger_error('Clone no se permite.', E_USER_ERROR);
    }

}

?>

Voy a construir una aplicación, probablemente en php o en Java, utilizando unos u otros, y también montaré los UML’s antes de ponerme a ello, así podemos ir comprobando los caminos y buscar los patrones más óptimos.

Saludos, sed felices ^^

Actualización para aclarar un comentario de JuanSa (su twitter):

Algunos ejemplos donde el singleton sería una opción:

• Clases Login: Son implementadas como singletons, y proporcionan un registro de punto de acceso global sin que sea necesario crear un objeto cada vez que se lleva a cabo.
• Configuración de Clases: Para diseñar las clases que proporcionan los ajustes de configuración de na aplicación. No sólo proporcionan un punto de acceso global, ya que también mantienen la instancia como un objeto de caché.
• Acceso a recursos compartidos: Si necesitas trabajar con el puerto serie puedes limitarlo con el singleton.
• Y para mí, el que está claro es el de la Factoría aplicando Singletons: Si diseñas una aplicación con una factoría (los 2 siguientes posts serán para factoría) para generar nuevos objetos, con sus identificaciones, en un entorno multihilo… Podrías utilizar el singleton para no superponer identificadores para 2 objetos distintos. (Pero lo vemos más adelante, eso sí, para mí es el momento más claro de utilizar el Singleton

Sed felices!

Clasificación de los patrones (los que iré posteando, claro):

• Creacional (Object Pool Pattern, Prototype Pattern, Factory Method Pattern, Builder Pattern, Factory Pattern, Abstract Factory Pattern, Singleton Pattern)
• Estructural (Adapter, Bridge, Composite, Decorator, Flyweight, Memento, Proxy)
• de Comportamiento (Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Observer, Strategy, Template Method, Visitor, Null Object)

Bien, manos a la obra, intentaré ir uno a uno ^^

Nos vemos en los siguientes posts :)

Liskov Substitution Principle (Principio de Sustitución de Liskov)

¿En qué se basa este principio?

He encontrado un par de frases que nos podrían servir como definición:

“Las funciones que usan punteros o referencias a clases base deben ser capaces de utilizar objetos de las clases derivadas sin tener conocimiento de ello” (Martin96b), también: “Las clases derivadas deben ser utilizables a través de la interfaz de la clase base, sin necesidad de que el usuario conozca la diferencia”

Y Liskov, dijo la que para mí es la más entendible: “Debe ser posible utilizar cualquier objeto instancia de una subclase en lugar de cualquier objeto instancia de su superclase sin que la semántica del programa escrito en los términos de la superclase se vea afectado” :)

Como siempre, con los ejemplos es como se ve más claro:

// cuando deja de cumplirse este principio, se hace más evidente
public class Figura
{
// ...
public void dibujar()
{
if (this instanceof Poligono) dibujarPoligono();
else if (this instanceof Circulo) dibujarCirculo();
}
}

El error es más que evidente. dibujar() viola el principio de sustitución de Liskov, si quisiéramos trabajar con una elipse, por ejemplo, ¿cómo lo haríamos? (FAIL) (Además, si os fijáis también se viola el OCP)

La solución: Polimorfismo. (cada tipo de figura se encargará de implementar dibujar())

Single Responsibility Principle (Principio de Responsabilidad Única)

Como frase, nos quedaremos con esta: Una clase debe tener una única razón para cambiar.

Asumamos que necesitamos un objeto que guarde un email. Utilizaremos la interface IEmail del ejemplo.
A primera vista todo funciona. Pero podemos ver como IEmail y Email tienen 2 razones para cambiar.

Si guardamos una clase, cada cambio de responsabilidad afectará a la otra.

// SRP - Mal ejemplo

interface IEmail {
	public void setSender(String sender);
	public void setReceiver(String receiver);
	public void setContent(String content);
}

class Email implements IEmail {
	public void setSender(String sender) {// set sender; }
	public void setReceiver(String receiver) {// set receiver; }
	public void setContent(String content) {// set content; }
}

Podemos crear una nueva interface IContent y Content para repartir las responsabilidades.

// SRP - Buen ejemplo
interface IEmail {
	public void setSender(String sender);
	public void setReceiver(String receiver);
	public void setContent(IContent content);
}

interface Content {
	public String getAsString(); // used for serialization
}

class Email implements IEmail {
	public void setSender(String sender) {// set sender; }
	public void setReceiver(String receiver) {// set receiver; }
	public void setContent(IContent content) {// set content; }
}

Conclusión:

El SRP representa una buena forma de identificar clases durante la fase de diseño de una aplicación, y nos recuerda pensar en todas las vías en las que una clase puede evolucionar. Se necesita una buena separación de responsabilidades.

Este ejemplo viola el principio ISP, tenemos una clase Manager que representa la persona que dirije a los trabajadores. Y tenemos 2 tipos de trabajadores, algunos muy eficientes. Ambos tipos necesitan un break para comer. Ahora, también hay algunos robots y éstos no necesitan comer.
Si conservamos el diseño, la clase robots se ve forzada a implementar el método eat().

// ISP - Mal ejemplo
interface IWorker {
	public void work();
	public void eat();
}

class Worker implements IWorker{
	public void work() {
		// ....working
	}
	public void eat() {
		// ...... eating in launch break
	}
}

class SuperWorker implements IWorker{
	public void work() {
		//.... working much more
	}

	public void eat() {
		//.... eating in launch break
	}
}

class Manager {
	IWorker worker;

	public void setWorker(IWorker w) {
		worker=w;
	}

	public void manage() {
		worker.work();
	}
}

A continuación tenemos el código siguiendo ISP. La interface IWorker la dividimos en 2.

// ISP - Correcto
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
	public void work();
}

interface IFeedable{
	public void eat();
}

class Worker implements IWorkable, IFeedable{
	public void work() {
		// ....working
	}

	public void eat() {
		//.... eating in launch break
	}
}

class Robot implements IWorkable{
	public void work() {
		// ....working
	}
}

class SuperWorker implements IWorkable, IFeedable{
	public void work() {
		//.... working much more
	}

	public void eat() {
		//.... eating in launch break
	}
}

class Manager {
	Workable worker;

	public void setWorker(Workable w) {
		worker=w;
	}

	public void manage() {
		worker.work();
	}
}

Conclusion

Como resumen:

“Los clientes no deberían ser obligados a depender de interfaces que no utilizan”
o…
“Muchas interfaces muy especializadas son preferibles a una interfaz general en la que se agrupen todas las interfaces”

Ambas son buenas…

Saludos,
Sed felices ^^