¿Errores informáticos?

Ante todo, este post no va dirigido precisamente a los profesionales del desarrollo. Así que si alguien de ese grupo me lee que no espere soluciones mágicas ni superdebuggers de la muerte. Si alguien del "otro grupo" lo lee (lo que por otra parte me haría muy feliz) que no espere compasión por mi parte. Este post trata sobre incompetencia.


Sucedió hace unos días: Francia se queda sin triple AAA debido a un error informático.

Antes había sido precedido por dos cagadas que no consiguieron achacar a las malévolas y revolucionarias máquinas: Cagada en la deuda de Alemania y Cagada en la deuda de Irlanda. Supongo que no ha de ser sencillo acusar a Microsoft por haberla pifiado al diseñar (mal) una hoja Excel.

La verdad es que los errores informáticos pululan por doquier. Ya sólo haciendo una consulta en meneame encontramos decenas de páginas llenitas de acusaciones y sospechas hacia nosotros, los pobres técnicos. No es que todos estemos libres de culpa pero es que parece que somos una panda de chapuceros y que en cualquier momento se acabará el mundo por nuestra culpa.

No voy a decir nada nuevo para quien se dedica al desarrollo (de hecho es una de nuestras máximas), pero seguro que a muchos "legos en la materia" les extraña leer esto que voy a poner:

El principal error informático se encuentra entre el ordenador y la silla.

Parecerá coña pero los ordenadores no se equivocan, son infalibles. Los ordenadores hacen lo que se les manda, ni más ni menos. Ni siquiera esos algoritmos tan chulos que hacen Google y Facebook para averiguar la marca de nuestra ropa interior servirían para mucho sin alguien que los hubiese ideado, que los estuviese revisando cada poco tiempo, que los afinase y que los probase.

Skynet no existe, y si existe todavía no tiene conciencia de sí misma. HAL 9000 no existe, y si existe, no piensa por sí mismo. Esos robotitos tan chulos de "Yo Robot" y todos los agentes Smith de Matrix sólo son pajas mentales de escritores, guionistas y plagiadores.

Un ordenador, o una red de ordenadores, o la red de ordenadores más grande del mundo no es más que una herramienta y, como todas las herramientas, está pensada para ser usada por los humanos (bueno, y por los gatos mientras esperan a que les crezcan pulgares para llevar a cabo su plan de conquista mundial). Un ordenador sin alguien que lo "alimente" es un conjunto de hierros inútiles. Sí, hasta esos de la manzanita, son poco más que pisapapeles de lujo.


Imaginemos que se produce un atropello en la calle: ¿alguien culpa al coche? O pensemos por un momento que un tren descarrilla: ¿la culpa es de la locomotora, que no frena en las curvas? O que alguien muere por un golpe con una llave inglesa: ¿metemos en la carcel a la pobre llave?

Pero claro, con los ordenadores es distinto, porque son muy listos. Están acechando y esperando a que llegue el momento adecuado y ¡Zasca! te largan un error y le quitan la triple AAA a Francia. O peor aun, se esperan a estar cerca de Marte y estrellan una sonda que vale millones de euros porque sí, porque son malévolos. Y qué decir de esos que te roban en el banco por internet cuando tú sólo estabas carteándote con el presidente de Nigeria.

Un ordenador es una máquina estúpida y detrás de esos "errores informáticos" siempre hay un grupito de humanos que la han cagado. Todavía estoy esperando el día en que un peritaje concluya que algo ha sido culpa de un ordenador; da igual que sea un accidente aéreo o un recuento de votos, quien se equivoca siempre es un humano. ¿A alguien le suena que haya sucedido? Pues a mí tampoco.

"Error informático" se usa para esconder la incompetencia de un analista económico que no sabe usar una hoja de cálculo.

"Error informático" se usa para justificar la incompetencia de una empresa al diseñar un producto informático. Bien sea por abaratar costes y contratar becarios, por ahorrarse el tiempo de probar lo que hacen o porque "da igual, ya les cobraremos el mantenimiento". Lo malo es cuando se usa "eso" en procesos electorales.

"Error informático" se usa para esconder la incompetencia de quien no hace su trabajo y espera que una máquina se lo resuelva. El error es dejarles ver pr0n en el trabajo, o haberles dado el trabajo, simplemente.

La verdad es que me apetecía desahogarme, y tampoco era cuestión de escribir un post sólo con la frase "sois una panda de ignorantes incompetentes". Es probable que mi tráfico de 3 lectores pasase a uno solo... yo mismo.

Pues eso, que la próxima vez que se os ocurra decir "error informático" os miréis las manos a ver dónde habéis metido la zarpa.

No, por mucho que os empeñéis no existen los "errores informáticos".

Crónica de un roadshow (Windows Phone 7)

Ya hace más de un mes que no publico nada, entre otras cosas porque he estado haciendo cosas productivas, por ejemplo conquistar Europa con Napoleón y el Total War. Pero el tema de mi adicción a los juegos lo dejaremos para otra ocasión porque tiene demasiada chicha.

Aprovechando que el Lunes 24 de Octubre asistí a una Roadshow sobre la plataforma Windows Phone 7.5 (Mango pa los amigos) y como estoy emocionado con lo que me regalaron, pues vamos a contar qué pasó.

El evento se llamaba "Cómo desarrollar y publicar las mejores aplicaciones y juegos para Windows Phone" y el programa era el siguiente:

09:00-09:30       Registro

09:30-10:30       Por qué Windows Phone?

10:30-12:00       Plataforma de desarrollo de aplicaciones y Juegos

12:00-12:15       Descanso (café)

12.15-13:15       Datos, Servicios y "Live Tiles" (Ventanas Vivas)

13:15-14:00       Capacidades avanzadas de Windows Phone

14:00-15:00       Descanso

15.00-16:00       Multitarea en Windows Phone

16:00-16:15       Descanso

16:15-17:15       Desarrollo paso a paso y publicación de "Zombsquare"

17:15-17:45       Cómo comercializar tus aplicaciones y juegos en el Marketplace

17:45-18:00       Recursos, Ayudas e Iniciativas

La verdad, tenía bastante miedo de que se convirtiera en algo parecido a "Developers! Developers!", o peor aún, que fuese un evento de captación de adeptos al lado oscuro y que hubiese que realizar algún sacrificio de sangre. En el mejor de los casos esperaba una aburrida presentación cargada de Powerpoints contando las bondades del producto pero sin llegar a ver la potencio (o la falta de ella) de la plataforma.

Menos mal que me equivoqué.

Soy ya perro viejo en estas lides y cuando me cuentan algo nuevo, sobre todo si viene de los propios iniciadores del invento, no me suelo creer ni la mitad. Yo también he maquillado "productos" y realizado "demos" y, aunque no se me da demasiado bien el Powerpoint, sé mentir lo suficientemente bien como para vender hielo a un esquimal si hace falta. Suelo detectar desde lejos a los vendemotos, supongo que será porque he tenido que vender yo algunas y quizás las feromonas que emiten puedo olerlas a kilómetros.

Pues no es el caso y, aunque alguien pueda pensar que el lado oscuro me ha llamado a su lado, he de reconocer que Windows Phone 7.5 está bastante completo. Si Microsoft hace algo bien, como en su día .NET o hace poco con Windows 7, se merecen mis elogios. En el fondo lo suyo es un negocio, como al que podamos dedicarnos cualquiera de nosotros (de hecho creo que muy pocos estamos libres de culpa porque o curramos o hemos currado en consultoras o tenemos nuestros clientes de pago).

Lo dejaré ahí y si hace falta se comenta algo más otro día.

El Roadshow, interesante de principio a fin, excepto en un par de ocasiones en las que el hambre no me dejaba razonar. Los ponentes (Eduardo Ortega, José Antonio Gallego e Isabel Gómez) controlaban y, ojo que es importante, fueron sinceros en todo momento con las limitaciones de la plataforma, que las tiene, y algunas las he twiteado (y otras las han twiteado otros).

Hubo presentaciones, hubo mucha cháchara a alta velocidad y chascarrillos y, sobre todo, hubo demostraciones y desarrollos en directo sobre la plataforma, ahí con un par, y petando lo justo. Si todo hubiera funcionado a la primera hubiera sido sospechoso.

No es que sea un entusiasta de la GUI Metro las "Live Tiles" y esos inventos, de hecho el que esté por defecto en Windows 8 me da bastante rabia (casi tanta como que Ubuntu traiga Unity de serie, puaj!) pero ¡coño! en el móvil queda bien.

El que la GUI haya que desarrollarla con Silverlight no me acaba de gustar demasiado, igual que no me gusta el Flash al que pretendía "sustituir". Quizás podría haberse optado a la solución de Windows 8, desarrollando con HTML5, pero supongo que la fechas aprietan y cambiarlo todo ahora sería un suicidio económico. Sea como sea, hacer la GUI con Visual Studio (o Microsoft Expression Blend) es sencillo y se basa, como Android, en "atar" eventos a widgets. El SDK es gratuito así que no hay queja.

Limitaciones de la plataforma, las tiene, algunas poco comprensibles. Según nos han aclarado era por falta de tiempo y que irían siendo puestas de forma pública, aunque comenté en twitter mis sospechas de que hubiese algún SDK pro de pago con accesso a lo limitado (seguro que alguno recuerda las acusaciones de hace años de que Microsoft ocultaba partes de la API de Windows para eliminar competencia). Les daré un voto de confianza y veremos si para la próxima están corregidas.

Algunas de esas limitaciones eran bastante curiosas, como el no poder acceder a Bluetooth, o que las alarmas no funciones si el teléfono no tiene batería (esta no es de la API), o alguna otra que había con las Live Tiles y las tareas en background. En todos los casos la respuesta fue que muchas limitaciones eran para proteger al usuario de malware O.O

No sé los demás pero a mí, como desarrollador, me interesa acceder a TODO y poder especificar yo las limitaciones de mi aplicación. Por otra parte es comprensible que, ya que todas las aplicaciones se van a tener que descargar obligatoriamente desde el Zune Marketplace, quieran cubrirse las espaldas y no arriesgarse a demandas por facturas de miles de euros en SMS no solicitados, por ejemplo. Pero ya digo, como desarrollador me fastidia (por no decir me jode) que esté limitada "por la seguridad de un fulano que suele ser demasiado estúpido como para saber qué instala". Casi hubiera preferido que se hubiesen creado zonas de aplicaciones confiables en el Marketplace pero que nos dejasen la oportunidas de trastear con todo.

El Marketplace, otra historia. Son 75 euros para registrarse como desarrollador, más caro que los 30 de Android y mucho más barato que los 200 de iOS. Y se pueden "liberar" hasta tres móviles para hacer instalaciones locales. Ni bien, ni mal; me parece correcto. Tiene en común con el resto de "mercados" que las aplicaciones pr0n están vetadas. Mal, muy mal; en el pr0n se mueve mucha pasta y están echando fuera a muchos potenciales compradores de la plataforma.

También hay un programa de Ads (anuncios) e incluso un componente para meter esos Ads en las aplicaciones (de Microsoft, que es quien controla los clicks y las visualizaciones de anuncios). Curioso y creo que lo usaré nada, odio los anuncios. Probablemente me la rechacen pero mi segunda aplicación sería un eliminador de Ads y un AdBlock o algo así para el Internet Explorer del móvil. Sí, no hay Firefox, por ahora, ni Chrome y no he visto si hay Opera... una pena.

Todavía he de probar cómo se comporta el navegador con los estándares. Prometían que iba bien pero no sé yo, no me fío del Explorer.

Mi conclusión final es que no tengo conclusión porque no he podido probarlo a fondo. Lo mostrado promete mucho y la GUI Metro es curiosa y funcional. Lo que nos han mostrado me ha parecido interesante y me ha animado a desarrollar alguna cosilla para cogerle el tranquillo. Supongo que no puede ser más terrible que trabajar con Windows CE (todavía recuerdo cuando en el 2000 me hice con una PDA e intenté acceder al sensor de infrarrojos... con C++ y a pelo).

Para poner los dientes largos: regalaban 5 móviles y nos hicieron, no sé, unas 30 preguntas para ver quienes se los llevaban.

Ahora tengo sobre mi mesa uno de ellos, un LG Quantum (como el detergente), liberado y ya con la última versión de Windows Phone 7.5.

Hale, moríos de envidia.

Para una vez que gano algo...


Update: me comentan desde twitter que el SDK de Microsoft es opcional y que otras compañías también pueden ofrecerlos. Gracias por la info. Sigo odiando los Ads vengan de quien vengan :-P

Marketing en redes sociales e idiotas con ordenador

Ayer, al destapar un yogur y dejar impoluta la tapa con mi lengua, descubrí algo que me llamó mucho la atención. Lo primero fue que normalmente el yogur se pega en grandes cantidades en el borde de la tapa y, si no tienes cuidado al lamer, te acaba salpicando. Lo segundo fue más inquietante: todavía había “premios” bajo las tapas.

Recuerdo que en mi niñez a mi madre la convencía con malas artes para que me comprase los yogures de determinada marca, no porque estuviesen más buenos, sino porque bajo las tapas había premios y, con suerte, recogías a la semana siguiente el álbum de cromos de Naranjito o el muñeco que acababa mordisqueado y olvidado bajo la cama...

Además, en el Cola Cao o tenías los muñequitos del Subbuteo o los Mini Airgamboys de Barcelona 92, o las camisetas del Mundobasket. Que le dieran po'l saco al Nesquick, aunque estaba más bueno y no te dejaba un pegote polvoroso en el fondo de la taza. El Cola Cao te regalaba cosas útiles.

Para recoger ciertos regalos tenías que enviar un carta, un cupón o lo que fuese y tú tenías tu cacho de cartón pintado y la empresa tenía tus datos y te enviaba publicidad y conocía algo más de tus hábitos de consumo.

Quid pro quo. A ti te daban un muñequito y les cedías unos datos que realmente te importaban poco. Total, que te enviasen un catálogo chorra que acababa en la basura tampoco era molesto.

A mi entender ésto no ha evolucionado demasiado a lo largo de los años. Lo que ha involucionado es la calidad de la recompensa al consumidor.

Todavía hay empresas que siguen dando “satisfacción inmediata” (de verdad que Cola Cao es honrosa en ese aspecto) pero la gran mayoría intentan saber de ti, seguirte y espiarte sin darte nada.

Y a las tapas de yogur me remito: mete un código, mete todos tus datos y adjunta un análisis de orina y una muestra de heces y entras a un sorteo de una muñeca chochona. Las tapas de yogur, los cartones de leche, el paquete de arroz o la bolsa de pañales para adultos.

Y lo peor no es que esos expertos en marketing pretendan obtenerlo todo a cambio de nada, que ya me jode bastante, sino que hay gente que gustosamente cede su vida por nada.

Ese es un consumidor estúpido. No es idiota, solo estúpido, porque no se da cuenta de que unos señores con unos trajes muy caros seguirán ganando mucho dinero gracias a varios miles de consumidores estúpidos que todavía creen en unicornios rosa.

El consumidor puede ser estúpido, pero no todos son idiotas. Sólo hay que hacerles ver que están haciendo el tonto y se acabó perder el tiempo en páginas web que, además, son horribles, hechas con Flash y que en condiciones normales no serían visitadas más que por los pobres programadores/diseñadoras a los que les toco hacerlas (vaya aquí mi condolencia para quienes tienen que sufrir tremendos engendros).

Hasta aquí mis reflexiones sobre las tapas de yogur, y ahora viene lo bueno: las campañas en Facebook y la sobreidiotización del consumidor.

Es que resulta que después de comer el yogur, y cuando la tele me pilló desprevenido sin el mando a mano para hacer zapping, me tocó sufrir uno de los anuncios más gilipollas que había visto desde lo último de Wipp Express: las maquinillas Gillete.

En ese engendro aparecen al final un montón de capturas de supuestos “comentarios de Facebook” hechos por “consumidores” alabando el deslizamiento de la susodicha maquinilla (que por otra parte es cierto, yo uso el modelo anterior y va de coña).

A ver, señores de Gillete, ¿nos han tomado a todos por GILIPOLLAS?

Todavía hay gente que no sabe cómo funciona esto de las redes sociales y podría creérselo a pies juntillas, igual que los hay que se creen los publirreportajes de la leche de turno, pero hasta el más cateto se da cuenta de que esos comentarios o han sido directamente falsificados con el Adobe Premiere de turno, o existen realmente y han sido puestos por los publicistas abriendo mil cuentas o porque sus empleados están obligados por contrato a cantar sus alabanzas en Facebook.

Hay que ser un cretino integral para ir a la página de una empresa a cantar las alabanzas de una puta maquinilla de afeitar. ¿Hay alguien que se crea que eso sucede?

Si hablásemos de teléfonos móviles, coches, vibradores... de algo satisfactorio y del que fácilmente pueden haber grupos de fans... pero, ¿de una maquinilla de afeitar?

¿De verdad se creen que somos tan imbéciles?

El problema, para mí, es que acabo de recibir un “¡Zas! ¡En toda la boca!”. Acabo de descubrir a unos 16000 idiotas, todos ellos fanáticos de una marca de agua ”ligera”.

O sea que ahora la pregunta ha cambiado, ¿cómo ese tipo de gente ha podido reproducirse?

Y hasta aquí mi disertación de hoy sobre el advenimiento de la idiocracia. Cabreado me hallo.

No tengo intención de poner enlaces a las empresas que menciono, no sólo por hacer campañas de marketing cutres en las que yo no gano nada, sino porque, principalmente, no me da la gana.

Hace un par de años, en mi temporada de navegante de Second Life escribí una pequeña serie de artículos tratando temas similares, pero orientado al marketing en ese entorno virtual. Para quien le interese: Estudio totalmente subjetivo sobreSecond Life.

Salut!

Annotations, esas desconocidas en PHP

He de reconocerlo, me encantan las annotations (attributes en .NET). Me parecen una de las herramientas mas útiles que nos puede proveer un lenguaje de programación y me pongo burro cuando las veo por algún sitio.

Ya me había acostumbrado a ellas en Java hace tiempo cuando comencé con Hibernate y más tarde seguí usándolas con .NET. Las annotations, en este caso, eran una manera de los más limpia para no tener que toquetear un xml cada vez que cambiaban los objetos de datos.

Creas tu objeto de datos y lo mapeas en dos patadas, tal que así:

@Entity
@Table( name = "EVENTS" )
public class Event {
   ...
}

Trabajo terminado.

Más o menos hace un año, mientras estaba RESTificando unga, que está programado, por ahora, con PHP, me surgieron una serie de dificultades:
- Necesitaba devolver los resultados en diferentes formatos (XML, JSON, HTML).
- PHP es un lenguaje de tipado débil y sólo en muy contadas ocasiones se puede especificar un tipo de datos.
- Con lo anterior tenía problemas para mapear números y cadenas, o incluso tipos de datos binarios sin mantener en algún sitio un objeto de conversión específico para cada tipo de datos. En Java/.NET/etc. es mucho más sencillo pues en cada momento se puede acceder al tipo de cada variable.

Cómo pasar, por ejemplo de ésto:

public class Cosa {
    public $DatoCadena = ‘pakito’;
    public $DatoFloat = 0.123;
    public $DatoEntero = 123;
    public $ArrayDeObjetos;
}

A ésto:

<?xml version="1.0" encoding="UTF-8" ?>
<Cosa>
    <DatoCadena>pakito</DatoCadena>
    <DatoFloat>0.123</DatoFloat>
    <DatoEntero>123</DatoEntero>

<ArrayDeObjetos>

    <Objeto....

    ...

</ArrayDeObjetos>
</Cosa>

O más difícil aún, ¿cómo hacerlo a la inversa? (de XML a objeto).

Recordemos: PHP es un lenguaje de tipado débil, de ahí el problema. Los Javeros, NETeros, C++eros y similares lo tienen algo más sencillo.

Hay muchas formas y podrían hacerse muchos tipos de parsers pero siempre vamos a encontrarnos con que esos parsers no van a ser genéricos y requerirán que, cada vez que se modifique una clase, se incluyan sus nuevas propiedades específicas (por ejemplo, DatoPatito, haciendo referencia a objetos de tipo Patito).

Podría delegarse la responsabilidad en cada objeto de datos, la cual fue mi primera opción, pero sería un coñazo, con el tiempo, tener que escribir las funciones de serializacion/deserialización cada vez que se crease un tipo de dato nuevo.

En mi afán de obtener grandes resultados con el mínimo esfuerzo se me ocurrió que quizás con annotations en PHP podría especificar el tipo de datos de cada propiedad y crear únicamente serializadores genéricos que no habrían de ser tocados cada vez que se crease una nueva clase.

La clase anterior bien podría quedar tal que así:

class Cosa {
    /* @type = ‘string’ */
    public $DatoCadena = ‘pakito’;
    /* @type = ‘float’ */
    public $DatoFloat = 0.123;
    /* @type = ‘integer’ */
    public $DatoEntero = 123;
    /* @type = ‘array’, @object_type=’Objeto’ */
    public $ArrayDeObjetos;
}

Limpio, claro y sin errores. Y además los componentes que tuviesen que tratar con esos objetos podrían tener especificados el tipo de datos con el que trabajarían y, si algún día hubiese que cambiarlo, sería modificar un simple parámetro. Por ejemplo:

/* @object_type = ‘Cosa’ */
public function HacerCosas {...}

Pues sí, aunque conozco a muchos desarrolladores que están en contra de estas cosas tan dinámicas, de construcción automática de código, de mapeos y de cosas así... no puedo evitarlo, a mí me gusta.

Si a la supuesta sobrecarga de la “interpretación” de PHP (medio desmentido aquí: http://www.phpclasses.org/blog/post/155-Top-10-Wrong-Ideas-About-PHP-That-You-Should-Get-Right.html ) le añades que antes ha de examinar (reflexión) las clases de datos y decodificarlas la aplicación se morirá de asco.

Yo no he notado disminución de rendimiento apreciable y sólo por la comodidad que me ofrece vale la pena la posible “pérdida” que pudiese acarrear. Hay que tener en cuenta que en los entornos de desarrollo yo no uso op-code caches ni optimizaciones de ningún tipo (memcache, caché de páginas, etc.).

Para “escoger” qué solución de Annotations era la más adecuada, en mi caso, me guié por las opciones presentadas aquí: declarative development using annotations in php. Al final me decidí por Addendum  porque no todos los hosting tienen la posibilidad de instalar PEAR y porque además podría modificarla a gusto si lo necesitase.

En unga todos los DTOs están “anotados” y me resulta muy sencillo realizar clases de serialización. Por ahora serializa para XML y JSON pero hay un futuro brillante esperando porque la era móvil me está obligando a pensarme ciertas cosas sobre la presentación.

Así que sí, PHP tiene Annotations. Y decían que no era un lenguaje serio...

Salut!

To REST or not to REST

Hay veces en las que no puedo evitar maravillarme por la raza humana. Somos capaces de crear unas herramientas increíbles y extremadamente versátiles, estudiarlas, justificarlas científicamente y analizando los pros (muchos) y los contras(escasos) de su uso... y acto seguido enviarlas a la mierda y condenarlas al ostracismo.

REST me parece uno de esos casos.

¿Qué es REST? Pues algo similar a ésto, en su forma más pura: REST en la wikipedia.

No es muy largo de leer pero por si acaso lo resumo:
- La mayor parte de las operaciones que realiza una aplicación es crear, actualizar, consultar y leer tipos de datos (clientes, productos, tweets, mensajitos de facebook, etc.) o “recursos” en la jerga. Lo que se llama CRUD.
- Si estás trabajando en la web, con el protocolo HTTP, puedes especificar la operación a realizar: get, post, put y delete (entre otras). Eso es el request method.
- Sé listo y simplifica tus aplicaciones web, que casi todas son CRUD, y no llenes de mierda las urls. Usa los “request method” http y sé limpio.

Pues no hay manera oye. Raro es el servicio web que usa “bien” REST. La gran mayoría te obligan a hacer verdaderas salvajadas del tipo:
http://servicio.com/uno/dos/tres/nombredeserviciototalmenteimposibledememorizar?op=1&papepipopu=asdf&pongaaquisusdatosinutiles

Como mucho se usa POST para enviar datos y GET para leerlos pero el resto de métodos se los han olvidado. Pero ¡ay de ti como se te olvidase la tabla de operaciones del parámetro “op”! (¿borrar era 1 o 4?)

Comprendo que quizás hace 5 o 10 años fuese difícil de hacer que un navegador enviase una petición DELETE, pero hace tiempo que estamos en la era AJAX y hacer las cosas bien y claritas no habría de ser tan complicado... ¿o será vagancia?

Sea como sea yo me he erigido a título personal en defensor del RESTarismo, soy un RESTafari de pro, y quizás fundamentalista. Desde hace ya tiempo no soporto ver código que no siga las especificaciones REST: si vas a hacer CRUD, hazlo bien, ¡carajo!.

Comprendo que hay recursos o servicios que son imposibles o dificilmente expresables usando REST, por ejemplo un servicio de login, pero para todo lo demás, teniendo en cuenta que la mayor parte de lo que hacemos es actualizar objetos : si pretendes que yo use tus APIs, facilítame el trabajo.


Al llegar a este punto voy a darme algo de autobombo con unga, mi mimadito framework PHP, está preparado para REST “puro”: implementar servicios CRUD es tan sencillo como crear un controlador y hacerlo heredar de REST_Controller (sí, mala elección de nombre, ya lo cambiaré).

Ese REST_Controller se va ocupar de recoger los parámetros de la url, recoger los datos de la petición (si los hubiese) y redirigir a la función correspondiente (create, retrieve, update, delete) según el “request method”.

Lo he hecho tan sencillo, además, que incluso no habrá que teclear ni una línea de código para llevarlo hasta la base de datos: crea una clase Model, indícale su nombre al Controlador y éste se encargará de hacerlo todo.

Es similar al scaffolding que te da Ruby on Rails pero un poco más elaborado y, sobre todo, fácilmente modificable.

¿Qué quieres obtener un dato? GET a http://servidor/servicio/objeto/id/xxxx
¿Que quieres borrar? DELETE hacia http://servidor/servicio/objeto/id/xxxx
¿Que quieres crear uno nuevo? POST a http://servidor/servicio/objeto

Más fácil, imposible. Y si además unimos que se puede filtrar por cualquier campo (id, name, product_name, manzanas, peras...), que admite filtros avanzados (<, >, like...) y que trabaja indistintamente con JSON o XML (con sus restricciones)... Es que cada vez que lo veo me beso a mí mismo.

Lástima que no esté todo lo estable que yo desearía, pero todo llegará.

En resumen, una buena parte de los servicios que pululan por internet, emulando a algunas pancartas del 15-M “lo llaman REST y no lo es”. Eso es lo que quería dejar claro: en muchos casos estamos infrautilizando la tecnología o arrastrando errores año tras año, por cabezonería (y yo el primero).

La próxima vez que tengas que hacer un CRUD: piensa en REST.

Salut!


Más información:
REST Web Services
Introducción a REST
Más REST
Presentación sobre REST

Entorno de Desarrollo (III) - Eclipse y xdebug

Tras instalar un entorno donde ejecutar PHP el siguiente paso lógico, tras probar que funciona, sería decidir cómo editar los ficheros (o páginas) que vamos a utilizar.

Como ya he dicho hay gente que todavía usa el bloc de notas (o sus equivalentes en Linux, incluyendo vi o Emacs) y algún “avanzado” ha descubierto Notepad++ o Ultraedit (probablemente crackeado, que todavía no conozco a nadie que haya pagado por él).

Yo soy algo más pijo y prefiero un entorno “integrado” donde poder ver todo a primera vista, tener arbolitos con mis objetos categorizados y poder navegar con comodidad entre los, habitualmente, cientos de objetos con los que suelo trabajar. Y lo más importante, necesito, o mejor, me es imprescindible el poder depurar el código, porque no siempre un fichero de log te da todo lo que necesitas.

Yo para todo esto uso Eclipse PDT, que es una especialización de Eclipse para trabajar con PHP. Es lo que YO uso y lo que yo recomiendo a quien me pregunta. Este entorno cubre por completo mis necesidades y además, para los que hemos trabajado con Java, es un entorno casi “de facto” por la cantidad de plugins útiles que tiene para nuestro trabajo diario.

Si a alguien le interesan otros entornos, como Zend Studio o similares, no voy a hablar de ellos aquí.

Instalar Eclipse no tiene demasiado secreto:

• En Windows es bajarse un fichero y descomprimirlo (doy por supuesto que se tiene la máquina virtual de Java).
• En Linux suele estar en los repositorios de programas y si no, habrá que buscar ayuda en la web de eclipse o preguntando a papá Google.

Como ya advertí la información que ofrezco no es para muñones, así que habrá que acostumbrarse a leer, que yo solo soy el padre de mis hijos, no de todo el mundo.

Si ya se tiene un Eclipse instalado podría actualizarse para que maneje PHP. En la web de Eclipse nos lo explican de manera bastante sencilla: http://wiki.eclipse.org/PDT/Installation

Cuando hayamos acabado ya podremos acceder a nuestra nueva instalación de Eclipse y editar ficheros como tontos.

Entorno Eclipse

xdebug - depurador y más

xdebug es una pequeña maravilla para PHP que nos va a permitir (entre otras cosas):
- Depurar código PHP (depuración remota).
- Realizar profiling del código ejecutado.
- Realizar Code coverage del código, muy útil para el test unitario.

Instalar xdebug es relativamente sencillo y en este enlace de Zend lo explican paso a paso: http://devzone.zend.com/article/2803-Introducing-xdebug.

Para Linux la manera más sencilla es instalando a través de PECL que es algo así como un macro repositorio de cosas útiles.

Para instalar PECL en ubuntu y similares se han de tener instaladas PEAR y las herramientas de desarrollo de php, tal como explican en este enlace: how to install PECL extensions.

Realmente debería instalarse con los comandos:

sudo apt-get install php-pear
sudo apt-get install php5-dev
sudo pecl install xdebug

En Windows hay que tener cuidado ya que se ha de saber con qué versión de Visual C++ ha sido compilada nuestra versión de PHP y si tenemos o no una versión Thread Safe. Para evitarnos problemas en esta página se puede pegar lo que nos devuelve phpInfo y sabremos qué versión descargar: Find xdebug binary

Tras instalarlo habría que activarlo y configurarlo y para ello hay que editar el fichero php.ini. Su ubicación depende del sistema operativo y el servidor LAMP/WAMP usado.

• Si se usa Wampserver en Windows se puede acceder a él a través del panel de control.
• En Linux suele estar en el directorio /etc/php5/apache2 o alguno similar y si no siempre se puede localizar utilizando estos comandos:

sudo updatedb
sudo locate php.ini

Una vez editado el fichero php.ini habrá que agregar una línea similar a la siguiente (cambiar las rutas por las que correspondan a la ubicación de la librería xdebug):

Windows:

zend_extension_ts="c:\php\ext\php_xdebug-2.0.1-5.2.1.dll"

Linux:

zend_extension="/usr/lib/apache2/modules/xdebug.so"

Yo suelo ubicarla al final de la definición de las extensiones porque justo después agrego la configuración de xdebug.

Existen varios parámetros que se pueden configurar (agregar las líneas indicadas en el php.ini, tras las anteriores), aunque yo, personalmente, sólo suelo incluir los siguientes en una instalación básica:

[xdebug]
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"

Esto nos permite depuración remota desde localhost para el puerto 9000. Todas las opciones de configuración están explicadas en la documentación de xdebug así que sólo me pararé cuando alguna me parezca importante.

En mi caso, dado que uso ciertos servicios que trabajan en el puerto 9000 suelo tener que cambiar el parámetro xdebug.remote_port a otro puerto.

Ahora ya deberíamos tneer preparado el entorno para depurar y para ello reiniciamos Apache:

Linux

sudo service apache2 restart (o su equivalente en otras distribuciones)

Windows

Desde el panel de control de WampServer o el que sea.

Al ejecutar http://localhost/info.php (que espero que no se haya borrado) se deberá obtener algo similar a lo mostrado en la figura:

phpInfo + xdebug

 This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
   with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans
Y deberá existir una sección xdebug donde se podrán ver todos los parámetros de configuración de la extensión.

Si el servidor no arrancase habría que examinar los logs de Apache y PHP para averiguar qué extensión está fallando y buscar ayuda en internet. Los errores que me he encontrado yo han sido, casi siempre, librerías de versiones erróneas.

Depurando con Eclipse

Llegamos a la parte útil y donde comenzaremos a ver la potencia de xdebug: depurando.

En este artículo podemos ver los pormenores de configuración del entorno de depuración, que no es que sea nada del otro mundo: Debugging PHP Applications with xdebug

La secuencia de pasos está bastante clara y, conociendo un poco Eclipse, se puede averiguar dónde cambiar ciertas opciones de configuración.

Por ejemplo, podemos cambiar el depurador o cambiar sus opciones (en el caso de que se cambie el puerto, por ejemplo). O eliminar el check que viene marcado por defecto siempre de “Break at first line” que con proyectos grandes puede hacerse pesado.

Todo eso puede hacerse desde la opción PHP de la ventana de preferencias de Eclipse:

Para averiguar qué efecto causa cada cosa se puede recurrir al clásico “trastear”. No estoy yo para hacer manuales pormenorizados de todo. Si hubiese problemas, internet es una gran fuente de información y casi seguro que los errores que tenemos le han sucedido a alguien ya.

El caso es que ya deberíamos haber acabado de configurar Eclipse para que pueda depurar remotamente así que vamos a crear un fichero de prueba llamado simple.php y rellenarlo con este código:

<?php

class Pakito {
    public function show($message) {
       $result = 'Este es el mensaje: '.$message;
       echo $result;
    }
}

$clase = new Pakito(); // Agregar punto de parada aquí
$clase->show('Chorrada de prueba');

?>

Odio hacer programas de ejemplo así que me he lucido bastante poco con éste. Tampoco es que la calidad vaya a variar mucho en el futuro por muchas críticas que reciba, así que en este caso toca aguantarse con lo que hay.

Primero deberíamos poner un punto de parada en la línea que he indicado y eso se hace desde dentro de Eclipse. Deberías saberlo ya: doble click en la zona sombreada del editor de ficheros.

El siguiente paso es lanzar la depuración en sí: botón derecho sobre el fichero (en el árbol de ficheros) y seleccionar la opción de “Debug as” y “PHP Web Page”.

Y si todo va bien (que debería) se abrirá la perspectiva de depuración PHP de Eclipse y el depurador se nos parará en el breakpoint indicado en nuestro chorriprograma (o en la primera línea si es que no hemos quitado el check).

Se puede ver que disponemos de las habituales herramientas de depuración de Eclipse, incluidas la pila de llamada y las variables. Como curiosidad se pueden acceder a las variables internas del servidor (por ejemplo $SERVER, $REQUEST o $COOKIES). ¡Semos todopoderosos!

Supongo que llegar a este punto no debería haber dado demasiados problemas. Lo que pudiera surgir probablemente sería alguna mala configuración de rutas (por ejemplo la ruta hacia el ejecutable de php) o de puertos. De todas formas: siempre nos quedará internet.

xdebug es una herramienta tremendamente potente de depuración y, aunque hablaré de ello en detalle más adelante, aquí van un par de enlaces, además de los presentes en la documentación oficial, para saborear sus posibilidades de Profiling (mucho cuidado porque se come el disco en un visto y no visto) y Code Coverage.

En unión con PHPUnit es una herramienta my efectiva para el TDD.

En futuros posts ampliaré la parte de Code Coverage con PHPUnit y Phing, el equivalente de ANT para PHP.


Salut!

Entorno de desarrollo LAMP (II) - Servidores web

En este artículo voy a mostrar cómo instalar un servidor LAMP/WAMP completo: Apache + PHP + MySQL.

Como no pretendo montar un supertutorial y repetir toda la información disponible por la red sólo voy a comentar los enlaces y dar ciertas indicaciones en casos especiales.

Tampoco, en este artículo, entraré en discusiones sobre si es mejor Apache como servidor web o debería usar Lighttpd porque es la bomba, o si MySQL, Oracle o PostgreSQL como motor de base de datos. Mi intención, ahora mismo es tener un entorno (de desarrollo, integración e incluso producción) funcionando. Si el desarrollo se realiza de forma correcta la migración a otros entornos no debería traer demasiados dolores de cabeza.

Empezaremos con el servidor LAMP/WAMP: Apache, PHP y MySQL. Las instrucciones las daré para Windows y Linux (en principio ubuntu y derivados)

Windows

Para Windows yo suelo utilizar WampServer, no porque sea mejor o peor sino porque es sencillo de instalar y estoy acostumbrado a su panel de control. A algunos les gusta más XAmpp pero yo sólo he usado éste para crear “demos” y llevármelas en un lápiz usb.

Como la página principal es muy explicativa y la instalación es sencillísima no voy a entrar en más detalles. Sólo hay que ir a http://www.wampserver.com/en/ y seguir las instrucciones.

Página web de WampServer

Tras hacer la instalación tendremos un icono nuevo, llamado WampServer, y al lanzarlo nos aparecerá un nuevo “applet” en la barra de herramientas desde donde podremos lanzar/apagar el servidor y realizar algunas tareas de configuración.

Icono WampServer y panel de control

A través de los menús podremos activar y desactivar módulos de Apache y PHP así como acceder al gestor de bases de datos PHPMyAdmin. Activar un módulo es tan simple como hacer click sobre él; WampServer se reiniciará y el módulo estará disponible al momento.

También se puede realizar lo mismo a través de los ficheros de configuración correspondientes (httpd.conf, php.ini, my.ini) a los que se puede acceder a través del panel de control de WampServer.

Editando httpd.conf

Para comprobar que está correctamente instalado (tanto el servidor web como PHP) simplemente se ha de crear un fichero con el nombre, por ejemplo, info.php con el siguiente contenido:

&lt;?phpphpInfo();
?&gt;

Este fichero ha de guardarse en el directorio “root” de apache. Si no se han tocado demasiado las rutas será algo como c:\wamp\www. Una vez allí sólo habrá que dirigirse a http://localhost/info.php y comprobar que se obtiene alguna pantalla similar a la mostrada.

phpInfo()

Otro paso es comprobar la base de datos y ésto se puede hacer con phpMyAdmin desde el panel de control de WampServer. Debería aparecer algo similar a la imagen de abajo.

phpMyAdmin

Si algo falla habrá que bucear en internet para descubrir qué es, a menos que uno sea adivino. Se pueden consultar los logs de cada aplicación desde el panel de control de Wamp. Muchas veces serán problemas de módulos de Apache/PHP mal configurados (por lo que recomiendo desactivarlos todos e ir activándolos uno a uno hasta llegar al culpable) o conflictos con puertos (por ejemplo tener instalado el IIS a la vez que el Wamp)

Apache error log

Linux

Como he dicho me voy a basar en Ubuntu y sus derivadas y presupondré que se saben instalar programas para este sistema operativo. Como no soy tan mala persona como parezco ahí va una pista: en esta página hay muchísima información sobre ubuntu y cómo trastear con él - Slice of Linux.

Normalmente al instalar Linux se pueden seleccionar los paquetes a agregar así que es probable que alguna parte de los componentes esté presente ya. Aunque se lance la reinstalación la mayoría de sistemas de empaquetado de Linux son lo bastante inteligentes como para comprobar antes si ya existe el programa.

Yo soy de los que prefiere comenzar con una instalación básica sin demasiada porquería e ir añadiendo a mano lo que necesite. Como buena parte de lo que hago va a estar en servidores y abierto a internet me parece muy peligroso meter toda la mierda de golpe y dejarla descontrolada. Linux es seguro, sí, pero yo no pondría la mano en el fuego porque ningún programa no te vaya a abrir un puerto que no deseas o bajar una configuración que dé acceso a los “programas de hacking” que ejecutan los script kiddies por ahí.

Por otra parte rara será la empresa de hosting que te ofrezca un terminal remoto o un panel de control aceptable a precio razonable así que considero imprescindible, cuando instalo un entorno de integración o pre-producción, que sea lo más parecido al entorno real, sin aditivos innecesarios. Lo mejor es ver paso a paso cómo instalar un ubuntu server.

También es conveniente ver cómo instalar un sistema “AMP” paso a paso en Ubuntu 11.04 (vale también para otras versiones). Las diferencias con Debian u otras distribuciones que usan paquetes .deb son mínimas (quizás de versiones). Para el resto de distribuciones, pues habrá que buscar ayuda; yo hace años que no uso CentOS o Fedora. La culpa es vuestra por usarlas :-P

Es recomendable instalarse phpMyAdmin en Linux ya que, a diferencia de los “AMP” de Windows, no suele estar por defecto.

Prometo que, por ahora, Canonical no me paga nada para que haga publicidad de Ubuntu. Lo que pasa es que soy un poco muñón cuando toco cosas y si la cago prefiero tener dónde buscar soluciones... y los Ubuntus están hasta en la sopa. Lo fácil que es googlear “lamp ubuntu” y que te devuelva chorrocientos tutoriales y hacer lo mismo con Fedora y que se acaben en la página 1...

Bien lo importante de esta instalación es recordar que las páginas web deberán alojarse en el directorio “var/www” (o su equivalente que habrá que buscar convenientemente según la distribución usada).

En este punto tendremos un servidor Apache, con PHP y MySQL así que ya se puede empezar a trastear. Todavía no está “seguro” ya que, por ejemplo, la clave de root en MySQL es probable
que esté en blanco o que sea un verdadero coñazo ejecutar ciertos scripts desde phpMyAdmin.

Bonus - MySQL Workbench

Alguno, sobre todo los que provenimos del mundo Oracle, podría echar de menos el Toad, aunque existe una versión para MySQL. Pero, ¿para qué pagar cuando puedes tener una herramienta similar, o incluso mejor, de forma gratuita?

De las pocas cosas buenas que hizo Oracle cuando compró MySQL fue unificar todas las herramientas de cliente en una sola: MySQL Workbench. Entre las cosas malas que hicieron fue subir los precios, pero ya lo criticaré si lo veo conveniente.

Con esta herramienta se pueden ejecutar scripts, acceder a las base de datos y a sus objetos, diseñar visualmente el modelo de datos e incluso controlar los servidores (start, stop, backups...). Así que recomiendo encarecidamente que cualquiera que vaya a trastear con bases de datos se lo instale.

MySQL Workbench. Tomada de www.mysql.com

En Windows es fácil: descargarse el ejecutable y lanzarlo. En Linux o bien está el programa en la lista de “instalables” o habrá de hacerse a mano (ésto para ubuntu https://help.ubuntu.com/community/MySqlWorkBench). Lo malo es que es muy probable que después de que Oracle haya metido las zarpas ya no exista un versión Open Source que pueda incluirse en los repositorios.



Bonus II - Cambio password de root (mySQL)

Tal como suelen estar las instalaciones por defecto en mysql la verdad es que de seguridad, poca. En Linux es probable que sí haya solicitado una password pero con Windows, y con el WampServer, estoy casi seguro que la password será “en blanco” (no literalmente... password vacía).

Con phpMyAdmin se puede cambiar la password sin problemas desde la pestaña de Privilegios y editando el usuario afectado.

Tras cambiar la password, phpMyAdmin dejará de funcionar y habrá que editar el archivo config.inc.php para incluir las nuevas credenciales.


Bonus III - Panel de Control Web en Linux

Cuando trabajo con servidores Linux me resulta un engorro el tener que entrar por telnet para reiniciar servidores o editar ficheros, sobre todo para lo último. Si el ordenador está cerca y es accesible al 100% no hay problema ya que siempre se puede instalar un entorno gráfico y la cosas se facilita. Si el ordenador está a 3000 km en un hosting podemos morirnos con los tiempos de latencia: movemos el ratón y, tras un café o dos, responderá al otro lado (sí, exagero).

En estos casos “remotos”, si nuestro proveedor de hosting no nos provee de un panel “chachi” como cPanel (de pago) tenemos todavía una opción free: Webmin.

Con este panel de control podemos controlarlo todo de manera visual y usando un navegador. Usa applets Java (puaj!) para ciertos servicios, pero es un mal menor. No es que la línea de comandos no sea bonita pero si nos ponen las cosas algo más fáciles acabaremos antes.

Como ya otros han escrito sobre el tema me ahorro el hacerlo yo. Para instalar: http://sliceoflinux.com/2009/09/07/instalar-webmin-en-ubuntu-paso-a-paso/. ¡Ojo! hay que tener cuidado con las versiones de Wembin o de sus dependencias. Lo mejor es ir a la página y asegurarse de que estamos descargando la versión más reciente.

Bonus IV - Activar/desactivar módulos de Apache (y PHP)

Usando WampServer en Windows es tan sencillo como poner o quitar el check en el módulo afectado (poner es pulsar una vez, quitar, es pulsar otra vez, el servidor se reiniciará cada vez que se cambie).

Sucede lo mismo para activar o desactivar módulos de PHP (excepto algunos que se verán más adelante).

Con Linux (basadas en Debian) es similar, pero en vez de usar el ratón se usarán los comandos "a2enmod" (activar) y "a2dismod" (desactivar) seguidos del nombre del comando. Por ejemplo, para activar el módulo rewrite (mod_rewrite):

a2enmod rewrite

Si nuestro Linux no dispusiese de este comando habría que buscar una alternativa o editar el fichero httpd.conf (normalmente en /etc/apache2) y comentar o descomentar la línea del módulo afectado.

En el caso de los módulos PHP no recuerdo si existe algún comando similar así que lo que se suele hacer es editar el fichero php.ini (su ubicación cambia según la distribución) y comentar o descomentar “lo que sea”.




Tras seguir todos estos pasos ya disponemos de la base para ejecutar programas con PHP. Realmente dispondremos de un servidor que podríamos publicar hacia internet y al que se podría acceder (usar la opción “Put Online” o su equivalente en castellano del panel de control de WampServer) desde fuera.

Dando acceso al servidor para internet

Es más, como tenemos un servidor Apache hecho y derecho, nada nos impediría instalar otros módulos para otros lenguajes, por ejemplo Python o Ruby. En un futuro escribiré algo sobre cómo trastear con ello y cómo trastear con otros servidores web y bases de datos.

Si a alguien le apetece jugar que pruebe a instalar un gestor de contenidos (CMS), como por ejemplo Drupal. Funcionará seguro, aunque es probable que haya que activar algún módulo.

Por ahora lo dejo aquí. Espero no haber olvidado nada.

Salut!

Una tontería

Una gilipollez que me han pasado y me ha hecho gracia...


Y aquí el original



mooooooola

¿Sistemas o Desarrollo?

El post anterior ha hecho que vuelva a mi mente una pregunta que me hicieron hace años, allá por la prehistoria: ¿y tú qué eres? ¿sistemero o picateclas?

Cuando me la hicieron conteste como buenamente pude porque en esa época todavía había preguntas que me descolocaban. Mi respuesta fue algo así como “persona, soy persona, y tú eres un racista” (y me fui llorando... no estoy orgulloso de ello). En aquella época me negaba a aceptar que alguien que programaba no supiera batirse con la configuración de un servidor, o no supiese instalar, por ejemplo, algo tan simple como una base de datos.

He de decir que mi “background” es del mundo del metal. Aparte de que entre mis grupos de cabecera están Metallica, AC/DC y Van Halen mi “otra” parte de metal viene de que durante casi una década me dediqué a cacharrear en las tripas de las máquinas. Me daba igual meterme dentro de un cajero automático, toquetear un S/36 de IBM, untar un cable con vaselina para que pasase por un conducto atestado con otros cables (y algún ente vivo con dientes) o diseñar y configurar un dominio para 100 puestos de trabajo con Windows NT.

Lo del desarrollo empezó como un hobby y se fue profesionalizando cuando pude dar “el gran salto”. Hasta el momento saltamontes yo estaba más que acostumbrado a cacharrear, llevarme calambrazos por tocar donde no debía y a tratar de entender en qué coño estaba pensando el tío que diseñó esa manera tan extraña de configurar un programa.

Y como los que me rodeaban hacían más o menos lo mismo que yo llegué a creer que si te dedicabas a eso de la informática tenías que saber de todo porque cualquier día podía hacerte falta.

Pero he aquí que un día entré profesionalmente en el mundo del desarrollo de software y tenía un alma inocente y muchas ganas de aprender. O sea, era un pardillo.

Para mí los programadores eran una élite inalcanzable, con grandes cerebros (y muchas veces, cabezas), capaces de entender conceptos abstractos que al resto de los mortales se nos escapaban (hoy es el día en el que todavía tengo que pensar dos veces cómo hacer una función recursiva), todopoderosos, pues podían controlar y reprogramar cualquier aparato que cayese bajo sus narices. Los que se dedicaban a programar para mí eran “los putos amos”.

Esos analistas, hablando de cosas como singletons, multithreading y transacciones. Aquel jefe de arquitectura que se había currado un puente COM/Corba que todavía hoy sé que sigue en producción en algún sitio. Ese programador con años de experiencia, admirado y puesto como ejemplo de eficiencia por tus jefes, que te miraba con suficiencia cuando hacías una pregunta simple sobre JSPs (casi seguro que pensaba “ya viene a tocarme las mandangas el mierdecilla este... así no hay quien chatee a gusto”).

Para mí era como estar en Hollywood o en la NASA. Cuando me preguntaban “y tú en que trabajas?” se me llenaba la boca diciendo “soy desarrollador de software” (ahora digo que soy Analista, que parece que tiene más estilo). Las mujeres caían a mis pies, me abrían todas las puertas de las discotecas y andaba como si tuviera una escoba metida por el culo (hasta llevaba traje y tenía el pelo corto).

El día que me hicieron la pregunta de “sistemero o picateclas”, tras secarme las lágrimas y dejar de temblar, me puse a reflexionar y a observar a mi alrededor para ubicarme.

Todavía hoy me dura el disgusto.

A la mayor parte de los que me rodean (y rodeaban) les dices que te configuren un servidor, aunque sea uno como con el que están trabajando cada día, y les da un telele. Yo creo que sacarlos de picar código a cascoporro y ponerlos a resolver una incidencia sencillita de configuración los mataría. Me parece tristísimo, pero la distinción entre técnicos de sistemas y técnicos de desarrollo existe, y la zanja que los separa es lo suficientemente amplia para que se le quiten a uno las ganas de saltar.

Ojo que tampoco digo que eso sea malo, cada uno se especializa en lo que quiere o en lo que cree que le va a dar dinero. Hasta ahora ha sido Java y su ecosistema, que das una patada a un edificio y te caen 1000 programadores. Cuando yo empecé era Visual Basic y Clipper (y todavía estaba Cobol).

Está claro que no puedes saberlo todo. Si eres la bestia de los EJBs no tienes tiempo para dedicarlo a ser un master del universo en Oracle o un supercertified de la muerte en Windows Azure.

Pero aún así a mí me sigue pareciendo extraño que haya personas que usan cosas que no saben como funcionan; bueno no, la analogía no es buena, pues casi todos usamos el coche y no tenemos ni idea de cómo cambiar las bombillas. Es como si te dedicases a construir motores de coches sin tener ni idea de si el chasis va a soportarlo, de dónde va a ir anclado o de si la carrocería es lo suficientemente amplia para que quepa.

Hoy yo tengo claro qué respondería a la pregunta de “sistemero o picateclas”. Usaría la definición no oficial de “rol” que me pusieron años ha: soy un asterisco.

En mi caso me he negado a especializarme. Lo toco todo y no le tengo miedo a ninguno de los nuevos juguetes que esta profesión nos da (asco sí, miedo no). Quizás he tenido suerte y he caído en departamentos y/o proyectos que me han dejado expresarme como el aprendiz de todo y maestro de nada que soy (sí, y he sido responsable de la arquitectura de varios de ellos).

¿Disperso? Quizás. Pero tengo la tranquilidad de saber (por haberlo comprobado) que cuando algo falla yo sé arreglarlo.

Y todo este tocho me ha venido a la cabeza por culpa de una pregunta...

Salut!

Entorno de Desarrollo LAMP (I) - Introducción

El primer paso lógico para empezar a desarrollar lo que sea con lo que sea sería disponer de un entorno de desarrollo. Ese entorno debería ser cómodo de utilizar, debería permitir depurar (porque examinar logs NO es una buena opción mientras desarrollas) y ya si permite esas cosas para frikis de Test unitarios, ayuda a la documentación, compilación, despliegue... vamos, eso es para nota.

No es que sea imprescindible, claro. Durante una temporada yo estuve programando en C++ editando con el vi directamente en un host HP-UX y todavía sigo aquí. También he conducido coches sin dirección asistida, he tenido bicicletas sin frenos (me dejaba la suela de los zapatos en la rueda de atrás) y tele sin mando a distancia.

Conozco a algún programador que edita ficheros PHP con el bloc de notas de Windows; conozco a alguno que cuando le enseñé el Notepad++ casi tuvo un orgasmo mental al ver tantos colorines e incluso he visto los ojos de alguno saliéndose de las órbitas al ver cómo yo depuraba tan tranquilamente con xdebug mientras él sufría leyendo archivos de texto que no daban pistas.

Lo que quiero decir es que a día de hoy, en el año 2011, con todas las herramientas que tenemos a nuestro alcance los desarrolladores (la mayoría de ellas gratuitas), la potencia de nuestros ordenadores y toda la ayuda que se puede encontrar por internet hay que ser un pedazo de inútil, cenutrio y lerdo para trabajar de manera precaria. Además opino que gente así no debería tener derecho a tocar un ordenador, pero esa es otra historia.

Podría disculpar a aquel que tiene que aguantarse con las herramientas que su “jefe” le provee. Sí, hay muchos que se hacen llamar “jefes de proyecto” o “gestores” que son capaces de condenar a un equipo de desarrollo a malvivir y maltrabajar por ahorrarse unos euros (o más bien transferirlos a su bolsillo para su viaje a Costa Rica).

El asunto es que a mí me gusta trabajar a gusto, con las herramientas adecuadas y si puedo ahorrarme tiempo gracias a ello, mejor, porque así podré dedicarlo a mi gran afición: no hacer nada.

Como éste es el entorno de desarrollo que a MI me gusta voy a usar los siguientes componentes:

• Un servidor LAMP, WAMP o como quiera que se llame para Mac, a gusto del consumidor. No soy demasiado racista para los sistemas de escritorio. En el caso de Mac no daré ninguna indicación pues ni tengo ni quiero :-)
• Varios componentes extra de PHP: xdebug (depuración/caché), APC (caché de código), memcached (caché, porque yo lo valgo), PEAR (librerías extra)...
• Eclipse PDT como entorno de desarrollo. No es que me me disgusten los otros, es que o vienen limitados, o con pocos plugins o, simplemente, son de pago (y yo, pobre).
• Extensiones para Eclipse (test unitario, documentación, acceso a repositorios de código, etc.)

Como las cosas al pasarlas al entorno real suelen cascar bastante (me vienen a la cabeza problemas con mayúsculas y minúsculas al pasar de Windows a Linux) también comentaré algo sobre montar un entorno de “integración” usando máquinas virtuales. En este caso usaré VirtualBox, porque me parece bastante ligera y es la única que me ha permitido mantener 4 máquinas virtuales funcionando simultáneamente sin que el ordenador se me muriera de asco. Adiós VMWare.

Una advertencia: en principio no escribo para cenutrios. Presupongo unos conocimientos mínimos (saber mover el ratón sin tirones, por ejemplo) y espero que los links que voy proveyendo se vayan leyendo porque me niego a repetir cien veces lo que otros ya han explicado.

De todas formas si alguien necesita ayuda extra yo nunca me niego a trabajar si hay dinero por medio. Mi tiempo no es gratis y lo pierdo como a mí me da la gana.

El post se me ha quedado demasiado largo así que dejaremos la chicha útil para el siguiente. Eso sí, no prometo que no se me vaya a ir la olla otra vez y me ponga a contar batallitas.


Salut!



Pd - Lo que tengo se llama verborrea y está mezclado con dispersión. Es que empiezo a acordarme de cosas y o las pongo o las pongo.

unga, o como complicarse la vida (I)

¿Alguien recuerda Second Life? Yo todavía estoy por allí, y de vez en cuando cae alguna venta. De hecho hemos llegado a ganar bastante dinero allí dentro. Es un mundo virtual 3D con bastantes posibilidades, si se hubiese explotado bien, no sólo para ver animaciones de muñequitos practicando sexo, sino para educación, representación arquitectónica o incluso juegos.

Pero seguro que muchos no conocen OpenSimulator, que intenta ser algo así como un Second Life open source y añade algunas cosas interesantes y otras realmente horribles. Corre sobre la plataforma .NET/Mono, pero es que nadie es perfecto. Le llamaremos Opensim, porque es un coñazo ir refiriéndose a su nombre oficial todo el rato.

Si algo tienen en común los dos entornos es la evidente falta de buen gusto, al menos visual. No es coña, la mayor parte de lo que allí se ve, construcciones sobre todo, te haría vomitar y arrancarte los ojos si estuvieses en el mundo real. Si el caso es grave en Second Life, mejor no hablemos de Opensimulator, donde el material suele ser creado por... desarrolladores o, en el peor de los casos, por usuarios con ínfulas pero nulo talento.

Que no es que todos los desarrolladores tengan mal gusto; por ejemplo yo tengo un gusto excelente y es una delicia utilizar las aplicaciones que diseño. No tengo abuela, eso no, pero es que ya sería demasiada perfección en una sola persona y no es cuestión de ir humillando al resto de la humanidad. Ante todo uno es humilde y modesto y se compadece de esas pobres mentes inferiores que pululan por este nuestro planeta.

Si quieres conseguir un absoluto fracaso de usabilidad dile a un desarrollador que diseñe el interface gráfico de tu aplicación. Si te gustan las emociones fuertes dile a un desarrollador (que no sea yo, claro) que te diseñe un edificio. Normalmente el resultado es parecido, por su elegancia, a esos engendros mitad orco mitad no se sabe qué que aparecían en el señor de los anillos.

Y me disperso...

Lo que quería explicar es que yo estuve mezclado en el tema de OpenSim. Hace ya mucho tiempo sugerí e hice las primeras pruebas para utilizar NHibernate, alguien lo implementó y un año después fue deshechado por falta de mantenimiento. La verdad no me importa demasiado porque lo que a mí me importa va por otro lado.

OpenSim es una especie de servidor de realidad virtual, es decir, que envía texturas, posiciones de objetos, colisiones... a un cliente visual y se encarga de mantener el contenido (persistirlo). Puede ejecutarse en solitario o pueden unirse varios servidores en lo que se viene a llamar un grid, y ahí empieza lo interesante.

Los servidores de Opensim, cuando se conectan entre sí, utilizan a su vez unos servidores de soporte que se encargan de controlar los usuarios, el inventario de objetos, los objetos en sí y la conectividad entre los servidores. Lo interesante de esta parte es que estos servidores utilizan http para comunicarse, por lo que podría usarse sin problemas cualquier servidor web.

En Opensim como son más chulos que un ocho se han currado sus servidores y se han hecho sus pajas mentales reinventando una arquitectura de plugins, unos servidores dedicados corriendo en .NET y, en mi opinión, es la peor parte del proyecto. Por ejemplo, se ha de usar una consola para realizar cualquier operación (dar de alta usuarios, crear servidores, bloquear usuarios...). O eso o escribes guarramente en la base de datos, que también hay "aplicaciones" que lo hacen... ahí con toda la seguridad.

Claro que ha habido intentos de hacer correr esos servidores de soporte en servidores web y algunos de ellos están funcionando, tanto programados en Perl, como con PHP o Python.

Pero aquí el menda es más chulo que un ocho y no le gustó absolutamente nada de lo que había así que decidió currárselo él solito y, aproximadamente en Marzo o Abril de 2010, presenté unga, mi propuesta de servidores de soporte. El éxito fue tan moderado que sólo lo estoy usando yo, pero el asunto prometía... aunque he de reconocer que me equivoqué en su concepción.

unga, que al principio era una serie inconexa de servicios, programados en PHP, que usaban XML-RPC y ligeramente jquery y algunos plugins bonitos para hacer ventanitas y efectos visuales, ha evolucionado muchísimo en un año. Este sistema, que al principio únicamente quería para conectarse a servidores Opensim se está convirtiendo en todo un framework o una plataforma, más bien, porque estoy rediseñando incluso la filosofía de funcionamiento.

Está programado con PHP, corre sobre el framework Code Igniter (el más rápido y eficiente que he encontrado), usa intensamente REST (sí, el puro, el que usa los comandos http, no esa paja mental que algunos llaman REST y después no es más que un POST mal entendido), Ajax (con jquery, que es de lo mejorcito), es modular (pegar, activar y a trabajar) y lo he usado para otros proyectos ya, entre ellos un gestor de descargas y una aplicación de control de fabricación.

De hecho me estoy pensando hasta en crear un módulo de gestión de contenido para poder usarlo como cualquier Drupal de la vida.

Lo interesante para un desarrollador quizás no sea unga en sí sino todas las tecnologías y metodologías que he usado y estoy aplicando en el proyecto, y de ellas voy a hablar en próximas entradas.

Entre los temas que voy a tratar estarán:

• Configuración de un entorno de desarrollo para PHP (con debugger).
• TDD y PHPUnit y ,sobre todo, los problemas de integrarlo con Code Igniter.
• Construcción automática, deployment, etc. con Phing.
• REST y cómo implementarlo.
• Aventuras con jquery o como llevar adelante una arquitectura visual ajax independiente del entorno de servidor.
• Migración a Python (Django y Tornado Web).
• Por qué Java es el demonio y huyo como de la peste de ese lenguaje.
• También programo con C# y todavía no he sido abducido por el lado oscuro de Micro$oft.
• ¿Tendré huevos para migrar ciertos servicios UDP a Node.js?

Y todo esto amenizado con comentarios sobre cómo configurar servidores Linux, optimizar bases de datos, uso de cache de código, CDNs y demás historias "modelnas" que podrían poner palote a muchos.

Que no es que sea para enseñar a nadie (que realmente dudo que le interese a demasiada gente), es que aquí el amigo escribe y escribe y como soy un figura se me pierden los manuales en el disco duro de no se qué ordenador y no recuerdo nada después. Al menos si lo pongo en internet ya se encargará de buscármelo el señor Google.

Pues nada, que prontito empezaré a guarrear la blogosfera con mi pajerío mental tecnofriki.

Salut!