Habilitar seguridad en Tomcat

Desarrolle unas demos para la empresa y para accederlas configure un subdominio de la empresa que apunta a un Tomcat 7. Pase la URL a los vendedores y sin problema accedian a las aplicaciones... como todo mundo... si realizabas la búsqueda en Google. En menos de tres días ya estaban en el indice del motor. Finalmente el objetivo de la venta es hacer visible al producto, por lo que sin quererlo ya estaba siendo promovido en internet. El tema aqui es que no podía quedar abierto por temas de inteligencia competitiva, por lo que procedi a habilitar la seguridad en tomcat, de manera muy rápida y sencilla.

Vamos a emplear lo que se denomina "Memory Realm", esto es, la autenticación es contra los datos de usuarios cargados en memoria... ¿de donde? Del archivo users.xml

Los pasos son:

1. Agregar en la tag <Engine></Engine> a conf/server.xml lo siguiente: <Realm className="org.apache.catalina.realm.MemoryRealm" />
2. Editar o crear el archivo conf/tomcat-users.xml, un ejemplo puede ser: <?xml version='1.0' encoding='utf-8'?><tomcat-users>  <role rolename="test"/>  <user username="user" password="pass" roles="test"/></tomcat-users>
3. El paso anterior crea un usuario "user" con el rol "test". 
4. Finalmente, hay que modificar el archivo XML de la aplicación Web (web.xml) y agregar algunos parámetros para que solicite autenticación: 

      <security-constraint>
        <web-resource-collection>
          <web-resource-name>
            Protected Site
          </web-resource-name>
          <!-- This would protect the entire site -->
          <url-pattern>
            /*
          </url-pattern>
          <!-- If you list http methods,             only those methods are protected -->
          <http-method>
            DELETE
          </http-method>
          <http-method>
            GET
          </http-method>
          <http-method>
            POST
          </http-method>
          <http-method>
            PUT
          </http-method>
        </web-resource-collection>
        <auth-constraint>
          <!-- Roles that have access -->
          <role-name>
            test
          </role-name>
        </auth-constraint>
      </security-constraint>
      <!-- BASIC authentication -->
      <login-config>
        <auth-method>
          BASIC
        </auth-method>
        <realm-name>
          Example Basic Authentication
        </realm-name>
      </login-config>
      <!-- Define security roles -->
      <security-role>
        <description>
          Test role
        </description>
        <role-name>
          test
        </role-name>
      </security-role>
      ..
      <?xml version="1.0" encoding="iso-8859-1"?>

La configuración anterior, obliga a que cualquier recurso que quiera ser accedido debe estar autenticado el usuario y tener el rol test.

Utilerías para desarrollo con Javascript

En la actualidad dedico no más de un 20% de mi tiempo a programar, sobre todo demos o POC's. Los desarrollos son en la plataforma Windows Server 2008, con Java empleando el modelo MVC y por lo tanto, AJAX y Javascript en la capa de la vista.

 

Javascript no es un lenguaje que me guste si no es a través de un framework como JQuery o Ext JS que lo estructuran de una manera limpia y entendible, pero cuando desarrollo o desarrollan las personas que me apoyan el código tiende a ser desordenado, ilegible y extenso. Al terminar los módulos, en mi proceso de revisión me di a la tarea de depurar el producto resultante con dos sencillas herramientas en línea que no solo le dan otra presentación, son muy útiles para identificar vicios ocultos y mejorar la codificación.

 

Javascript Beautifier

Permite copiar el código y lo formatea, agrega tabulaciones y elimina espacios en blanco y cambios de línea innecesario.
La liga es: http://jsbeautifier.org/

 

Code Compactor

Permite crear versiones reducidas de las librerías o componentes JS, de manera que cuando se promueve a producción, se tenga la versión "optimizada" de la librería JS.
La liga es: http://www.meanfreepath.com/tools/jscompactor.html

Diseño físico y lógico de una solución tecnológica

Este es una tema de la licenciatura y son conceptos que asumiría básicos que cualquier ingeniero en sistemas debería manejar. Sin embargo, me he encontrado que tanto colaboradores como cliente tienen conceptos diferentes de lo que lógico y físico significa, por lo que me he dado a la tarea de tratar de consolidar las diferentes definiciones de estos conceptos.

Diseño Lógico

Es la descripción de los requerimientos funcionales de la solución, independientemente del hardware y software que se requiere para su desplegado. En otras palabras, es la expresión conceptual de lo que hará el sistema para resolver los problemas identificados en el análisis previo.


Esta conformado por: casos de uso, escenarios, prototipos, diagramas "lógicos" ER, diagramas de flujo de datos DFDs, clases, paquetes, actividad, proceso, solución conceptual y arquitectura a alto nivel.

En el caso del diagrama de arquitectura, muestra a alto nivel los nodos, sin detallar canales de comunicación, componentes, artefactos y demás. Es más un apoyo ilustrativo que una guía para la instalación y configuración de los componentes.

Esta más enfocado el negocio.

Diseño Físico

Para este concepto, hago uso y enriquezco la definición de Vilmary Galindez. En el diseño físico se especifican las características de los componentes del sistema requeridos para poner en práctica el diseño lógico. Se emplean diagramas con mayor detalle técnico y con la premisa de que se deben brindar los elementos que permitan llevar a la práctica la solución definida.


En esta fase deben delinearse las características de cada uno de los componentes que se enumeran a continuación.

• Diseño de hardware. Debe especificarse todo el equipo de cómputo, lo que incluye dispositivos de entrada, procesamiento y salida, con sus características de rendimiento. Por ejemplo, si el diseño lógico especifica que la base de datos debe contener grandes volúmenes de datos históricos, se requerirá que los dispositivos de almacenamiento del sistema sean de gran capacidad. Se debe específicar 
• Diseño de software. Deben especificarse las características de todo el Software Por ejemplo, si en el diseño lógico se indica la necesidad de que de que los usuarios actualicen al mismo tiempo la base de datos, en el diseño físico deben especificarse un sistema de administración de base de datos que lo permita algunos casos se puede adquirir el software, mientras que en otros se desarrollan internamente. Las especificaciones de diseño lógico, en cuanto a requisitos de salidas, entradas y procesamiento de los programas, también se toman en cuenta durante el diseño físico del software. Así pues, se especificaría la capacidad de acceder a datos almacenados en ciertos archivos de disco que el programa utiliza.
• Diseño de bases de datos. Es necesario detallar el tipo, estructura y funciones de las bases de datos. Las relaciones entre los elementos de datos establecidas en el diseño lógico deben reflejarse también en el diseño físico. Estas relaciones incluyen aspectos tales como las rutas de acceso y la organización de la estructura de archivos. Por fortuna, existen muchos sistemas excelentes de administración de bases de datos que son útiles para esta actividad. 
• Diseño de telecomunicaciones. Deben especificarse las características necesarias del software, medios y dispositivos de telecomunicaciones. De tal suerte, si el diseño lógico indica que todo los miembros de un departamento deben compartir datos y software, ha de hacerlo posible la configuración de la red de área local y el software de telecomunicaciones especificados en el diseño físico.
• Diseño de personal. Este paso incluye especificar los antecedentes y experiencia de los individuos que más probablemente satisfagan las descripciones de empleos que se incluyen en el diseño lógico. 
• Diseño de procedimientos y controles. Comprende detallar la forma en que se ejecuta cada aplicación y las medidas para minimizar las probabilidades de fallo. Tales especificaciones incluyen métodos de auditoria, soporte y distribución de salidas.

Es la especificación técnica detalla de la solución.

Analisis y modelado mediante procesos

Introducción 

Los proyectos de tecnología siempre iran enfocados a la mejora, lo que se hace actualmente y como una nueva solución o un cambio a la actual, favorecen que los resultados sean más rápidos, precisos y fiables.

El levantamiento de requerimientos y su traducción a especificaciones técnicas normalmente representa el gran reto para todo consultor en TI. Para poder llevar a cabo esta labor de manera correcta y productiva, el cliente debe indicar CLARAMENTE que es lo que desea mejorar, el tema es que sabe a alto nivel lo que espera: disminuir costos, mejorar el nivel de servicio, disminuir costos mediante el manejo de formularios electrónicos, etc.; el detalle pide que lo veamos con la gente que lo hace, es decir, los que operarán el sistema. Ellos no saben que debe hacer, saben como se hace actualmente y que podría mejorarse.

Entonces, el consultor debe:

1. Entender la visión de mejora global que se tiene.
2. Conocer como se hacen las cosas actualmente.
3. Proponer como se puede hacer "mejor".
4. Documentar como deben ser estos cambios o nuevas funcionalidades.

Muchas metodologías indican que se deben seguir los siguientes pasos a grandes razgos:

1. Solicitar una lista de requerimientos.
2. Priorizar los requerimietos.
3. Establecer sesiones para detallar los requerimientos y documentar la mejora/solicitud a través de un caso de uso.
4. Implementar el caso de uso.
5. Validar su funcionamiento (pruebas).
6. Liberarlo al usuario.

El problema reside en que el usuario de entrada no sabe a detalle lo que desea, por lo tanto el detalle del requerimiento es subjetivo, esta enfocado en lo que quiere hacer más rápido y fácil, no necesariamente que de más valor al negocio. Pero como el consultor no lo sabe, lo asume como correcto. Esto se plasma posteriormente en un caso de uso, unidad aislada de funcionalidad solicitada a través de un requerimiento, y se implementa. Este subproducto es entregado al usuario y empieza a utilizarlo. El problema surge cuando empieza a recibir los bloques "independientes" de funcionalidad y surgen nuevas inquietudes y solicitudes de integrar las funcionalidades, hacer ajustes, compaginar resultados, etc... empiezan los controles de cambio, retrasos, costos adicionales y otro etc.


El modelado de procesos brinda una visión holística del entorno, como es y como debe mejorar de forma integral; por lo que, permite atender estos puntos indispensables para poder llevar a cabo la especificación de los requerimientos, su modelado y posterior el diseño e implementación de manera adecuada ya que:

1. Permite conocer la empresa y sus procesos, con esto, donde aplica la necesidad de mejora y como impacta el funcionamiento actual, permitiendo proponer ajustes en la cadena de procesos que se vea impactada.
2. Permite el entendimiento del proceso de negocio de forma integral, no por funcionalidad.
3. El modelo de caso de uso y el detalle de cada uno, entrada para el diseño e implementación, presenta una mayor coherencia al brindar al análista la visión de lo que se debe atender de manera global, no solo tareas especifícas. 

Aquí menciono caso de uso, aplicable más al proceso unificado (UP), pero puede ser un escenario (SCRUM).

Niveles de proceso 

Para llevar a cabo el modelado del proceso es importante conocer los niveles presentes en una organización y aunque no necesariamente se modelan todos, se debe tener claro en cual de ellos se centra el esfuerzo de análisis y modelado para tener un contexto del alcance de la solución.

1. Nivel 0: Macroprocesos. Brindan el contexto de la organización, que hace (cadena de valor), que áreas hay, que procesos son primarios y cuales secundarios (soporte). 
2. Nivel 1: Procesos. Describen lo que se hace a nivel funcional (áreas).
3. Nivel 2: Subproceso. Indican quien hace que (actividad), que recibe y que entrega. Muestra los roles.
4. Nivel 3: Actividad. Mediante diagramas de flujo, ilustran lo que sería una instrucción de trabajo. Un solo rol la ejecuta.
5. Nivel 4: Tareas (Transacciones). Son atómicas y pueden (no siempre se llega a este nivel), describir funciones, estados, etc.

Los casos de uso o escenarios surgen a partir del nivel 4. El consultor de procesos, con rol de analista, debe entregar al diseñador, consultor de ti, los documentos de caso de uso correspondientes a este nivel con la especificación del caso, modele datos, prototipos, etc.

Procedimiento propuesta

1. Elaborar mapa de procesos.
2. Elaborar el diagrama de cada proceso, las opciones son:
1. Alto nivel de cada proceso (SIPOC).
2. Diagrama de despliegue con BPMN, identificando las áreas involucradas.
3. Por cada subproceso del paso previo, elaborar el diagrama BPMN a nivel Actividad e identificar los roles participantes.
4. Por cada actividad del paso previo, elaborar diagrama de flujo (UML de Actividad),  donde cada bloque es una acción atomica.

La siguiente figura muestra el SIPOC de este procedimiento (v1.0).

Los formatos se pueden generar o encontrar facilmente en internet.

Modelado de procesos - Diagrama SIPOC

Descripción

Un diagrama SIPOC es una herramienta utilizada por un equipo de mejora de procesos para identificar todos los elementos relevantes de un proyecto de mejora de proceso antes de comenzar el trabajo. 

SIPOC significa:

Supplier (proveedor): El que proporciona las entradas al proceso; puede ser una persona u otro proceso
Input (entrada): Material, información, datos, documentación, servicio que se necesita para realizar las actividades del proceso
Process (proceso): Una secuencia de actividades que añaden valor a las entradas para producir las salidas
Output (salida): Producto, servicio, información, documentación que es importante para el cliente
Customer (cliente): El usuario de la salida del proceso


La herramienta SIPOC es particularmente útil cuando no está claro:

• ¿Quién suministra insumos para el proceso?
• ¿Qué especificaciones se colocan en las entradas?
• ¿Quiénes son los clientes verdaderos del proceso?
• ¿Cuáles son los requisitos de los clientes?

En la metodología Six Sigma esta técnica es el punto de partida para identificar la Voz del Cliente (VOC). El diagrama proporciona una visión inicial de los factores vitales (los Xs) para el proceso [Y = f(X)] que tienen un impacto significativo sobre el resultado (Y).

El diagrama SIPOC también es información principal para la definición detallada y la mejora de un proceso.

Como se elaborá

Los pasos son:

1. Proporcionar un área en la que el equipo pueda fácilmente dibujar y modificar el diagrama. Esto puede ser una pizarra blanca, pantalla en la que se proyecta el diagrama si se hace a través de una herramienta, rotafolio, etc.
2. Dibuja el mapa del proceso empezando de las 4 ó 5 actividades a más alto nivel. Puedes dibujar cada actividad debajo del rol que la ejecuta.dentificar las salidas (Outputs) del proceso.
3. Identificar las entradas (Inputs) que se necesitan para realizar el proceso correctamente.
4. Identificar a los proveedores (Suppliers) de las entradas necesarias.
5. Identifica a los clientes que van a recibir estas salidas del proceso.

Ejemplo

Este diagrama es un ejemplo de un SIPOC para seguimiento de actividades, con algunas variantes para indicar las herramientas empleadas.

Plantillas

En las siguientes URLs se pueden obtener plantillas listas para usar:

• Adobe Acrobat (.PDF)

• Microsoft PowerPoint (.PPT)

¿Porque evaluar a los empleados?

Tanto en los trabajos que he tenido como en las empresas para las cuales he prestado servicios como externo, llega un momento en que es necesario medir y evaluar el desempeño. Siempre que llega este momento, la gente (me incluyo) se pregunta el porque. Una parte de la gente toma la evaluación como algo negativo, siente que hay desconfianza hacía las labores que están realizando. Lo mismo sucede cuando se trata de reportar horas.

Siempre que vamos a ser "auditados" nos llena una sensación de riesgo y pesadumbre. Creo que el transfondo de esta situación es que no tenemos claro para que nos evaluan (nos van subir el sueldo, va a ver recorte, me aumentarán responsabilidades son algunas de las primera preguntas). Puede ser, si evaluas y todo es muy bueno, un incentivo no está mal.

Factores que se evaluan

• Conocimiento del trabajo
• Calidad del trabajo
• Relaciones con las personas
• Estabilidad emotiva
• Capacidad de síntesis
• Capacidad analítica

Propósitos

Enlisto 8 puntos de Robert D. Behn, quien organizó todas las razones que pudo encontrar que justifican el medir el desempeño y creo estos propositos específicos:

1. Evaluar: Saber que tan bien te desempeñas. 
2. Control: Una forma de controlar es medir lo que la gente hace.
3. Presupuestar: Capacitación, cursos, bonos, etc... son elementos que dependen del desempeño para su asignación.
4. Motivar: La evaluación es útil porque permite identificar y reconocer aquellos aspectos que contribuyen al máximo el desempeño del trabajo.
5. Promover: Un buen desempeño habre la posibilidad de ascensos objetivos, lejos de favoritismos.
6. Celebrar: A todos nos gusta festejar y que mejor que sean causas reales y justificadas como un logro o alcanzar una meta.
7. Aprender: Para detectar necesidades de adiestramiento y capacitación. El desempeño insuficiente puede indicar la necesidad de volver a capacitar. Un desempeño superior puede indicar la presencia de un potencial mal aprovechado.
8. Mejorar: Todos los puntos anterior estan enfocados en MEJORAR.

La medición del desempeño no es un fin, es un instrumento que nos permite cuantificar aspectos relevantes en el desempeño de nuestro trabajo, identificar áreas de oportunidad y establecer estrategias de desarrollo de las personas. Si la persona generá para si todos estos elementos (autocrítica, mejora continua, autodidacta, etc), cuando la evaluen seguramente tendrá un excelente resultado y no sería nada raro que ascendiera. Esto nos lleva a que además de capacidades actuales y adquiridas, la actitud es uno de los grandes valores y el pesimismo ante retos o posibles amenazas, una gran debilidad.

Lo importante y lo urgente

Señala MacKenzie que un trabajo urgente es aquel que debe hacerse de inmediato, pero eso no significa que deba ser importante. Puede ser vital para conseguir tus objetivos a largo plazo… o puede que no.

Debemos distinguir entre cuatro categorías: lo importante y urgente, lo no importante y no urgente, lo importante y no urgente y lo no importante y urgente.

Según los expertos, debemos centrarnos primero en lo importante por encima de lo urgente, con las excepciones lógicas, aunque hay gente que es adicta a la urgencia. Cuanto más urgencia tenemos, menor es la importancia de lo que hacemos. Una fórmula para hallar la diferencia entre urgente e importante es preguntarse si la tarea urgente nos ayudó a conseguir un objetivo importante.

• Lo importante y urgente: Ésta sería la categoría de los desafíos. Muchas actividades importantes se vuelven urgentes porque las postergamos más de lo necesario o porque nuestra planificación de actividades es insuficiente.

• Lo importante pero no urgente: Ésta es la categoría de la calidad y el liderazgo personal, es dónde planificamos a largo plazo, anticipamos y prevemos problemas, otorgamos poder a los demás o nos preparamos para reuniones y presentaciones importantes.

• Lo urgente y no importante: Es la categoría del engaño. Atienden a este nombre muchas llamadas de teléfono, reuniones de última hora, visitas inesperadas, etc. Pasamos mucho tiempo en esta fase para satisfacer las prioridades y expectativas de los demás, creyendo que estamos en la primera categoría.

• Lo no ugente y no importante: Son las pérdidas de tiempo por antonomasia. Entraría dentro de esta categoría todo aquello que no encaje en nuestro trabajo (por ejemplo, el chismorreo en la máquina de café, navegar en Internet sin ningún objetivo, etc.).

Por lo tanto:

Para tomar decisiones acertadas sobre el uso de tu tiempo es necesario que distingas entre lo importante y lo urgente, de tal forma que:

• Lo importante y urgente: ¡Hazlo ya!
• Lo importante pero no urgente: ¡Aplázalo!
• Lo urgente y no importante: ¡Delégalo!
• Lo que no es ni urgente ni importante: ¡Descártalo!