Alfredo Sanchez Aguado

¿Por qué es divertido programar? ¿Qué beneficios esperan obtener los programadores?

Primero, por el placer de construir cosas. Al construir cosas, los adultos experimentan el mismo placer que los niños al jugar con el barro, especialmente si construyen cosas que ellos mismos han diseñado.

Segundo, por el placer de hacer cosas que puedan resultar útiles a otras personas. En realidad lo que persiguen es que otros usen su trabajo y lo encuentren útil.

Tercero, por la fascinación de ver trabajar sistemas complejos, que asemejan rompecabezas en los que se integran diferentes piezas y partes móviles, que interactúan entre sí para llevar a cabo las funciones que inicialmente se han previsto.

Cuarto, por el placer de estar siempre aprendiendo al trabajar cada vez en proyectos de características diferentes.

Y por último, por el placer de construir con un material tan maleable y tan etéreo. El trabajo del programador, como el del poeta, se construye de forma sutil desde la materia pura de su pensamiento. Puede construir castillos en el aire, sólo con el esfuerzo de su imaginación. Pocos medios de creación son tan flexibles, tan limpios y fáciles de remodelar, para desarrollar complejas estructuras conceptuales.

Frederick P. Brooks. The Mythical Man-Month (Phillips Brooks, 1975)

Llevo trabajando con Notes desde el año 1999 con la versión 4.6 y hasta el día de hoy mi carrera profesional se ha desarrollado siempre en el ámbito “Notes” con todo lo que conlleva: javascript, sql, html, xml, javascript, css, OLE classes, applets de java, etc…. como véis “no solo de Notes vive el hombre”.

Ésta es mi opinión respecto al estado actual del mercado “Lotus Notes”, desde mi punto de vista personal:

IBM desde la versión 6.x, dejó abandonado comercialmente a Notes para potenciar otros productos como Websphere y pasamos de la época “dorada” a una mucho más parada en cuanto a apoyo comercial por parte de IBM, se fueron abandonando muchos proyectos y muchas pequeñas empresas dejaron de utilizarlo, lo pude vivir de primera mano cuando estaba trabajando con IBM en una importante entidad bancaria española.

En ese tiempo Microsoft debió darse cuenta de ello y potenció Exchange en muchas empresas ofertando el cambio de Lotus Notes como cliente de correo a Microsoft Exchange, y esto supuso la “muerte” no solo del correo sino de muchas aplicaciones y desarrollos asociadas a los servidores Lotus Domino.

Con el tiempo, IBM quiso recuperar estrategia de mercado con Lotus Notes implementando en su versión 7 la posibilidad de conectar con sistemas de gestión de base de datos (SGBD); (en inglés: DataBase Management System, abreviado DBMS), pero como todo lo que hace IBM la única SGBD soportada era DB2, volviendo a cometer otro error. Dicha funcionalidad se ha explotado poco o nada, ya que dicho gestor de bases de datos no es uno de los mas difundidos del mercado y tan solo se puede “ver” en grandes empresas.

Pasamos a la versión 8 sin muchos cambios, aunque sí una renovada interfaz. Con la versión 8.5 y con la evolución del mercado, llega la revolución: basado en la plataforma Eclipse y por primera vez se empiezan a ver los términos JAVA junto a Notes: “Lotus Notes / Notes Designer 8.5 /JAVA”.

Veremos como reacciona el mercado aunque quizá… sea demasiado tarde.

Si alguien se pregunta alguna vez cómo crear una imagen de una cuenta de gmail, pues es muy fácil, existe una utilidad online llamada E-Mail Icon Generator, que te crea un icono con tu Gmail en un momento. También podréis generar una imagen de muchos otros proveedores de correo.

Esta nueva aplicación web será la delicia de los desarrolladores web, con ella podrás crear via web menus personalizados en CSS e integrarlos facilmente en tus proyectos.

$Title
Insert this single $ field to store the name of the form in a document.

$$HTMLhead
If you don’t use the “For Web Access: Treat document contents as HTML” form property, adding a $$HTMLHead field to a form allows you to pass HTML information, such as Meta tags and JavaScript, to the Head tag for a document. The field can be any data type, but a hidden computed-for-display text field is the best choice.
(source: Notes Help 4.6)

$$QueryOpenAgent (4.6) or the form event WebQueryOpen (4.6)
The Notes Help 4.6 says about WebQueryOpen: A WebQueryOpen event runs the agent before Domino converts a document to HTML and sends it to the browser. Domino ignores any output produced by the agent in this context.
Create a shared agent that runs manually. Then write a formula that uses @Command({ToolsRunMacro}) to run the agent and attach it to the WebQueryOpen form events. This simulates the LotusScript QueryOpen form event that isn’t supported on the Web.
The $$QueryOpenAgent field works in the same way. Works also in 4.6.

$$QuerySaveAgent (4.5) or the form event WebQuerySave (4.6)
The Notes Help 4.6 says about WebQuerySave: A WebQuerySave event runs the agent before the document is actually saved to disk. The agent can modify the document or use the document data to perform other operations.
Create a shared agent that runs manually. Then write a formula that uses @Command({ToolsRunMacro}) to run the agent and attach it to the WebQuerySave form events. This simulates the LotusScript QuerySave form event that isn’t supported on the Web.
The $$QuerySaveAgent field works in the same way. Works also in 4.6.

$$Return
After Web users submit a document, Domino responds with the default confirmation “Form processed.” To override the default response, add a computed text field to the form, name it $$Return, and use HTML as the computed value to create a customized confirmation.
(source: Notes Help 4.6)

$$ViewBody
Value is view name (in quotes) or a formula that computes the view name. Same as Embedded View.
(source: Notes Help 4.6)
This is the field you put in a form to display a view. See also the list of $$ forms below.

$$ViewList
Has no value. Same as Embedded Folder Pane.
(source: Notes Help 4.6)
This is the field you put in a form to display the list of available views and folders. See also the list of $$ forms below.

$$NavigatorBody, $$NavigatorBody_n
Value is navigator name (in quotes) or a formula that computes the navigator name.
Same as Embedded Navigator. To create multiple $$NavigatorBody fields on a form, append an underscore and a character to each subsequent field name.
(source: Notes Help 4.6)
This is the field you put in a form to display a navigator. See also the list of $$ forms below.
The following fields are no $$ fields, but they are reserved names in a Web context.

Table of CGI variables from the Notes Help 4.6

Domino captures the following CGI variables through a field or a LotusScript agent. You can also capture any CGI variable preceded by HTTP or HTTPS. For example, cookies are sent to the server by the browser as HTTP_Cookie.

Auth_Type
If the server supports user authentication and the script is protected, this is the protocol-specific authentication method used to validate the user.

Content_Length
The length of the content, as given by the client.

Content_Type
For queries that have attached information, such as HTTP POST and PUT, this is the content type of the data.

Gateway_Interface
The version of the CGI spec with which the server complies.

HTTP_Accept
The MIME types that the client accepts, as specified by HTTP headers.

HTTP_Referer
The URL of the page the user used to get here.

HTTPS
Indicates if SSL mode is enabled for the server.

HTTP_User_Agent
The browser that the client is using to send the request.

Path_Info
The extra path information (from the server’s root HMTL directory), as given by the client. In other words, scripts can be accessed by their virtual path name, followed by extra information that is sent as PATH_INFO.

Path_Translated
The server provides a translated version of PATH_INFO, which takes the path and does any virtual-to-physical mapping to it.

Query_String
The information that follows the ? in the URL that referenced this script.

Remote_Addr
The IP address of the remote host making the request.

Remote_Host
The name of the host making the request.

Remote_Ident
This variable will be set to the remote user name retrieved from the server. Use this variable only for logging.

Remote_User
Authentication method that returns the authenticated user name.

Request_Method
The method used to make the request. For HTTP, this is “GET,” “HEAD,” “POST,” and so on.

Script_Name
A virtual path to the script being executed, used for self-referencing URLs.

Server_Name
The server’s host name, DNS alias, or IP address as it would appear in self-referencing URLs.

Server_Protocol
The name and revision of the information protocol accompanying this request.

Server_Port
The port to which the request was sent.

Server_Software
The name and version of the information server software running the CGI program.

Server_URL_Gateway_Interface
The version of the CGI spec with which the server complies.
Associated with a lot of the $$ fields are the following forms:

$$ViewTemplate for viewname
Requires a embedded view or $$ViewBody field
Associates the form with a specific view. The form name includes viewname, which is the alias for the view or when no alias exists, the name of the view. For example, the form named “$$ViewTemplate for By Author” associates the form with the By Author view.
Domino requires an Embedded View or the $$ViewBody field on the form, but ignores the value.
(source: Notes Help 4.6)

$$NavigatorTemplate for navigatorname
Requires a embedded navigator or $$NavigatorBody field.
Associates the form with a specific navigator. The form name includes navigatorname, which is the navigator name. For example, the form named “$$NavigatorTemplate for World Map” associates the form with the World Map navigator.
Domino requires an embedded navigator or the $$NavigatorBody field on the form, but ignores the value. Domino ignores create and read access lists on the form.
(source: Notes Help 4.6)

$$ViewTemplateDefault
Requires a embedded view or $$ViewBody field.
Makes this form the template for all Web views that aren’t associated with another form.
Domino requires an embedded view or the $$ViewBody field on the form, but ignores the value.
(source: Notes Help 4.6)

$$NavigatorTemplateDefault
Requires a embedded navigator or $$NavigatorBody field.
Makes this form the template for all Web navigators that aren’t associated with another form.
Domino requires an embedded navigator or the $$NavigatorBody field on the form, but ignores the value.
(source: Notes Help 4.6)

$$SearchTemplate for viewname
Associates the form with a specific view. Domino requires the $$ViewBody field, but ignores the value. The form name includes viewname, which is the alias for the view, or, when no alias exists, the name of the view. For example, the form named “$$SearchTemplate for All Documents” associates the form with the All Documents view.
(source: Notes Help 4.6)

$$SearchTemplateDefault
Domino requires the $$ViewBody field, but ignores the value. This form is the default for all Web searches that aren’t associated with a specific form.
(source: Notes Help 4.6)

$$SearchSiteTemplate
In a site search this form is used in stead of $$SearchTemplateDefault
(source: posting by Andrew S Grant on Notes.Net)

$$Search
When a user initiates a text search from the Web, Domino looks in the current database or in the search site database in a multiple-database search for a form with the actual name or the alias name $$Search. If the form exists, Domino opens it; otherwise, Domino displays the default search.htm file stored in the domino\icons directory.
(source: Notes Help 4.6)
And another set of very useful forms (i didn’t even know they exsisted until a few moments before):

$$ReturnDocumentDeleted
Displays to Web users when the user successfully deletes documents. Create an editable text field named MessageString to hold the error message.
(source: Notes Help 4.6)

$$ReturnAuthenticationFailure
Displays to Web users when the user’s name and password can’t be verified. Create an editable text field named MessageString to hold the error message.
(source: Notes Help 4.6)

$$ReturnAuthorizationFailure
Displays to Web users when the user doesn’t have a high enough access level to access the database. Create an editable text field named MessageString to hold the error message.
(source: Notes Help 4.6)

$$ReturnGeneralError
Displays to Web users when any other errors occur.. Create an editable text field named MessageString to hold the error message.
(source: Notes Help 4.6)
Roles

$$WebClient
Is a role which is applied to all Web clients. This role can be very useful in hiding formulas. To check if a client is Web client use @IsMember(“WebClient”; @UserRoles).

Para modificar campos “reservados” en lotus notes mediantes LotusScript debemos utilizar el siguiente método:

Set memo = New NotesDocument( db )
memo.Form = “Memo”
……
‘si lo estamos enviando automaticamente no queremos mensjes de “out of office messages”
memo.~$AutoForward = “1″

‘Incluimos un icono para el correo
Set item = memo.ReplaceItemValue(“_ViewIcon”, 59)

My cool Button es un servicio que nos permite crear y descargar botones Web 2.0 personalizados. Mediante 4 sencillos pasos podemos obtener botones de diseño agradable. Entre las opciones que nos da está: elegir el tamaño de nuestro botón (entre 100 y 200px), color de fondo, un icono de fondo y agregar texto. Podemos ver como nos está quedando mientras le agregamos las características deseadas y finalmentes descargarlo en formato .png.

Hace ya tiempo que la mayoría de páginas webs incluyen a su comienzo una misteriosa etiqueta <!DOCTYPE, y sin embargo hay mucha gente que ignora cuál es su significado o para qué sirve, por lo que simplemente se limita a copiarla, haciéndolo además muchas veces de forma incorrecta. En las siguientes líneas trataremos de explicar para qué sirve y cómo ha de utilizarse.

La declaración de tipo de documento DOCTYPE, que así es como se llama, es una parte fundamental de todas aquellas páginas que quieran cumplir los estándares, tanto HTML como XHTML. Esta declaración indica que versión de (X)HTML se usa en la página, de forma que los navegadores pueden saber qué sintaxis y gramática se usa, y los validadores puedan comprobar su validez. Para ello la declaración indica un DTD contra el cual se puede realizar la validación.

Aparte de esto la declaración DOCTYPE se utiliza por los navegadores para activar su modo estándar o estricto, o su modo compatibilidad (quirk). La razón de esto y las diferencias existentes entre estos modos queda fuera del ámbito de esta explicación, pero es suficiente con darse cuenta de que la no utilización de un DOCTYPE o su incorrecto uso, puede hacer que los navegadores rendericen la página de forma completamente diferente a lo que teníamos previsto. Todas las páginas nuevas que se hagan deberían contener esta declaración y hacerlo de forma correcta, con el fin de cumplir los estándares por un lado y garantizar resultados de renderizado homogéneos por otro.

Una declaración DOCTYPE suele tener una estructura similar a la siguiente:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

En este ejemplo se indica que la página debe validarse como XHTML Transitional utilizando el DTD existente en la url http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd. Es habitual que estas líneas las creen los propios editores pero no siempre lo hacen de forma correcta, además a veces se copia de alguna otra página en la que por ejemplo la ruta del DTD es local, por lo que seguramente generaría un fallo en la validación en nuestro web.

Existen tres tipos de documentos XHTML: Strict, Transitional y Frameset. A continuación se muestra la declaración de cada una de ellas con la referencias válidad a cada DTD, y un poco más abajo sus diferencias para saber cuándo usar cada una.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>

• Strict: este tipo de documento está principalmente ideado para su utilización con CSS, separando completamente el contenido y la presentación. Para ello no permite la utilización de etiquetas y atributos ya en desuso orientados a la presentación, como font, center y otros. Escribiendo páginas en XHTML 1.0 Strict se consiguen páginas bien estructuradas y fácilmente adaptables mediante CSS, pero tiene la desventaja de crear incompatibilidades con ciertos navegadores.
• Transitional: incluye todas las características de XHTML 1.0 Strict, pero añade características orientadas a la presentación ya en desuso.
• Frameset: es una variante del Transitional para las páginas que utilizan frames

Por último hay que tener en cuenta que no es necesario que las páginas XHTML contengan una instrucción prolog similar a <?xml version=”1.0″ encoding=”utf-8″ ?> salvo en los modos estrictos. En realidad esta instrucción es únicamente necesaria cuando el contenido de la página se sirve como text/xml y además su utilización hace que Explorer 6 pase a modo Quirk por lo que no se recomienda su uso. Si necesitamos indicar el encoding de la página se recomienda utilizar la etiqueta meta correspondiente.

Autor: Patxi Echarte (eslomas.com)

¿Cómo es posible que un individuo absolutamente lego en materia de software sea capaz de dirigir un proyecto sin que se le vea el plumero? ¿No debería hacerse evidente su incompetencia? ¿No debería fracasar el proyecto estrepitosamente? Sin embargo, estos individuos conservan sus puestos durante años (normalmente hasta la quiebra de la empresa).

La clave de este misterio está en el proyecto bicicleta.

Grosso modo, las fases de un proyecto bicicleta son: Análisis de requisitos, diseño, implementación, fase de pruebas, entrega, revisión. En la fase de análisis de requisitos el cliente informa de lo que desea, en la fase de diseño se da forma al producto, en la fase de implementación se codifica, en la fase de pruebas se comprueba que todo haya ido bien. Las cuatro primeras fases pueden parecer las más importantes, pero en un proyecto bicicleta resultan ser del todo prescindibles. Se deja todo a la fase de revisión (que le suele tocar a uno).

En estas primeras fases nuestro amigo manager no trabaja (recordemos que simplemente es incapaz), tan sólo sale del paso. Hasta la fase de entrega no hay nada de que preocuparse, se trata de disimular. Pero claro, algo tangible hay que tener, algo que enseñar a la directiva en las reuniones. ¿De dónde se saca? Simplemente se baja de internet o se compra. Digamos que el cliente necesita un sistema de workflow, accesible por web y que sea escalable. Pues bien, se va uno a un buscador y se introduce “cheap web-based workflow system java source code download”. Se navega un poco, se busca un producto con colorido futurista, se saca la tarjeta de crédito, y voila. El proyecto bicicleta ya tiene forma.

A continuación nuestro amigo manager designa un equipo de desarrollo para las fases dos, tres, y cuatro. La experiencia le ha enseñado que para proyectos bicicleta se deben escoger desarrolladores cuanto más lerdos mejor, para que no se den cuenta del pastel (aquí se sigue el principio del “traje del emperador”).

Podemos empezar a sospechar que en la mesa de al lado se esta cociendo un proyecto bicicleta cuando el equipo de lerdo-desarrollo juega al 69 profesional. Se intercambian comentarios-perla muy pomposos, tales como “los canales de intercambio de información son muy limpios”, “el factor usabilidad es determinante en el diseño de los javabeans”, “ya he incrementado el número de parámetros del constructor, te mando el punto class por mail”, o “este JSP tiene tres mil líneas porque he aplicado un patrón FACADE de acceso concentrado”.

Dos meses después llegamos a la fase de pruebas. Obviamente el producto es una mierda. Pero las pruebas corren a cargo del mismo equipo, y los niños de uno nunca son feos. Así que con la cabeza bien alta, se prepara un zip, un manual de instalación, y entrega tú, Carlitos, que a mí me da la risa. ¿Estado del proyecto? Entregado. Viernes noche. Cena de proyecto. Aplausos, risas, más 69. El lunes llegarán las sorpresas.

Ilustremos la fase de revisión con un ejemplo gráfico:

El proyecto porsche

Llega el lunes y uno abre el correo. Subject: “Incidencias en el proyecto Porsche”. Te requieren “un par de días” para “echar una mano” con “unos bugs”. Reunión dentro de quince minutos.
Entras al despacho. Ahí esta nuestro amigo manager. Te explica la historia: el proyecto Porsche es uno de los más punteros de la empresa (uno sospecha que es puntero a null). Se han aplicado novedosas técnicas de diseño e implementación y se ha conseguido entregar un producto perfectamente acorde a los requisitos del cliente: un porsche descapotable, seguro, ligero, veloz, de bajo consumo y de bajo coste. Se ha hecho rápido y bien. Un éxito. En la fase de revisión han surgido unas pequeñas incidencias que hay que revisar.

Bien. Vamos a ver la maravilla. Entramos al hangar del proyecto porsche, y ahí está la criatura: una bicicleta. De paseo. Sin cambio de piñón ni nada. Lleva una pegatina detrás del sillín con el logo de la empresa y la palabra “PORSCHE”. En la cesta va un certificado de AENOR. Aquí uno normalmente monta en cólera y empieza a gritar que quiere ir a hablar con el director, los socios fundadores, los clientes, los accionistas, el papa de Roma. Uno quiere ver a alguien colgado en la plaza pública.

Lo que sucede acto seguido es que a uno le llevan a un despacho en recursos humanos y le aplican de nuevo el método combinado “Ludovico/Habitación 101″. La chavala de RRHH, que se suele llamar Maika o Ivon y va vestida con ese traje de pantalón negro y tacones estilo mujer corporativa con master en dirección de empresas, nos interroga con voz de Valium 500:

[Ivon] Señor Fuckowski, ¿cuáles son sus quejas respecto al proyecto porsche?

[yo] ¿¿¡PERO QUE PORSCHE!??

[Ivon] El proyecto porsche, uno de los mas punteros en…

[yo] ¡¡Que sí, que sí, que me sé la película!! ¡¡Pero es que “eso” es una bicicleta, y se supone que tengo que convertirla en un porsche en dos días, y me han dado un destornillador y un bote de pintura!!

[Ivon] Señor Fuckowski, es cierto que el porsche presenta algunas incidencias, pero..

[yo] ¡¡BICICLETA!! ¡¡BICICLETA!!

[Ivon] Señor Fuckowski, ¿está atravesando una crisis personal? Debe haber una razón para su postura negativa acerca del porsche.

[yo] No. Estoy perfectamente. O lo estaba, hasta que vi la bicicleta.

[Ivon] Habitación 101, señor Fuckowski .

Habitación 101. Silla con correas. Camisa de fuerzas. Logos de la corporación. Certificaciones de calidad. Proyector XGA. Pantalla panorámica que muestra una enorme bicicleta de paseo. Allí nos espera el director de la empresa.

[director] Señor Fuckowski, describa usted este porsche.

Me ahorraré los detalles de la tortura, pero implica disertaciones sobre la actitud positiva, la creencia en la visión de la empresa, la auto motivación, la letra pequeña del contrato. En definitiva, que si no ves el porsche vas a la calle.

Después del almuerzo ya está uno perfectamente motivado, asistiendo a una conference call entre la empresa, representada por el manager, y el cliente, representado por un consultor con traje negro y corbata chillona, contratado ayer, que cobra 100 euros la hora mas dietas, y al que no le interesa decir “meteos la bicicleta por donde os quepa” y cobrar 25 euros por quince minutos.

[consultor] Bien, vamos a clarificar las incidencias respecto al porsche. Lo primero que hemos notado es que le faltan dos ruedas.

[manager] Sí, hemos optado por el diseño minimalista que va con nuestra visión de empresa: “práctico, funcional, óptimo”.

[consultor] Ya veo. Pero un porsche con dos ruedas no casa con nuestro modelo de negocio. Lo necesitamos de cuatro ruedas.

[manager] Creo que podremos refactorizar el porsche y hacer un clone para añadir dos ruedas extras, ¿cierto? -me mira a mí

[yo] ¡¡Sí, jajaja!! ¡¡Chupado!! Dame una hora.

[consultor] Perfecto. Bien, la segunda incidencia. No encontramos la capota.

[manager] Sí. Lo querías descapotable, ¿no?. Pues hemos simplificado mucho la usabilidad retirando la capota.

[consultor] Bien, pero no sólo la queremos quitar, también la queremos poner.

[manager] Ah. Eso no está especificado en los requisitos iniciales, así que lo consideraremos funcionalidad extra y lo cobraremos por separado. ¿Que impacto tiene este nuevo requerimiento en el sistema? -me vuelve a mirar.

[yo] Afortunadamente los interfaces están muy limpios, así que podremos modificar la capa externa sin impacto en el kernel, jajaja.

[consultor] Perfecto. Otra cuestión, ¿dónde están el contacto y la llave? Cualquiera podría robarnos el porsche.

[manager] Hemos optado por el modelo multiusuario para la implementación inicial, pero podemos añadir un módulo de seguridad al sistema, ¿no?

[yo] ¡¡Siiii!! ¡Precisamente tengo aquí un módulo de encriptación SSL para porsche!

[consultor] Brillante. Sólo dos incidencias más. Se requiere demasiado esfuerzo al usuario para completar tareas con el sistema. ¿Podrías cambiar los pedales por un motor?

[manager] En principio queríamos dar la máxima libertad de acción al usuario, por lo que hemos optado por un modelo de cliente pesado.

[consultor] Bien, pero consideramos excesiva la cantidad de trabajo que se deja al usuario.

[manager] Podemos llegar a un compromiso razonable entre la libertad del usuario y la automatización de procesos, ¿no es cierto?

[yo] Indudablemente. Sustituiremos el motor de giro asistido por pedales por uno compatible asisitido por pistones. Quizá requiera añadir un módulo de almacenamiento externo para combustible, pero siempre lo podríamos poner en la cesta, jajaja.

[consultor] Estoy contigo al cien por cien. La última: el sistema no ha superado las pruebas de rendimiento. En los requisitos consta que el sistema debe alcanzar los doscientos por hora.

[manager] El rendimiento siempre puede variar dependiendo de la plataforma. Las especificaciones de este sistema son “carretera de hielo con un 70% de pendiente descendiente”.

[consultor] Bien, verificaré qué plataforma estamos utilizando en explotación. Pero creo que vamos a necesitar más velocidad.

[manager] Siempre podemos afinar el kernel, ¿no es cierto?

[yo] Cierto como que me llamo Fuckowski.

[consultor] Muy bien, caballeros. Ha sido un placer.

Tres de la mañana. Un termo de café. Un cubo de pintura, un destornillador. Y una bicic.. un porsche.

Fuente: http://www.despacho101.com/press/proyecto-bicicleta

En 2004 se celebró una carrera de remo entre empleados de una empresa japonesa y de otra española. Se dio la salida y los japoneses empezaron a destacar desde el primer momento, llegando a la meta con una hora de ventaja sobre el equipo español.

La dirección de la empresa española analizó las causas de tan amarga derrota y advirtió que el equipo japonés estaba compuesto por 10 remeros y un jefe de equipo, mientras que la tripulación española la componían 10 jefes de equipo y un remero, por lo que se decidió adoptar las medidas adecuadas.

En 2005, la tripulación japonesa llegó dos horas y media antes que la española. La Dirección se volvió a reunir y, tras un sonoro rapapolvo a la Gerencia, concluyeron que los japoneses habían repetido estrategia (10 remeros y 1 jefe de equipo) mientras que la innovadora tripulación española, remozada tras las eficaces medidas tomadas el año anterior estaba compuesta por: 1 jefe de equipo, 2 asesores a gerencia, 7 jefes de sección y 1 remero.

La conclusión de la Dirección fue unánime: el remero es un incompetente.

En 2006, tras encargar una innovadora trainera al departamento de nuevas tecnologías, la ventaja de los japoneses fue de cuatro horas. El equipo directivo reunido para analizar las causas del nuevo desastre comprobó que el equipo nipón había optado por la ya tradicional formación ( 1 jefe de equipo y 10 remeros), mientras que el español, tras una auditoría externa y el asesoramiento especial el departamento de organización, optó por una formación mucho más vanguardista: 1 jefe de equipo, 3 jefes de sección con plus de productividad, 2 auditores de Arthur Andersen y 4 vigilantes jurados que no quitaban ojo al único remero de la tripulación, al que habían amonestado y castigado quitándole los pluses e incentivos tras el fracaso del año anterior.

Tras varias horas de reuniones, se acordó que, para la regata de 2007, el remero sea un becario o en su defecto, una contrata externa, ya que, a partir de la vigésimo quinta milla, se ha venido observando cierta dejadez en el remero de plantilla, actitud que roza el pasotismo y con comentarios del tipo: “El año que viene va a remar su puta madre” al llegar a la línea de meta.