Genbetadev

Defacement contra el impago de una web, ¿una solución acertada?

Johnbo — Thu, 17 May 2012 14:00:00 GMT

La imagen que veis arriba es un ejemplo real que estos días está circulando por diversas redes sociales. Se trata de la web de una pequeña empresa que, atendiendo a la versión de su diseñador, no fue pagada. Esto me da que pensar y me hace lanzar una pregunta al aire: ¿sirve de algo okupar la web de quien no te paga?

La raíz del problema está bastante clara y es conocida en nuestro mundillo: a día de hoy, sigue siendo muy difícil hacer ver a los clientes el valor de nuestro trabajo. Nuestra profesión está muy infravalorada y nos encontramos con muchos clientes que piensan que programar una web es poner cuatro botones y que diseñarla artísticamente es hacer tres garabatos. Así, cuando llega el momento de la entrega y pasamos la factura, nos podemos encontrar con la desagradable sorpresa de que el clienta no se crea nuestros precios y decida no pagarnos.

Ante una situación así, ¿qué podemos hacer para cobrar lo que nos corresponde? ¿Cómo podríamos haber evitado llegar hasta aquí?

El dilema moral

Hacer un defacement es una decisión que no debería tomarse a la ligera. Sí, vale que tenemos la mala costumbre de querer comer a diario, pero antes de elegir ese método para reclamar tu dinero debes recordar el sabio dicho que aconsejaba:

No tomes decisiones estando enfadado, ni hagas promesas estando contento.

En el caso de una pequeña o mediana empresa es bastante probable que haya recaído sobre ti toda la responsabilidad tecnológica, desde el alquiler del hosting y el dominio, hasta la programación y diseño de la web. Es probable que tú tengas todas las claves del ftp, e incluso que seas el único que las conoce, pero tener ese poder no te da derecho a modificarlo a tu gusto. Por eso lo llaman ser el responsable del apartado tecnológico.

Al cambiar la web de tu cliente para mostrar tu reclamación en lugar de su producto, te estás rebajando al nivel de un cracker o de un chantajista. Pero es más, aparte de tu dilema ético está el hecho de que darías al cliente la potestad de denunciarte por diversas faltas o delitos, desde el incumplimiento de contrato hasta la difamación y otros delitos contra el honor.

Por otra parte, no hace falta tener acceso a las claves del dominio de la propia web para crearle una campaña en contra. Ahora son muchos los que se dedican a crear cuentas específicas de Twitter o páginas de empresa en Facebook con el nombre de la empresa morosa pero con contenidos que denuncian dicho impago. Una táctica similar fue usada por la “Plataforma per la llengua” para exigir el uso del catalán a varias marcas conocidas, registrando un dominio .cat por cada una de ellas y denunciando sus prácticas, aunque se ofrecían a ceder dichos dominios a las marcas de marras.

Aunque la estrategia dio algunos de sus frutos y las marcas adoptaron el dominio .cat, buena parte de la opinión pública lo vio como una extorsión a las multinacionales. Polémicas aparte, es precisamente con estas grandes empresas, tan preocupadas por su imagen pública, cuando más fácil es que funcione la táctica de la publicidad negativa, mientras que a una pyme puede afectarle mucho menos lo que se diga de ella.

Reputación vs cobro

Pero no todo queda ahí. Independientemente de cómo acabe la situación con el cliente con el que tienes la disputa, el deface puede convertirse en tu peor tarjeta de presentación. El mundo de la informática, y especialmente en algunos sectores concretos, es bastante endogámico, y tus posibles futuros clientes podrían tener conocimiento de las malas artes con las que has reclamado el cobro.

¿Qué opinión se puede hacer de ti un cliente que buscando tu portfolio se encuentra una página de denuncia que deja en mal lugar al cliente o anunciante? Ten en cuenta que este futuro cliente no sabrá si eres tú quien llevaba la razón contra tu no pagador, y es probable que se posicione junto al otro cliente y te vea como alguien con exigencias económicas muy altas o poco sentido de la ética profesional.

Salvo que la mordida por este proyecto sea muy importante en lo económico, es importante que sopeses cuánto podrías ganar si consigues que finalmente te pague, y cuánto puedes llegar a perder en proyectos futuros no concedidos por culpa de una reputación beligerante.

Cómo evitar llegar a este punto

En un mundo utópico tú sabrías reconocer todas las necesidades de un cliente, él sabría reconocer tu trabajo y ambos llegaríais a un acuerdo sobre el precio más justo para ese trabajo, tú entregarías la web con toda la funcionalidad en el plazo acordado y por último él te pagaría lo pactado. Demasiado utópico todo, ¿verdad?

En primer lugar, hagamos un poco de introspección. ¿Hemos cubierto las necesidades planteadas por el cliente? Si es así, ¿queda patente que están cubiertas? Si queremos hacer valer nuestro trabajo, lo primero que tenemos que conseguir es que quede constancia de que con nuestro desarrollo se van a satisfacer las necesidades por las que se nos llamó en un primer momento. Si la web no cumple alguno de los requisitos descritos, o la operatividad es tan compleja que no se ve de forma sencilla que la funcionalidad está realmente ahí, el cliente pensará que no hemos hecho el trabajo para el que nos contrató.

En segundo lugar, hay que acordar un precio que sea justo tanto para ti como para el cliente. Aquí no existe ninguna panacea, pero sí que puedes usar herramientas como la aplicación CuantoCobrar para que te sirva de guía para no inflar demasiado tus precios, al tiempo que le puedes mostrar al cliente unos baremos aproximados de cómo está el mercado y de los distintos costes en los que incurres, que van mucho más allá del teclear un poco y dibujar unos trazos.

Si hasta aquí ha ido todo bien y has conseguido involucrar al cliente en tu trabajo hasta el punto de reconocer su valor, ahora es toda tu responsabilidad el seguir con el plan trazado y entregar toda la funcionalidad en plazo. Desgraciadamente, los imprevistos son inevitables y siempre puede haber algo que lo impida, pero si has sabido demostrar tu implicación en el proyecto es menos probable que el cliente se aferre a la excusa de los plazos para incumplir su deber de pago.

No obstante, en esta vida hay mucho caradura y aunque hagas todo bien puede dejar de pagarte alegando fallos que no son tales o falta de liquidez debido a sus proveedores, etc. Puede que incluso se apodere de tus diseños sin haber pagado por ellos y los utilice en la rotulación de su establecimiento, coches de empresa, branding, etc. Ahí, inevitablemente, te ves en la misma situación que el compositor cuya obra han plagiado o el panadero al que le han robado su pan. No es plato de buen gusto, pero en esa situación debes denunciar y esperar que la justicia te conceda lo que es tuyo.

No obstante, si durante la fase de desarrollo (especialmente si te acercas al final y ya has invertido mucho tiempo y esfuerzo) sospechas que tu cliente pueda ser uno de esos caraduras, puedes intentar forzar una renegociación de las condiciones de pago y sólo activar ciertas funcionalidades conforme te vaya pagando la parte proporcional de las mismas.

Puestos a meter una bomba lógica dentro del programa, mejor que sea para activar funciones en el momento en el que cobres, que para desactivarlas si la otra parte incumple el trato. Si entregas una maqueta consistente, aunque sin funcionamiento real, será más fácil convencer al cliente de que si cumple con su obligación, activarás los datos y procesos reales.

En Tecnología Pyme | Si contratas a un profesional para diseñar tu web, deja que haga su trabajo
En Genbeta Dev | Los límites de la ética del programador mercenario, Autoempleo no es prostitución
Imagen de danone.cat | Plataforma per la llengua

¿Cuál fue tu primer lenguaje y por qué lo abandonaste?: La pregunta de la semana

Oscar Campos — Thu, 17 May 2012 10:10:14 GMT

Pues ya estamos aquí otra vez dispuestos a realizar la pregunta de la semana. La semana pasada afloró la vena filosófica y esta semana va a aflorar la pragmática:

¿Cuál fue tu primer lenguaje y por qué lo abandonaste?

A ser posible explicad de forma objetiva el motivo que os llevó a abandonar ese primer lenguaje que habíais abrazado y que tantas satisfacciones (o no) os había dado.

Como siempre, es mejor responder a la pregunta en la sección de respuestas en lugar de en los comentarios de esta entrada, aunque puedes hacerlo en los dos sitios si lo prefieres. Lo principal es que siempre respondas en la sección de respuestas y así tu respuesta podrá salir vencedora y aparecerá en el post de la próxima semana.

Y hablando de repuestas elegidas, esta es la respuesta elegida para nuestra pregunta de la semana pasada ¿Qué te motivó a convertirte en programador? enviada por errepunto (triki para los amigos):

¡Es lo más parecido a ser un nigromante! Creas un ejército de rutinas y funciones que lanzas con indiferencia a batallar a la RAM con el procesador como arma, para conseguir tus oscuros fines. Estooo, ¿cuál era la pregunta? :)

¡Nos vemos en la sección de respuestas!.

En Genbeta Dev | ¿Cuál fue tu primer lenguaje y por qué lo abandonaste?

Amazon Cloudfront, permite distribuir contenido dinámico desde sus CDN

Txema Rodríguez — Wed, 16 May 2012 06:51:25 GMT

A la capacidad de distribuir contenido estático y streaming de Amazon Cloudfront, se le une una nueva característica que permite servir contenido dinámico y personalizado con la ventaja de disponer de numerosos CDN repartidos por todo el mundo. El competidor de Akamai desarrollado por Amazon Web Services sigue ofreciendo más servicios a bajo coste y de una forma sencilla de configurar a través de la AWS Management Console.

Amazon explica en una entrada de su blog técnico que este nuevo servicio no implicará ningún coste adicional, ni la necesidad de escribir código adicional. Incrementa el rendimiento y la fiabilidad a la hora de servir contenido dinámico.

Podemos seleccionar distintos servidores orígenes para cada tipo de contenidos: un bucket de Amazon S3 para el contenido estático y Amazon EC2 para el contenido dinámico. Este contenido puede engancharse de cualquier instancia que tengamos en EC2 que sirva contenido dinámico indicando los paramentos que queramos en la query string para indicarle a Cloudfront si debe ofrecer ese contenido cacheado o directamente del servidor origen.

No está permitido ningún origen fuera de AWS, así que no podremos usar este servicio con nuestros propios servidores, pero es una buena alternativa si todo nuestro contenido está en Amazon EC2 o S3.

Más información | Amazon Cloudfront
Vía | AWS blog
Vídeo | Introducción a Amazon Cloudfront

Introducción: Play Framework 2 (Parte I: Scala)

Oscar Campos — Wed, 16 May 2012 04:00:00 GMT

Para aquellos que no lo conozcan, Play es un Framework de desarrollo web para Java y Scala. Ha sido desarrollado por Guillaume Bort como proyecto interno para su empresa Zenexity y luego liberado como Open Source.

A partir de la versión 2.0 del mismo, Martin Odersky y su compañía TypeSafe que a su vez son los creadores de Scala han decidido incluirlo en el paquete que denominan TypeSafe Stack.

Como ya hemos dicho, Play puede ser utilizado para construir sitios y aplicaciones web tanto en Java como en Scala comparten gran parte de la API ya que Scala puede importar y utilizar librerías de Java sin problemas.

Pero antes de hacer una pequeña introducción al framework es necesario hablar sobre que es Scala y por qué es “especial“. Esta guía introductoria no pretende ser una guía exhaustiva del lenguaje de programación Scala, tal tarea es algo que se escapa a mis pretensiones y mi inteligencia.

¿Qué es Scala?

Scala es un lenguaje de programación multiparadigma diseñado para integrar características de la programación orientada a objetos y de la programación funcional. Aunque nuestra primera reacción es pensar que ambos paradigmas son excluyentes, lo cierto es que Scala ha sabido mezclarlos de manera muy sutil con un gran resultado.

Scala es de tipado estático fuerte y por lo tanto debe compilarse aunque también puede utilizarse a modo de scripts utilizando el “intérprete” de línea de comandos para ejecutar pequeños programas escritos en él sin necesidad de compilar previamente a bytecode los mismos.

Scala nos permite programar de forma imperativa, funcional o ambas a la vez. Por ejemplo, podemos utilizar Polimorfismo clásico de la orientación a objetos o bien pattern matching para resolver el mismo problema. Podemos usar uno u otro paradigma dependiendo de si la solución que plantea parece la más adecuada a la hora de resolver el problema al que nos estamos enfrentando.

En Scala, así como en todos los lenguajes que soportan la programación funcional (incluso PHP después de su versión 5.3.1) las funciones son ciudadanos de primer orden (o first-class) dentro del lenguaje y por lo tanto pueden ser creadas utilizando literales que después pueden ser pasados como parámetros y devueltos por otras funciones.

En Scala además los tipos son inferidos aunque también pueden ser definidos de forma explicita. Por ejemplo:

val uno = 1
 val dos: Int = 2

Ambas declaraciones son válidas. En el primer caso el tipo de la variable (aunque inmutable) uno es Int ya que es inferido por el compilador.

Scala se ejecuta sobre la máquina virtual de Java (JVM) y/o la máquina virtual de .NET (CLR), también puede correr sobre Dalvik en la plataforma Android. Tanto el compilador como las librerías se distribuyen bajo una licencia BSD.

El REPL

Scala viene con una especie de intérprete conocido como el REPL (Read, Evaluate, Print, Loop) que puede ser ejecutado desde el terminal al instalar el lenguaje en nuestro sistema. Para acceder a él tan solo tenemos que escribir el comando scala en la línea de comandos de nuestro sistema operativo.

En el caso de Windows es posible que primero necesites añadir la ruta al directorio de los binarios de Scala al PATH del sistema.

Programación Orientada a Objetos

Scala es un lenguaje orientado a objetos puro, es decir, todo en Scala es un objeto. Las estructuras de datos así como los métodos que definen su comportamiento están descritos por clases y traits. Así definiríamos una clase en Scala:

class User { private var name = "Perico" private var lastname = "Los Palotes" // En Scala se usa la palabra reservada def (como en Python) // para declarar un método o función def fullname(): String = { name + " " + lastname }
 }
 val perico = new User
 perico.fullname

Habréis notado la ausencia de la palabra reservada return en el ejemplo anterior, en Scala la última expresión que aparece en una función es usada como su valor de retorno. Los punto y coma son opcionales.

El cuerpo de una función no es obligatorio en Scala si, como en nuestro ejemplo, la función solo ejecuta una expresión. Podríamos haber reducido nuestro código declarando el método fullname de la siguiente forma:

def fullname(): String = name + " " + lastname

Tambień podríamos haber obviado el tipo del valor de retorno (String) que habría sido inferido de forma automática.

Scala es más estricto en su orientación a objetos que Java o C++ y las clases no soportan métodos estáticos por lo que el lenguaje hace uso de objetos singleton. La definición de un objeto singleton se parece a la definición de una clase excepto que en lugar de usar la palabra reservada class usamos la palabra reservada object.

Scala soporta la extensión de tipos mediante herencia simple así como un mecanismo de composición basado en mixins usando traits. Asimismo Scala incorpora reglas de visibilidad para ocultar el scope de los métodos y/o propiedades a través de las palabras reservadas public, protected y private.

Podemos sobreescribir métodos de clases y traits utilizando la palabra reservada override. Podemos declarar los tipos como finales para que no puedan sobreescribirse o abstractos para lo contrario.

La implementación de la orientación a objetos en Scala es bastante peculiar, por ejemplo existen los companion objects y las case clases recomiendo echar un ojo a la página de Scala para ampliar esta muy escueta información.

Programación Funcional

Scala soporta plenamente la programación funcional aunque no exento de problema. Por ejemplo la optimización de recursión (convertir una función recursiva a un loop eliminando posibles stack overflow y la sobrecarga de la llamada a función) con tail calls (subrutina que aparece en una función como su última instrucción) no está soportada de forma nativa por la JVM, el compilador de Scala (scalac) si lo hace.

Dentro del estilo de programación funcional encontramos implementadas las siguientes:

Inmutablidad: Scala soporta las variables inmutables a través de la palabra reservada val
Funciones First Class: Las funciones son ciudadanas de primera clase
Closures: Se pueden definir y utilizar closures y clases anidadas
Traversing, Mapping, Filtering, Folding y Reducing: Operaciones que no producen efectos secundarios en las colecciones
Pattern Matching: Pieza fundamental en los lenguajes funcionales
Partial Functions: Expresiones en las que no todos los argumentos definidos en una función son pasados a la función
Currying: Convierte una función que toma múltiples argumentos en una cadena de funciones que toman un único argumento
Implicit: Algunas veces es necesario usar un tipo en un contexto diferente pero similar al tipo real requerido para ello se usa la palabra reservada implicit
Lazy vals: Inicialización vaga de variables

Actores

Scala implementa la concurrencia a través de los llamados actores que inspirados por el trabajo de Carl Hewitt, Peter Bishop, y Richard Steiger en A Universal Modular Actor Formalism for Artificial Intelligence y la implementación de estos en el lenguaje Erlang.

En su forma más básica, los Actores en Scala son objetos que heredan de scala.actors.Actor y ejecutan alguna función:

import scala.actors.Actor
 class WorkerDog extends Actor { def talk() { println("Woof woof… and this is a side effect :(") } def act = talk
 }
 val toby = new WorkerDog
 toby.start

Esto es bastante similar a la forma en la que usaríamos un Thread en otro lenguaje como por ejemplo Python o Java.

Conclusión

Aunque en Scala se puede programar de forma imperativa, es recomendable ir utilizando una forma más funcional conforme nos vamos sintiendo cómodos con el lenguaje aunque eso de la comodidad va a tardar en llegar. Scala es un lenguaje complejo y enrevesado con una curva de aprendizaje brutal y en muchos casos desalentadora.

Recomiendo echarle un ojo en serio a la documentación de Scala y a la página de Play Framework.

Más en Genbeta Dev | Diferencias entre paradigmas de programación

Freepik, un buscador de imágenes libres. Made in Spain

Juan Quijano — Tue, 15 May 2012 06:00:00 GMT

Siguiendo la línea de GenbetaDev de señalar el trabajo de los desarrolladores de España en particular y de Latinoamérica en general, hoy quiero compartir un vistazo, y una breve conversación, a un recurso muy interesante para los diseñadores y desarrolladores web.

Freepik es un motor de búsqueda que ayuda a los diseñadores gráficos y de web a localizar fotos de alta calidad, imágenes vectoriales, ilustraciones y archivos PSD para sus proyectos creativos.

Freepik busca y localiza contenidos gráficos libres en Internet y muestra los resultados en una disposición adecuada para facilitar el acceso. Freepik hace más fácil que pueda encontrar los archivos que necesitas sin buscar manualmente en decenas de sitios web.

¿Cómo funciona?

Los robots de Freepik visitan cientos de páginas web en busca de recursos gráficos, leen el contenido de estos sites y, si lo considera oportuno, los trata con un algoritmo que determina el valor del contenido y clasifica los resultados según criterios de calidad y pertinencia.

El trabajo duro en Freepik no es realizado por personas. Los robots rastrean Internet manteniendo la base de datos actualizada con los últimos contenidos.

Freepik tiene como objetivo el convertirse en una de las fuentes gráficas más importante, relacionada con el contenido libre, y una herramienta esencial para los diseñadores. Una vez que el usuario encuentra los archivos que necesita, se le redirige a los sitios de alojamiento de los archivos originales.

Algunas palabras del autor

¿Cómo se te ocurrió hacer este producto teniendo a google images o bing images como “competidores“?

La idea de desarrollar este proyecto fue por necesidad propia ya que llevo años desarrollando webs y siempre he necesitado de contenido gráfico a poder ser gratuito. Para encontrar una imagen o vector medianamente bueno tenía que recorrer una lista decenas de webs donde diseñadores colgaban contenido gratuito hasta dar con el que me interesaba y todo esto me hacía perder mucho tiempo.

Ahora si buscas una imagen en concreto, el buscador se encarga de visitar por ti cientos de webs y darte los resultados más relevantes de ese momento.

¿En qué lenguaje y sobre qué plataforma lo habéis realizado?

Freepik está desarrollado en PHP y Mysql, y como servidor web utilizo Nginx. Está desarrollado completamente a medida ya que es necesario que la web esté muy optimizada ya que tiene millones de usuarios al mes.

¿Cuantas personas componen el equipo?

El sitio lo desarrollé yo en su totalidad, pero desde hace he incorporado a personas en el equipo ya que el proyecto necesita cada día más trabajo.

¿Alguna ayuda privada o pública?

Ninguna ayuda, al desarrollarlo yo lo único que necesitaba era tiempo y mas tiempo ;)

¿Y el futuro?¿Hacia donde se encamina freepik?

Freepik nació con la idea de ser el buscador de contenido gratuito líder en la red, una vez conseguido este objetivo, estamos trabajando muy duro para darle a los usuarios herramientas para poder proponer contenido, votarlo, clasificarlo y con la ayuda de la comunidad hacer que el contenido sea todavía mejor.

¿De donde es la empresa?

La empresa esta en Málaga Capital.

Revisión

Desde que ha llegado a mis oídos este buscador, se me ha hecho mucho más fácil encontrar imágenes sin derechos de autor para realizar las imágenes de portada de los artículos.

El buscador es rápido y el número de resultados y la utilidad de los mismos, me ha parecido muy buena. Si acaso mejoraría la velocidad en que carga la primera página de imágenes ya que es un poquillo lenta.

Me gusta el poder filtrar la búsqueda por imágenes vectoriales o por fotos. O dar un vistazo rápido a las nuevas imágenes, o los recursos más populares. Y, como marca de la casa, puedo buscar también ficheros PSD (Photoshop).

Curioso que solo salgan 8 resultados de “Free Source”

Otra ayuda es el poder darme de alta como usuario. Pudiendo acceder a un histórico de mis descargas o almacenar mis favoritos.

Como conclusión, si bien es cierto que se nota que lleva poco tiempo indexando cuando buscas términos “raros” como World of Warcraft, a mi parecer merece mucho la pena y es de agradecer el trabajo de Alex, el autor.

Web | freepik.com

7 consejos para hacer buen responsive design

Fernando Siles — Mon, 14 May 2012 17:45:18 GMT

Este 2012 es el año de la prima de riesgo, Lana del Rey, las pelis de superhéroes y el diseño sensible o responsive design (amigo lector, esto es sólo la intro del post, no centres tus iras en ella…). Por eso, cuando he visto un post en uno de mis blogs de desarrollo de cabecera, Cats who Code, con una serie de consejos o tips para crear diseños responsive de calidad, me he visto en la obligación ética y moral de compartirlo con toda la comunidad de Genbeta Dev. En total son 7 consejos para hacer buen responsive design y tengo que reconocer que los comparto todos y cada uno:

Empieza con una plantilla. Si, mola ser un tipo duro y empezar las cosas desde cero pero si hay cosas muy chulas ya hechas (Skeleton, Omega, Amazium…), ¿por qué no utilizarlas?
Trabaja con layouts basados en grids fluidos. Lo que en cristiano viene a ser: ni una medida en pixeles, todo en porcentajes y relaciones
Imágenes flexibles o adaptativas. Esto no siempre es fácil y la mayoría de las veces es costoso pero con unas reglas de CSS bien definidas y un buen número de presets para los tamaños de las imágenes, se puede lograr y dar un aspecto genial.
jQuery es tu amigo. Y los plugins de jQuery son más amigos tuyos todavía, añado yo. Exprímelos todo lo que puedas, sin miedo.
No te olvides del viewport de Apple. Porque ahora los iPhones y los iPads son lo que está petando el mercado y lo sabes.
Fondos escalables. Primordial para dar una sensación de responsive design bien hecho.
Inspírate. Ya dijo Picasso aquello de “los buenos artistas copian, los genios roban”. No tengas miedo a ser un Tarantino e inspírate todo lo que puedas. No se trata de inventar la rueda sino de que esta haga ir a nuestro vehículo lo más rápido posible.
Prueba, prueba y vuelve a probar. Hay en ciertos ámbitos culturetas cierto desdén por el “prueba y error”. En el caso del responsive design no queda otra, tanto que se puede hacer tedioso… aunque por suerte hay algunas herramientas que nos pueden facilitar un poco la vida.

Y esto es todo. Ya sabéis, la tertulia (mejor tertulia que discusión, que ya somos mayorcitos y este tema tampoco es que sea la crisis económica o la burbuja inmobiliaria, tomemoslo con calma y buen rollo) en los comentarios, que para algo están.

Vía | Cats who Code
Imagen | Web Design Shock
En Genbeta Dev | Responsive Design

Sobrecargando los métodos en C#

Juan Quijano — Mon, 14 May 2012 06:00:00 GMT

Los lenguajes, como casi todo en este universo que tiende a la entropía, van evolucionando y ganando complejidad con el tiempo. Así nos encontramos con la paradoja de que cuanto más completa es la sintaxis, más ilegible se puede volver el código.

Por ejemplo, la máxima que decía “escribe la menor cantidad de código, que vaya lo más rápido posible”, tiene un orden de prioridad menor frente a paradigmas de programación más modernos como Clean Code o KISS.

Por ello ahora quiero compartir una técnica para facilitar la legibilidad de nuestros programas y que trata de la sobrecarga de los métodos.

Qué es sobrecargar

Según MSDN, “La sobrecarga consiste en crear más de un procedimiento, constructor de instancia o propiedad en una clase con el mismo nombre y distintos tipos de argumento”. Lo cual, sin un buen ejemplo, es un tanto confuso.

Me pongo manos a la obra, creo un proyecto de consola y, en el inicio del programa, hago que escriba por consola el resultado de un método llamado suma().


 using System;
 namespace GenbetaDevConsola

 {
 class Program
 {
 static void Main(string[] args)
 {
 System.Console.Write(suma(1, 1));
 }
 }

 }

Obviamente debo escribir el método, tal que así:


 private int suma(int numero1, int numero2)

 {
 return numero1 + numero2;

 }

Pero, ¿si me encuentro con que los números no son enteros si no que son más grandes?

Tengo dos opciones. Una sería crear un nuevo método que se llame algo como sumaDouble() y que tenga dos números doubles por parámetros. La otra opción es sobrecargar el método suma con nuevos parámetros, pudiéndolo utilizar indistintamente en un caso o en el otro.


 private int suma(double numero1, double numero2)

 {
 int numero = 0;
 Int32.TryParse((numero1 + numero2).ToString(),out numero);
 return numero;

 }

Lo mejor es que Intellisense del Visual Studio me ayuda y me indica que el método suma() está sobrecargado y me ofrece ver la firma de cada una de ellas.

Es más, puedo ir añadiendo complejidad a mi método suma aceptando más parámetros y de diferente tipo como, por ejemplo, poder sumar tres cantidades o hacer sumas booleanas.


 private static int suma(int numero1, int numero2, int numero3)

 {
 return numero1 + numero2 – numero3;

 }
 private static int suma(Boolean numero1, Boolean numero2)

 {
 return numero1 == numero2? 1 : 0;

 }

NOTA: Lo que he utilizado en la suma Booleana es una forma compacta de un condicional. Si se cumple la igualdad, devuelvo 1. Si no, devuelvo 0. No es muy legible y conozco alguno que decía que esto era “evil”. Pero es muy útil.

Fíjate que lo importante de utilizar sobrecargas, es que encapsulo el funcionamiento de los métodos de forma que siempre llamo a suma(), y solo me debo preocupar de cumplimentar correctamente alguna de sus posibles firmas.

Por cierto, por si alguno desconoce el concepto de firma, MSDN dice:

Los métodos se declaran en una clase o struct mediante la especificación del nivel de acceso como public o private, modificadores opcionales como abstract o sealed, el valor devuelto, el nombre del método y cualquier parámetro de método.Todos esos elementos constituyen la firma del método.

Mejorando las sobrecargas

Pero C# sigue adelante en su evolución (realmente todo .NET) y a partir de la versión 4.0 tengo tres novedades que me han llamado mucho la atención por su utilidad.

Puedo declarar un método y ponerle por defecto un valor a cada uno de sus parámetros. Por ejemplo si quiero calcular la hipotenusa puedo crear un método tal cual,


 public static double calculaHipotenusa
 (
 double cateto1 = 100,
 double cateto2 = 100,
 double hipotenusa = 0
 )

 { 
 return Math.Sqrt(Math.Pow(cateto1,2) + Math.Pow(cateto1,2));

 }

Así puedo llamar a este método de diferentes formas de acuerdo a los datos que tenga, sin tener que rellenar obligatoriamente todos los parámetros.


 static void Main(string[] args)

 {
 System.Console.Write(calculaHipotenusa());
 System.Console.Write(calculaHipotenusa(100));
 System.Console.Write(calculaHipotenusa(100, 50));
 System.Console.Write(calculaHipotenusa(cateto2:50));

 }

Ahora fíjate en la última forma de llamar al método. Estoy introduciendo el nombre del parámetro que quiero cargar. Esto, que parece trivial, nos alivia de tener que construir un método sobrecargado para cada una de las firmas. Y tampoco debemos de invocar el método con todos sus parámetros, ya que solamente remito los que quiero enviándolos por su nombre.

Por último, y si tienes ganas de jugar más fuerte, te puedes meter en la sobrecarga de operadores. Es decir, darle comportamientos particulares y específicos a cosas como +, -, =, etc. Así puedo hacer una suma directa de valores booleanos en una clase sin tener que construir un método con esa firma.

Pero esto yo no lo he utilizado nunca y no encuentro ahora mismo donde aplicarlo.

Más información | Métodos (Guía de programación de C#), Nuevas características de C# en .NET Framework 4

Manos en la masa, haciendo crecer nuestro árbol del repositorio de código

Juan Quijano — Sun, 13 May 2012 12:01:03 GMT

Este es el tercer capítulo de la miniserie sobre Branching. Que se ha compuesto de Labeling, Branching y este, Manos en la masa. Y que trata sobre técnicas de división del desarrollo en el repositorio de código que nos haga más fácil el manejar la complejidad inherente a toda construcción de aplicaciones de software.

Este ejemplo lo voy a mostrar en Visual Studio 11 beta contra un Team Foundation Service, pero es muy similar el realizarlo en Git, Mercurial o SVN. Lo importante no es la herramienta, si no tener claro que el uso de estas técnicas nos hace crecer en la madurez de nuestros equipos y nos facilita y prepara para cuando las cosas se tuercen ~~que es casi siempre~~.

Haciendo un branch

Tengo un proyecto de GenbetaDev en mi repositorio de código en una cuenta de Team Foundation Service (en la Nube). Accedo a él, y selecciono el explorador del repositorio de código.

En la ventana que se me abre, veo mi directorio de carpetas de proyectos, en donde abro la de GenbetaDev.

Aquí me encuentro la carpeta troncal Trunk de mi desarrollo y de la cual quiero hacer una nueva rama. Para ello pulso con el botón derecho encima del nodo del cual quiero que salga la rama, y en el menú contextual selecciono “Branching and Merging”.

En el menú desplegable selecciono la opción “Branch”, y se me abre una ventana en donde le pongo un nombre en el repositorio a la carpeta que va a contener la nueva rama; qué versión del código original quiero copiar en el Branch (el último, una etiqueta específica, una fecha, etc.); y si quiero descargar la nueva rama en mi workspaces actual o convertirla en mi código por defecto.

A continuación me solicita que haga un mapeado de la carpeta del repositorio de código a mi disco duro. Es decir, en qué carpeta local voy a guardar el código almacenado en el Branch. Y aquí te voy a dar un consejillo.

En desarrollos medios o pequeños, sin mucha complejidad, yo utilizo la misma carpeta para el Trunk y los Branch. Así me evito modificar el código en la rama inadecuada por no darme cuenta de cual solución estoy abriendo. Puede que no sea la mejor práctica, pero a mi me funciona muy bien para evitar errores.

Una vez realizado esto, pulsamos el botón de “Map” y el sistema se pone a realizar el branching de nuestro código. Observándose en el explorador del repositorio, cuando finalice el proceso, nuestra nueva rama y el que está configurada como solución por defecto.

Fundiendo ramas

La segunda parte del proceso, y sin duda la más difícil, es cuando tengo una rama y la quiero actualizar en el Trunk. O actualizar con el código de la principal, el código de una Branch.

Para ello, desde la ventana del explorador del repositorio, pulso con el botón derecho sobre la rama que quiero fundir con otra, y escojo “Merge”. Abriéndose la ventana de un asistente en donde debo escoger cual es la rama destino para realizar la actualización y cual es la versión de código que nos queremos llevar.

Acto y seguido el TF Service se pondrá a trabajar y añadirá y modificará los ficheros de forma automática, siempre que sea posible. Y en el caso de que no lo pueda hacer porque la modificación tiene posibilidades de no hacerse correctamente, entonces nos marca el Merge como manual y debemos de utilizar la herramienta de comparación de código para completar la unión.

Pero de esta herramienta hablaré en el próximo capítulo,

Más información | Visual Studio Team Foundation Server Branching and Merging Guide Git. Magia Con Los Branches

En GenbetaDev | Etiquetando,haciendo crecer nuestro árbol del repositorio de código, Branching, haciendo crecer nuestro árbol del repositorio de código

Un juego de la serpiente en jQuery para ir aprendiendo el framework de moda

Fernando Siles — Sat, 12 May 2012 11:00:00 GMT

Siempre he pensado que el juego de la serpiente o Snake es uno de los problemas más interesantes cuando estás intentando hacerte con el control un lenguaje de programación o tecnología. Si sabes hacer un Snake, el lenguaje de programación ya (casi) no tiene secretos para ti. Por eso me ha parecido interesante esta demo del Snake hecho en jQuery que os enlazamos hoy y que se han currado en webdeveloper juice.

Unas cuantas líneas de html, otras pocas de css y todo el potencial de jQuery y tenemos un Snake perfectamente funcional en un rato. Una buena manera de adentrarte en el framework de moda en el mundo Javascript y de conocer su sintaxis, sus flujos y sus peculiaridades. Y además, aunque el juego es perfectamente funcional, es también perfectamente mejorable (ajustar más la velocidad, opciones de stop y reset, tabla de high scores…) por lo que seguro que te entran ganas de trastear el código y mejorarlo ya seas un novato en el mundillo de jQuery o todo un experto.

Una sombrita, unas birras y un poco de picar código jQuery, ¿qué mejor plan que este se te ocurre para esta calurosa tarde de sábado? Pues eso, de nada.

Vía y demo | webdeveloper juice
Imagen | Snake para Nokia
En Genbeta Dev | 30 días para aprender jQuery

Desentrañando el RSS. ¿Cómo es un feed por dentro?

Johnbo — Sat, 12 May 2012 08:00:00 GMT

Todos los aquí presentes conocemos los RSS y estamos suscritos a decenas, o incluso cientos de ellos, pero seguramente pocos conocen ni el significado de las siglas (según la Wikipedia es Really Simple Syndication, pero también fue Rich Site Summary), ni mucho menos el funcionamiento interno de estas fuentes web que nos tienen al tanto de todas las novedades en nuestras páginas favoritas.

Y es normal, ya que quien use un blog, una wiki o cualquier gestor de contenido típico, no tiene que preocuparse ya que sus RSS se generan automáticamente conforme nutre de contenido a su web. Pero, ¿y si tenemos que crear nuestro RSS a mano? ¿Qué formato debemos utilizar y cómo podemos automatizar esta tarea?

RSS es un subconjunto de XML

Pues bien, básicamente el RSS no es más que un fichero XML que contiene ciertos elementos que lo definen y que serán reconocidos por cualquier navegador moderno, así como por lectores de feeds como Google Reader, Netvibes o similares. Es decir, es un subconjunto de XML con unas etiquetas determinadas. De un modo muy básico y genérico, podríamos decir que el formato de un RSS 2.0 sería el siguiente:

 <?xml version="1.0" encoding="utf-8"?> <rss version="2.0"> <channel> <!-- Aquí van las propiedades del canal --> <item> <!-- Aquí va el contenido de una entrada publicada --> </item> ... <!-- Tantos elementos como entradas queramos --> <item> </item> </channel> </rss>

Ahora después entraremos en detalle acerca de qué hay que poner en el canal y en los ítems (las entradas), pero de momento vamos a centrarnos en lo más genérico del formato. Las únicas etiquetas obligatorias son las dos que abren el anterior extracto de código: el encabezado XML versión 1.0 con su codificación de caracteres, y un único elemento RSS versión 2.0.

Etiquetas y atributos opcionales del encabezado

Aunque nos bastaría con lo anterior, también podemos añadir estos otros dos encabezados tras el primero:

 <?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2spanishfull.xsl"?> <?xml-stylesheet type="text/css" media="screen" href="http://feeds.weblogssl.com/~d/styles/itemcontent.css"?>

Estos enlaces no tiene valor semántico, sino puramente estético, ya que sólo definen cómo se representará la información si visualizamos el feed en un navegador sin suscribirnos a él. Por una parte, el XSL dirá cómo transformar el XML en HTML en nuestro navegador, mientras que el CSS aplicará los estilos correspondientes a dicho HTML.

En cuanto a la etiqueta RSS, el único atributo obligatorio es la versión, pero podemos añadirle algunos más:

 <rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">

Esto nos permitirá usar namespaces propios de itunes, atom, etc. y hacer así que se reconozca un podcast o un feed atom como extensiones de RSS.

Propiedades del canal

Cuando hablamos del canal nos referimos al origen de los posts, que puede ser una web o una sección dentro de la misma (podemos ofrecer un RSS general y otros específicos por temática, por ejemplo). Son varios los elementos utilizados para identificar un canal, muchos de ellos opcionales, pero lo normal es que tenga un aspecto similar a éste:

 <channel> <title>Genbetadev</title> <link>http://www.genbetadev.com</link> <description>Informaci&#195;&#179;n sobre el sector de los desarrolladores, el desarrollo de aplicaciones, para m&#195;&#179;viles, desarrollo web, bases de datos, frameworks y lenguajes de programaci&#195;&#179;n</description> <language>es-ES</language> <lastBuildDate>Tue, 08 May 2012 06:13:05 GMT</lastBuildDate> <ttl>2</ttl> </channel>

En <title> indicamos el título de la web o sección, siendo éste el nombre con el que el feed se guardará en el lector, a cambio que el usuario lo modifique manualmente si su lector lo permite.

El <link> es un enlace a la que consideremos como página principal, ya sea de la web o de la sección a la que corresponde el RSS.

En la <description> se debe introducir un pequeño resumen de lo que versa el feed, similar al texto con el que definimos una web cuando queremos que sea indexada por los buscadores.

El hecho de indicar un <language> no supone ninguna obligación de que el post verdaderamente esté en ese idioma, sino que más bien puede servir para la categorización por idiomas en agregadores de feeds.

Con <lastBuildDate> informamos de cuándo se generó por última vez el RSS. Es útil si no tenemos mucha periodicidad a la hora de escribir pero queremos que el lector sepa que nuestro feed no ha dejado de generarse y sigue funcionando a la perfección.

Precisamente, dependiendo de nuestra periodicidad nos puede interesar cambiar el elemento <ttl>, con el que informamos del tiempo de vida de una versión concreta del RSS. Con ello, conseguimos que el lector revisite nuestro feed cuando pasen tantos segundos como se indica en este elemento. Si publicamos un artículo al día, nos puede bastar con que el RSS se consulte cada hora y que nuestro servidor no se satura de llamadas buscando un nuevo contenido que aún no existe. Por contra, si nuestra web es de noticias, o simplemente la actualidad es uno de sus puntos fuertes, nos interesará tener un ttl bajo y asegurarnos que los usuarios puedan tener el feed actualizado casi tan pronto como el artículo se publique.

Otros elementos para el canal

Existen otros elementos que pueden aparecer en el canal, aunque de menor utilidad que los anteriores. Por ejemplo, podemos agregar una imagen identificativa, y hacer que tenga un enlace a nuestra web. Sin embargo, este dato orientado al usuario humano y no al software lector sólo será visible, en el mejor de los casos, en el momento de suscribirse, por lo que no es de gran importancia.

 <image> <url>http://blogs.es/imagenes/planet/genbetadev.jpg</url> <link>http://www.genbetadev.com</link> <title>Genbeta Dev</title> </image>

Si sabemos que hay ciertas horas en las que nunca vamos a publicar nada (de madrugada, normalmente) o ciertos días de la semana en los que nunca sacamos contenidos, podemos indicar al lector que no intente actualizarse en esos periodos mediante las estructuras <skipHours> y <skipDays>

 <skipDays> <day>Saturday</day> <day>Sunday</day> </skipDays> <skipHours> <hour>0</hour> <hour>1</hour> <hour>2</hour> <hour>3</hour> <hour>4</hour> <hour>5</hour> <hour>6</hour> <hour>7</hour> <hour>20</hour> <hour>21</hour> <hour>22</hour> <hour>23</hour> </skipHours>

Si queremos que los derechos de los artículos queden patentes en el propio RSS aparte de en nuestra web de destino, podemos agregar un elemento <copyright> con el texto correspondiente.

Del mismo modo, si queremos que quede constancia de la aplicación con la que hemos generado el feed, podemos indicarlo añadiendo el tag <generator>.

Por último, antes de pasar a las entradas que suponen el verdadero contenido del RSS, si hemos añadido namespaces de feedburner, itunes y otros servicios de terceros, lo normal es que tengamos algunos elementos pertenecientes a dichos namespaces y que se regirán por las restricciones de formato que cada uno de ellos imponga, por lo que no vamos a verlos aquí.

Las entradas

Cada una de las entradas o posts que queremos notificar a nuestros suscriptores vendrá definida por un elemento <item>, que entre elementos obligatorios y los muy recomendables, suele ser como mínimo algo similar a esto:

 <item> <title>Diagrama para elegir la licencia m&#195;&#161;s apropiada para tu software</title> <link> http://weblogssl.feedsportal.com/c/33859/f/609642/s/1f17063b/l/0L0Sgenbetadev0N0Csoftware0Elibre0Ey0Elicencias0Cdiagrama0Epara0Eelegir0Ela0Elicencia0Emas0Eapropiada0Epara0Etu0Esoftware/story01.htm</link> <description>&lt;p&gt;&lt;img alt="Cabecera infograf&#195;&#173;a licencias libres" src="http://img.genbetadev.com/2012/05/Cabecera_licencias.jpg" class="centro_sinmarco" /&gt;&lt;br /&gt; Ponerle copyright a un software y &lt;em&gt;sentarse a esperar los beneficios&lt;/em&gt; es muy f&#195;&#161;cil, pero si alguna vez has pensado &lt;strong&gt;aplicar una licencia libre&lt;/strong&gt; al fruto de tus trabajos te habr&#195;&#161;s encontrado con que es una decisi&#195;&#179;n bastante complicada, especialmente por el &lt;strong&gt;amplio abanico de licencias&lt;/strong&gt; disponibles y las a veces muy sutiles diferencias entre unas y otras.&lt;/p&gt; &lt;p&gt;Como m&#195;&#169;todo de ayuda a la hora de elegir, y a mitad de camino entre el estudio exhaustivo y el sentido del humor, &lt;a href="https://twitter.com/#%21/dbentley"&gt;Dan Bentley&lt;/a&gt; y &lt;a href="https://twitter.com/#%21/therealfitz"&gt;Brian Fitzpatrick&lt;/a&gt; han creado esta infograf&#195;&#173;a en forma de &lt;strong&gt;diagrama de flujo&lt;/strong&gt; para ayudarnos en la decisi&#195;&#179;n en favor de una u otra licencia.&lt;/p&gt; &lt;p&gt;Yo lo he seguido y me sale que deber&#195;&#173;a usar la &lt;span class="caps"&gt;LGPL&lt;/span&gt; en mis desarrollos. &#194;&#191;Y a vosotros? </description> <pubDate>Mon, 07 May 2012 13:30:00 GMT</pubDate> <author>Johnbo</author> <guid isPermaLink="false"> http://www.genbetadev.com/software-libre-y-licencias/diagrama-para-elegir-la-licencia-mas-apropiada-para-tu-software</guid> </item>

El elemento <title>, como su propio nombre indica, es el título del artículo. En lectores de feeds con formato minimalista será lo único que veamos. Normalmente, lo ideal es que coincida al 100% con el título de la entrada en la web, aunque en casos de títulos muy largos, puede ser conveniente utilizar una versión reducida para que se visualice en el feed.

El otro elemento fundamental de las entradas es el <guid>, un identificador unívoco para nuestra entrada. La importancia del GUID radica en el hecho de que, manteniéndolo, podemos realizar cualquier cambio dentro del resto del ítem, y por lo general los agregadores lo seguirán tratando como el mismo post, mientras que si cambiamos el GUID, aunque todo lo demás permanezca invariable, lo más probable es que nuestro lector duplique la entrada, al considerar que cada GUID correspondía a un artículo distinto. La forma más sencilla de asegurarse que sea único y que no vaya a variar es utilizar como identificador la URL de destino, aunque esto no significa que al clicar vayamos a llegar seguro a esa dirección. De hecho, al darle el valor falso a su atributo isPermaLink (que por defecto es verdadero) le estamos indicando que no debe interpretarse como una URL al uso.

Esto se debe a que quien realmente nos indica el destino es el elemento <link>, que puede coincidir (o no) con el GUID. Hoy día, donde las analíticas web cobran tanta importancia, lo normal es que este enlace no nos lleve directamente a la página de destino, sino que nos haga pasar por una página intermedia que haga las veces de contador, ya que un lector de feeds que no tenga interfaz web normalmente no proporcionará un referer adecuado para poder medir la influencia del RSS.

La mayoría de discrepancias están a la hora de elegir el contenido del elemento <description>, ya que hay quien calza ahí el artículo completo, hay quien pone los primeros dos o tres párrafos y hay quien se contenta con apenas un abstract. La decisión dependerá de qué consideración tenemos hacia nuestros usuarios. Ponerles únicamente un breve resumen para obligarles a que te visiten, generándote ingresos por publicidad, puede hacer que la gente acabe por adoptar una actitud reacia, o incluso que el artículo no les interese porque no les has mostrado la parte más atractiva. Poner el artículo completo suele ser una buena alternativa, ya que tratas respetuosamente al usuario y sólo le haces ir a tu web para interactuar (escribiendo comentarios, por ejemplo), aunque tiene la pega de que los artículos de gran longitud se pueden llegar a ver como un estorbo dentro del lector.

En cuanto a su formato, no es necesario que sea texto plano, sino que podemos usar HTML igual que en la propia entrada, con unas salvedades bastante obvias. En primer lugar, los caracteres < y > han de introducirse con sus entidades HTML correspondientes < y > para evitar que sean reconocidas en el propio XML. En segundo lugar, hay que tener cuidado de convertir en absolutas todas las rutas relativas de imágenes u otros recursos, así como permitir en nuestro servidor el hotlinking para esos archivos desde los dominios de los principales lectores de noticias. Y por último, saber que el lector no va a reconocer estilos más allá de los más básicos: <strong>, <em>, etc.

Elementos opcionales para una entrada

El <pubDate> es la fecha de publicación del artículo. En principio debería servir para ordenar las entradas dentro del feed, pero lo cierto es que muchos lectores la ignoran y las muestran por orden estrictamente secuencial, por lo que su finalidad principal es simplemente informar al usuario de cuándo se publicó. Importante: para no marear, lo mejor es usar la hora GMT, y que ya el software del lector se encargue de traducirlo a la zona horaria del usuario.

Otro elemento no obligatorio dentro de un <item> relativamente habitual es el <author>, aunque sólo en blogs con varios articulistas, ya que en páginas llevadas por una única persona no tiene mucho sentido confirmar su autoría en todos y cada uno de ellos. En un inicio se solía indicar aquí el e-mail del autor, pero debido a los medios automatizados para spammear, actualmente se suele usar el nombre propio o un apodo.

Mucho menos habitual es encontrar el elemento <comments>, cuyo contenido es un texto con comentarios con respecto a la entrada, o incluso el enlace a una segunda URL donde encontrar esos comentarios. Al no haber limitación de tamaño en la descripción, este elemento aporta muy poco a la misma.

Con <enclosure> tenemos la posibilidad de adjuntar un archivo al RSS, aportando su URL, longitud y tipo. Dado que la descripción podía contener algunos objetos incrustados, no es muy habitual usar esta construcción para añadir uno al final.

 <enclosure url="http://www.direcciondelrecurso/archivo.mp3" length="3000000" type="audio/mpeg" />

Para finalizar, el elemento <category> permite agrupar los posts por su temática, de forma que los agregadores RSS puedan mostrar los distintos feeds organizados por categorías. Tanto el canal como cada uno de los ítems puede pertenecer a una o más categorías.

¿Cómo generarlo?

Bueno, ya sabemos en qué consiste el formato de un RSS al detalle, pero aún no hemos dicho cómo podemos generarlo. Mientras en el mercado existen herramientas de pago como Feed for all, ya que somos programadores vamos a ver cómo haríamos para generarlo nosotros mismos sin depender de terceros.

El problema se reduce a tener un fichero llamado rss.xml y ser capaces de parsearlo para añadir un nuevo ítem cada vez que tengamos una actualización. Lo normal es que usemos el mismo lenguaje con el que hemos desarrollado la página y aprovechemos el momento en que se publica el contenido para añadir una nueva función que genere dicho XML.

El cómo hacerlo ya dependerá del lenguaje utilizado y las librerías de tratamiento de XML con las que cuente, ya que mientras algunos nos permiten de forma muy sencilla parsear un XML, movernos por él y añadir o eliminar elementos a nuestro antojo; es posible que otros menos modernos no dispongan de esta capacidad y no nos quede más remedio que abrir el archivo en modo texto y movernos por él secuencialmente buscando patrones para encontrar el lugar de inserción del nuevo elemento, que habremos de añadir también como si de una simple cadena de texto se tratase.

Más información | w3schools.com – RSS Tutorial
En Genbeta Dev Respuestas | ¿Cómo crear una RSS para mi web?

No te lo vas a creer, el Goto aún existe en C#

Juan Quijano — Fri, 11 May 2012 15:25:43 GMT

Tengo que reconocer que Twiter se ha convertido en una fuente de información sorprendente. Como leí en algún sitio “desde que existe twiter, siempre leo en el periódico noticias antiguas“.

Esto viene al caso al llegarme por este medio un rumor que, al principio, no me podía creer. El rey del “spaguetti code“, el causante de inmenso dolor en los tiempos del GWBASIC, el paradigma de lo que no se tiene que utilizar; aún vive.

Y estoy hablando de la sentencia de salto absoluto GOTO.

Lo que parecía una broma, me ha llevado a la página de MSDN, en donde he leído boquiabierto que no solamente no es un recuerdo lejano de un pasado secuencial, si no que se sigue implementado en .NET.

Y para comprobar que funciona, traigo un ejemplo escrito en C# con Visual Studio 11 beta. Lo cual significa que en el novísimo framework 4.5, aún se puede utilizar.

 int numero = 0; int suma = 0; switch (numero)
 {
 case 1:
 suma += 20;
 break;
 case 2:
 suma += 30;
 goto case 1;
 case 3:
 suma += 50;
 goto case 1;
 default:
 suma = 0;
 break;
 }

Me he quedado sin palabras…

Más información | MSDN: goto (Referencia de C#)

¿Qué te motivó a convertirte en programador?: la pregunta de la semana

Fernando Siles — Thu, 10 May 2012 12:34:06 GMT

Otra semana más aquí estamos en Genbeta Dev con nuestra pregunta de la semana. Esta vez nos ponemos un poco más genéricos e incluso filosóficos si se me permite y te cuestionamos sobre las decisiones que has tomado en tu vida. Bueno, de todas no, principalmente de la siguiente:

¿Qué te motivó a convertirte en programador?

Es decir, ¿cómo llegaste a ser desarrollador y por qué? Y ya de paso pues te puedes explayar un poco y contarnos tus sensaciones sobre este trabajo, si es lo que esperabas, si estás pensando en dejarlo o te ves muchos años dentro del gremio… Y si no eres desarrollador pero estás pensando en serlo, pues lo mismo: ¿por qué?

Recuerda que mejor contestar a la pregunta en la sección de Respuestas del blog (que para algo está aquí) que hacerlo en los comentarios porque si tu respuesta gusta podrás salir en el post de la semana que viene, como es el caso de Juan M. Gómez, que contesto a la pregunta de la semana pasada, ‘¿Deberíamos preocuparnos por el copyright de lenguajes y APIs de programación?‘, tal como sigue:

Del uso que le damos a una API o servicio creo que deberíamos preocuparnos, sobre todo a éste último.

En cuanto a la pregunta en sí, el copyright. Pues creo que a corto plazo puede que no, pero nos estamos dirigiendo a un modelo que destruye la innovación. Llegará un momento en que las empresas cobraran de manera masiva por el uso de APis (entiendase pago de patentes) y será imposible para el pequeño programador/empresas desarrollar aplicaciones sin pasar por caja.

Creo firmemente que las herramientas de desarrollo y todo lo relacionado con ellas, deberían ser libres y gratuitas. ¿Acaso alguien paga patentes por utilizar herramientas matemáticas en cualquier otro campo (arquitectura, ingeniería, etc.) ?

Esto es todo. La semana que viene, más y mejor.

En Genbeta Dev | ¿Qué te motivó a convertirte en programador?

Cazadores de Mitos: Las propiedades privadas en Python

Oscar Campos — Thu, 10 May 2012 04:00:00 GMT

El otro día discutía con un buen amigo en Twitter sobre lo que el llamaba “falta de private protected y public keywords“ en Python y recordé la tremenda confusión y desinformación que hay en la red en relación a las propiedades y/o métodos “privadas/os“ en el lenguaje creado por Guido Van Rossum.

En esta entrada voy a intentar explicar por qué no existen propiedades ni métodos privados en Python y por qué no son necesarios, por qué existe esta confusión sobre los métodos y propiedades (o atributos) que utilizan el underscore (_ y __) y cual es la auténtica naturaleza de los mismos.

El origen del Mito

Muy posiblemente el origen del mito comenzó con el fantástico libro de Mark Pilgrim Dive into Python que ha sido el primer contacto y libro de referencia por antonomasia para los novicios en Python desde prácticamente su lanzamiento el treinta de octubre del 2000. Yo mismo aprendí con él.

El capítulo 5.9. del citado libro, lamentablemente, se titula “Private Functions“ y en él se dice lo siguiente:

Como en muchos otros lenguajes, Python tiene el concepto de elementos privados:
Funciones privadas, que no pueden ser invocadas desde fuera de su módulo
Métodos de clase privados, que no pueden ser invocados desde fuera de su clase
Atributos privados, que no pueden ser accedidos desde fuera de su clase

Pero a diferencia de la mayoría de lenguajes, lo que hace a una función, método o atributo de Python privado viene determinado enteramente por su nombre.

Si el nombre de una función, el método de una clase o uno de sus atributos comienza con (pero no termina con) dos guiones bajos (underscores), es privado; todo lo demás es público.

Para reforzar esta afirmación recurre a un sencillo ejemplo que demuestra que no se puede invocar un método llamado “__parse“ desde fuera de una clase. Yo voy a escribir otro sencillo ejemplo en el REPL e iré explicando sobre la marcha por qué Mark Pilgrim estaba, sencillamente, equivocado con respecto a este particular en específico.

>> class Gato(object): >>> """Clase Gato""" >>> def __init__(self): >>> super(Gato, self).__init__() >>> def __privado(self): >>> """Metodo supuestamente privado""" >>> print "Soy privado como los intereses del Estado…" >>> def un_metodo(self): >>> """Metodo supuestamente publico desde el que se accede a __privado""" >>> self.__privado() >>> >>> g1 = Gato() >>> g1.__privado() >>> Traceback (most recent call last): >>> File "<interactive input>", line 1, in ? >>> AttributeError: 'Gato' object has no attribute '__privado' >>> >>> g1.un_metodo() Soy privado como los intereses del Estado… >>>

Vemos como efectivamente no hemos sido capaces de invocar al método __privado de nuestra clase Gato pero sin embargo al invocar al método un_metodo que llama internamente al método “__privado“ si se ha imprimido el mensaje y por lo tanto “demuestra” la teoría explicada por Pilgrim en Dive Into Python.

Pero esto no es más que una desagradable coincidencia. Que el método no sea accesible desde fuera de la clase no tiene nada que ver con la visibilidad o restricción del método sino que es el efecto de un mecanismo de Python conocido como name mangling (presente en otros lenguajes como C++ o Java) y no sirve para lo que por error se cree de manera popular. Vamos a explicarlo con otro ejemplo en la REPL:

>>> class Gatico(Gato): >>> """La clase Gatico hereda de la clase Gato""" >>> def __init__(self): >>> super(Gatico, self).__init__() >>> def __privado(self): >>> """Estoy sobreescribiendo el metodo privado?""" >>> print "Es necesario abrir los datos al publico y dejar de ser privado…" >>> def otro_metodo(self): >>> """Soy otro metodo y me llamo asi a posta para nos sobreescribir a un_metodo de la clase base""" >>> self.__privado() >>> >>> g2 = Gatico() >>> g2.__privado() >>> Traceback (most recent call last): >>> File "<interactive input>", line 1, in ? >>> AttributeError: 'Gatico' object has no attribute '__privado' >>> >>> g2.otro_metodo() Es necesario abrir los datos al publico y dejar de ser privado… >>> >>> g2.un_metodo() Soy privado como los intereses del Estado… >>>

¿Qué es lo que ha pasado aquí?. Los programadores de Java y de C++ que están leyendo este artículo (porque lo estáis leyendo verdad, os interesa un montón…) se habrán percatado rápidamente de que algo raro está pasando.

En Java no está permitido sobreescribir métodos privados, si el programador nombra a un método privado en una clase heredada exactamente igual que un método privado de su clase base, sencillamente estará creando un método completamente nuevo en la subclase y este ocultará al método de la superclase.

En C++ se puede sobreescribir cualquier método que sea virtual, de hecho, es una práctica aceptada y recomendable sobreescribir solo funciones virtuales privadas y nunca públicas pero si sobreescribimos un método privado de una clase base en una subclase y lo invocamos desde la subclase, debería de llamarse al método adecuado, es decir, al nuevo método que sobreescribe al de la clase base aunque sea invocado por un método de la clase base desde la subclase. Este es uno de los principios del polimorfismo en C++.

Por lo tanto es extraño que en Python hayamos sobreescrito el método “__privado“ pero sin embargo el método “un_metodo“ siga pudiendo invocar a la implementación del método “__privado“ de su propia clase. De hecho, esto ocurre por que en ningún momento hemos sobreescrito el método “__privado“ de la clase Gato ni es un método privado, ni nunca ha sido intención del lenguaje poder crear métodos privados ni por éste ni por ningún otro medio.

Ahora si que estoy perdido, ¿me lo explica?

Python es un lenguaje potente que permite al programador hacer prácticamente lo que quiera, como por ejemplo, definir algo como True = False y liarla parda o bien sobreescribir una función builtin. Esto es así por la particular visión de como debe ser el lenguaje por parte de los Pythonistas y del BDFL (Benevolent Dictator For Life).

Uno de los principales valores de Python es que trata al programador como mayor de edad y en lugar de imponer restricciones confía en el buen juicio de nosotros, los programadores, para no hacer barbaridades así que la Comunidad define una serie de convenciones sobre el lenguaje.

Entre estas convenciones se encuentra la de nombrar a toda aquella función, todo aquel método o atributo que no sea parte de la API pública (que no métodos ni propiedades) de nuestra clase, librería, framework o módulo y sea perceptible a cambios, la desaparición o el estado obsoleto y olvidado sin previo aviso, con un underscore delante del nombre para informar a los consumidores de dicha API de que se trata de un método interno que puede cambiar sin previo aviso y no está diseñado (ni es útil) para el uso normal de la API.

Si además el nombre de nuestra variable coincide con una clase, método, variable o builtin pero es el único que tiene lógica, por ejemplo, list, sum, rand por convención se añade un underscore al nombre antes de hacer algo “tan guarro“ (para el Zen de Python) como nombrarlo “lst“, “sm“, “rnd“ que no aporta valor semántico.

Por otro lado, para posibilitar que las clases que heredan de clases bases puedan sobreescribir métodos sin romper las llamadas internas de sus clases base a dichos métodos, cualquier método (o función o atributo) que comience con al menos dos underscores (y no acabe en dos underscores, uno si está permitido) es renombrado por el intérprete en la definición de la clase siguiendo la siguiente norma “_classname__methodname“ así que para nuestro ejemplo el método quedaría así “_Gato__privado“ y de hecho podría seguir siendo invocado desde fuera de la clase si así lo queremos:

&gt;&gt;&gt; g1._Gato__privado() Soy privado como los intereses del Estado...

Y puede ser invocado ya que nunca fue la intención del lenguaje que existieran los métodos privados, ya que en Python, por su propia condición de lenguaje dinámico y sus características, no es necesario. Asimismo, los métodos, funciones o variables que empiezan con un underscore no son importados al usar from bleh import * que por otro lado es una sintaxis considerada “deprectaed“ y mala práctica de programación por el PEP-8.

Conclusión

Ya se que ha sido un artículo ladrillazo pero considero que en vista a la falta total de literatura al respecto era necesario realizar esta aclaración para ayudar así a comprender mejor este maravilloso lenguaje.

En breve escribiré otro artículo explicando porque no es necesario el uso de métodos o propiedades privados. Hasta entonces, happy hacking.

Más Desinformación | Capítulo 5.9. de Dive Into Python

I/O Extended e I/O Live, otras maneras de ser parte de la Google I/O 2012

Fernando Siles — Wed, 09 May 2012 16:18:46 GMT

Google I/O es indiscutiblemente uno de los grandes eventos para desarrolladores que hay a nivel global. Pero San Francisco está lejos y los tickets son muy caros (aunque esto siempre es relativo, claro) por lo que seguro que te interesan las dos iniciativas aledañas que prepara Google para finales del mes de Junio: I/O Extended e I/O Live.

La segunda, I/O Live, viene a ser el streaming habitual de todos los años, que ya el año pasado reunió a más de un millón de espectadores y que en esta edición esperan casi doblar. ¿Cómo? Ofreciendo la keynote y varias de las conferencias y actividades más relevantes. Todas ellas más la que no se retransmitan en directo se podrán luego visualizar en menos de 48 horas.

La primera, I/O Extended, podemos decir que se trata de fiestas o quedadas oficiales para seguir el evento principal repartidas por todo el largo y ancho mundo: desde Chattanooga en Tennesee hasta Uganda pasando por varias en Europa, incluyendo una en Barcelona de la que puedes encontrar más info aquí. Todavía Google está aceptando nuevas fiestas por lo que lo mismo nos encontramos con alguna todavía más cerquita.

En definitiva, que los días 27, 28 y 29 de Junio se prevén intensos para cualquier developer que se precie de serlo y guste de estar a la última, vamos, para un genbetadevero de pro.

Pd: ¿alguien en la sala que vaya a estar in situ?

Vía | Google Developers Blog
En Genbeta Dev | Se anuncia la fecha de registro del Google IO 2012, atentos al 27 de marzo

KarmicGraphs, plugin jQuery para gráficas liberado por Karmacracy

Oscar Campos — Wed, 09 May 2012 04:00:00 GMT

Para quien no lo sepa, KarmaCracy es una startup nacida en Bilbao de mano de Alex Dolara y Jordi Martí pero ademaś es un acortador de Urls que en las últimas 24 horas ha generado 37.849 clicks válidos a través de 1.169 enlaces generados por 222 usuarios, nada mal ¿he?.

Recientemente han liberado bajo el amparo de la GPLv3 la primera versión del plugin que ellos mismos utilizan para mostrar las gráficas en detalle de los enlaces o kclicks que se generan en la plataforma.

Los mismos desarrolladores nos cuentan que decidieron crear un plugin ligero para jQuery que reemplazara las antiguas gráficas generadas con flash mediante FusionCharts.

Hemos podido hablar con Xabi Sáez de Ocariz y Alex Dolara programador JavaScript y Diseñador Gráfico respectivamente además de padres de la criatura que nos han explicado como funciona el plugin y como ha sido el proceso de desarrollo y liberación del código.

¿Cómo se usa?

Usar el plugin es muy sencillo, tan solo necesitamos un array de entrada de datos válido con el que alimentar al plugin y llamar a un simple método usando un selector de jQuery:

$(document).ready(function() { var data = [[[40,[“3”,“25\/11\/2011”]], [1,[“1”,“26\/11\/2011”]], [4,[“4”,“27\/11\/2011”]], [5,[“5”,“28\/11\/2011”]], [14,[“14”,“29\/11\/2011”]], [15,[“15”,“30\/11\/2011”]], [13,[“13”,“01\/12\/2011”]], [6,[“6”,“02\/12\/2011”]], [1,[“1”,“03\/12\/2011”]], [10,[“10”,“04\/12\/2011”]], [7,[“7”,“05\/12\/2011”]], [7,[“7”,“06\/12\/2011”]], [40,[“40”,“07\/12\/2011”]]];
 $(’#grafico’).karmicGraph(data, { ‘outLabel’: ‘Situa el cursor sobre un dato para descubrir su valor’, ‘color’: ‘blue’, ‘label’: ‘{0} puntos el día {1}’, ‘type’: ‘flatbars’, ‘freeColumn’ : 1 }); });

El código anterior da como resultado lo que vemos en la siguiente imagen:

Gráfico generado por el plugin

Como podéis comprobar su uso no es nada complicado.

¿Cómo funciona?

El plugin cuenta con una función llamada karmicGrahp, que se aplica sobre un elemento div. Esta función acepta tres parámetros:

method: El método que se quiere invocar. Este parámetro es opcional y, de no ponerlo, se ejecuta el único método implementado por el momento: init.
data: Array de datos del gráfico. Tiene la siguiente forma: [[valor1,[elementos del label]],[valor2,[elementos del label]],…]
options: Objeto javascript con las opciones de configuración. Son las siguientes:
- type: Tipo de gráfico. Actualmente hay dos estilos: flatbars, para el gráfico que se ve en el detalle de kcy y tinybars, para el que se ve en las estadísticas del usuario.
- color: El color. Acepta: blue, red, green, yellow, orange, dark-orange, violet y gold.
- showLabel: Si se muestra el label o no. true o false.
- label: La cadena de texto que se muestra cuando se pone el cursor sobre una barra. Puede hacerse referencia al valor a través con {val} y a los elementos del label descritos en el array de datos con {0},{1}, haciendo referencia a su posición en dicho array.
- outLabel: La cadena de texto que se muestra cuando el usuario no está posicionado encima de ninguna barra.
- noLabel: La cadena de texto que se muestra cuando no hay valor definido para la barra sobre la que está el usuario.
- freeColumn: Indica dónde se “anclan” las barras del gráfico. Si es menor o igual que 0, las barras sin datos se colocarán a la izquierda y la última barra del gráfico estará pegada a la derecha. Si es mayor que 0, las barras sin datos muestran a la derecha de las que sí los tienen y el principio del gráfico se ancla al extremo izquierdo.
- width: La anchura, en píxeles, que queremos que tenga el gráfico.

¿Cómo se desarrolló y liberó?

Para construir el plugin siguieron las indicaciones y consejos de la página oficial de jQuery. En la versión actual, el plugin solo ofrece un método que inicializa el gráfico y genera el HTML adecuado pero la intención de Xabi es ofrecer otro método que realice una actualización de los datos desde una URL que se le pueda pasar como un parámetro configurable.

Para el desarrolo se ha seguido el modelo de implementación de varios métodos para un plugin que aconseja jQuery. Los métodos se agrupan en un objeto javascript y se llaman a través de la función principal, pasándole como parámetro una cadena de texto con el nombre del método en cuestión.

Esto se hace así para no saturar el espacio de nombres $.fn que es dónde se declaran las funciones plugin de jQuery. En el siguiente bloque de código podemos comprobar la gestión de la llamada a métodos:

$.fn.karmicGraph = function( method ) { if ( methods[method] ) { return methods[ method ].apply( this, Array.prototype.slice.call( arguments, 1 )); } else if ( typeof method === 'object' || ! method ) { return methods.init.apply( this, arguments ); } else { $.error( 'Method ' + method + ' does not exist on jQuery.karmicGraph' ); } }

A la hora de liberar el código se añadió una licencia GPLv3 para que toda la Comunidad pueda beneficiarse del código y se subió al repositorio público GitHub de Karmacracy.

Desde Genbeta Dev, y como siempre, les deseamos la mejor de las suertes a los chicos de Karmacracy y esperamos que en el futuro sigan liberando Software Libre de forma regular.

Más Información | Repositorio del proyecto
En Genbeta Dev |

Dell prepara un portátil para Desarrolladores con Ubuntu y Software Libre

Oscar Campos — Tue, 08 May 2012 06:00:00 GMT

Ayer día siete de mayo, Dell anunciaba en la Ubuntu Developers Summit que pretende introducirse dentro del mercado de portátiles con Linux (otra vez) con el proyecto Sputnik, un ordenador portátil para desarrolladores centrado en Ubuntu 12.04 bajo el hardware Dell Ultrabook XPS13.

Si eres el feliz propietario de un XPS13 puedes descargar la imagen en fase de desarrollo de la distribución de Linux modificada y darle un tiento, si quieres saber lo que se encuentra dentro de ella solo tienes que seguir leyendo esta entrada.

¿Por qué un portátil para Desarrolladores?

Según Barton George, líder del proyecto, Dell realizó un estudio de mercado acerca de las necesidades de desarrollo para empresas que utilizan Internet como su plataforma. Una de las ideas que recogieron fue la de un portátil Dell ejecutando Ubuntu Linux especialmente enfocado en los desarrolladores.

A los ingenieros de Dell la idea les pareció interesante y se pusieron manos a la obra con el proyecto Sputnik para de esta forma poder servir mejor a las necesidades de los desarrolladores y la plataforma XPS13 les pareció la más adecuada.

La decisión de Dell de elegir Ubuntu viene dada por su gren experiencia previa con la distribución de Linux de Canonical y por su alta popularidad de la que obviamente también pretenden beneficiarse. Recordemos que los XPS13 son portátiles de la gama más alta de Dell, solo superados en precio y prestaciones por la serie Alienware para Gamers.

La imagen actual de Sputnik contiene lo siguiente:

drivers/parches para la activación de Hardware
un kit básico de herramientas y utilidades
una herramienta de administración de software con la que se podrán descargar “perfiles” de desarrollo desde GitHub (en desarrollo)

Administración de perfiles de desarrollo

Donde el proyecto se torna interesante es en esto que Dell ha llamado “perfiles de desarrollo”. Según Barton, no hay dos desarrolladores iguales, por lo que en lugar de sembrar la distribución con todas las herramientas de desarrollo disponibles, plantean un enfoque diferente.

Como ya hemos comentado, la imagen de instalación es muy simple, la intención de la compañía es crear perfiles de desarrollo que podrán ser descargados e instalados a través de repositorios alojados en GitHub. Los primeros perfiles que están probando son Android, Ruby y JavaScript.

Charles Lowell, parte del equipo de desarrollo en Austin comenta sobre el proyecto:

Lo que quiero ver no es solo una configuración estándar impecable sino además un meta-sistema para administrar tu configuración de desarrollo. La revolución de los devops es sobre tratar la configuración como código. ¿Cómo de guai sería que la configuración del portátil donde programo pudiera ser almacenada en un repositorio de código en algún sitio?.

La intención de Dell es conseguir que la Comunidad de desarrolladores creen y cuelguen sus propios perfiles de desarrollo una vez la plataforma esté en marcha.

Como proyecto es cuanto menos curioso y la decisión de que los repositorios se encuentren en Github a disposición de cualquiera me parece muy acertada pero habrá que ver bajo que licencia se lanza el administrador de perfiles.

Si el administrador se lanza con una licencia de Software Libre sería genial para la Comunidad ya que podría extenderse el uso (si al final resulta útil y todo el sistema) del invento a otras plataformas y distribuciones. En caso contrario, el invento me parece además un movimiento de marketing muy bien pensado por Dell y Ubuntu para vender más hardware y crear más marca respectivamente.

¿Qué opináis vosotros?

Más Información en | Blog personal de Barton

Branching, haciendo crecer nuestro árbol del repositorio de código

Juan Quijano — Tue, 08 May 2012 04:00:00 GMT

En el artículo anterior de esta miniserie, estuve tratando sobre la necesidad básica de tener un repositorio de código. Y de una primera aproximación a la gestión más madura del trabajo por medio del etiquetado de versiones: labeling.

En esta segunda parte, final, quiero dar un paso adelante y describir una técnica de separación de las líneas de desarrollo en el repositorio de código fuente que nos ayude, en gran medida, a organizar la complejidad inherente a todo desarrollo en equipo.

Branching, dicho de forma espantosa sería algo como “rameando” o ir haciendo ramas, se utiliza en los repositorios de código. No es algo novedoso, ni mucho menos. De hecho, al menos desde los años 70 ya existen aplicaciones como CA Software Change Manager, que permiten hacer branching; mucho antes de que algunos de nuestros lectores hubiese, tan siquiera nacido.

Porqué necesitamos hacer branching

Por ejemplo, estoy integrado en un equipo de cuatro personas haciendo un proyecto de una aplicación de gestión de una empresa de repuestos. Y empezamos a trabajar sobre el módulo de almacén.

Vemos que vamos a necesitar hacer una pantalla típica de CRUD: alta, modificación, baja y listado de piezas. Para ir más deprisa vamos a trabajar los cuatro al mismo tiempo en la misma pantalla, por lo cual vamos a trastear en el mismo código tanto en la capa de representación, en la de negocio y en la de acceso a datos.

Para que no haya problemas, habilitamos la capacidad de checkin múltiple, así varios podemos tocar el mismo código al mismo tiempo, y mantenemos la coherencia del código por medio de merges. Cuando lo tenemos acabado y vemos que ha funcionado bien, le ponemos una etiqueta, y continuamos con la siguiente pantalla.

Cuando tenemos terminado el módulo de almacén, y todas sus pantallas, volvemos a etiquetar y le damos al cliente el módulo para su puesta en producción. Y nos disponemos a continuar con el módulo de facturación, que está muy relacionado con el de almacén.Nos volvemos a repartir el trabajo, y empezamos a modificar y añadir las líneas del nuevo código al ya existente de almacén.

Y en esto nos encontramos que el cliente ha encontrado un fallo crítico y hay que corregirlo y publicar una actualización. Para ello nos hacemos una copia de seguridad, recuperamos la etiqueta, realizamos los arreglos, volvemos a etiquetar y se lo mandamos al cliente el módulo arreglado.

¿Y ahora cómo vuelvo al código original, que aún no funciona y que está en desarrollo; y, además, le añado los arreglos añadidos en la nueva versión?

La respuesta más obvia es, utilizando desarrollo en ramas (branching).

Cuando he terminado de hacer el módulo de almacén, no solamente lo etiqueto si no que creo una nueva rama, que es una copia del código, en donde voy a ir desarrollando el nuevo módulo de facturación. Así, si tengo que modificar el módulo de almacén, no tengo que esperar a tener una versión funcional del de facturación, o andar haciendo copias de seguridad.

Como se ve en la figura, este sistema es mucho más robusto y seguro. Y evito que los trabajos en un módulo me afecten al trabajo en los demás.

Diferentes sabores

Ahora que tengo claro que la complejidad del desarrollo del software me lleva de la mano a realizar ramas en mi repositorio de código, quiero compartir los dos primeros niveles de branching que utilizo con diariamente.

El primero es una forma secuencial en donde tengo el tronco de la aplicación (siempre lista para ser desplegada), etiquetado cada punto de publicación y en donde las modificaciones y añadidos se inician, se completan y se unen al tronco por medio de una rama. Una vez terminada la misma, iniciaría otra rama para el siguiente módulo.

Esta forma de trabajo tiene la ventaja de ser muy ordenada y que la dirección de las actualizaciones siempre es del branch al trunk. Es decir, del nuevo desarrollo a la línea base. Como inconveniente, se complica hacer varios trabajos de forma simultánea. A menos que arranquemos tareas de similar duración que acaben al mismo tiempo o que no compartan nada de código (lo cual es difícil en cuanto empiezas a trabajar en capas).

Lo más habitual es que el grafo del árbol de ramas alrededor del tronco principal, sea de múltiples direcciones. No solamente de las ramas hacia el trunk, si no de este a diferentes ramas o, incluso, entre ramas diferentes.

Así, por ejemplo, en la figura anterior he iniciado una corrección en el trunk mientras termino el módulo1. Ya que he terminado la corrección, hago un merge de este con el branch del módulo 2, para que esté actualizado; ya que hay cosas en la capa de negocio que están implicadas.

Como se ve, con esta forma de trabajo voy a tener una versión de la aplicación lista para ser publicada en cualquier momento. Aseguro el no tener que esperar a que se acabe un trabajo para iniciar otro. Y puedo mantener actualizado los módulos según lo necesite en cada caso.

El mayor inconveniente es la complejidad. Si somos varios equipos, y realizamos desarrollos cruzados, con puntos en común crecientes y que se deben mantener sincronizados, puedo tener un árbol con muchas ramas que llegue a ser confuso o difícil de abarcar.

A partir de este punto de madurez, podemos ir ganando complejidad subdividiendo los trabajos incluso hasta tener una rama por Sprint o por tarea dentro de un Sprint. Teniendo siempre claro que el concepto subyacente es que el desarrollo no impida tener código funcionando en cualquier momento.

Incluso podemos llegar a un sistema de branching similar a una publicación continua, en donde no trabajamos contra un tronco, si no con simultaneas ramas. Y donde se activan o desactivan las funcionalidades según tengamos finalizados y probados los módulos.

Ahora solamente queda el pasar de la teoría a la práctica y ver un ejemplo en mi repositorio de código.

Más información | Visual Studio Team Foundation Server Branching and Merging Guide, Git. Magia Con Los Branches
En GenbetaDev | Etiquetando,haciendo crecer nuestro árbol del repositorio de código, Manejo de ramas de desarrollo con git

Diagrama para elegir la licencia más apropiada para tu software

Johnbo — Mon, 07 May 2012 13:30:00 GMT

Ponerle copyright a un software y sentarse a esperar los beneficios es muy fácil, pero si alguna vez has pensado aplicar una licencia libre al fruto de tus trabajos te habrás encontrado con que es una decisión bastante complicada, especialmente por el amplio abanico de licencias disponibles y las a veces muy sutiles diferencias entre unas y otras.

Como método de ayuda a la hora de elegir, y a mitad de camino entre el estudio exhaustivo y el sentido del humor, Dan Bentley y Brian Fitzpatrick han creado esta infografía en forma de diagrama de flujo para ayudarnos en la decisión en favor de una u otra licencia.

Yo lo he seguido y me sale que debería usar la LGPL en mis desarrollos. ¿Y a vosotros?

Vía | Bill the Lizard – Which open source license?
Autores de la infografía | Dan Bentley y Brian Fitzpatrick

¿Cómo funciona el memory breakpoint en un depurador de C/C++? (breakpoints part III)

Oscar Campos — Mon, 07 May 2012 10:00:00 GMT

Desensamblador y Depurador IDA corriendo en Windows

En el último artículo de la serie vimos lo útiles que pueden llegar a ser los hardware breakpoints para depurar aplicaciones que por ejemplo hacen comprobaciones de CRC y no pueden ser depuradas modificando sus datos en memoria.

Hoy vamos a ver como podemos utilizar memory breakpoints para sobrepasar los límites impuestos por los hardware breakpoints y poder entre otras cosas controlar el acceso a grandes partes de la memoria.

Memory Breakpoints

Para empezar hay que decir que los memory breakpoints no son realmente breakpoints. Cuando un depurador fija un memory breakpoint cambia los permisos en una región o página de la memoria.

Una página es la porción más pequeña de memoria que un sistema operativo puede manejar, este valor normalmente es de 4096 Bytes (4K). Cuando se asigna una página, el sistema operativo le otorga una serie de permisos que indican como debe ser accedida. Algunos de esos permisos son los que siguen:

Ejecución: Permite la ejecución pero eleva una excepción si el proceso intenta escribir o leer de la página
Lectura: Activa el acceso para lectura pero se eleva una excepción ante cualquier intento de escritura o ejecución
Escritura: Permite el acceso de escritura
Protegida: Cualquier acceso a una página protegida resulta en una excepción y la página vuelve a su estado original

La mayoría de los sistemas operativos modernos permiten combinar estos permisos. Por ejemplo, podemos tener páginas en memoria que permitan el acceso de lectura y escritura mientras que otras pueden permitir el acceso de lectura y la ejecución.

Cada sistema operativo implementa sus propios métodos para consultar los permisos de una página en particular y modificarlos si fuese necesario. El permiso que nos interesa para nuestra tarea de depurado es el de “página protegida.

Este tipo de página es realmente útil para cosas como separar el stack del heap o comprobar que una región de memoria dada no sobrepasa sus límites. Y claro, también es tremendamente útil para detener un proceso cuando accede a una sección de memoria en particular.

¿Cómo se usan?

Imaginemos que estamos depurando un servidor de red, podríamos establecer un memory breakpoint en la región de memoria donde se guarda el cuerpo de un paquete de red al recibirlo. Esto permite determinar cuando y de que manera, la aplicación utiliza el contenido del paquete recibido ya que cualquier acceso a esa región de memoria hará que la CPU se pare y levantará una excepción de página protegida que podremos capturar con el depurador.

Entonces podremos inspeccionar la instrucción que ha accedido a la memoria y determinar que operaciones realiza con el contenido de la misma. Esta técnica también esquiva el problema de comprobación de firma CRC ya que no modificamos nada del código en ejecución.

Y con este último método ya hemos visto todas las formas en las que podemos colocar un punto de interrupción en una aplicación en ejecución para poder depurarla con los fines que sean.

Más en GenbetaDev | Funcionamiento de los depuradores de C y C++

Etiquetando,haciendo crecer nuestro árbol del repositorio de código

Juan Quijano — Mon, 07 May 2012 04:00:00 GMT

Una de las cosas que más me sorprenden y escandalizan es la cantidad de empresas y compañeros que trabajan sin un repositorio de código. No conocen las virtudes de configurar un punto único en donde almacenar, versionar y recuperar las cientos o miles de horas/hombre invertidas en millones de líneas de programación.

Cuando toca juntar las fuentes de dos o tres personas es un auténtico dolor, pero la cosa se hace imposible cuando lo ha de realizar todo un equipo o departamento. Haciéndose una costumbre el perder código, o tener una árbol de carpetas de “copias de seguridad“ en el ordenador que se utiliza para hacer las publicaciones y que, generalmente, es el del líder del equipo.

Pero incluso cuando se establece, por fin, un repositorio de código, se trabaja continuadamente en un mismo tronco (trunk). El cual soporta las modificaciones y actualizaciones más variopintas. Sufriendo roturas a causa de errores o el no poder publicar hasta que se termine la decimonovena modificación o arreglo.

A estos equipos les invito a dar un paso en la escalera de la madurez del ecosistema y a leer esta serie que trata sobre la técnica de branching. Es decir, la forma de construir software alrededor de un núcleo estable, minimizando las causas de ruptura o de no disponibilidad.

Y que voy a iniciar con el etiquetado de las versiones.

Las herramientas

En el núcleo tengo el repositorio de código, control de versiones y gestor de proyectos: el Team Foundation Service Preview. Que es una versión en la nube del Team Foundation Server 11; a la que me han dado acceso por invitación. De precios y costes aún no se ha anunciado nada, pero es un servicio muy completo que me permite hacer prácticamente todo lo que puedo hacer con un TFS 11 beta pero con la flexibilidad, escalabilidad, accesibilidad y disponibilidad que nos provee un sistema basado en la Cloud. Un ejemplo más del desarrollo del concepto SaaS.

Para el que tenga máquina o que quiera trastear en un entorno local, puede utilizar el Team Foundation Server 11 Beta, que está disponible para su descarga y uso sin coste, hasta que salga la versión definitiva de pago. Y aún entonces, se va a publicar una versión gratuita.

El acceso al repositorio de código lo hago desde Visual Studio 11 beta, el cual ha remozado totalmente el interfaz de la antigua versión. Y que llevo utilizando desde la versión Developer Preview presentada en el evento BUILD del año pasado.

Pero tanto ahora como en el futuro puedo utilizar cualquier fabricante o versión de repositorio de código para poner en práctica el branching. Por ejemplo, un Visual Studio 2010 contra un SVN; o un Eclipse contra un TFS, o un Git; o incluso un muy poco aconsejable y anticuado sourcesafe.

Etiquetas, un primer paso

Una vez que he conseguido instalar el repositorio; y el equipo supere las primeras suspicacias y pérdidas de código por un uso inesperadamente sorprendente de los check-in, los check-out y las malas prácticas de copy, paste & move de ficheros físicos; llega el momento en que se hace parte de la cultura corporativa tener todo el trabajo en un solo sitio compartido, seguro y que se realice el versionado de forma automática y sencilla.

¿Pero qué pasa cuando hemos realizado una publicación en integración; y encontramos varios errores que hay que solucionar; y a los dos días nos damos cuenta que hemos roto la versión publicada y que hay que volver a la última válida? Pues que tenemos un desastre a la vista, ya que en esos dos días algunos ficheros han sido modificados, otros han sido borrados y la mayoría no se han tocado. Y, además, el impacto de cada uno de ellos en el resto de la aplicación depende de muchos otros factores.

La forma más sencilla de poder acceder a una versión específica de mi código, es por medio del uso de etiquetas. Es decir, hago una instantánea de la evolución de mi aplicación en un momento dado y le doy un nombre para poder recuperarla como una unidad. Así no tengo que preocuparme de saber qué versión de cada fichero es la correcta para el momento específico, ni cual ha sido cambiada anterior o posteriormente. Es una especie de backup de los hitos importantes en el desarrollo de la aplicación.

En TFS, realizar etiquetados es algo tan sencillo como entrar en la pestaña del Team Explorer, y seleccionar el enlace del Source Control Explorer para abrir la ventana del Explorador de Código. Aquí pulso el botón derecho del ratón encima del nodo raíz del proyecto, o el nodo que queramos etiquetar, y selecciono “Apply label“. Así abrimos una ventana emergente en donde debemos introducir el título de la etiqueta y su descripción.

Mi consejo: sé cuidadoso. En el título incluye la fecha y describe de forma expresiva lo que caracteriza a esta versión del código. Ten en cuenta que para recuperar esta instantánea tendrás que hacer un Get specific version por etiqueta. Y en el listado que se abre en una nueva ventana emergente, seleccionar la que almacena la versión que deseas recuperar. Por lo cual el título, cuanto más descriptivo mejor.

Aquí no se acaba

Ahora si, puedo estar haciendo diabluras en el código y romper todo lo rompible, y puedo en cualquier momento recuperar un punto específico en donde las cosas aún funcionaban de forma correcta. Pero esto, insisto, es una solución muy básica.

Los problemas empiezan a crecer cuando dos o más desarrolladores están modificando el mismo código al mismo tiempo. Ya que el sistema de etiquetas es lineal, por lo cual tarde o temprano tendremos un nudo gordiano en donde no hay forma de tener una versión estable del proyecto sin un gran y doloroso esfuerzo.

Y aquí llegamos a los troncos y las ramas: branching.

Más información | Visual Studio Team Foundation Server Branching and Merging Guide, Git. Magia Con Los Branches
En GenbetaDev | Manejo de ramas de desarrollo con git

¿Por qué las APIs no deberían usar el modelo de autenticación login/password?

Txema Rodríguez — Sun, 06 May 2012 17:13:30 GMT

Cada vez es más común que las aplicaciones móviles o clientes externos usen las APIs para acceder e interactuar con los datos de un usuario. Para permitir este acceso, existen varias alternativas. Quizás la que con más fuerza se está imponiendo es usar OAuth para conceder acceso, pero aún quedan muchas APIs que sigue usando el modelo de solicitar un login y password en los métodos de autenticación que ofrecen a los desarrolladores interesados en crear alguna aplicación.

Este modelo de solicitar login y password conlleva una serie de inconvenientes y problemas, tanto para el usuario como para los desarrolladores que tienen que trabajar con la API, y posteriormente enviar estos datos al servicio de la API.

Confianza. Por supuesto, esta es la más obvia. ¿Confiarías en una aplicación que te solicita tu login y password de tu cuenta de correo? Este quizás sea el ejemplo más extremo, pero por qué debería confiar en ceder esos datos a un desarrollador que hace uso de la API del servicio del que tengo cuenta de usuario.
Phishing. Incluso si el usuario se siente cómodo proporcionando su contraseña a la aplicación podría sufrir suplantación de la identidad cediendo los datos a aplicaciones de terceros que no son tales. Por ejemplo, un cliente falso de Twitter (Ojo, Twitter usa OAuth así que no deberías acceder directamente con tu contraseña desde una aplicación de tercero)
Acceso total a la cuenta de usuario. Al darle nuestra clave de acceso le estamos dando acceso total a nuestra cuenta. Si usáramos el modelo de tokens de oAuth la API podría gestionar distintos privilegios y acceso limitado a funcionalidades.
Si el usuario cambia la contraseña no se puede acceder a sus datos. Multiplica esto si el usuario tiene esa cuenta en distintos dispositivos.
Por otro lado, si el usuario quiere revocar el acceso a una aplicación no le queda otra alternativa que cambiar de contraseña de acceso. Con OAuth, podríamos revocar el acceso a una aplicación en concreto sin afectar al resto.
Dificultad para implementar una autenticación fuerte. La API puede sufrir fácilmente ataques para acceder a los datos de un usuario a través de la llamadas de login/password. Para evitarlo se complica el acceso teniendo que usar CAPTCHAs.

Alternativas como OAuth 2.0 permite a las aplicaciones que usen la API acceder de forma segura, sin requerir ni el usuario ni el passord del usuario. Además su expansión hace que sea fácilmente utilizado por los desarrolladores, ya que se está convirtiendo en un método estándar de seguridad, según Programmable Web en Febrero de 2012 ya hay más de 300 APIs en la web que usan OAuth como método de autenticación.

Más información | OAuth
En Genbeta Dev | El crecimiento imparable de las APIs, fundamentales en el desarrollo de webs y aplicaciones móviles actualmente

Se lanza XobotOS, un Android en .NET y C#

Fernando Siles — Sat, 05 May 2012 15:06:03 GMT

Como es sabido, Android se basa en Java y Java pertenece a Oracle. ~~De momento no ha habido hostilidades pero siempre es posible que el belicoso Larry Ellison decida un día tirar de patentes y pedir dinero a espuertas~~ Y las previsibles hostilidades entre Google y Oracle van subiendo de tono cada semana. Por eso la migración de Android a otros cimientos es algo de lo que se viene hablando hace tiempo. Pues bien, ahora la gente de Xamarin ha portado el código en Java de Android a C# (con la herramienta Sharpen) y lo han hecho correr sobre .NET pero no la implementación de de Microsoft sino sobre Mono (que la misma gente de Mono había creado antes de formar la empresa). Al resultado lo han XobotOS.

Este XobotOS es tan sólo un proyecto de investigación que no va a ser continuado por la gente de Xamarin pero al ser software open source con una licencia Apache, es posible que alguien (incluso la propia Google) se aproveche del gran trabajo previo realizado (millones de líneas de código portadas) para sacar un sistema operativo Android completo sin ningún atisbo de Java.

Pd: en Xamarin afirman que los resultados de este XobotOS son mejores que los de Java con Dalvik (el primo hermano de la JVM de Google)

Vía | Ars Technica
Foto | Xamarin
Más info | Xamarin
Descarga | Github

Se lanza XobotOS, un Android en .NET y C#

Fernando Siles — Sat, 05 May 2012 15:06:03 GMT

Como es sabido, Android se basa en Java y Java pertenece a Oracle. De momento no ha habido hostilidades pero siempre es posible que el belicoso Larry Ellison decida un día tirar de patentes y pedir dinero a espuertas. Por eso la migración de Android a otros cimientos es algo de lo que se viene hablando hace tiempo. Pues bien, ahora la gente de Xamarin ha portado el código en Java de Android a C# (con la herramienta Sharpen) y lo han hecho correr sobre .NET pero no la implementación de de Microsoft sino sobre Mono (que la misma gente de Mono había creado antes de formar la empresa). Al resultado lo han XobotOS.

Pd: en Xamarin afirman que los resultados de este XobotOS son mejores que los de Java con Dalvik (el primo hermano de la JVM de Google)

Vía | Ars Technica
Foto | Xamarin
Más info | Github

"Había que potenciar la comunidad de JavaScript en Madrid". Entrevista a Israel Alcázar

Juan Quijano — Fri, 04 May 2012 06:00:00 GMT

En julio del 2011, esta batidora de información que es twiter me hizo saber la curiosa convocatoria de un grupo de estudio de JavaScript, ese lenguaje endemoniado que tantas veces me ha llevado por la calle de la amargura. Obviamente me apunté, aunque fuera para ir a conocer y ponerle cara a personas que solo conocía en la Red.

La sorpresa fue cuando nos juntamos más de 50 personas y tuve el placer de saludar brevemente a Israel Alcázar, el alma mater y promotor de este movimiento incipiente. Movimiento que no ha parado de crecer en capacidad de convocatoria; en calidad de los ponentes; constituyéndose en MadridJS y enfrentándose a su primer gran evento internacional para el próximo verano de 2012.

He ido encontrándome con Israel en otros eventos relacionados con el agilísimo o el movimiento de emprendedores. Y desde una humildad que le honra, se ha consolidado como el impulsor de una viva y poderosa comunidad alrededor de este lenguaje.

Ahora tengo la satisfacción de transcribir sus palabras con las que ha contestado las preguntas que componen esta entrevista.

Obviamente para tí JavaScript tiene un futuro prometedor, ¿pero podrías argumentarlo desde el cerebro y no desde el corazón?

Pues si echamos un vistazo rápido a HTML5 y a todo lo relativo a tecnologías móviles en entorno web nos encontramos con que gran parte de todo está basado en APIs JavaScript. Así que hay que aprenderlo, sea como sea, porque nos lo encontraremos hasta en la sopa. Además con cosas como NodeJS también tenemos JavaScript en el servidor….¿no es alucinante?

En mi opinión, lo que menos me gusta es que es un lenguaje sin tipado fuerte, ¿qué ventajas le ofrece a JavaScript esta “desventaja”?

La principal ventaja que le veo al tipado débil es la versatilidad y el dinamismo que puedes conseguir en tu código. Aunque tiene el peligro de perder el control y no saber lo que estamos haciendo. Por eso es importante utilizar técnicas de testing para permitirnos detectar problemas rápidamente. Tampoco hay que perder de vista a CoffeeScript, que nos permite “picar” código JavaScript muy limpio y claro.

¿Es posible hacer Programación Orientada a Objetos de forma sencilla en JavaScript?

Digamos que JavaScript proporciona POO de una forma “distinta” a lo habitual. Estamos acostumbrados en otros tipos de lenguajes orientados a objetos como Java o C++ a utilizar el concepto de clase y herencia para implementar la orientación a objetos. Sin embargo, JavaScript nos proporciona una forma distinta, ni mejor ni peor simplemente distinta, como son las funciones y los prototipos.

Olvidándonos de JavaScript, ¿cual es tu lenguaje preferido?

Mi “lenguaje materno” es Java. Fue el primero (sin contar a Pascal claro) que aprendí y le tengo un especial cariño. Dicen los gurus que es el nuevo Cobol pero yo creo que todavía le queda mucho recorrido!!

¿Qué piensas de los lenguajes funcionales o de cosas aún más raras como Erlang ?

Que son algo raro, raro, raro….no, ahora en serio, creo que son lenguajes con mucha potencia pero con una curva de aprendizaje bastante alta. Otra de las cosas que me gusta de JavaScript es que permite programación funcional, aunque ya sabemos que la potencia sin control no tiene sentido.

De Erlang…creo que con el auge de las redes sociales, el cloud computing y el manejo masivo de operaciones distribuida, etc, le ha permitido avanzar y ser mas utilizado de lo que en principio cabría esperar…personalmente no es un lenguaje que me motive demasiado aunque reconozco que tiene su puntito.

¿Cuando te diste cuenta que el desarrollo iba a ser tu profesión/pasión?

Desde pequeño tuve claro que me encantaban los ordenadores. Empecé la universidad enfocado en los sistemas y las redes pero enseguida me di cuenta que a mi lo que me gustaba era programar. Desde entonces, con el paso del tiempo me he ido interesando por diferentes lenguajes pasando no solo de ser un trabajo sino en un hobbie.

Está claro que eres un apasionado de la programación en general, pero ¿cómo has terminado liderando la comunidad de javascript?

No me considero líder de nada. Había que potenciar la comunidad de JavaScript en Madrid porque era una pena que con la cantidad de gente buena que hay programando en este lenguaje, no hubiera ningún punto de encuentro donde aprender y compartir conocimientos y experiencias. ¡Había que reunir a todos los JavaScripters! Aprovechamos que en Junio se fundó el grupo de MadridJS para potenciarlo un poco.

¿Estudias (obviamente) y/o trabajas?¿Donde?

Estudiar, en esta profesión es el día a día, así que no paro de leer y estudiar cosas nuevas. En cuanto a trabajar, los últimos 5 años los he pasado en atSistemas, consultora tecnológica donde me dedico sobre todo a ayudar a los equipos de desarrollo a hacer mejor software y programar cuando me dejan.

¿De donde sacas el tiempo para tu familia, o tus amigos u otras actividades no relacionadas con el código?

Todo es cuestión de planificarse bien y saber compaginarlo todo. El día y las semanas tienen muchas horas. Hay que saber compensar todos esos momentos que no puedes estar con ellos con otros en los que tienes que estar al 200%. Desde luego tengo una familia, pareja y amigos que entienden mi profesión y el tiempo que muchas veces hay que dedicarle para estar siempre a la última.

¿Cómo se gestiona una comunidad virtual como el Grupo de Estudio de JavaScript?

Para los que no lo conozcan, el grupo de estudio fue una iniciativa que duró 1 mes (agosto 2011) y que culminó en lo que actualmente es el grupo local MadridJS. Empezó con la intención de ser un grupo de estudio en el que todo el mundo participase en el aprendizaje pero, al final, se convirtió en algo parecido a un mini-curso ya que el nivel de los asistentes era mas bajo de lo esperado y consideramos que el formato que mejor se adaptaba era el de curso mas que grupo de estudio.

Lo mas complicado de gestionarlo fue el lugar donde nos reuníamos. Al ser muchas personas era lo mas complejo de encontrar. Siempre tuvimos la ayuda de Madrid On Rails a los que aprovecho para agradecer su apoyo.

El resto de cosas fluyeron solas tanto con la gente que participó compartiendo sus conocimientos, como todos los que se acercaron a aprender. Si alguien está interesado en ver lo que hicimos, creamos esta web donde encontrar ejercicios y material de ayuda. No es demasiado pero solo estuvimos un mes.

¿Esperabas esta capacidad de convocatoria cuando lo creaste?

Me vi desbordado por completo. Todo empezó con un mensaje en Twitter que mandé volviendo de la playa, donde animaba a cualquiera que estuviera por Madrid en agosto a aprender JavaScript. Pensaba que siendo agosto, no llegaríamos ni a 5 personas. Que sorpresa cuando unas 30 personas se interesaron y finalmente vinieron. Semana tras semana fuimos una media de 15-20 personas. ¡Qué grande es esto de Twitter!

¿Merece la pena el lio de gestionar una de las comunidades más activas en este momento, incluso llegando a ser nominada en MeetUp?

Merece mucho la pena claro. Siempre he dicho que todo esto lo hago por egoísmo puro (je je), yo quería aprender JavaScript y que mejor forma de hacerlo que potenciando la comunidad local.

A pesar del esfuerzo que exige me ha permitido conocer a personas que de otra forma no hubiera tenido oportunidad. Hay mucha gente que se acerca a saludarte que de otra forma no las hubiera conocido nunca y créeme que son gente muy interesante, con mucha ideas y muchas cosas de las que puedo aprender.

¿A quien quisieras agradecer, como si estuvieras dando un discurso en los Oscar?

Pues agradecer especialmente al incansable Enrique Amodeo, por toda la ayuda y el apoyo prestado tanto con el Grupo de Estudio, como posteriormente con el grupo local MadridJS. Si su colaboración no hubiera sido lo mismo.

Y por supuesto a todos esos JavaScripters que nos siguen mes a mes y nos acompañan en cada reunión tanto presencialmente como por streaming….me consta que nos ve gente de Argentina, Colombia, Brasil, Venezuela, y muchos otros países.

¿Cómo ves el panorama del desarrollo en España?

Creo que por suerte nos está tocando poco la crisis en el sector (toquemos madera). Veo últimamente mucho movimiento en cuanto al desarrollo de productos se refiere. Ya sabemos que España, históricamente, es un país donde no se desarrolla mucho software (entendido como productos) y a lo que mas se dedican las empresas del sector es a subcontratar servicios y personas.

En ese sentido creo que las cosas están cambiando y poco a poco surgen mas empresas con ideas y productos a los que dar forma.

¿Qué consejos le darías a un estudiante o a un recién llegado al sector para no morir en el intento?

Pues que este sector necesita gente motivada y con pasión por lo que hace. Por desgracia, los salarios actuales no son los mismos que los de antes de la crisis así que es especialmente importante que la gente que se inicia en este sector sea gente a la que le apasione trabajar en esto.

A los estudiantes, que cuanto antes adquieran experiencia haciendo prácticas o becas en diferentes empresas mejor. Hace unos años era fácil encontrar trabajo sin experiencia pero con el panorama actual se piden perfiles con un poco mas de experiencia, así que cuanto antes la tengan mejor que mejor.

Y para terminar…
Solo me queda agradeceros por la oportunidad que me habéis brindado con esta entrevista. Animar a todos los desarrolladores que no están interesados en JavaScript que se lo piensen, que se acerquen al lenguaje porque a pesar de ser un lenguaje con muchos años a sus espaldas, es el presente y futuro de la web, los móviles, la televisión y cualquier cosa que se os ocurra.

Espero veros a todos en la conferencia internacional sobre JavaScript (SpainJS) que estamos montando en Madrid para este verano. Esperamos sea algo grande que atraiga a muchos JavaScripters internacionales y así poder seguir potenciando la comunidad local y nacional.

Twiter | @ialcazar
Blog | Farmer Dev’s Blog
MadridJS | Meetup de MadridJS
En GenbetaDev | Entrevista a Miquel Camps, organizador de Betabeers

Descubierto bug de PHP con 8 años de antigüedad

Fernando Siles — Fri, 04 May 2012 04:30:00 GMT

Una de dos: o me descubrían ya o empezaba a pedir la paga

Ocho años en el mundo del desarrollo es varios lustros en el equivalente del mundo real (si, esa cosa que hay más allá de las líneas de código). Por eso sorprende (por lo menos a mi) que ahora se haya descubierto un bug de PHP que lleva allí desde un commit de 2004. Vamos, que unos meses más y hace la comunión el bicho.

El bug en cuestión afecta a las instalaciones de PHP que usen el modo mod_cgi de Apache y viene a ser lo siguiente: si añades a una url parámetros sin que haya ningún signo ‘=’ (por ejemplo ‘?s’), te hace un bonito dump de tu código fuente. A partir de ahí, como siempre en estos casos, entra la malicia de cada uno.

La gente de PHP ha solucionado este bug con solera en las recientes actualizaciones 5.3.12 y 5.4.2 pero como reconocen que esto del mod_cgi es una cosa bastante pasada de moda y que es posible que la mayoría de las instalaciones afectadas sean tan vetustas que no merecen mucho la pena actualizar a unas versiones de PHP tan avanzadas, ofrecen una solución añadiendo un par de líneas similares a estas en la configuración de tu servidor:

RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC] RewriteRule ^(.*) $1? [L]

Vía | PHP.net
Imagen | Fotograma de la película ‘Bichos’ de Pixar
En Genbeta Dev | PHP 5.4 a fondo