10 proverbios para programadores.

Keving Pang comenta 10 proverbios que todo programador debería conocer. Aquí la lista y una línea sobre cada uno, como para tentarlos a que lean el post completo, que es excelente.

1. There is no smoke without fire: nos recuerda que problemas tales como código duplicado o complejo son señales de fallas de diseño subyacentes.

2. An ounce of prevention is worth a pound of cure: nos alienta a buscar y prevenir problemas a futuro.

3. Don't put all your eggs in one basket: se refiere a la creación de “dominios de experticia”, porciones claves de un sistema sobre las que un (y sólo un) integrante del equipo tiene suficiente conocimiento como para mantenerlas, convirtiéndolo en la canasta que sostiene a todo el proyecto…

4. As you sow, so shall you reap: “Cosecharás tu siembra”, diríamos por aquí. Si sembramos buen código cosecharemos buen código, y si sembramos código pobre…

5. Great haste makes great waste: grandes pérdidas de tiempo suelen tener origen en el apuro por terminar lo antes posible.

6. Look before you leap: la exageración de los principios ágiles puede llevarnos a saltar al vacío, comenzar sin tener una idea clara de los objetivos (para comenzar no es necesario un objetivo preciso, pero sí uno claro).

7. When the only tool you have is a hammer, everything looks like a nail: es tentador apegarse a lo que uno conoce, pero es mejor elegir y aprender las herramientas apropiadas para cada situación.

8. Silence is construed as approval: si vemos problemas en el código o en el diseño de nuestros compañeros de equipo y no decimos nada lo estamos aprobando.

9. A bird in the hand is worth two in the bush: donde se comenta el balance entre la refactorización y la entrega de valor.

10. With great power comes great responsibility: mucho del software que desarrollamos es vital para el desenvolvimiento de un negocio o para la vida cotidiana de muchos usuarios, y debemos sentir la responsabilidad derivada de ello. Los principios ágiles dan poder al equipo, y este poder tiene su precio.

El post completo, aquí.

Hitler de líder técnico.

“Si no hacés funcionar esa VM para mañana a las 12…

…vas a programar COBOL para bancos en Alaska”.

Visto en {codesqueeze}.

Cámara lenta a 1000fps.

Si les gusta éste no dejen de visitar la página de David Coiffier en vimeo.

I-Movix SprintCam v3 NAB 2009 showreel from David Coiffier on Vimeo.

Visto en FayerWayer.

Frases: Comentarios (en el código).

// sometimes I believe compiler ignores all my comments

Visto en Incognitosis… no se pierdan la fuente original: ¿Cuál es el mejor comentario en código fuente que has encontrado? en stackoverflow.

Jueguitos de viernes: Mk5

En MK5 representamos a una cruza entre robot y helicóptero que tiene por misión recoger… no sé, algo verde, con pinta de radioactivo. Los niveles están muy bien logrados, con elementos simples pero lo suficientemente abundantes como para hacernos la vida imposible.

Es  100% adictivo, tengan cuidado si es que tienen algo importante para esta tarde.

Jugando con PhotoFace.

PhotoFace es una aplicación online que nos permite subir una foto y juguetear un poco con ella, con varios efectos que nos permiten llevarla desde lo…

¿normal? Bueno, por lo menos para mí. Hasta…

“Hi, honey, I’m home”, o…

“¿Qué hice yo para recibir este código?”.

También podemos agregarle audio para enviárselo a alguien junto con la imagen. Es… extrañamente adictivo. Vale la pena pegarle un vistazo.

Visto en Código Geek.

Sistemas administrativos, software, avances, cambios, revoluciones.

 

Encontré la imagen que ilustra este post en Acceso Directo (que a su vez lo vio en Abadía Digital, que lo sacó de Digg… ¿es que nadie dice nada nuevo ya?). Viene muy a cuento de lo que estaba escribiendo, que es lo que sigue:

Es un camino posible para los proyectos de desarrollo de sistemas (de soporte a la gestión en las organizaciones) el que se inicia con trabajadores de las distintas áreas (futuros usuarios) comentando con un analista funcional el recorrido de la información en los diferentes procesos en que participan. Es un camino que continúa con el analista transformando esa información en especificaciones (tal vez haciendo algunas recomendaciones de cambio al cliente), alguien modelando una base de datos, programadores codificándolo en forma de formularios, validaciones, autorizaciones, un sinfín de ajustes, problemas menores y mayores, retrasos… Sigue luego de la instalación con caídas y recuperaciones varias, más ajustes y un final feliz para todos… algunas veces. Es el camino del desarrollo a medida.

En el otro extremo de un amplio espectro de relaciones posibles entre el cliente y el equipo de desarrollo, otro camino comienza más o menos igual, en esa famosa charla entre analista y usuario. Pero luego es el analista el que indica las adaptaciones al recorrido de la información necesarias para la implantación del software. Sigue con la capacitación a los usuarios, la implantación del software, migración de datos… y termina más o menos igual que el anterior, con caídas y recuperaciones varias, más ajustes y un final feliz para todos… algunas veces. Es el camino de la adopción de un sistema de software “enlatado” (ya sé, no es enlatado exactamente pero para el caso está bien, no seamos muy estrictos con los términos).

Esos son dos extremos, obviamente teóricos (o por lo menos muy poco frecuentes), de una escala absolutamente arbitraria creada al sólo efecto de poner en tema al lector de este artículo.

Lo que ubica a todo desarrollo de la vida real en algún punto intermedio de esa escala es una negociación entre cliente y proveedor que tiene lugar en algún punto o a lo largo de todo el proceso previo al desarrollo propiamente dicho. En ella se establece en qué aspectos se adaptará el recorrido de la información en la organización a las necesidades específicas del proveedor del sistema y en qué otros aspectos se adaptará el proveedor del sistema a las necesidades o caprichos del cliente.

Lo que es seguro es que el resultado final -en términos de circuitos administrativos- no se apartará demasiado del original del cliente (en un extremo) o del implementado anterior y repetidamente por el proveedor (en el otro). Tampoco será sustancialmente diferente al que gente de sistemas como yo, analistas, programadores, administradores, contadores, ingenieros y demás profesionales hemos aprendido en la facultad o a través de la experiencia.

Finalmente, y para resumir, la organización termina haciendo más rápido (mucho más rápido) más o menos lo mismo de antes o pareciéndose (usualmente para mejor) a todas las demás en el mercado.

Con lo que volvemos a la imagen que ilustra todo esto. Hemos resuelto efectivamente el “problema”. Hemos reducido costos y personal, acelerado los procesos administrativos, optimizado tiempos y recursos… todo mejor y más rápido y sin embargo, por debajo de todo eso, persisten los mismos problemas que enfrenta la administración… porque nada ha cambiado realmente todavía.

Que no se entienda lo anterior como una queja, que no lo es. A lo que apunto es a esto: la tecnología ha revolucionado nuestra vida y sociedad en muchos aspectos. Hoy la mayoría de las organizaciones cosechan el fruto de esta revolución en forma de un aumento en la velocidad, alcance y menores costos de funcionamiento de sus circuitos administrativos. Este aumento no ha sido lineal sino exponencial, por lo que los cambios han sido profundos. Pero en este aspecto (el de los circuitos administrativos en las organizaciones) no podemos hablar de revolución, por lo dicho anteriormente: las organizaciones siguen funcionando más o menos como antes.

Creo que en el transcurso de nuestras vidas este “cambio” se transformará en una “revolución”. Comienzan a surgir nuevas formas de organización. Formas de organización que no “aprovechan”, sino que tienen origen en las posibilidades inherentes a la tecnología de la que disponemos ahora y de la que no disponíamos antes, marcando una diferencia cualitativa.

Proyectos de software colaborativos, Wikipedia y demás wikis de todo tipo, comunidades creadas alrededor y a través de determinados servicios o soportes como Facebook, Twitter, Digg… toda esa (aunque no solamente esa) cosa “2.0”.

Es un comienzo. En definitiva todos esos proyectos, empresas o comunidades/servicios que mencioné se apoyan o son en alguna medida organizaciones “comunes” con un lado “tradicional”. Pero creo que tienen el potencial de generar algo diferente. Diferente y seguramente también ajeno a ellos mismos. Algo revolucionario.

¿Nuevos recorridos para la información? ¿Ningún recorrido en absoluto, un especie de caos acotado y dirigido hacia determinado objetivo? ¿Organizaciones sin objetivos concretos propios? ¿Organizaciones con un objetivo amplio (beneficio económico, por ejemplo) y sin reglas formales establecidas? ¿Con wiki-reglas que pueden hacerse y deshacerse, que “todo el mundo puede editar”? ¿Que un sistema implementa automáticamente en forma de circuitos cambiantes? ¿Organizaciones que se generan espontáneamente y que desaparecen tan rápido como se crearon, también espontáneamente? Quién sabe.

5 temas vertiginosos para cuando las fechas apuran.

Estoy desmotivado para postear algo serio. Pensé “Voy a entretenerme con alguna pavada”, así que aquí voy.

Como muy acertadamente se apunta en Sinergia sin control (aquí a la izquierda el cuadrito de relevancia) el informático necesita algo que motive para ganarle al reloj.

5 temas 5 muy -pero muy- veloces. No necesariamente en el sentido estricto del término (para eso lo pongo a Tiago interpretando el Vuelo del Moscardón a 320bps y listo, no tiene mucha gracia).  Digamos vertiginosos, para ser exactos.

El primer puesto se lo lleva Picturing the Past, de Sonata Arctica. Lo descubrí recién anteayer buscando en Vattoz “algún tema para ver como suenan” y elijo justo éste. Uf. De yapa el increíble cover de Still Loving You (sí, aquella baladita de los Scorpions) al estilo Sonata Arctica.

El segundo es Tortuga Bay, de Running Wild. Un tema perfecto para cantar en el Scumm Bar con una jarra de grog en alto.

Lo que me lleva directamente al tercero, Victim of Fate, los primeros pasos de Helloween. Sale arando y llevándose todo por delante, sigue una pequeña pausa para recuperar el aliento y prepararse para lo que se viene, que es como la bajada de una montaña rusa hasta el final.

Sigue Aces High, de los mejores años de la Dama de Hierro. He aquí un buen ejemplo de que veloz y vertiginoso no es lo mismo.

Y una joyita reservada para el gran final: Mirror mirror, de Blind Guardian.

Acepto recomendaciones para agregar a la lista. Siempre siguiendo la línea, que no voy a poner a Britney al lado de esta gente (vaya a saber qué le harían).

9 reglas para una mejor orientación a objetos.

Sebastian Hermida comparte unos posters y y folletos con las “9 rules for a better object orientation” inspiradas en el libro ThoughtWorks Anthology (hizo también algunas viñetas, la primera de ellas aquí).

En el artículo “Object Calisthenics” Jeff Bay propone el ejercicio de elaborar un programa de 1000 líneas siguiendo estas reglas estrictamente (verán que son terriblemente restrictivas) con el objetivo de mejorar la orientación a objetos de nuestro código.

Primero lean, luego seguimos con mi propia verborragia.

1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.

2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.

3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.

4. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods, and thereby conceptually breaking encapsulation.

5. Don’t abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().

6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package. The 50 lines per class constraint is crucial. Not only does it force concision and keep classes focused, but it means most classes can fit on a single screen in any editor/IDE.

7. Don’t use any classes with more than two instance variables. This is perhaps the hardest constraint. Bay’s point is that with more than two instance variables, there is almost certainly a reason to subgroup some variables into a separate class.

8. Use first-class collections. In other words, any class that contains a collection should contain no other member variables. The idea is an extension of primitive obsession. If you need a class that’s a subsumes the collection, then write it that way.

9. Don’t use setters, getters, or properties. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim “tell, don’t ask.”

¡Ja! Dos preguntas: ¿Estas reglas llevan a una mejor orientación a objetos? ¿Qué opinan de seguir estas reglas a rajatabla en “la vida real”?

Yo creo que sí, que indudablemente llevan a una mejor orientación a objetos. En cuanto a la segunda pregunta, mi propia opinión se resume en aquel principio de diseño del BDFL Guido van Rossum:

“Lo pragmático gana a la pureza”.

Y que el ejercicio de aplicarlas estrictamente debería quedarse en eso: un ejercicio acotado a un sistema de más o menos 1000 líneas.

Si programar es como escribir, un sistema es como un libro: hay un argumento central con algunos pasajes magistrales, algunos secundarios que hacen a que la historia sea completa y coherente, y mucho relleno y lugares comunes que siempre –o casi siempre- tienen que estar. La proporción de unos sobre otros determinará la calidad del resultado final, que puede ir del folletín a la obra maestra.

Todo es cuestión de saber dónde y cuándo utilizarlas, porque conllevan cierto esfuerzo adicional. Aplicadas en las funcionalidades críticas del sistema (en aquellas más complejas o indefinidas que se llevarán el grueso de las horas de cambios y mantenimiento) supondrán un ahorro considerable y la diferencia entre el código que resiste las modificaciones (e incluso mejora con ellas) y el que cae sobre sí mismo como un castillo de naipes al viento, convirtiéndose en una masa desordenada de clases. Utilizadas obsesivamente a través de todo el sistema no es más que una pérdida de tiempo.

Las reglas son muy bonitas pero, como decimos a veces en el trabajo “hay que pensar, no queda otra”, todavía no encontramos el método que nos libre de eso… por suerte, porque ese día nos quedamos sin trabajo.

De todas maneras me llamó la atención el libro, habrá que conseguirlo.

La evolución de los videojuegos.

Impresiona un poco recordar cómo nos divertíamos hace 10 o 15 años (o un poco más) y seguir la línea de tiempo hasta los sofisticadísimos juegos de hoy en día.

Visto en MiBaToon.

Trabajos peligrosos.

¿O trabajadores inconscientes? De cualquier manera, la gente de estas fotos deben pensar que desarrollando software la tenemos muy fácil, nuestro mayor riesgo laboral es que nos mate algún cliente insatisfecho (o que se popularicen herramientas como ésta).

El resto en Jimmy Ruska's Blog (visto en ApuntesGestion.com).

Las reglas de HP en la época del garage.

Sebastian Hermida's Blog hace referencia a una entrada de Binstock On Software en la que el autor menciona un póster de hp que recuerda las reglas vigentes en aquel viejo garage:

Las reglas son:

• Believe you can change the world.
• Work quickly, keep the tools unlocked, work whenever.
• Know when to work alone and when to work together.
• Share tools, ideas. Trust your colleagues.
• No Politics. No bureaucracy. (These are ridiculous in a garage).
• The customer defines a job well done.
• Radical ideas are not bad ideas.
• Invent different ways of working.
• Make a contribution every day. If it doesn’t contribute, it doesn’t leave the garage.
• Believe that together we can do anything.
• Invent.

Seguramente compañías con frases más bonitas y motivadoras han quedado en el olvido… en fin, la historia la escriben los que quedan, inevitablemente.

Buscando la imagen pasé por la sección del sitio de la compañía donde se repasa su historia y que es bastante entretenida, muy recomendable. Tiene una bonita línea de tiempo e incluso el primer capítulo de un documental (del que se puede solicitar una copia en dvd –¿llegará?-).

Jueguitos de… miércoles: Damn Birds.

Esta semana adelantamos, dudo que mucha gente trabaje el viernes así que habrá poca productividad a la que atacar.

Damn Birds es uno de los juegos más simples y adictivos con los que me he cruzado (justo para mí, que odio a las malditas palomas, son poco menos que ratas con alas). Interpretamos a una estatua que ha decidido responder los constantes coproataques de estos bichos del demonio… a balazos.

No sólo tendremos que tener buena puntería sino afinar la estrategia de inversión al intercambiar puntos por municiones, nuevas armas, protección o servicios de limpieza de cara a los próximos niveles.

Desarrollo de Carrera Laboral.

Un buen resumen de los conceptos básicos del desarrollo de carrera, visto en Mi Carrera Laboral en Informática & Tecnología.

Desarrollo De Carrera Laboral

View more presentations from Juan carlos Fernandez.

Entre la formación y la realidad.

Creo que hay una gran brecha entre la orientación que brindan las distintas carreras de sistemas y la realidad del mercado del desarrollo de software, por lo menos aquí en Buenos Aires y con respecto a la UBA (la Universidad de Buenos Aires, que es la universidad pública, gratuita y –por lo menos para las carreras que nos ocupan- de acceso irrestricto).

IMHO, por un lado el mercado requiere programadores para satisfacer una demanda creciente (incluso en estos tiempos de crisis) de desarrollo, mantenimiento (sobre todo), adaptación o implantación de sistemas de gestión de la información. Sistemas de pago, de facturación, de cuentas corrientes, de control de la producción, etc., y cada vez más orientados a negocios o rubros específicos (panadería, gestión de un taller mecánico, de una tienda de ropa), donde pequeñas empresas o equipos de desarrollo y profesionales independientes encuentran un nicho al que no pueden llegar los sistemas más conocidos como SAP o Tango (supongo que sólo tiene vuelo local, pero es muy conocido aquí).

Desde el punto de vista de la programación o codificación estos sistemas no son muy complejos… de hecho no son complejos en lo absoluto. Como se mencionaba hace algún tiempo en ¿Aburrido?, básicamente existe una base de datos que representa objetos y transacciones de la vida real, un software que materializa en múltiples pantallas de ingreso las reglas que indican cómo y cuándo esa información puede ser actualizada y un montón de reportes a través de los cuales es distribuida a través de la empresa o, hablando más en general, la organización.

Cada sistema tendrá algunas funcionalidades únicas (si no es así probablemente esté condenado al fracaso) o problemas particulares que representarán un verdadero desafío, pero no suelen representar más que un pequeño porcentaje de la funcionalidad total, y muchas veces son extras más orientados a diferenciarlo en la venta que al uso real y cotidiano.

El éxito o fracaso de un proyecto dependerá, más que de la pericia o ingenio de los programadores para crear algoritmos complejos que resuelvan problemas complejos, del conocimiento que posean, tanto éstos como los analistas y líderes del proyecto, del negocio que están modelando.

Este conocimiento tiene más que ver con facturas, recibos, remitos, balances, arqueos, tickets, inventario, impuestos, control de costos y esas cosas que con optimización, índices, grafos, métodos de ordenamiento, operaciones por ciclo de máquina, lenguajes, compiladores.

Eso por el lado del mercado.

El problema es que, del lado de la formación, las carreras de sistemas con contenido de programación poco y nada tienen que ver con el mundo de los negocios, y viceversa. Esa fue siempre mi sensación. Para este artículo estuve haciendo un poco de investigación tratando de verificarla o refutarla.

De las carreras de grado de la UBA, las que tienen algo que ver con sistemas son:

• De la Facultad de Ingeniería, la Licenciatura en Análisis de Sistemas y la carrera de Ingeniería en Informática. Esta última cuenta con tres orientaciones: en Gestión Industrial de Sistemas, en Sistemas Distribuidos y en Sistemas de Producción.

• De la Facultad de Ciencias Exactas, la Licenciatura en Ciencias de la Computación.

• De la Facultad de Ciencias Económicas, la Licenciatura en Sistemas de Información de las Organizaciones.

Más o menos a ojo (espero no haber pifiado mucho, si alguno de ustedes es o fue alumno de esas carreras me gustaría conocer su opinión al respecto), por los nombres de las materias, se deduce que:

• Para Análisis de Sistemas (Fc. de Ingeniería, 1739 alumnos) el 27% de las materias están orientadas a la programación propiamente dicha, y sólo el 7% tiene que algo que ver con lo administrativo, lo contable o la gestión de una organización.

• En Ingeniería en informática (Fc. de Ingeniería, 3194 alumnos), la programación ocupa entre el 26 y el 33%, contra un 4%, 2% y 15%, con la salvedad de que éste último porcentaje corresponde a la Orientación en Sistemas de Producción, por lo que imagino que estará enfocado a esa área.

• En la Licenciatura en Ciencias de la Computación (Fc. de Cs. Exactas, 1573 alumnos), los porcentajes son 38% contra… 0%. 38% para el lado de la programación, por supuesto. Debe ser duro para un egresado de esta carrera enfrentarse a un ERP o a un CRM armado sólo con lo que la universidad le ha enseñado.

• En la Licenciatura en Sistemas de Información de las Organizaciones (Fc. de Cs. Económicas, 1566 alumnos) nos encontramos que el estudio acerca del funcionamiento de la organización ocupa el 29% de la carrera (menos mal, ya que es de la Facultad de Ciencias Económicas), pero la programación sólo un 12%.

Pueden consultar la lista de materias (fuente oficial aquí, siguiendo el vínculo de cada carrera), cuáles conté para uno y otro lado y cuáles dejé afuera, aquí. La cantidad de alumnos proviene, desgraciadamente, del Censo de Estudiantes 2004, que es el último disponible (ese vicio tan habitual en la cosa pública Argentina, de ir a ciegas por la vida).

Es obligatorio aclarar que esto no dice nada acerca de la competencia de los profesionales que egresan de esas facultades (habrán buenos y malos en todos los casos). La experiencia aporta el resto y si hay algo que hace (en mi opinión) a la UBA una de las mejores universidades (seguro que de Argentina y puede que de Latinoamérica) es que sus alumnos salen con una innegable capacidad de seguir aprendiendo y enfrentarse a nuevos problemas, gracias también a que el resto de la plantilla brinda un conjunto de herramientas teóricas de carácter general que el profesional puede adaptar a su situación específica. Finalmente unos tendrán que aprender qué es eso de la partida doble y otros qué es una lista doblemente enlazada, si es que lo necesitan.

Se me dirá que se requiere de profesionales de más de una de esas carreras para completar un equipo. Cierto. En los papeles. Es verdad que en un proyecto mediano o grande habrán analistas (probablemente egresados de económicas) que interpreten el negocio y lo transmitan a los programadores.

Pero yo veo eso no como una característica inherente a los equipos de desarrollo sino como un problema (tal vez generado por la segmentación de las unidades de formación, las universidades) que afecta directamente al mercado de software “de gestión”.

Para un producto que pretenda concentrarse y especializarse en un nicho pequeño (lo que llamamos con cariño “el programita del verdulero”) un equipo de desarrollo compuesto por analistas y programadores es extremada e innecesariamente caro.

En general es un nicho cubierto por uno o dos profesionales que se ocupan de todo, incluso del management de su propio emprendimiento. Si son egresados de alguna de las carreras mencionadas deben superar un duro aprendizaje acerca de “la otra mitad” del negocio, para la que la carrera no los ha preparado.

Recordemos que en conjunto los sistemas de gestión representan la gran mayoría de sistemas existentes, los más cambiantes y dinámicos (tanto como los negocios que soportan), y por ello los que requieren más mano de obra en desarrollo y mantenimiento. Finalmente es donde van a trabajar la mayoría de los programadores, analistas, líderes de proyecto o profesionales independientes con cualquier orientación.

Pero lo que la universidad está produciendo es una mano de obra sobre calificada técnicamente (son los que o se aburren en el trabajo o resuelven los problemas más simples con los algoritmos más inútilmente complejos y eficientes, o no entienden los requerimientos) o en conocimiento del negocio (que producen ese software que resuelve exactamente lo que el usuario necesita pero que por dentro es un desastre y que finalmente se vuelve imposible de mantener o modificar).

Lo que sucede finalmente es que prima la realidad, la necesidad del mercado, y los profesionales se ven obligados a complementar su carrera con experiencia y cursos. En este contexto devalúa el título obtenido. Antes de llegar a ese punto (del que creo que hoy por hoy estamos lejos, pero acercándonos progresivamente) la UBA debería orientar alguna de esas carreras hacia un contenido más balanceado. Una carrera de la cual egrese un profesional que pueda programar algoritmos simples (validaciones, búsquedas, interacción con bases datos, cálculos, reportes) y que conozca el funcionamiento administrativo de las organizaciones (circuitos administrativos, documentos, conceptos contables básicos). Creo que la Licenciatura en Sistemas de Información de las Organizaciones es la que más se acerca, más que nada por el contexto que brinda la Fc. de Cs. Económicas, su proximidad con la carrera de Administración de Empresas y la de Contador.

Monkey Island: resumen animado.

Se me ha piantado un lagrimón con esto:

Visto en Gran Angular y compartido por Cerebrado.

Las cuatro etapas del programador.

1. El programador inconsciente de su incompetencia.
2. El programador consciente de su incompetencia.
3. El programador consciente de su competencia.
4. El programador inconsciente de su competencia.

O me quedé en la segunda o me salté la tercera. ¿Ustedes?

Visto en despuesdegoogle (donde hay un poco más para seguir el tema), vía Nicolás (que si quiere un link a algún lado no tiene más que reclamarlo).

Jueguitos de viernes x2: Rollercoaster Creator y Torus.

En Rollercoaster Creator tenemos que construir una montaña rusa de manera tal que se recolecten todas las monedas en la pantalla durante el recorrido. Hay puntos extra si a los visitantes del parque les gusta (será proporcional a qué tan cerca de la muerte los llevemos).

Los primeros 7 niveles son de aprendizaje y después se complica.

El bouns es Torus, un tetris circular programado como widget para Opera. Si tienen Windows 7 lo pueden jugar directamente sobre el escritorio y queda muy bien.

La verdad es que como juego no le aporta mucho al clásico de los clásicos, apenas un poco de complejidad extra. Pero está extremadamente bien hecho.