by ·4 Comentarios

Apple a lo largo de los años se ha caracterizado por la imagen limpia y diferente de sus anuncios. Esto ha significado que, constantemente sean parodiados, junto con otros aspectos de Apple (como su imagen o el mismo Steve Jobs).

Son docenas las parodias de Apple que se han hecho, pero algunas han sido memorables, así que reproduzco aquí las mejores gracias a Google Video y YouTube.



iBrator: Una de las primeras parodias que recuerdo. A los pocos días de salir los anuncios de los iMacs originales miles pudimos confirmar que Apple estaba de nuevo causando ruido.

Después del salto este y una docena más…
Continuar

by ·0 Comentarios

Juan García tiene un weblog de fotografía de una calidad impecable y además tiene la presencia y constancia para documentar todos sus artículos de forma simple e informativa siempre en dos idiomas. No sólo en español sino en inglés impecable.

Aunque desde hace algún tiempo lo tengo en mi lista de sitios leídos frecuentemente no había comentado nada de él pero su imagen de la Estación de Atocha me ha encantado, especialmente con el retoque a sepia que le ha hecho. Así pues, pongo aquí una versión peuqeña de la foto y os envío a que os perdáis un poco por allí.

jggweb.com


Evocadora imagen de la estación de Atocha, virada a Sepia, de jggweb.com

jgarcía dijo:
05.31.2006 a las 12:48 pm

He utilizado el Calculador de Profundidad de Campo para intentar explicar la razón de la nitidez:

Cámara Nikon D200
Lente 18mm
Abertura f3.6 (f3.5 no disponible en el simulador)
Distancia sujeto 100m (calculo, más o menos)

Resultados:
Distancia mínima con nitidez aceptable: 4.35m
Distancia máxima con nitidez aceptable: Infinito

Profundidad de campo total: Infinito
Profundidad de campo entre el sujeto y la cámara: 95.7m
Profundidad de campo tras el sujeto: Infinito

Distancia Hiperfocal: 4.56m

… y es que cuando los sujetos de nuestras fotografías se encuentran a gran distancia la profundidad de campo no se ve tan afectada por la abertura de diafragma como cuando se encuentran cerca.

by ·0 Comentarios

Hay una sorpresa para aquellos que utilizamos Google Earth en España. Hace no mucho se añadió soporte para Europa a nivel de Calle, con lo que buscar rutas y direcciones, incluso internacionales, era posible tanto en el programa como en Google Maps.

Ahora la base de datos de ambos ha sido actualizada. Hay una cantidad de puntos de interés que activar las vistas de los mismos puede ser una locura:


Puntos de Interés (POIs) de Madrid

by ·4 Comentarios

Es una frase común recordar todo lo que hemos aprendido de nuestros padres y, si bien correcta en el contexto que la queremos decir, también es cierto que inconscientemente nos referimos a todas las cosas que gracias a ellos sabemos que hay que evitar.
Tal vez sea nuestra única consolacion al considerar ser padres. Que sin importar lo mal que llevemos nuestra vida, lo desacertado de nuestras decisiones, las meteduras de pata… alguien aprenderá de nuestros errores (o debería hacerlo) y evitará cometerlos. Es nuestra mayor lección de humildad como padres y una de nuestras mayores responsabilidades. Tal vez por esto es que no pensamos en ello y, aquellas veces que lo hacemos, cruzamos los dedos para que todas esas cosas que sabemos, en el fondo, que hacemos mal, no sirvan como aprendizaje de imitación sino de prevención a los que sin darse cuenta nos usan como ejemplo. No puedo imaginar de qué estaría más orgulloso si alguna vez miro hacia atrás y veo en lo que se han convertido personas que aprendían de mí. Si el que sean similares a mí o si fueron capaces de reconocer mis defectos y evitarlos pero tiendo a pensar que lo segundo me daría más orgullo de ellos, mientras que lo primero me daría orgullo de mí mismo. La versión familiar de cuando «el pupilo supera al maestro».

Sabemos que cuando le decimos a un niño «No metas los dedos en la licuadora» le estamos enseñando algo bueno pero, creo, se nos olvida que todo cuanto decimos es una lección para ellos. Cuando relegamos su educación a sus profesores sin decir ni pío pero ponemos el grito en el cielo cuando consideramos que ha rebasado las que pensamos «sus atribuciones como educadores». Cada vez que decimos «no hagas esto, aunque lo hago yo», «cuando seas grande comerás dos huevos» y «esto es para mayores, vete a la cama».

Probablemente uno de los mecanismos de defensa más eficaces que tienen los padres es, precisamente, la negación que les permite ignorar el tener presente, todo el tiempo, que toda frase, movimiento, gesto y acción son una clase hacia sus hijos, y que éstos no serán capaces de distinguir las buenas de las malas hasta que probablemente sea demasiado tarde (e invariablemente pasando por la etapa caótica donde absolutamente TODO lo que sus padres hacen está mal, comúnmente llamada «adolescencia», donde mas vale que les hayamos ya enseñado todo lo que necesitan para tomar decisiones correctas porque ya no escucharán nada).

(casi decidí no escribir esto porque, bien podria alegarse, no tengo hijos y alguno pensará que eso me quita el derecho a hablar sobre el tema. Por eso aclaro que esto lo escribo no como padre, sino como un hijo que un día tuvo un atisbo, en los ojos de su padre, de la carga de responsabilidad que saber esto supone y la tranquilidad mental de ver a sus hijos evitar los errores cometidos por él)

by ·4 Comentarios

Estoy en el hospital Ramon y Cajal ahora mismo, escribiendo desde la Palm. Una visita de rutina a su doctor de cabecera le ha resultado a mi padre en un viaje en ambulancia, sirenas y todo, a esta Sala de Urgencias.
A pesar del tono brutalmente alarmista de la doctora en el teléfono al llamarme solo están, por el momento, haciendo exámenes y verificando resultados. Tratando de encontrar qué puede haber desatado los síntomas (menores por separado, alarmantes en conjunto) de su condición actual.
En menos de 40 minutos hemos visto pasar todos esos tests y procedimientos que vemos en programas como House, Scrubs, Anatomía de Grey y ER. Le han tocado, en fila india: Orina, sangre, electro, rayos-X, inhaladores, intravenosas, temperatura, esfuerzo y entre todo esto mi padre riendo porque nunca había estado en una ambulancia con la sirena puesta y diciendo que si le abro el oxígeno podría colocarse como Steve Martin, haciendo de dentista sado en Little House of Horrors.
Ahora, como se dice, a esperar…
[5 horas despues]
Más exámenes mañana. Hoy se queda a dormir en Observación, donde no lo puedo acompañar. Han encontrado líquido en el pulmón y a lo mejor una masa, pero no están seguros. Esperemos lo mejor. Me molesta haberlo dejado ahí sólo pero no me dejaban quedarme.

by ·7 Comentarios

He aqui una fantástica simulación de lo que sucedería si un asteroide de tamaño considerable golpeara la tierra. La simulación esta hecha de forma matemática aunque se han insertado videos para aclarar los efectos a nivel menos macroscópico:



Enlace Directo

Este vídeo da una idea un poco mas clara de lo que suelo repetir en conversaciones (especialmente con gente ciegamente «ecologista») una vez y otra. La realidad es que somos insignificantes, una mota de polvo de estrellas que puede ser borrada de la historia sin dejar rastro en cuestión de horas. Nos sentimos tan superiores a lo que nos rodea e ignoramos que nuestra capacidad de aguantar un evento de nivel planetario es ínfima. La tierra periódicamente se deshace de cualesquiera especie animal que resulta en ese momento ser dominante y nosotros somos la actual.

Otro vídeo, un clásico ya, que muestra precisamente, nuestro lugar y proporción con respecto al universo (macro y micro) conocido:



Enlace Directo
El vídeo se conoce como «Powers of Ten» (Traducido como «Potencias de diez» e interpretado como «Magnitudes«) y es parte de un DVD homónimo sobre este tema. De 1024 a 10-16

Lo menos que podemos es sonreir maravillados. Somos una parte minúscula de todo lo que hay pero tenemos que darnos cuenta que eso no solo no nos hace menos importantes sino que nos hace aún más especiales. Aprovechemos nuestro tiempo aquí, en un sentido más que metafórico somos mas efímeros que la flama de una vela en un día ventoso.

by ·2 Comentarios

Con alarmante frecuencia en las últimas dos semanas me he encontrado a mí mismo repitiéndole lo mismo a gente que debería saberlo ya. Hablo específicamente de una ley aplicada al desarrollo de programas informáticos conocida como la «Ley de Brooks» y, aunque es realmente simple de entender, por algún motivo no parece ni obvia ni natural si no te la muestran y demuestran usando tus propios errores como ejemplo.

Hay muchas metodologías, en estos días de tanto «emprendedor» y «gente altamente eficaz», que se enseñan para manejar equipos de trabajo y proyectos de todo tipo. La «Ley de Brooks» se centra sobre la incorrecta aplicación de uno de los estilos más comunes de llevar proyectos y, específicamente, a la espiral de desastre que suele desencadenar. Al final del artículo pongo más información sobre el libro de Brooks en cuestión y sus otros postulados sobre manejo de proyectos.

En México se dice «Échale más cemento» cuando algún proyecto está atrasándose y no va como debería. La frase viene de la construcción, donde lo que no puedas arreglar con buena ingeniería y arquitectura siempre lo puedes arreglar poniéndole mas hormigón y hierro. Esta analogía se extiende a muchas cosas en las que podemos vernos envueltos:

-¿No puedes transportar todo lo que debes? Échale más camiones
-¿No estás logrando apagar un fuego? Échale más agua
-¿Tienes más información de la que puedes capturar? Échale más gente capturista
-¿No puedes detener a Godzilla? Échale más tanques ((Ésta última es más común de lo que parece.))

El problema es que la solución de «Echarle más cemento» sólo sirve en los proyectos en los que el problema son los recursos y la solución obvia es buscar más recursos.

El otro tipo de proyecto, que es el que nos concierne, es el ‘Serializado’. Proyectos donde una tarea no puede ir antes de otra y cada tarea tiene que hacerse por la misma persona/grupo. Los desarrollos de software son de este tipo porque, con frecuencia (y especialmente en la segunda mitad), las partes que lo componen son interdependientes y dependen unas de otras. No puedes desarrollar pantallas de usuario si no tienes datos que presentar, no puedes hacer rutinas de importación si no tienes tablas definidas.

Esto obviamente no suele ser un problema en desarrollos hechos por grupos pequeños de manera informal pero cada vez más se ve el uso, por parte de compañías y corporaciones, de equipos de desarrollo de terceros, el famoso «outsourcing» o «subcontratación». El outsourcing significa, simple y llanamente, que alguien más hace el trabajo a partir de una serie de condiciones de resultados, por una cuota. ¿Cual es la pega? Que cuando se hace outsourcing de desarrollo tiene que haber un estimado previo estipulando cuánto se va a pagar por ese desarrollo y la forma más fácil de comprender lo que se está pagando es cotizar los proyectos en «horas-hombre»:

Concepto Estimación
(números inventados por mí para este ejemplo)
Una pantalla de acceso: 10 horas-hombre
Una rutina de importación: 40 horas-hombre
Pantallas de CRUD básicas: 80 horas-hombre
Un proceso de envío de mail automático: 20 horas-hombre
Total: 150 horas-hombre

Estas horas-hombre pueden luego, fácilmente, multiplicarse por el coste por hora y se sabe de antemano el costo de desarrollo del proyecto (o sea, 1500 euros en el caso de un desarrollador freelance y 150,000 euros en el caso de un desarrollador certificado de consultoría de Oracle).

Las horas-hombre (o su múltiplo, meses-hombre, equivalente a 160 horas) conducen a la deducción equivocada que si una parte requiere 10 horas-hombre entonces diez personas lo completarían en 1 hora. Es dolorosamente indiscutible que TODO líder de proyecto de desarrollo caerá en esta falacia, usualmente en su primer proyecto y, hasta que alguien no se lo señale, fallará en ver que es lo que está pasando mal.

La Ley de Brooks lo dice que «Añadir mas personal a un proyecto tardío sólo logrará retrasarlo más«. Esto significa que cuando un proyecto va retrasado y se intentan añadir desarrolladores nuevos no se toma en cuenta el tiempo el tiempo añadido que le lleva a los nuevos elementos el familiarizarse con el mismo, y que el tiempo adicional perdido en comunicaciones entre ellos puede aumentar tanto que puede llegar a rebasar el tiempo disponible (hay una fórmula al respecto, donde se muestra que a medida que se añaden elementos a comunicar el tiempo dedicado crece de tal manera que al final el 100% del tiempo se dedica a comunicación y el desarrollo se detiene).

¿Qué se puede hacer cuando un desarrollo está retrasado?
Las opiniones aquí son varias y variadas, y no hay ninguna que sea 100% adecuada, ya que depende mucho de la situación específica del proyecto y el cliente, pero el resultado final suele ser que la fecha de entrega del proyecto se retrasa (con o sin cargo adicional al cliente, usualmente el segundo) y en casos extremos el proyecto se cancela totalmente.

La única forma de evitar este problema es a través de delineación adecuada de etapas, metas y módulos en el proyecto y de una distribución adecuada de los recursos asegurándonos de tener localizados a aquellos programadores «estrella» que son capaces de moverse de uno a otro trayendo resultados inmediatos con el mínimo de preparación.

The Mythical Man-Month (El mítico mes-hombre), de Fred Brooks.
El libro ‘El mítico mes-hombre’ de Fred Brooks surge de sus experiencias en IBM y su error de intentar acelerar el desarrollo añadiendo mas desarrolladores al mismo, que es el tema central del libro. En el libro se manejan varios conceptos, de los cuales destacan:
El mítico mes-hombre
Arriba ya he comentado algo de este concepto, conocido como la «Ley de Brooks» pero cabe aclarar que la Ley se suele interpretar de forma incorrecta. Dependiendo de como se entienda puede pensarse que lo que sugiere es que un proyecto debe ser desarrollado por grupos pequeños de programadores altamente capaces, pero la realidad es que el concepto lo que cubre es la adecuada planeación del proyecto y la capacidad de dividir el mismo en módulos separados y que se puedan desarrollar de forma independiente. Específicamente la Ley de Brooks no dice que quitando personal de un proyecto se pueda acelerar su terminación (que podría ser una consecuencia lógica de invertir el postulado).

El efecto del ‘Segundo Proyecto‘
De este problema también son víctima casi todos los líderes de proyectos cuando, después de haber completado el primero deciden aplicar al segundo todo lo que han aprendido. El segundo sistema que haga un jefe de proyecto siempre estará horriblemente sobre-diseñado. En un intento de evitar los problemas encontrados en el primer proyecto el jefe de proyecto sobre compensará cayendo en el extremo opuesto.

El ‘equipo quirúrgico’
Todo jefe de desarrollo debe ser capaz de tener en su equipo al menos una persona e idealmente un conjunto de ellas capaz de atacar cualquier problema que surja. La idea es tener a estos grupos dedicandose a varios proyectos en áreas especialmente problemáticas o con labores asignadas pero capaces de entrar de emergencia en alguna etapa problemática. El concepto es bastante similar al concepto de «Electrón Libre» de Rands

Seguimiento del Proyecto
Metas y etapas (milestones) deben ser definidas de antemano para el proyecto, con fechas límite y conjuntos de funcionalidad mínima requerida. La única forma de evitar el acecho de nuevas funcionalidades es mantener el objetivo inicial hasta su conclusión y sólo entonces introducir mejoras al diseño original (la única excepción a esto siendo los «electrones libres», gracias a su capacidad especial de genios y aún en estos casos debe controlarse de cerca. Esto está atado directamente a…

Congelación de código y versionamiento
No existe ningun sistema perfecto y si no se decide un momento en que el código, esté como esté, se detiene y se declara la versión como terminada, jamás se producirían resultados. Escoger las funcionalidades que deben incluirse en cada versión y el momento en que el desarrollo se detiene hasta la próxima versión es vital para poder dar resultados. Obviamente el «síndrome de la versión 1.0» surge de aquí, pero la alternativa sería lo que se conoce como «vaporware». Proyectos que cada vez parecen tener más y mejor funcionalidad y capacidades, pero que nunca ven la luz del día.