archivo

Archivos Mensuales: octubre 2009

Desde hace años tengo la práctica de anotar las tareas que tengo pendientes de realizar y reconozco que a día de hoy no podría trabajar de manera adecuada sin hacer uso de esa técnica.

¿Qué me aporta?

1) Recibo peticiones de diferentes personas y temáticas, las cuales en su mayoría requieren un tiempo moderado para su realización. La anotación de las mismas permite, reducir el riesgo de que se me olvide hacer algunas de las tareas y me permite priorizarlas.

2) Tener las tareas anotadas y poder verlas en su conjunto favorece el proceso de priorización que he comentado en el punto anterior y además simplifica la agrupación de tareas y la reflexión sobre las mismas, lo que permite tomar mejores decisiones sobre las mismas.

3) La anotación de tareas y la señalización de las que están hechas, es un elemento de motivación muy importante.

4) Disminución del tráfico mental. Si tengo la tarea anotada, disminuye o desaparece la necesidad (sensación) de tener que recordar que hay que hacerla, ya que si se olvida está registrada en un sitio que voy a mirar seguro.

Me he referido en este post a lo que es el hecho de anotar las tareas sin indicar qué instrumento utilizar para realizar dichas anotaciones, ya que entiendo que lo importante es el hecho de la anotación en sí, por encima de la herramienta que se utilice, aunque el uso de una herramienta adecuada puede hacer todavía más productivo si cabe el proceso de la anotación de tareas.

En mi caso utilizo un método un tanto rudimentario, como es un cuaderno. He hecho algunas pruebas con algún software pero no han sido positivas por falta de disciplina por mi parte, ya que como me muevo mucho, me resulta mucho más cómodo anotar las tareas en mi cuaderno y no tener que trascribirlas a continuación a una aplicación. En cualquier caso reconozco que tengo que evolucionar en este sentido e ir más allá al uso del cuaderno, pero independientemente de eso, también tengo que reconocer que desde hace mucho tiempo, el uso del cuaderno me ha traído muy buenos resultados.

Otro aspecto que considero también importante es el repaso semanal de las tareas pendientes, ya que favorece esa visión global de las tareas que comenté anteriormente y por consiguiente ayuda a la priorización, agrupación y reflexión sobre las mismas.

Tal y como publica Genbeta, Google y Microsoft han llegado a un acuerdo con Twitter para devolver sus resultados a través de sus respectivos buscadores. De hecho Bing, ya ha realizado una integración.

Supuestamente ambas habrán llegado a unos términos de acuerdo similares con Twitter, por lo que la plataforma que tendrá más éxito será aquella que consiga integrar mejor dichos resultados y que estos sean relevantes para el usuario.

En cualquier caso quien ha salido ganando en todo esto es Twitter que obtendrá unos beneficios económicos de ambos acuerdos, ya sea directamente, a través de una participación en los ingresos por publicidad o en una mezcla de ambos conceptos. Esto viene a demostrar que por muy simple que sea la idea de Twitter, lo importante es la atención que se es capaz de generar y Twitter lo ha conseguido, tiene toda una legión de usuarios fieles que no paran de aportar contenidos y de convertir el servicio en un auténtico pulso del mundo.

La atención vale dinero y no solo eso, produce dinero. Muchos dudaban (dudan) del modelo de negocio de Twitter, pues ahí tenemos un ejemplo de fuente de ingresos. La cual se mantendrá, se incrementará o desaparecerá en función de si Twitter sigue generando interés entre la comunidad de usuarios. Así es la economía de la atención.

Otro aspecto importante en la negociación que habrá llevado a cabo Twitter es que ninguno de los acuerdos adoptados es en exclusividad lo que le ha permitido “vender” sus servicios a ambas plataformas y le da vía libre para otros posibles acuerdos en el futuro.

En la entrada de Genbeta, se comenta que Microsoft también ha llegado a un acuerdo con Facebook para integrar en las búsquedas de Bing sus resultados. Habrá que ver cómo se articula esto teniendo en cuenta que la información de Facebook es en su mayoría de acceso restringido.

Ya nos pasó a todos cuando estudiábamos. Cuando más conseguíamos rendir era en los días previos a los exámenes. Muchas veces ese sprint final permitía que llegásemos al aprobado o consiguiéramos mejores notas, pero si se dejaba todo en manos de ese último impulso podría ocurrir que no diera tiempo de estudiarnos todo el temario con la suficiente profundidad y suspender (o no sacar la nota que nos habíamos marcado como objetivo).

Los seres humanos somos así, la cercanía del momento decisivo hace que nos pongamos las pilas y empecemos a rendir con el nivel que hubiéramos deseado desde el principio.

En el proceso de desarrollo de software se repite, como no podría ser de otra forma, esta máxima, normalmente la proximidad de una fecha de entrega mejora el rendimiento y productividad del equipo (por regla general, también la cantidad de tiempo que se dedica al proyecto, empujado por la necesidad de querer cumplir los plazos). También es cierto que la mala evaluación de las fechas de entrega, siendo demasiado exigentes en muchos casos, obliga en gran cantidad de ocasiones a hacer este sprint final por mucho que se apriete o se mantenga un nivel alto de rendimiento en todo el proyecto.

Por tanto, el sprint final va a ser necesario en la mayoría de los proyectos de desarrollo de software (esos famosos picos de trabajo), que va a durar más cuanto peor esté estimado el proyecto en tiempo y/o recursos (picos de trabajo continuos (y que darán lugar además de tener quemado al equipo del proyecto a una merma en la calidad del producto y a un más que probable retraso en la entrega)) pero que en cualquier caso es necesario mantener un ritmo constante para terminar el proyecto en fecha, ya que si no se ha avanzado lo suficiente antes del sprint final será muy complicado que se puedan cumplir los plazos con un nivel de calidad aceptable.

A diferencia de la ingeniería social donde el individuo se muestra más activo, poniéndose en contacto con las personas que pueden suministrarle la información necesaria para atacar o introducirse en un sistema, la ingeniería social inversa es pasiva, ya que en ella se pone la trampa y se espera cautelosamente a que alguien caiga en ella (la trampa puede estar dirigida a un colectivo concreto o bien a una generalidad de usuarios).

¿En qué consiste? En este caso el usuario es el que se pone en contacto (utilizando cualquiera de los medios que se suelen utilizar en la ingeniería social: de persona a persona, teléfono, sitio web, correo electrónico, red social, etc…), sin saberlo con la persona que desea obtener información de él y una vez establecido el contacto ésta obtiene la información necesaria para realizar el ataque o la intrusión. ¿Cuál es la trampa? Pues consiste en ponerle al usuario las miguitas de pan para llegar a él.

¿Algunos ejemplos?

– Descubro un sitio web en el que dicen que son expertos en arreglar determinados problemas relacionados con el ordenador. Una vez que me pongo en contacto con ellos a través de uno de los medios indicados anteriormente, obtienen la información que necesitan para un futuro posible ataque.
– Me llega al buzón de correos un anuncio o una tarjeta de una persona que arregla ordenadores. Lo conservo y pasado un tiempo el ordenador se estropea, me pongo en contacto con dicha persona y obtiene la información que precisa.
– (Uno más cinematográfico :-))Voy a un congreso de seguridad y una persona tiene en la solapa una acreditación de la marca del servidor de aplicaciones de mi organización, me acerco a él para hacerle algunas preguntas y termina siendo él el que obtiene información que puede resultar relavante para un posible ataque.

En la ingeniería social inversa no tiene por qué actuar siempre una persona para obtener información, ya que también se considera este tipo de prácticas al acceso a un sitio web y descarga de un determinado software que se encuentra infectado por un virus (en cualquiera de sus variantes: gusano, troyano, etc…) el cual puede servir para provocar vulnerabilidades en el sistema a través de las cuales realizar ataque. En este caso el reclamo ha sido un determinado software que podría resultarnos de interés.

Pero necesario.

Si tienes un puesto de responsabilidad y la carga de trabajo es superior a lo que puedes soportar y/o rompe el equilibrio que te permite hacer tu trabajo correctamente, es necesario delegar.

Delegar supone dar responsabilidades y confiar en el trabajo de la persona en quien se delega (importante es que la empresa u organización en la que trabaja te de medios para poder delegar, es decir, en primer lugar recursos humanos suficientes y en segundo lugar recursos humanos que respondan), delegar no es llevar un control exhaustivo de la persona en quien se delega, porque de lo contrario no se consigue el objetivo que se persigue con la delegación de responsabilidades que es principalmente tener más tiempo para desempeñar otras, tan importantes o más que la que has delegado.

Creo en las aplicaciones beta en producción, la web 2.0 ha demostrado que se pueden tener productos accesibles al ciudadano de muy buena calidad en fase beta.

Eso sí, creo en las betas con calidad, en betas que funcionan aunque tengan alguna funcionalidad que todavía quede por implementar o incidencias que haya que corregir, pero que unas u otras no impidan un desempeño eficiente del usuario con la aplicación.

No hay que confundir las betas con las famosas versiones 0. Cuidado con las entregas de aplicaciones basadas en el concepto de versión 0 que consiste en: “ahí te entrego el producto, le faltan funcionalidades, no es robusto (estas dos cosas evidentemente no te la dicen), y…, este…. funciona”. Cuando la aplicación empieza a hacer aguas y te diriges a quien lo ha desarrollado para solicitar cambios y la corrección de las incidencias, ya te están poniendo el cazo, para la versión 1 o la 0.5.

Atacar directamente a un modelo de datos de otra aplicación incrementa el grado de acoplamiento entre sistemas y cuando este modelo se extiende a la mayoría de sistemas de información de una organización, se entiende que está implantado lo que se denomina modelo en spaghetti.

La teoría dice que hay que intentar reducir al mínimo el nivel de acoplamiento y que una de las posibilidades para reducirla se encuentra en el uso de APIs que utilizarán la tecnología que se elija en cada caso para suministrarle a una aplicación la información que necesita de otra.

Hasta ahí todo bien y estoy de acuerdo. La reducción del nivel de acoplamiento minimiza impactos en terceras aplicaciones que consumen o graban datos ya que si se conserva el API (los cambios son internos (principio de caja negra)) las aplicaciones que hacen uso del mismo no se enteran.

Me considero bastante ortodoxo (muy teórico) en el desempeño de mi labor profesional y en consecuencia eso se traduce en muchas de las decisiones que tomo, que como ya he dicho muchas veces en este blog, a veces son acertadas y otras equivocadas, ya que la teoría no vale para todos los casos o bien porque la teoría no se ha aplicado o interpretado correctamente. Lo que me enseñaron en la facultad era teoría (por muchas prácticas que tuvieran las asignaturas) y es lo que aplico, aunque afortunadamente la experiencia y tropezarse contra muchas piedras (alguna de ellas más de una vez) permite que donde han habido errores intente abordar el problema de otra manera.

En el asunto de las API podemos realizar la siguiente clasificación: las APIs que se utilizan porque no hay otra forma de obtener/grabar información en otro sistema (es decir, aquellas en las que no tenemos acceso al modelo de datos) y aquellas que se ponen por encima de un modelo de datos al que sí podemos acceder. En el primer caso, no hay más remedio que utilizar el API. En el segundo tenemos la posibilidad de elegir y si tenemos la posibilidad de elegir no hay que caer (yo he caído), en el error de aplicar la teoría a rajatabla y si el API no está bien construido o no es lo suficientemente eficiente, utilizar el API por narices. Si el API original está en nuestra manos mejorarlo y en un tiempo razonable sí que puede ser solución continuar con su uso, en caso contrario yo recomiendo una implementación alternativa o atacar directamente al modelo de datos, ya que lo primero es que las aplicaciones funcionen de forma eficiente y con usabilidad para el usuario, la ortodoxia viene después.

No es este un post en contra del uso de APIs, en absoluto, antes al contrario, ya he comentado que estoy totalmente de acuerdo con su uso (y que en ocasiones no hay otro medio para acceder/grabar la información) y en sus fundamentos teóricos, lo que quiero decir con este artículo esta expresado al final del párrafo anterior: lo primero, el usuario.