sábado, 23 de diciembre de 2006

La Historia de las Consolas de Videojuegos


Este articulo de PC World es bastante nostalgico, completo y atrayente visualmente. Muestra la historia de las consolas de videogames (desde Pong, pasando por Atari 2600, NES, SuperNES, PSOne, etc... hasta llegar a XBOX 360, Wii y PS3).

Lo novedoso es que la historia es contada unicamente a traves de comerciales de TV de las respectivas epocas. Disfruten!

sábado, 18 de noviembre de 2006

Creating passionate Users


Este blog es excelente.... tanto conocimiento que no se encuentra facilmente acerca de como funcionamos como personas y como afecta esto lo que hacemos (vida familiar, profesional, academica, etc). Para muestra dos botoncitos:


miércoles, 15 de noviembre de 2006

Basecamp

Basecamp project management and collaboration

Estoy revisando esta herramienta de Gestión de Proyectos y Colaboración y me parece muy buena. Tiene un enfoque bastante ágil, intuitivo y sencillo pero a la vez poderoso. Ha sido desarrollada entre otras cosas con RubyOnRails y Ajax. Aunque no es Open Source, se puede probar gratuitamente y las tarifas que cobran son razonables incluso para proyectos pequeños.

Definitivamente, una alternativa válida para los que (como yo) desconfiamos y estamos hartos de Microsoft Project!

Hasta la gente Microsoft lo reconoce:

"Basecamp is the first product I have seen that is truly project management for everyone"
"I worked in the project management software industry for nearly fifteen years and Basecamp is the first product I have seen that is truly project management for everyone. It is nice to see someone finally figured it out."
-Jim Dunnigan, Former Product Manager Microsoft Project
Fuente: http://www.basecamphq.com/buzz

viernes, 27 de octubre de 2006

Joel on Software










Hace poco descubir esta pagina (blog?) y me parecio altamente recomendable para cualquiera que desee saber mas sobre la profesion de desarrollo de software (en un sentido amplio) desde el punto de vista de alguien con experiencia e historias que contar. El susodicho (Joel Spolsky) tiene años haciendo esto, incluso antes que los blogs fueran populares. Aqui una seleccion de sus cronicas, para que se entretengan y aprendan un poco:




Si les vacilo, una seleccion aun mayor ha sido publicada como libro. Esta barato, asi que pueden aprovechar.

Life at Google

Este post esta bastante interesante. El tio explica como es el ambiente y la filosofia de trabajo en Google. Aunque no estoy necesariamente de acuerdo con su vision sobre las metodologias agiles:

http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

miércoles, 26 de julio de 2006

Peopleware (Parte III)

Continuando con lo mejor de Peopleware (IMHO, por supuesto), aquí esta lo correspondiente a la tercera parte del libro. Si no lo han hecho, les recomiendo que primero revisen los posts anteriores:

PART III

Management science is much more concerned with the boss's role as principal strategist and tactician of the work. You are taught to think of management as playing out one of those battle simulation board games. There are no personalities or individual talents to be reckoned with in such a game; you succeed or fail based on your decisions of when and where to deploy your faceless resources.

  • get the right people
  • make them happy so they don't want to leave
  • turn them loose

Anything that upsets the weak manager is almost by definition unprofessional. So popcorn is unprofessional. Long hair is unprofessional if it grows out of a male head, but perfectly okay if it grows out of a female head. Posters of any kind are unprofessional. Comfortable shoes are unprofessional. Dancing around your desk when something good happens is unprofessional. Giggling and laughing is unprofessional. (It's all right to smile, but not too often.)

Conversely, professional means unsurprising. You will be considered professional to the extent you look, act, and think like everyone else, a perfect drone. Of course, this perverted sense of professionalism is pathological. In a healthier organizational culture, people are thought professional to the extent they are knowledgeable and competent.

Circus Manager: How long have you been juggling?

Candidate: Oh, about six years.

Manager: Can you handle three balls, four balls, and five balls?

Candidate: Yes, yes, and yes.

Manager: Do you work with flaming objects?

Candidate: Sure.

Manager: ... knives, axes, open cigar boxes, floppy hats?

Candidate: I can juggle anything.

Manager: Do you have a line of funny patter that goes with your juggling?

Candidate: It's hilarious.

Manager: Well, that sounds fine. I guess you're hired.

Candidate: Umm ... Don't you want to see me juggle?

Manager: Gee, I never thought of that.


Aptitude tests are almost always oriented toward the tasks the person will perform immediately after being hired. They test whether he or she is likely to be good at statistical analysis or programming or whatever it is that's required in the position. You can buy aptitude tests in virtually any technical area, and they all tend to have fairly respectable track records at predicting how well the new hire will perform. But so what? A successful new hire might do those tasks for a few years and then move on to be team leader or a product manager or a project head. That person might end up doing the tasks that the test measured for two years and then do other things for twenty.

The idea is simple enough. You ask a candidate to prepare a ten- or fifteen-minute presentation on some aspect of past work. It could be about a new technology and the experience with first trying it out, or about a management lesson learned the hard way, or about a particularly interesting project. The candidate chooses the subject. The date is set and you assemble a small audience made up of those who will be the new hire's co-workers.

Of course the candidate will be nervous, perhaps even reluctant to undertake such an experience. You'll have to explain that all candidates are nervous about the audition and give your reasons for holding one: to see the various candidates' communication skills, and to give the future co-workers a part in the hiring process. At the end of the audition and after the candidate has left, you hold a debriefing of those present. Each one gets to comment on the person's suitability for the job and whether he or she seems likely to fit well into the team. Although it's ultimately your responsibility to decide whether to hire or not, the feedback from future co-workers can be invaluable. Even more important, any new person hired is more likely to be accepted smoothly into the group, since the other group members have had a voice in choosing the candidate.

In companies with high turnover, people tend toward a destructively short-term viewpoint, because they know they just aren't going to be there very long. So if you find yourself campaigning for better workspace for your staff, for example, don't be surprised to bump into someone up the hierarchy who counters with an argument like this:

"Hold on there, Buster. You're talking about big bucks. If we gave our engineers that much space and noise protection and even privacy, we might end up spending fifty dollars per person per month! Multiply that times all the engineers and you're into the tens of thousands of dollars. We can't spend that kind of money. I'm as much in favor of productivity as the next guy, but have you seen what a terrible third quarter we're having?"

Many of us have come to believe that companies that promote early are where the action is. That's natural, because as young workers we're eager to get ahead. But from the corporate perspective, late promotion is a sign of health. In companies with low turnover, promotion into the first-level management position comes only after as much as ten years with the company. (This has long been true of some of the strongest organizations within IBM, for example.) The people at the lowest level have on the average at least five years' experience. The hierarchy is low and flat.

The insidious effect here is that turnover engenders turnover. People leave quickly, so there's no use spending money on training. Since the company has invested nothing in the individual, the individual thinks nothing of moving on. New people are not hired for their extraordinary qualities, since replacing extraordinary qualities is too difficult. The feeling that the company sees nothing extraordinary in the worker makes the worker feel unappreciated as an individual. Other people are leaving all the time, so there's something wrong with you if you're still here next year.

Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

lunes, 26 de junio de 2006

Peopleware (Parte II)

Continuando con mi humilde selección de lo más resaltante de Peopleware, aquí esta lo correspondiente a la segunda parte del libro. Revisen también el post anterior.

PART II

Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It's only when you're in flow that the work goes well.

Unfortunately, you can't turn on flow like a switch. It takes a slow descent into the subject, requiring fifteen minutes or more of concentration before the state is locked in. During this immersion period, you are particularly sensitive to noise and interruption. A disruptive environment can make it difficult or impossible to attain flow.

If the average incoming phone call takes five minutes and your reimmersion period is fifteen minutes, the total cost of that call inflow time (work time) lost is twenty minutes. A dozen phone calls use up half a day. A dozen other interruptions and the rest of the work day is gone. This is what guarantees, "You never get anything done around here between 9 and 5."

If you're a manager, you may be relatively unsympathetic to the frustrations of being in no-flow. After all, you do most of your own work in interrupt mode -that's management- but the people who work for you need to get into flow. Anything that keeps them from it will reduce their effectiveness and the satisfaction they take in their work. It will also increase the cost of getting the work done.

What matters is not the amount of time you're present, but the amount of time that you're -working at full potential. An hour in flow really accomplishes something, but ten six-minute work periods sandwiched between eleven interruptions won't accomplish anything.

Management, at its best, should make sure there is enough space, enough quiet, and enough ways to ensure privacy so that people can create their own sensible workspace. Uniformity has no place in this view. You have to grin and bear it when people put up odd pictures or leave their desks a mess or move the furniture around or merge their offices. When they've got it just the way they want it, they'll be able to put it out of their minds entirely and get on with the work.

We are trained to accept windowless office space as inevitable. The company would love for every one of us to have a window, we hear, but that just isn't realistic. Sure it is. There is a perfect proof that sufficient windows can be built into a space without excessive cost. The existence proof is the hotel, any hotel. You can't even imagine being shown a hotel room with no window. You wouldn't stand for it. (And this is for a space you're only going to sleep in.) So hotels are constructed with lots of windows.

Even if there is a higher cost per worker to house people in the more agreeable space, the added expense is likely to make good sense because of the savings it provides in other areas. The real problem is that the cost is in a highly visible category (space and services), while the offsetting advantage is in poorly measured and therefore invisible categories (increased productivity and reduced turnover).


Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

martes, 20 de junio de 2006

El auge y la caida de CORBA

Este artículo me parece interesante. Habla de por qué fracasó CORBA como tecnología distribuida. En resumen, según el autor, se debió a graves errores técnicos y políticos (OMG):

The Rise and Fall of CORBA

Como para que los profes de algunos cursos de mi alma mater le den una revisada... no?

martes, 13 de junio de 2006

Peopleware (Parte I)

Este libro es excelente en mi opinión, así que he decidido colocar los extractos que me parecen más resaltantes. Todo programador, desarrollador, líder técnico, funcional, arquitecto o jefe de proyecto debería leerlo. Mejor aún si lo compran. Aquí va lo más resaltante de la primera parte:

PART I

The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work.

The project that has to be done by an impossible fixed date is the very one that can't afford not to have frequent brainstorms and even a project dinner or some such affair to help the individual participants knit into an effective whole.

The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.

The Eagle project at Data General is a case in point. The project was a Spanish Theory triumph: Workaholic project members put in endless unpaid overtime hours to push productivity to unheard of levels. At the end of the project, virtually the entire development staff quit.

People under time pressure don't work better; they Just work faster. In order to work faster, they may have to sacrifice the quality of the product and their own job satisfaction.

We all tend to tie our self-esteem strongly to the quality of the product we produce, not the quantity of product, but the quality. Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.

Managers jeopardize product quality by setting unreachable deadlines.

The nation (Japan) that is an acknowledged quality leader is also known for its high productivity. The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.

Hewlett-Packard is an example of an organization that reaps the benefits from increased productivity due to high, builder-set quality standards. The company makes a cult of quality. In such an environment, the argument that more time or money is needed to produce a high-quality product is generally not heard. The result is that developers know they are part of a culture that delivers quality beyond what the marketplace requires. Their sense of quality identification works for increased job satisfaction and some of the lowest turnover figures seen anywhere in the industry.

In some Japanese companies, notably Hitachi Software and parts of Fujitsu, the project team has an effective power of veto over delivery of what they believe to be a not-yet-ready product. No matter that the client would be willing to accept even a substandard product, the team can insist that delivery wait until its own standards are achieved. Of course, project managers are under the same pressure there that they are here: They're being pressed to deliver something, anything, right away. But enough of a quality culture has been built up so that these Japanese managers know better than to bully their workers into settling for lower quality.

In a healthy work environment, the reasons that some people don't perform are lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. In none of these cases is schedule pressure liable to help very much. When a worker seems unable to perform and seems not to care at all about the quality of his work, for example, it is a sure sign that the poor fellow is overwhelmed by the difficulty of the work. He doesn't need more pressure. What he needs is reassignment, possibly to another company.

"In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group. She was a walking example of much of what I now think of as enlightened management. One snowy day, I dragged myself out of a sick bed to pull together our shaky system for a user demo. Sharon came in and found me propped up at the console. She disappeared and came back a few minutes later with a container of soup. After she'd poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do. She gave me her patented grin and said, Tom, this is management."


Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

viernes, 9 de junio de 2006

Decisiones... cada dia....

Este texto me parecio un buen resumen de las decisiones que debemos enfrentar cuando desarrollamos aplicaciones Web J2EE (o Java EE). IMHO, tener el poder de decidir es bueno. Es uno de los pilares de la democracia y es una de las razones por las cuales prefiero el modelo open source a la dictadura de Microsof.

Yes, there seems to be nothing but choice when it comes to developing web applications.

To begin with, someone has to choose between ASPX, Java, PHP, Python, Ruby, et al. Once you choose Java, then you have to choose a web container, such as Jetty, Tomcat, Resin, WebLogic, or WebSphere, to name a few. Of course, you also have to build the application that runs in the container, which is where choosing Apache Struts comes in. Then, most teams also use a data access framework. Choices there include Cayenne, iBATIS, Hibernate, JDO, Turbine, and OJB, to name a few.

(Right about now, Ruby's single-stack approach must be sounding pretty good!)

But, wait, there's more! You also have to choose an editor or IDE: Eclipse? IDEA? NetBeans? UltraEdit? Some other? (Many teams decide to use more than one!) And do we use Ant, Maven, or the IDE to build it all?

Lest we forget: Someone also needs to choose a database system (DB2? Derby? Oracle? PostGres? MySQL?), a version control system (CVS? Subversion? Perforce?), a development methodology (eXtreme Programming? RUP? Scrum? Waterfall?), and, if you're lucky, an issue tracker (Bugzilla? JIRA? Scarab?).

Welcome to the jungle!

Tomado de: http://struts.apache.org/roadmap.html#choice

viernes, 2 de junio de 2006

El Codigo Florinchi (Parte II)



En nuestro ultimo episodio, nuestros heroes se encontraron ante un misterio aparentemente insodable.

Sigamos ahora con la historia...

Despues de la info proporcionada por los "tios del cliente", decidimos buscar en internet el parche para las clases propietarias de encriptacion. Finalmente lo encontramos en la pagina del proveedor (aunque no estaba muy visible que digamos). Pero, una vez mas, la suerte jugo en contra. Al intentar bajarlo, por algun motivo el browser nos daba time-out. Se habra caido la pagina? -pensamos.

Tras un par de llamadas a la gente indicada nos enteramos que la conexion a internet se habia caido en esa zona de San Isidro! En este punto ya empezamos a conjeturar por que estabamos teniendo tan mala suerte en este fuxxxing pase a produccion!! Y entonces........ sucedio.

Al voltear la mirada vimos la fuente de nuestra desdicha. Teniamos frente a nuestros ojos a Mr. Flores (alias Flowers). Ya empiezan a entender el por que del titulo de la presente saga... Y quien es este personaje? -se preguntara Uds. Pues es nada menos que uno de los "tios del cliente", el cual estaba a cargo del pase. El problema con el susodicho -que por cierto es buena gente y no tengo nada personal contra el- es que tiene una mala suerte con los pases a produccion que ni el personaje de Hanna-Barbera se le compara . Para muestra, baste decir que una vez empezo un pase un viernes por la noche y termino el domingo a las 3pm. Y no es exageracion...

Pero volvamos a la historia... tras intentar una y otra vez bajar el parche, finalmente lo conseguimos y tras unos pequeños tropiezos con la instalacion del mismo -pues no estaba bien documentada- todo salio bien. Al momento de probar el producto, sin embargo, obtuvimos nuevos mensajes de error. El tiempo seguia corriendo y si o si teniamos que dejar todo operativo para la mañana siguiente o eramos historia.

Indagando en los logs del servidor de aplicaciones y del web server, descubrimos que este ultimo estaba teniendo dificultades al intentar comunicarse con el primero mediante SSL. Buscando de nuevo en internet, decidimos bajar el ultimo parche del servidor web. Nos llevamos otra sorpresa cuando vimos que no habian parches sino que habia que reinstalar el servidor web... en fin. A estas alturas ya no podiamos ponernos exigentes.

Hicimos un backup del archivo de configuracion y reinstalamos el servidor. Al probar de nuevo la conexion, encontramos nuevos errores. Despues de un par de maldiciones a la mala suerte de Flowers, decidimos regenerar el certificado digital para reconfigurar la comunicacion SSL entre los servers. Finalmente lo logramos, pero al hacer la prueba obtuvimos nuevos errores. Esta vez, Jadclipse mediante, vimos que el problema era que el producto no podia desencriptar los passwords almacenados en los archivos de configuracion. Casi seguro se debia al upgrade que habiamos hecho de las librerias de seguridad.

Ya eran casi las 2 am y nuestra paciencia, si bien no se agotaba, ya saba señales de cansancio. Afortunadamente, los "tios del cliente" se portaron bien y compraron un pollito a la brasa, el cual fue devorado por los presentes. Armandonos de valor, buscamos el mensaje de error en la documentacion on-line y por suerte encontramos una pista.

Si bien lo que hallamos se referia a otra version del producto, al parecer aplicaba a nuestra situacion. La solucion pasaba por correr unos queries en la BD y regenerar otros archivos mediante comandos. Al realizar esto y probar otra vez... finalmente funciono! Pudimos extraer los documentos del servidor de contenido y todo se veia bien.

Sin embargo, la mala suerte de Flowers paracia no descansar. Esto lo descubrimos al salir del edificio y dirigirnos al estacionamiento donde el Agente X habia dejado su auto. Era tan tarde que estaba cerrado y no habia nadie que nos abriera las rejas.... chess!!! Despues de un par de gritos y forcejeos decidimos zafar a nuestros hogares... en el fondo satisfechos de haber cumplido la tarea.

Pero aun hay mas!! ....Cuando todo parecia bien... al dia siguiente tuvimos una desagradable sorpresa. Como nos habiamos amanecido en el bendito pase, nos correspondia llegar tarde a la chamba. Pero a eso de las 10 u 11 recibi varias llamadas de gente del cliente y de mi empresa diciendo que los usuarios no podian conectarse a "El Content" y subir sus documentos escaneados. Diablos!! Si ayer todo funcionaba....

Tuve que dejar mi merecido descanso y volar al lugar del desastre para encontrar que simplemente se trataba de un error de conexion. Como la prueba que habiamos hecho la noche anterior fue en el mismo server todo habia salido OK. El tema era que al regenerar el certificado digital habiamos cambiado el hostname por el nombre calificado de la maquina (hostname + dominio) y las maquinas de los usuarios estaban apuntando al nombre anterior.

Para colmo, el servidor de contenido no estaba inscrito en el servidor DNS -por extrañas razones que no comprendo-, sino que estaba en cada archivo hosts de los usuarios. Y, obviamente, solo estaba el nombre corto. Corregido este impase todo fluyo a la perfeccion y pudimos respirar tranquilos.... no sin antes decir una vez mas... Flowers salado!!

miércoles, 24 de mayo de 2006

El Codigo Florinchi (Parte I)

Lo que supuestamente iba a ser un relativamente normal pase a produccion de fixes en los servidores del ambiente de produccion del cliente XYZ SAC -normal segun los estandares del cliente en cuestion (o sea, de dos a 3 horas extras de trabajo nocturno) -terminó conviertiendose en una busqueda casi interminable de errores plagada de pistas e indagaciones digna de la proxima novela de Dan Brown. Claro, si Brown esuviera interesado en retratar el devenir de un grupo de arquitectos de SW, gente de infraestructura y programadores.

Pero vamos por partes. Nuestra mision imposible, que decimos aceptar pues nadie nos pregunto si queriamos o no, era parchar un producto que llamaremos "El Content" que sirve para la administracion y manejo de contenido de todo tipo, el cual es vendido por una conocida empresa transnacional de IT y que actualmente utiliza extensivamente el cliente XYZ SAC.

Por motivos de falta de coordinacion y prevencion se decidio cancelar el pase a eso de las 9 pm. Sin embargo ya habiamos realizado el primer paso que consistia en backapear la BD que usa "El Content". Antes de irnos reiniciamos el server y procedimos a probar que todo funcionaba OK.

Grande fue nuestra sorpresa cuanto intentamos acceder a los documentos almacenados y obtuvimos errores innesperados. Sospechando que este percance nos iba a tomar mas tiempo de lo calculado, decidimos convocar refuerzos, o mas bien un refuerzo, alguien quien tiene amplia experiencia con el producto y que estaba planeado que viniera de todas maneras, pero que aun no llegaba pues tenia un compromiso previo ese dia. Llamemoslo Agente X.

Al llegar el susodicho se puso a revisar el estado del backup, el cual se habia realizado con exito. Porsiaca corrio uno mas y tambien termino OK. La BD estaba consistente y podiamos loguearnos sin problemas. El error ocurria cuando accediamos al contenido propiamente, el cual es provisto por un servidor de aplicaciones J2EE de una version un tanto antigua (digamos que era V2 y la actual es V4). Lo extraño es que ni siquiera habiamos tocado el dichoso servidor por lo que nuestra perplejidad se duplico. Y esta se triplico al ver en el log un mensaje de NoClassDefFoundError.

Varias preguntas rondaron mi cabeza: ¿Como era posible que faltara una clase en una aplicacion que viene con un producto como este? ¿Como podia pasar asi de pronto? Tenia que haber una explicacion logica y como tanto el Agente X y yo somos tercos y nos gusta resolver problemas (ademas que teniamos a los tios responsables del pase por parte del cliente "watching our backs") teniamos que encontrar la causa y resolver el impase.

Nos decimos a sacar el kit de rastreo de huellas digitales, o sea el poderoso JadClipse para descompilar las clases Java del producto que estaban lanzanado el NoClassDefFoundError. Fue asi que llegue a la madre del cordero. Al parecer el error se lanzaba al momento de instanciar mediante reflection una clase propietaria para encriptacion/desencriptacion. Pero, ¿como era posible que una clase que estaba funcionando bien se no se pueda instanciar de repente? ¿Era acaso que las clases tiene fecha de caducidad o algo asi? jeje.... nica.....

Pues......sica! Haciendo memoria por parte de los tios del cliente, resulto que habian recibido un mail de parte de la empresa que fabrica el producto hacia un par de dias atras que decia que el 18 de mayo del 2006 vencian las clases de encriptacion usadas en la version de App Server que estabamos usando!!

To be continued...

martes, 23 de mayo de 2006

Bienvenidos

Bueno, por fin me anime a crear un blog 'geek'. Aunque en realidad no sera tan geek pues pienso colgar historias personales, claro que siempre relacionadas al ambiente desarrollo de software en los ambientes y empresas que conozco personalmente y por amistades. Espero lo disfruten!