Café Instantáneo

Café Instantáneo es la idea de utilizar scripts bastante sencillos para generar código. Surge de una necesidad personal de aumentar la productividad en el desarrollo de un par de sistemas web con Java.

Es más fácil copiar y pegar código conocido que escribirlo.

Esta necesidad se me presentó hace relativamente poco tiempo, por lo que actualmente sólo he desarrollado unas pocas horas (para ser generoso) en esta dirección. Sólo hice este script Tcl/Tk de pocas líneas para generar fuentes a partir de plantillas.

Habrá más café instantáneo en algún futuro.

Cómo NO hacer programas

200610 - Antipatrones de Software

View more documents from Javier Gonzalez Sanchez.

El juego más difícil del mundo

Es impozible!!! Muy difícil!!!

Unix, el sistema operativo "hackeable"

Es indudable que Unix (en sus distintas implementaciones y clones) es el sistema operativo favorito de los hackers. Y cuando digo hackers no me refiero a los que se dedican a la seguridad informática, ya que esos son crackers, sino a los que estudian y practican la programación de computadoras por placer.

La principal razón de usar Unix es que este sistema operativo ofrece un ambiente muy propicio para la programación "casual".

A diferencia de otros sistemas, como MS windorch, Unix no establece una estricta barrera entre usuario y desarrollador. En windorch se da esta barrera porque el sistema no ofrece recursos para hacer programas o scripts ad hoc, como por ejemplo un buen interprete de comandos y un potente sistema de scripting. De hecho, windorch ni siquiera viene con un editor de texto decente en el que se pueda escribir una miserable línea de código.

La programación en windorch requiere de adquirir algún pesado y costoso entorno de desarrollo integrado, como .NET. Muy apto para uso profesional, pero muy poco adaptado para las necesidades del desarrollador casual.

Esta barrera molesta deja en claro que el sistema está pensado para que el usuario NO programe. Surge de una concepción de que el software es elaborado en un engorroso proyecto planificado y en un entorno más bien profesional, pero no a través de la escritura de pequeños programas o scripts por parte de los usuarios.

Algo muy distinto pasa en el mundo del Unix, donde el sistema sí viene con muchos recursos para programar modestas soluciones a medida. Se podría decir que Unix es un sistema "hackeable" ya que ofrece buenos editores de texto, con potentes interpretes de comandos y potentes sistemas de scripting. Sólo basta con abrir un archivo nuevo, y comenzar a escribir código y listo, ya estamos programando. En Unix casi que decir usuario es decir también programador.

El día internacional del software libre

Software Freedom Day (SFD) es una celebración anual del software libre. SFD busca no sólo celebrar las virtudes del software libre, sino que además promocionar su uso.

SFD fue creado en el 2004 y se celebró el 28 de Agosto. Desde entonces ha crecido en popularidad. En el 2008 más de 500 agrupaciones en 90 países lo festejaron.

Desde el 2006 se decidió que se realizara el tercer sábado de cada Septiembre: 15 de Septiembre del 2007, 20 de Septiembre del 2008, 19 de Septiembre del 2009, etc.

La velocidad mata

Fuente: Dos Ideas Escrito por Leonardo De Seta

Miércoles 16 de Septiembre de 2009 09:30

Sos un programador. Eso signifca que tenés una presión tremenda por trabajar rápido. Hay fechas que cumplir. Hay bugs que arreglar antes de la gran demo. Hay calendarios productivos a los que llegar. Y tu trabajo depende de cuán rápido vayas y qué tan confiable seas para cumplir las planificaciones. Y esto significa que tenés que tomar atajos, compromisos, ser rápido y desprolijo. Que estupidez. Si, me escucharon. ¡Que estupidez! No existe el "rápido y desprolijo" en el software. La desprolijidad significa lentitud. La desprolijdad es la muerte. El código malo hace que todos sean lentos. Vos lo sabes. Yo lo sé. Alguna vez, todos nos vimos retrasados por mal código. Nos volvimos lentos con mal código que escribimos hace un mes, hace dos semanas, incluso ayer. En el software hay una cosa seguro: si escribimos código malo, vamos a ir lento. Y si el código es muy malo, es probable que directamente nos detengamos. La única forma de ir rápido es trabajar bien. Y esto es simple sentido común. Podría citar frase tras frase al respecto. Cualquier cosa que vale la pena hacer, vale la pena hacerla bien. Un lugar para cada cosa, y cada cosa en su lugar. Lento y constante ganan la carrera. Y así, y así. Tenemos siglos de sabiduría que nos dicen que apurarse es mala idea. Y sin embargo, cuando la fecha se acerca... La habilidad de los profesionales es su capacidad para tener intención. Los profesionales no se apuran. Los profesionales comprenden el valor de la prolijidad y la disciplina. Los profesionales no escriben mal código - nunca. Equipo tras equipo caen en la tentación de apresurar las cosas en su código. Equipo tras equipo usaron largas horas de sobreesfuerzo en un intento de llegar con su producto al mercado. Y equipo tras equipo destruyeron los proyectos en el intento. Los equipos que empiezan a empiezan a apresurarse y hacer milagros, a menudo terminan arrastrándose en lentitud después de unos meses. Su código está tan mezclado, tan confuso, tan acoplado, que nadie puede hacer un cambio sin romper otro ocho módulos. Nadie puede tocar un módulo sin tener que tocar otros veinte. Y cada cambio introduce un nuevo efecto secundario impredecible, junto con más bugs. Las estimaciones se estiran de días a meses. El equipo se paraliza en una lentitud mortal. Los gerentes se vuelven locos, y los desarrolladores comienzan a buscar trabajos nuevos. ¿Y qué pueden hacer los líderes? Pueden gritar y gritar sobre que "hay que ir más rápido". Pueden apresurar más las fechas, para causar una sensación de urgencia. Pero al final, lo único que resulta es contratar más programadores. E incluso esto no funciona siempre, porque las nuevas personas van a terminar agregando más problemas por encima del problema viejo. En poco tiempo, el equipo volvió a estar lento, en una marcha continua e inexorable hacia la Productividad Cero. ¿Y quien es el responsable del desastre? Los programadores. Vos. Yo. Nos apresuramos. Hicimos lio. No mantuvimos la prolijidad. No actuamos profesionalmente. Si queremos ser profesionales, si amamos esta profesión, entonces no debemos apresurarnos. Debemos mantener prolijo al código. Tan prolijo que casi no necesite comentarios. Traducido de Speed kills, por Uncle Bob.

I wish I were the moon

Extraño juego creado por el innovador desarrollador argentino independiente Daniel Benmergui inspirado en el cuento "La distancia de la Luna" del escritor italiano (nacido en Cuba) Italo Calvino. Consiste en encontrar los posibles finales de un triángulo amoroso entre dos enamorados y la luna.

Lo sorprendente es el modo de juego, que imita tomar una "fotografía" con el mouse y arrastrarla para interactuar con los distintos elementos de la pantalla. Casi no se utiliza texto para comunicarse con el usuario, se trata de apelar a la intuición del jugador, lo cual ayuda a establecer un vínculo emocional.

Los gráficos "retro" pixelados de bajísima resolución son increíbles. Le dan una estética muy bella ante los nostálgicos que vivieron algo de la historia de los videojuegos. Por otro parte intentan apartarse del hiperrealismo que, posibilitado por los recursos tecnológicos, nos propone un gran grupo de desarrolladores en estos tiempos.

Además el juego le rinde culto a la sencillez. Probando una vez más que lo simple es mejor... Una verdadera obra de arte.

Puede jugar aquí.

Ejemplo de GUI Bizarra...

La siguiente captura de pantalla pertenece a un software de CMR bastante popular entre las compañías de telecomunicaciones. Pueden observar este cuadro de diálogo al finalizar el alta un cliente ADSL. Juro que no hay ningún tipo de edición sobre la imagen.




Podría argumentarse que esta interfaz no es bizarra, sólo estúpida... pero prefiero no hacer mucho ruido al respecto.

Sobre el IQ

Fuente: Steal This Software

Hace rato que tenia ganas de escribir sobre esto. Cuantas veces uno ha oído "tal persona tiene tanto de IQ" o "determinado personaje posee un coeficiente intelectual de X"
Ahora, alguna vez uno se planteó qué es un IQ??
Según wikipedia el IQ es un resultado de un test:

El cociente intelectual o coeficiente intelectual,[1] abreviado CI (en inglés IQ) es un número que resulta de la realización de un test estandarizado para medir las habilidades cognitivas de una persona, "inteligencia", en relación con su grupo de edad.

La primera vez que me enteré de la existencia de esto (tendría unos 15 años) me pareció interesante, anque simplista voy a reconocer. Simplista para ser algo que "define" la inteligencia. O sea, vendría a ser, X individuo hace un test que consiste en N numero de preguntas (de logica, reconocimiento de series, patrones) y dependendiendo de como le vaya, es cuan inteligente es esa persona. Muy chato para mi gusto. Sin envargo realicé varios tests por curiosidad. No recuerdo los resultados (seguramente me salió que estoy en la media) pero lo que si recuerdo es que, siendo distintos los tests, hacer el primero me fue mas dificil que el segundo. Esto es, el hacer el primero me "entrenó" de alguna forma. Hizo que hacer el segundo fuera más sencillo, además de que sabía que esperar (a pesar de que los tests no eran iguales) me había mostrado una forma encarar ciertos problemas. Entonces, hice algunos más y noté que era como si justamente fuera un entrenamiento, practicar el tipo de ejercicios hacía que los posteriores costaran un poco menos.

De todo esto se desprende mi conclusión. Los tests de IQ dan un número a la habilidad/experiencia de una persona para resolver un tipo de problema. La inteligencia no es algo "medible" y mucho menos por completar unas series de cuadraditos o de números. Estos tests sólo dividen, y estancan. Le dicen a alguien "vos sos la media" como que no hubiera más remedio.

No me hubiera atrevido a publicar esta entradad (hubiera considerado que estos son disparates míos) si no fuera por un comentario que leí en un libro de Paenza (de las serie "matematica, estás ahí?") donde él mismo opinaba algo similar a mi.

Frase del día

"Copiar de una fuente es plagiar, copiar de dos o más es investigar."

A Una Década Del Ultimo Sueño de Sega

El pasado miércoles no fue un día cualquiera para los aficionados a los consolas de videojuegos (en especial para los que llevan más de 20 años arrastrándose por este mundo). Concretamente, se cumplieron diez años desde aquél memorable 9/9/99, fecha elegida por la filial norteamericana de Sega para el lanzamiento de la esperada Dreamcast en occidente, la que sería luego conocida como la mejor y la última consola de videojuegos de dicha compañía.

Si tuvieron la suerte de poseer una de estas maravillas (o al menos de haberla probado en casa de algún amigo / enemigo algo más afortunado), saben de lo que estoy hablando. Juegos como Soul Calibur (considerado por muchos como el mejor juego de lucha de la historia), Sonic Adventure, Virtua Tennis, Shenmue (maravilla técnica si las hubo), Power Stone, Skies Of Arkadia y Dead Or Alive 2 representaban los desarrollos cumbre en juegos de aquél entonces.

Sega venía de tiempos muy complicados: el rotundo fracaso de la Saturn (consola de 32bit que compartió su generación con Playstation y N64) y del Sega32X (una suerte de "upgrade" para la megaexitosa Genesis/Mega Drive) dejaron en bastantes apuros económicos a la compañía nipona, que no podía darse el lujo de fracasar nuevamente. El proyecto que devolvería los laureles a Sega se conocería inicialmente como Katana, y mediante una acertada jugada se lanzaría casi un año antes que sus competidores (la Playstation 2 de Sony, la Nintendo GameCube y el Xbox de Microsoft).

Algunas de las características técnicas más destacables de la Dreamcast eran su procesador de video (PowerVR2 de Nec); los VMU (una suerte de memory card con esteroides); el modem de 56k integrado (esta consola prácticamente inventó el juego online para este tipo de plataformas); y la posibilidad de utilizar un cable D-Sub para conectarlo a un monitor VGA o HDTV (mejorando notablemente la calidad de imagen).

El sistema de almacenamiento era el bizarro "GD-ROM", de manofactura propietaria, capaz de almacenar hasta 1GB de información. Una decisión bastante desacertada, por cierto, motivada principalmente por un intento para evitar la piratería. Por supuesto, dicho propósito no fue conseguido: los siempre hábiles piratas lograron hacer "rippings" en CD-ROMs convencionales, con algunos trucos realtivamente sencillos como eliminación de videos y resampleo de audio. Un lectora de DVD externa fue anunciada, pero lamentablemente no llegó a dar a luz.

En fin, una máquina que en teoría lo tenía casi todo como para llevarse al mundo por delante. Y eso era lo que parecía ocurrir en principio: durante su lanzamiento, el producto se agotó rápidamente, y al poco tiempo Sega se vió en dificultades para poder cumplir con la alta demanda de Dreamcast que el mercado exigía. Los primeros juegos fueron de un éxito notable, y en general eran una mezcla de conceptos relativamente nuevos (como Sonic Adventure o Shenmue) con clásicos arcades de Sega (como Daytona Usa, Crazy Taxi y Virtua Fighter). Los títulos deportivos de la línea Sega Sports son particularmente recordados (entre ellos el mítico Virtua Tennis).

¿Que ocurrió luego? Bueno, eso es motivo de divergente discusión, pero en general se coincide en lo siguiente: Sega no pudo destinar el dinero suficiente que un buen plan de Marketing requería, ni logró convencer a la suficiente cantidad de desarrolladores terceros de que publicaran en su consola (es particularmente llamativo el caso de Electronics Arts, que abiertamente le dió la espalda a Dreamcast. Pueden leer más acerca de esto en la referencias). Como resultado, la casa del erizo azul ya no poseía la solvencia financiera para seguir fabricando Dreamcast y sostenerla en el mercado. La ventaja inicial que había logrado sacarle a sus competidores se había esfumado, y Playstation 2 (a la que Sony estaba promocionando sin reparar en gastos de ningún tipo) comenzaba a apoderarse del mercado.

Marzo del 2001 fue el final del camino. Sega decidió centrar su antención en el desarrollo de software, abandonando el hardware definitivamente. Durante algún tiempo más, no obstante, siguieron saliendo considerables juegos nuevos, totalizando una biblioteca de bastante maś de 600 títulos. Asimismo, creció el círculo de desarrollos "homebrew" alrededor de esta consola (incluso hubo una versión del sistema GNU/Linux Debian preparada para correr en Dreamcast).

Sintetizando, Dreamcast no logró devolverle a Sega el lugar que en el pasado había alcanzado con éxitos como el Master System y el Sega Genesis, pero indudablemente no puede considerársele un fracaso. Fue un rotundo suceso comercial que, aunque breve, batió varias marcas. Dreamcast innovó en varios aspectos (como el del juego online), y definió nuevos estándares de calidad para los desarrollos de las generaciones siguientes (Soul Calibur sigue viéndose maś que bien hoy día, incluso pese a sus años). Y principalmente, brindó muchas horas de sano entretenimiento a incontables usuarios. Entre ellos se encuentra quién escribe estas líneas, en un intento de brindarle un humilde homenaje a tan formidable pieza de hardware, de una época muy destacable dentro de la historia de los videojuegos.

Referencias

Entrada en Wikipedia
http://en.wikipedia.org/wiki/Dreamcast

Artículo conmemorativo en Gamasutra, con interesantes entrevistas a los involucrados en la producción de la consola
http://www.gamasutra.com/view/feature/4128/the_rise_and_fall_of_the_dreamcast.php?

No se recomienda borrar datos

Fuente: Dos Ideas

Escrito por Leonardo De Seta

Miércoles 09 de Septiembre de 2009 17:43

En las bases de datos, la eliminación lógica es aquella que ocurre al activar una marca de "eliminado" al registro, mientras que la eliminación física consiste en eliminar realmente el registro de la base. ¿Cuál estrategia es mejor? Quienes aplican el borrado lógica sugieren agregar una columna "eliminado" a la tabla, y dejar los datos intactos. Una fila se considera borrada si la columna "eliminado" contiene un "true". Este enfoque es simple, facil de entender, rápido para implemente y explicar, pero a menudo se implementa mal. El problema es que, en general, eliminar una fila o entidad no es un evento simple. No sólo afecta a los datos del modelo, sino también a la forma del modelo. Es por esto que existen las claves foráneas, para asegurarnos de no terminar con Items de Factura sin una Factura padre. Y este es el más sencillo de los ejemplos... Cuando hay que lidiar con las bajas lógicas, es facil terminar en situaciones de corrupción de datos. Por ejemplo, el campo "última órden" del Cliente (una optimización que nadie se acordó) podría terminar apuntando a una Orden con baja lógica. Entonces, si un desarrollador tiene que borrar un registro de la base, y las bajas lógicas parecen desrecomendadas, queda la opción de las bajas físicas. Para preservar la integridad de datos, deberemos eliminar la fila en cuestión y todas las filas relacionadas en cascada. Pero en el mundo real la cascada no es posible. Supongamos que el departamento de marketing decide eliminar un producto del catálogo. ¿Deberían desaparecer también todas las órdenes que contienen ese producto? Y si continuamos la cascada, ¿deberíamos borrar todas las peticiones para esas órdenes también? Y siguiendo, ¿deberíamos rearmar el resumen financiero de la empresa? Obviamente, no. El problema viene por la interpretación del "eliminar". En el ejemplo anterior, cuando marketing dice "eliminar", se refiere a discontinuar un producto. No queremos vender más este producto. Queremos quitarlo del inventario, y no hacer más pedidos a nuestro proveedor. El producto no debería aprecer más cuando nuestros clientes hacen una búsqueda en el sitio, pero la gente del almacen va a tener que seguir gestionando este producto en el interín. Por supuesto, es mucho más facil decir "eliminar el producto" que explicar todo esto. Entonces, tenemos varias interpretaciones del "eliminar" para los usuarios: Las órdenes de compra no se borran: se cancelan. De hecho, también podría haber cargos extra por cancelar una órden tarde. Los empleados no se borran: renuncian, se jubilan o se los despide. También es probable que haya que gestionar una compensación. Los puestos no se borran: se cubren (cuando entra un candidato). y así... En todos los casos, debemos enfocarnos en la tarea que el usuario desea realizar, en vez de en acciones técnicas sobre la base de datos. En vez de enfocarnos en una columna "eliminado", lo mejor es usar un campo que contenga el estado del dato: activo, discontinuado, cancelado, obsoleto, etc. Estos campos de estado le permiten al usuario mirar los datos históricos y tomar decisiones. La eliminacion física de datos puede tener consecuencias negativas más allá de romper la integridad. Tenemos que tener mucho cuidado cuando intentamos una eliminación física. Y como regla general, no borremos nada. Basado en Deleting data is not a recommended practice.

Programación Talabartera Volumen 1

Hoy: Cómo verificar que una variable sea un entero en BASH...

(tomado de por ahí)




1)

if [ $VARIABLE -eq $VARIABLE 2> /dev/null ]; then
 echo "integer"
else
 echo "not integer"
fi

2)

echo "${VAR}" | grep "[^0-9]" > /dev/null >&1
if [ "$?" -eq "0" ]; then
 echo string
else
 echo integer
fi

3)

if [ $VARIABLE -ge 0 2>/dev/null ]; then

4)

echo "${VAR}" | grep -v -- "^-\?[0-9]\+$" > /dev/null >&1
if [ "$?" -eq "0" ]; then
  echo string
else
  echo integer
fi

5)

if (($x)); then
 echo "true"
else
 echo "false"
fi

6)

if (($x)) 2>/dev/null; then
 echo "true"
else
 echo "false"
fi

7)

if echo $VAR | grep -Eq '^[+-]?[0-9]+$'
then
 echo integer
else
 echo non integer
fi

Recreo: el diccionario del Eclipse

Hoy...

más de cerca...

La felicidad del usuario según la funcionalidad del software

Anda dando vueltas por ahí...