Algunos consejos al desarrollador de PL/SQL - 2da parte

Que no te de miedo pedir ayuda

Es probable que, si eres un profesional del software, seas una persona muy inteligente. Estudiaste muy duro, perfeccionaste tus habilidades y ahora te das la buena vida escribiendo código. Resuelves casi cualquier problema que tocas y eso te enorgullece. Desafortunadamente, el éxito puede también hacerte egoísta, arrogante, y renuente a pedir ayuda cuando te atoras. Esta dinámica es uno los aspectos más peligrosos y destructivos del desarrollo de software.

El software es escrito por seres humanos; y por lo tanto, es importante reconocer que la psicología humana juega un papel importante en el desarrollo de software. Un ejemplo de esto es el siguiente.

Joe, un desarrollador con antigüedad en un equipo de seis, tiene un problema con su código. Lo ha revisado por horas, incrementando su frustración y sin poder encontrar donde está el bug. No se le ocurre ni siquiera pensar el pedir ayuda a sus compañeros porque ninguno de ellos tiene la experiencia de él. Finalmente, su cabeza no le da más y termina "dándose por vencido". Suspirando, levanta su teléfono y marca una extensión: "Sandra, ¿podrías venir y darle una revisada a mi código? tengo un problema el cual no encuentro en donde puede estar". Sandra pasa por su lugar y, de una rápida revisada al código de Joe, señala lo que para él debió ser obvio desde hace mucho. ¡Hurra! El código funciona, y Joe le da las gracias, aunque de hecho se siente apenado en su interior.

Pensamientos como "¿Cómo es que no lo vi antes?" y "Si hubiera pasado otros cinco minutos haciendo mis pruebas lo hubiera encontrado" pasan por la mente de Joe. Es entendible aunque también muy estúpido. El punto aquí es que con frecuencia no alcanzamos a ver nuestros problemas porque estamos muy metidos en nuestro propio código. Algunas veces todo lo que necesitamos es una nueva perspectiva, la visión relativamente objetiva de alguien sin nada en juego. No tiene nada que ver con la antigüedad, pericia o competencia.

Steven recomienda fuertemente establecer dentro de la organización los siguientes lineamientos:

Retribuye admisiones de ignorancia
Ocultar lo que no sabes acerca de una aplicación o su código es muy peligroso. Desarrolla una cultura de preguntas y peticiones de ayuda.

Pide ayuda
Si no puedes encontrar la causa de un bug en 30 minutos, pide ayuda inmediata. Puedes incluso idear un "sistema amigo", de tal manera que cada quien tiene asignado a alguien del grupo a quien se espera se le pida soporte. No te permitas (o a otros en tu grupo) estar por horas golpeándote contra la pared en una infructuosa búsqueda de respuestas.

Establece un proceso de revisión de código por un compañero
No permitas que ningún código se suba a producción sin que sea leído y criticado (en una manera positiva y constructiva) por uno o más desarrolladores en tu equipo

Continuar leyendo...

Algunos consejos al desarrollador de PL/SQL - 1ra parte

Leyendo el libro de Steven Feuerstein Oracle PL/SQL Programming 5ta ed. -el cual es dicho sea de paso material de referencia altamente recomendado para quienes desarrollan en PL- comparte los siguientes consejos que en su opinión son el resultado de haber capacitado, enseñar y trabajar con miles de desarrolladores en PL y en cuyo proceso ha obtenido algunas conclusiones sobre la forma en la que todos hacemos nuestro trabajo en el mundo de PL/SQL.

¡No desarrolles a las prisas!

Casi siempre estamos trabajando con tiempos de entrega apretados, o poniéndonos al día por alguno que otro contratiempo. No tenemos tiempo que perder y si mucho código que escribir. Asi que manos a la obra—¿cierto?

Falso. Si nos metemos así de pronto y de lleno a construir código convirtiendo al pie de la letra los requerimientos en cientos, miles o incluso cientos de miles de líneas de código, vamos a terminar con un caos total que es casi imposible de depurar y mantener.

No hay que entrar en pánico ante las fechas de entrega; lo más probable es que cumplas si haces una cuidadosa planeación.

Steven recomienda a resistir la presión de la entrega y a asegurarse de hacer lo siguiente antes de comenzar una nueva aplicación, o inclusive alguna parte específica de la aplicación:

Construir casos y scripts de prueba antes de escribir el código
Debes determinar como vas a verificar una implementación exitosa antes de escribir una sola línea código del programa. Haciéndolo, es más probable que la interfaz de tu programa sea la correcta, e identifiques plenamente qué es lo que tu programa necesita hacer.

Establecer reglas claras de como los desarrolladores escribirán las sentencias SQL en la aplicación
En general, Steven no recomienda que cada desarrollador escriba montones de SQL. En vez de eso, los queries que regresan un solo registro, inserts y updates deberían estar "ocultos" en procedimientos y funciones preconstruídos y bien probados (llamado encapsulamiento de información). Estos programas se pueden probar, optimizar y mantener de una manera más efectiva que solo sentencias SQL (algunas de ellas redundantes) desparramadas por todo el código.

Establecer reglas claras de como los desarrolladores manejarán las excepciones en la aplicación
Todos los desarrolladores del equipo deberían lanzar, manejar y registrar los errores de la misma manera. Para lograrlo, lo mejor es crear un solo paquete de manejo-de-errores que oculte los detalles de como se registran estos, que establezca como se lanzan y propagan las excepciones hacia arriba a través de bloques anidados, y que evite la codificación en duro de excepciones específicas-de-la-aplicación. Asegurarse de que todos usen ese paquete y que no escriban su propio código de manejo de errores complicado, que consume tiempo y que es propenso a errores.

Usar el "refinamiento paso a paso" (también llamado diseño top-down) para limitar la complejidad de los requerimientos a enfrentar en un momento dado
Si utilizas este enfoque, verás que las partes ejecutables de tus módulos son cortos y fáciles de entender, lo que hace que el código sea fácil de mantener y de mejorarlo con el tiempo. Los módulos locales o anidados juegan un papel clave en el seguimiento de este principio de diseño.

Estas son solo unas cuantas cosas importantes a tener en cuenta para antes de comenzar a escribir todo ese código. Solo recuerda: en el mundo del desarrollo de software, la prisa no solo hace cosas frágiles, prácticamente garantiza un generoso ofrecimiento de bugs y de fines de semana perdidos.

Continuar leyendo...

Fundamentos de Rendimiento de Software - Referencia rápida

Muchas veces cuando nos ponemos a programar nos olvidamos que no solo se trata de escribir líneas de código que "hagan algo" y ya, nos olvidamos que el ambiente de desarrollo en el que trabajamos no tiene ni la décima parte de la carga de trabajo que tiene un ambiente productivo y es en este último que sucede lo que no consideramos -en el peor de los casos- y tenemos que hacer una revisión de los puntos donde podría estarse presentando el cuello de botella. Leyendo una entrada en el blog de Cary Millsap me encontré con lo que él llama una "Referencia rápida sobre los Fundamentos de Rendimiento del Software" de los términos que deberíamos tener presentes cuando algo no funciona eficientemente.

Glosario

eficiencia Es la medida de cuantos recursos está consumiendo la ejecución de una tarea. Eficiencia es lo inverso a cuanto del tiempo total de servicio de la ejecución de la tarea puede eliminarse sin incrementar su capacidad ni sacrificar la función de negocio.

ocupación Es el valor de utilización de un recurso cuya tasa de transferencia se maximiza con un mínimo impacto en los tiempos de respuesta. El valor de ocupación para un número dado de canales de servicio es menor o igual que el valor mostrado a continuación:

# de canales de servicio	1	2	4	8	16	32	64	128
Ocupación	50%	57%	66%	74%	81%	86%	89%	92%

carga Competencia por un recurso inducido por las ejecuciones concurrentes de tareas, medida como utilización.

rendimiento Velocidad de ejecución de la tarea, medido ya sea como tasa de transferencia o tiempo de respuesta.

perfil Descomposición tabular del tiempo de respuesta, listado comúnmente en orden descendente de la aportación del tiempo de respuesta del componente.

demora en la cola Duración que una tarea pasa encolada en un recurso dado, a la espera de su oportunidad de consumirlo, medido en tiempo de ejecución por tarea: segundos por click.

tiempo de respuesta Duración de ejecución de una tarea, medido en tiempo por tarea: segundos por click. El tiempo de respuesta es la suma de la demora en la cola y el tiempo de servicio.

diagrama de secuencia Es un diagrama especificado en el Lenguaje de Modelado Unificado (UML), usado para mostrar las interacciones entre objetos en el orden secuencial en que estas ocurren. Este diagrama es útil para visualizar el tiempo de respuesta.

canal de servicio Un sub-recurso que comparte una sola cola con otros sub-recursos, como una cabina de cuota en un centro comercial o un CPU en una computadora SMP.

tiempo de servicio Duración que una tarea pasa consumiendo un recurso dado, medido en tiempo por ejecución de tarea: segundos por click.

tarea Unidad de trabajo orientada al negocio. Éstas pueden anidarse: imprimir facturas es una tarea; imprimir una factura—subtarea— es también un tarea.

tasa de transferencia Conteo de las ejecuciones completadas por la tarea dentro de un intervalo específico de tiempo: clicks por segundo.

utilización Uso de recurso dividido por capacidad por un intervalo de tiempo específico; una medida cuantitativa de carga.

Principios

1. Un diagrama de secuencia es una herramienta útil para conceptualizar el tiempo de respuesta, sin embargo, para tareas que ejecutan miles de invocacioes (incluso docenas), es más útil el perfil.

2. La tasa de transferencia es el recíproco del tiempo de respuesta. Si agregas carga para crear altas tasas de transferencia cambias el tiempo de respuesta ya que añades espera en la cola.

3. La diferencia entre el tiempo de respuesta de una tarea que tiene un recurso con carga ligera y su tiempo de respuesta con carga pesada es la espera en la cola.

4. La duración de una tarea en la cola para obtener un recurso depende del número de canales de servicio de ese recurso además de su carga:

1. Agregar canales de servicio reduce la espera en la cola para una carga dada. Sin embargo, el beneficio disminuye cuando los agregas.


2. Reducir la carga disminuye la espera en la cola para una determinada arquitectura. No hay un límite de escalabilidad para reducir la carga

5. La ocupación es el valor de utilización que define el umbral entre carga ligera y carga pesada sobre un recurso.

1. En un recurso con carga pesada, los tiempos de respuesta se degradan exponencialmente cuando la carga crece.


2. En un recurso con carga pesada, los tiempos de respuesta mejoran exponencialmente cuando la carga disminuye

6. Para sistemas con peticiones de servicio de tiempo aleatorio, permitir excesivas cargas sostenidas en los recursos con respecto al valor de ocupación resulta en tiempos de respuesta severamente degradados y tasas de transferencia que fluctúan constantemente con cambios microscópicos en la carga.

7. Para un conjunto de recursos de una computadora, no se puede mejorar el rendimiento haciendo que el código se ejecute velózmente; se puede mejorar el rendimiento solamente eliminando las instrucciones innecesarias en el código, o en el código que compite contra tu código para hacerse de recursos.

8. Mejorar el enfoque de tu código de manera eficiente reduce el tiempo de servicio y carga, los cuales mejoran el tiempo de respuesta, los cuales mejoran exponencialmente el rendimiento en recursos con demasiada carga pesada.

9. No se puede optimizar la tasa de transferencia de una tarea ineficaz. Para analizar la eficiencia de una tarea, se debe analizar su tiempo de respuesta. De aquí que, para optimizar la tasa de transferencia primero se debe analizar el tiempo de respuesta.

10. No le atinarás a la primera en donde es que un programa consume su tiempo, y que es ineficaz tratar de optimizar cualquier cosa que le veas. Analizar su comportamiento ayuda a escribir código que sea más veloz.

Continuar leyendo...

Creador y colaboradores de CentOS llegan a acuerdo

Vaya que sí resonó la carta publicada por el equipo de desarrolladores del proyecto CentOS ya que finalmente estos y Lance Davis se reunieron para llegar a acuerdos sobre los puntos mencionados en un post anterior donde los primeros solicitaban entre otros puntos, el que hubiera un delegado tanto para la administración del dominio 'centos.org' como de los canales IRC.

Ahora el proyecto está en control de los dominios 'centos.org' y 'centos.info', además de tener todos los derechos sobre las marcas registradas, materiales y trabajo gráfico contenido en las distribuciones de CentOS.

Por supuesto que no muere el proyecto, hay un plan de acción elaborado de mutuo acuerdo para los casos extraordinarios.

El proyecto es llevado completamente por voluntarios y están conscientes de que requiere un estilo diferente de administración. Han y continúan trabajando para evitar que situaciones como estas ocurran en el futuro.

Los desarrolladores están completamente comprometidos con el proyecto, por lo que seguiremos viendo actualizaciones sobre las versiones actuales, esperando también, por supuesto, nuevos releases.

Enhorabuena

Continuar leyendo...

¿Adiós a CentOS?

CentOS es una distro Linux -nacida del código fuente del Red Hat Enterprise(RHEL)- el cual cobró fuerza cuando Red Hat comenzó a comercializar su sistema operativo por medio de lincencias de uso y de soporte. CentOS por su parte surge como una alternativa de software libre ofreciendo la calidad y robustes de RHEL sin pagar costosas licencias y pólizas de soporte sosteniéndo el proyecto únicamente a base de donaciones.

El día de hoy el equipo base de desarrolladores de este proyecto, hizo pública una carta dirigida a su fundador Lance Davis.

Julio 30, 2009 04:39 GMT

Carta abierta a Lance Davis de los miembros que desarrollan CentOS.

Es lamentable que nos veamos obligados a escribir esta carta no nos quedó otra opción. De algún tiempo a la fecha hemos tratado de arreglar estos problemas:

Parece que te arrastraste hacia un agujero ... y no es aceptable.

Por mucho tiempo diste por hecho que habría fondos para el proyecto CentOS; al día de hoy no hemos visto nada.

Sólo tú tienes control del dominio 'centos.org' sin nadie más delegado; no es lo apropiado.

Sólo tú, así parece, eres el único que tiene privilegios de 'Fundador' en los canales de IRC sin nadie más delegado; no es lo apropiado.

Cuando traté de comunicarme (Russ) a los números telefónicos de Linux UK o a tu número, he escuchado el mensaje 'Líneas temporalmente ocupadas' durante las últimas dos semanas. Finalmente ayer, me respondió una máquina contestadora en la cual te dejé un mensaje solicitando que me regreses la llamada con caracter urgente. Karanbir reportó que también te ha llamado dejándote mensajes sin respuesta.

Por favor no mates CentOS sólo por el hecho de tener miedo en querer compartir la administración del proyecto.

Está claro que el proyecto muere si todos los desarrolladores se van.

Contáctame de favor, o a cualquiera de los demás que firman esta carta para ponernos de acuerdo sobre la información arriba mencionada y mantener vivo el proyecto con el dominio 'centos.org'.

Firman,

Russ Herrold
Ralph Angenendt
Karanbir Singh
Jim Perrin
Donavan Nelson
Tim Verhoeven
Tru Huynh
Johnny Hughes

CentOS ha sido adoptado por empresas de todos los calibres demostrando su calidad, sería una verdadera pena que por actitudes de esta naturaleza pudiera ver su fin un proyecto tan bueno como este.

Vía
CentOS Linux Project In Trouble

Continuar leyendo...