Archive for the 'Programación' Category

LISP II, El retorno del Rey

Lunes, Mayo 19th, 2008

Después de casi 1 año… vuelve LISP a nuestras pantallas.

Cosas que he descubierto:

  • Tiene su punto… sobretodo para cuando salte a C#3.0
  • No he encontrado un compilador para windows mejor que el WinLisp (Apteryx Lisp)
  • Apteryx significa KIWI

  • El Apteryx Lisp al ser una versión 1994 en vez CTRL+C y CTRL+V tiene otros atajos de teclado distintos (CTRL+INS e INS)
  • En Autocad parece que se usa bastante… pobres.
  • Aquí dejo parte de mi flamante práctica
(DEFUN PartidosGanados (LIGAAUX equipo ContadorVictorias)
(cond
((null LIGAAUX) ContadorVictorias)
(t
(cond
((equal ‘GANA (if (equal (cadaar LIGAAUX) equipo) (GanadorPartido (car LIGAAUX) equipo))) (PartidosGanados (cdr LIGAAUX) equipo (+ 1 ContadorVictorias)))
(t (PartidosGanados (cdr LIGAAUX) equipo ContadorVictorias))
)
)
)
)

Si alguien conoce algún compilador de LISP para windows mejor que el Apteryx LISP (nada de los basados en EMACS que personalmente me aberran) por favor que lo comente…

Open Solaris vs Linux… Democracia vs BDFL?

Jueves, Marzo 27th, 2008

El otro dia tomando unas cañas con Futur3 acabamos hablando de un tema interesante.
Cómo gestionar un proyecto de software libre? Es algo que parece trivial pero si piensas en ello es muy parecido a la política.


La guerra de siempre fue entre Windows, Linux y MAC. Pero ultimamente hay más sistemas operativos en el campo de batalla…

Todo vino por el “pique” que tiene Linus Torvalds con Open Solaris y por la entrevista a Alvaro Lopez Ortega, creador del Servidor Web Cherokee que hicieron en El Geek Errante, en la que le preguntaron por su opinión al respecto.

Según dijo Linus:
It’s generally hard to build a community around a commercial entity that also wants to be in control because everybody else around that commercial entity will always feel like they’re at the mercy of Sun. And I’m not even going to go into Open Solaris because, quite frankly, I don’t even care.”

O más escueto:
Open Solaris is a joke“.

Parece que a Linus y a la Linux Foundation no le ha sentado muy bien la aparición de Open Solaris. Por un lado es comprensible ya que una gran empresa está detrás… creen que es más parecido a una catedral que a un bazar.

Por otro lado que Solaris sea libre es algo bueno aunque sea competencia directa de Linux. Cuanta más competencia mejor.

Lo que está claro es que la guerra Linux-Windows en servidores tiene un nuevo competidor: Open Solaris.

Futur3 defendía que Open Solaris es un proyecto donde los líderes se eligen democráticamente mientras que Linux tiene un dictador (Linus Torvalds) que cada vez está más alejado del código.
Así que acabamos hablando como gestionar un proyecto de software libre.

¿Cómo gestionar un proyecto de software libre?

- Aproximación tipo Linux (Dictador Benevolente de por vida BDFL)
Si un proyecto comienza desde cero lo normal es que comience como una dictadura donde el desarrollador principal valide y decida el código fuente que se sube al proyecto. Esta es la historia de Linux y de otros muchos , que comenzó el proyecto desde cero con Linus Torvalds como dictador benevolente.
Cuando el dictador es bueno (recomiendo leer sobre Cincinato ) el sistema funciona. Pero si se aleja de todo o si la gente empieza a no estar a gusto con su forma de decidir pueden surgir problemas. Por ejemplo Linus marginó ReiserFs en favor de ext3.

Aún así siempre se puede hacer un fork del proyecto. En el Kernel del Linux han habido forks de Alan Cox que no han durado demasiadas versiones. De hecho cuando hablamos de Linux en este post hablamos del Kernel del Linux… porque en distribuciones los forks han sido permanentes con las ventajas e inconvenientes de las múltiples distribuciones existentes.

La idea de Dictador Benevolente de por vida está asociada a Guido van Rossum, creador de Python ( y actual jefe de desarrollo de Google.. por cierto en Google le dejan el 50% del tiempo para mantener Python ), aunque hay muchos más como Larry Wall (Perl) y Linus Torvalds (Linux).

- Aproximación tipo Open Solaris (Elecciones):
Open Solaris en cambio es distinto. El código fuente existía ya en estado muy avanzado. Los líderes del proyecto son elegidos democráticamente por una votación entre los miembros de la comunidad. Esto tiene sus ventajas (si el BDFL deja de tener razón se le puede cambiar) pero también sus inconvenientes (quien tiene derecho a votar? bajo que criterio? quien puede ser elegido? Y si alguien gana por su popularidad pese a ser técnicamente malo?)

Al ser código libre comparte la ventaja de que siempre que alguien quiera puede hacer un fork del proyecto.

Preguntas:
- Cual es el mejor método de gestionar un proyecto libre grande?
- Y tu propio proyecto personal según crece?
- Está Linus perdiendo el norte? Está Linux perdiendo la batalla?
- Acabarán ciertas bases del GNU/Unix (Perl, Linux, Apache, Sendmail) muriendo en favor de otros proyectos(Pythom/Ruby, Open Solaris, Cherokee, Qmail)?


(Pulsa para ampliar)

Los 30 errores mas comunes del desarrollo de Software

Martes, Marzo 18th, 2008

Anoche navegando di con un artículo en un blog llamado Real Software Develpment sobre desarrollo de software sobre desarrollo de software muy interesante. Está escrito por un tal Miguel Angel Carrasco, otro Dilbert más, que empezó programando en papel hasta que su tio le compró un Commodore 64:

Los 30 errores mas comunes del desarrollo de Software (Inglés)

El blog está bastante bien, digno de leer a menudo. Aquí tenéis traducido el artículo:
—-
Miguel Carrasco
He estado desarrollando software y aplicaciones Web durante unos 11 años. El desarrollo de Software ha evolucionado mucho desde la época del Cobol. Lo que más me fascina es que se siguen cometiendo los mismos errores de antaño. Aquí están los 30 errores más comunes que se cometen en el desarrollo de Software. Es sorprendente comprobar como ninguno de estos errores tiene que ver con el lenguaje de programación elegido:

1- No comprender las necesidades del usuario. Falta de información de las necesidades del usuario. A veces incluso ni se le pregunta.

2- Subestimar el tamaño del proyecto

3- Acelerar la fase de planificación y análisis o incluso evitarla completamente. Primero programar y luego planificar! MAL!

4- No probar suficientemente el código o incluso no probarlo en absoluto.

5- Elegir una metodología “chula” en vez de una que ha funcionado en el pasado. Algo que lleva al punto 6:

6- No usar ningún tipo de metodología

7- Dejar que un programador lleve la dirección del proyecto.

8- Un equipo de desarrollo aburrido sin motivación. Hay que motivar a los desarrolladores. Si no eres capaz ni intentes liderar un equipo. Tu equipo se aburrirá y se quedará dormido (literalmente)

9- La planificación ya la haremos más tarde. No lo hagas! Ni pienses en ello!

10- Sin gestión de código de código fuente. Terrible. Y no… con instalar el software de gestión de código fuente no basta.

11- Decidir cambiar las herramientas de desarrollo mientras estás a mitad del proyecto.

12- Permitir que se incrementen los requisitos. Simplemente di NO. Todo el mundo será más feliz al final.

13- Omitir tareas necesarias para acortar el plan de proyecto. Qué sentido tiene esto?

14- Insuficientes controles de gestión en el desarrollo del proyecto.

15- Falta de apoyo por parte de la dirección de la empresa

16- Añadir gente al final del proyecto para “acelerar” las cosas. Lo único que harás es endentecerlas.

17- No hacer pruebas unitarias. Demonios, si no puedes usa el Visual Studio Team Foundation Server y configura algunas pruebas unitarias para que se hagan automáticamente cada noche.

18- Programadores bajo gran presión. Si te las has apañado para cometer uno o dos estos errores de gestión tendrás un montón de programadores estresados que gestionar.

19- Falta de control de errores/bugs.

20- “Off by one” errors. These happen a lot during the software development process.. *sigh*.

21- Tipos! Usa la opción de tipados fuertes de tu lenguaje. Durante un proyecto en el que trabajé se obtenían cientos de errores por todos lados. Resultó que el programador no escribía correctamente los tipos. No es un problema… a no ser que tengas desactivado el tipado fuerte (Option Strict & Option Explicit)

22- No comprender el proceso de despliegue o el hardware sobre el que se instalará lo que estás desarrollando. Ohhh, es un MAC? Espero que se pueda instalar…

23- No usar una guía de estilo de programación. Honestamente no importa mucho que estilo uses… siempre que sea el mismo que tus compañeros.

24- Usar variables globales por todos los lados. Las variables globales NO son tus amigas y consumen memoria como no te imaginas.

25- No pedir ayudar durante el desarrollo. Si estás atascado pide ayuda en vez de luchar días contra un problema.

26- No comentar tu código.

27- Quedarte con toda la información tu mismo. Piensas que eres más valioso de esta manera? Realmente no.

28- Ejecutar operaciones de acceso a la base de datos fuera de la capa de acceso a datos.

29- No validar los datos. La información que te den jamás será perfecta.

30- No hacer pruebas de carga. Cómo? Se supone que mi software funcionará con 1000 usuarios simultáneos bajo Citrix?

Desarrollar software es muy complicado. Hazlo más sencillo evitando cometer estos errores. Es una lista muy fácil de cosas que NO hacer que harán tu vida más sencilla.

Que hacian Ken Thompson y Rob Pike en la merienda de un dia 2 de Septiembre del 1992

Viernes, Marzo 7th, 2008

Ken Thompson y Rob Pike son dos geeks…

Aquí tenéis a Ken Thompson (El de la izda, el de la derecha es Dennis Ritchie) con una perilla estilo la que gastaba Futur3:

Y este es Rob Pike:

Parece que el 2 de Septiembre de 1992 (Miércoles) quedaron a merendar… y parece que se aburrían un poco y tuvieron una charla Geek…

Os cuento… buscando movidas de XML, UTF, etc… he llegado a esta artículo de la Wikipedia: http://es.wikipedia.org/wiki/UTF-8. Atentos al texto:

UTF-8 fue inventado por Ken Thompson el 2 de septiembre de 1992 en un mantel de un merendero de New Jersey con Rob Pike. Al día siguiente, Pike y Thompson lo implementaron e implantaron en su sistema operativo Plan 9.
UTF-8 fue oficialmente presentado en la conferencia USENIX en San Diego en Enero de 1993.

Será cierto? Pues parece que si. Si leemos este correo de Rob Pike que cuenta la historia, sus palabras son:

We suggested this and the deal was, if we could do it fast, OK. So we went to dinner, Ken figured out the bit-packing, and when we came back to the lab after dinner we called the X/Open guys and explained our scheme.

Lo hicieron durante la cena y seguro que lo hicieron en una servilleta ;-)

Por cierto, si os fijáis en el From…
From: “Rob ‘Commander’ Pike” (at) google.com>

Rob Pike trabaja en Google y parece feliz. Ken Thompson también…

Almacenamiento en Java

Martes, Febrero 12th, 2008

Registros:

  • Es el tipo de almacenamiento más rápido
  • Los registros están dentro del procesador
  • Están muy limitados (son pocos)
  • En java no se pueden usar
  • En c y c++ se permite al desarrollador sugerir usar un registro
  • Memoria Stack:

  • El Stack está en la RAM
  • Tiene soporte directo del procesador mediante el puntero a la stack (stack pointer)
  • El puntero a la stack se avanza para reservar nueva memoria y se retrocede para liberar esta memoria
  • Extremadamente rápida (una instrucción en ensamblador para mover el puntero)
  • Un sistema Java ha de saber en tiempo de compilación la vida y tamaño de todas las variables guardadas en la stack. En particular las referencias a objetos. Los objetos en si no se almacenan en la stack.
  • Las variables de tipo primitivo (int, char..) se alojan en la stack
  • Las referencias a objetos se almacenan en la stack
  • Memoria Heap:

  • La heap está en la RAM
  • Los objetos Java se alojan en la memoria Heap
  • Al contrario que la Stack, el compilador no necesita conocer por cuanto tiempo van a alojarse estos objetos en la Heap.
  • La Heap se usa para crear objetos de forma dinámica en tiempo de ejecución.
  • “new” reserva espacio en la heap para almacenar el objeto creado.
  • La heap es mas lenta para reservar y liberar espacio que la stack
  • en c++ puedes crear objetos en la stack. En java no.
  • Almacenamiento de valores tipo Constant:

  • Los valores tipo Constant (variables cuyo contenido nunca cambia) se almacenan directamente en espacio de memoria de código. No hay problema con esto ya que no varían.
  • Almacenamiento fuera de RAM:
    Si los datos viven fuera de un programa, pueden existir mientras el programa no está corriendo, dos tipos principales:
    Objetos Streamed: Objetos transformados en streams (chorros) de bytes, generalmente para ser enviados a otra máquina.
    Objetos persistentes:Objetos almacenados en disco para almacenar su estado incluso si el proceso es finalizado.

  • Java provee de soporte para persistencia ligera (lightweight persistence), JDBC e Hibernate para almacenar y recuperar información de objetos en bases de datos.
  • Code Review :-)

    Martes, Febrero 12th, 2008

    Anti Patrón Gran Bola de Lodo

    Miércoles, Enero 23rd, 2008

    Si habéis leido/trabajado con patrones Gof, Patrones GRASP, etc… igual habéis leido en algún momento algo sobre antipatrones.
    Algunos antipatrones son extremadamente divertidos.
    - Si estáis aburridos leeros unos cuantos antipatrones de la wikipedia e imaginad la vida del pobre programador que está detrás de todo.
    - O contad cuantos de esos véis a vuestro alrededor (no tan divertido). El de la bola de mierda lodo es el que más me gusta:

    Anti Patrón Gran Bola de Lodo:
    En programación, gran bola de lodo es un término aplicable a un sistema de ordenador sin una arquitectura realmente discernible. Normalmente involucra más de algún otro antipatrón.

    O mejor dicho:
    Una Gran bola de lodo es una selva de código enrevesado, chapucero, caóticamente estructurado, que crece descontroladamente, que se mantiene como unido a base de cuerda y cinta aislante.

    O todavía mejor explicado en este enlace:
    http://www.alfredodehoces.com/press/microfabula, sacado del maravilloso pero lamentablemente poco actualizado de Fuckowski…

    Por cierto recomiendo la lectura de su libro en PDF. Tb es un estupendo regalo geek…

    Estimar un proyecto

    Miércoles, Diciembre 19th, 2007

    Como estimar un proyecto, a cada respuesta del consultor se le puede añadir un or die “A ver que como el mes que viene, creo que en Huesca cuidando cabras se vive de puta madre..”
    dilbert
    Cliente: ” Necesito un tropicontero”
    Consultor geek: “Ningun problema, somos expertos en IT, asi que si alguien sabe hacer tropiconteros nosotros tambien (por que si no a ver que comemos el mes que viene)”
    Cliente: “Cuanto me va a costar el tropicontero?”
    Consultor geek: “jajaja, esto va uno que diceeee, wass wass, mira el pajarito!, oye, cuanto presupuesto te quieres gastar?”
    Cliente: 10.000
    Consultor geek: 10.000
    Cliente:”Y cuanto vais a tardar en tenerme el tropicontero listo?”
    Consultor geek: un año
    Cliente: “lo necesito para dentro de un mes”
    Consultor geek: un mes
    Cliente: “Perfecto, pues cuando me pases la propuesta-contrato en la que especifiques lo que vais a hacer la firmo y empezamos”
    Consultor geek: “Pero es que no puedo saber a priori lo suficiente del proyecto para hacer una propuesta-contrato que no sea totalmente al azar!”
    Cliente:”pues todas esas otras empresas lo hacen, y estan deseosas de trabajar para mi”
    Consultor geek:” Ningun problema, la semana que viene te la traigo y la firmas, por cierto, aqui tienes la pda esa de la que hablamos y con la propuesta te traigo una cesta de navidad”
    Cliente:”Trato hecho!”
    Consultor geek:” Trato hecho!”

    (Al final el tropicóntero resultó ser del tipo wafensneider, un tipo especialmente complejo de tropicónteros, con lo que el equipo de desarrollo se las vió y se las deseó para que el proyecto funcionara, dependiendo el 90% del desarrollo de un consultor del tipo “Michael Jordan”, que acabó quemándose y dejando la empresa. El proyecto se entregó con retraso y costó más de lo que se había estimado al principio y falla con determinados inputs, pero el cliente está contento, ya que aquello funciona mas o menos, y cuando falla, tienen un equipo de soporte que hace a mano lo que falta)

    Developers (El Geek Errante)

    Lunes, Diciembre 3rd, 2007

    Escuchando el podcast del El Geek Errante (que por cierto os recomiendo) me ha dado por buscar el vídeo original de Developers en el que se basa la introducción de la sección de Desarrollo de El Geek Errante. Es viejo pero digno de verse:

    Y aquí tenéis un vídeo musical muy divertido con Steve Ballmer como estrella:

    A N D R O I D

    Martes, Noviembre 13th, 2007

    Por fín ya sabemos algo más sobre los rumores del “Google Phone”. Finalmente sacarán un móvil o se conforma con ANDROID?

    ANDROID

    ANDROID es la primera plataforma completa, abierta y libre para dispositivos móviles. Consiste en un sistema operativo basado en el Kernel de Linux y cuenta con una máquina virtual de Java.

    Junto a ANDROID, también se presenta la ‘Open Handset Alliance’, un grupo de más de 30 firmas que se unen para impulsar Android. En esta alizanza se encuentran empresas como T-Mobile, HTC, Qualcomm, Motorola, Telefónica de España, China Mobile, Texas Instruments, eBay, Sprint Nextel o Samsung.

    Lo mejor de todo es que Google acaba de presentar el SDK de Android y ha ofrecido 10 millones de dólares en premios en su concurso de aplicaciones para Android.

    Os dejo el típico ejemplito desarrollado en Eclipse y un vídeo de presentación:

    android.jpg