indexante

Una importante característica de los grandes programadores es la meticulosidad con la que construyen. Saben que les pondrán diez no por el esfuerzo, sino por los resultados;

Eric S. Raymond en La Catedral y el Bazar, ensayo clásico del software libre.

Hicimos muchos cambios, el nuevo sitio permite muchas cosas, revísenlo, comentenlo, critiquelo, es costumbre de la casa escuchar las opiniones, luego vienen un post con más detalles, por ahora me pueden agregar en elcomercio.pe/cesars

Actualización : en el blog de Medios Digitales publicamos algunos videos de los momentos previos de la migración, aqui uno junto con Mariella contando algunos detalles.

Eso es como ver que tipo de ladrillos va a usar, antes de hacer los planos.

Optar por una tecnología requiere un mejor análisis, puedes terminar gastando en licencias de software que no necesitas o usar un CMS de reciente creación sin soporte, esto es especialmente peligroso cuando comienzas tu emprendimiento dospuntoalgo y no tienes un super presupuesto. Errar en esto te puede costar el proyecto.

Primero elabore objetivos y en base a ellos decida que tecnologías ayudaran a lograrlos, comenzar diciendo “este proyecto usara ajax” por que si es una mala señal, las decisiones técnicas van en base a los objetivos planteados, la audiencia y el presupuesto.

Objetivos medibles antes que tecnología de moda.

En proyectos web tienes que atreverte a hacer, intentar y volver a intentar, no esperes a tener todos lo elemento necesarios para poder comenzar (no hay Cloud Servers? usa hosting tradicional, etc), avanza con lo que tengas, pregunta a quien necesites preguntar e itera tu proyecto.

De estos intentos pueden suceder 2 cosas :

• Si sale mal, bueno al menos tuviste la experiencia de hacer algo por ti mismo y aprenderás de la lección.
• Si sale bien, ¡felicitaciones! el éxito viene de la mano con el trabajo, disfruta lo que es tener un proyecto propio y valorado por usuarios de verdad.

Eso es mejor a solo decir que seguramente “tu lo puedes hacer mejor”, una cosa es decir y otra hacer, no sea comentarista 2.0, intente jugar, necesitamos buenos ejemplos.

El fin de semana algunos sitios del Estado fueron atacados por defacing, no es la primera vez que pasa y si no aprendemos la lección no creo que sea la ultima.

El problema de seguridad en las instituciones estatales no es nuevo, la soluciones en caja sin actualizar, el bajo nivel de educación informática, la seguridad como solo un item en toda la carrera, los bajos sueldos o la contratación de personal con poca experiencia, los convierten en presa fácil de defacers y festín de pseudo consultores de seguridad.

Esto demuestra la débil situación de los sistemas del estado, no se puede esperar que la próxima vez sea un ataque serio a sistemas vitales de la nación, la necesidad de un área de seguridad informática como prevención y respuesta dentro de las FFAA es clara. ONGEI tiene que ponerse las pilas con este asunto.

Tanto en estado como en empresas privadas, la política debe ser seguridad por default, programadores conscientes de la seguridad al escribir sus programas, mantener el software actualizado, practicar hacking ético en sus sistemas, contratar personal capacitado y experimentado son buenas formas de comenzar.

Antes esto las comunidades de usuarios y las empresas son las llamadas a evangelizar sobre la seguridad en las tecnologías que promueven.

La seguridad es una práctica constante, y en ningún caso un item para dejar fuera del presupuesto.

Mañana sábado 14 estaré en el FESOLI 2009 hablando sobre software libre y medios digitales, compartiendo la experiencia del trabajo que llevamos en los sitios del Grupo El Comercio con las tecnologías abiertas.

Me toca la primera ponencia, 9:00 am, ahí nos vemos.

Ayer dejamos de usar sistemas de tickets para el control de incidencias, normalmente los formularios son restrictivos e insuficientes en el nivel de detalle para describir los casos, y en ocasiones tienden a aumentar la burocracia.

Ahora usamos un wiki, un entorno más adecuado para documentar tickets y nuevos desarrollos, y que hasta ahora da buenos resultados.

Aunque este es un pequeño ejemplo el punto es que si el equipo de desarrollo nota que el método no contribuye a crear un mejor producto algo va mal y deben buscarse alternativas.

A veces es necesario sacrificar método para ganar agilidad.

Gracias a una gentil invitación del Instituto Continental estaré en la I Jornada de Innovación en Gestión y Tecnología en la ciudad de Huancayo, el evento comienza este viernes, a mi me toca el sábado hablando sobre Empresas basadas en la web, intentare hacer una transmisión en vivo si la conexión lo permite, si estas en la ciudad es una buena oportunidad de juntarse y hablar de tecnología junto con otros colegas del medio, ahí nos vemos.

A propósito de un post anterior, voy recomendando una lectura : Diseño de Interfaz de Usuario para Programadores, una serie de artículos (traducidos al español) escritos por Joel Spolsky, acerca de estos dilemas de programadores y como la gente intenta usar las cosas que creamos.

En la imagen, un ejemplo del capitulo 3 acerca de las decisiones que al usuario no le importan ni debería hacer :

El primer problema con este diálogo es que te distrae. Estás intentando encontrar ayuda en el fichero de ayuda. En ese particular momento, te importa un carajo si la base de datos es pequeña, grande, personalizada o cubierta de chocolate (...)

El problema viene cuando les pides que tomen una decisión sobre un tema que no les importa.

Gracias Joel.