C# Recipe 2: How to calculate the date of the Easter Sunday.

Easter is the celebration of Christ’s resurrection from the dead. It is celebrated on Sunday, and marks the end of Holy Week, the end of Lent, the last day of the Easter Triduum (Holy Thursday, Good Friday and Easter Sunday), and is the beginning of the Easter season of the liturgical year.

As we know from the Gospels, Jesus Christ rose from the dead on the third day following his crucifixion, which would be Sunday.
Since the early Middle Ages, all Christians have used the same method for determining the date of Easter, though they arrive at a different result.

The following code calculates the easter sunday for a given year:

Listing 1. The main program

Listing 2. The Util class

Fig 1. Running the sample, output 1

Fig 2. Running the sample, output 2

Fig 3. Running the sample, output 3

Download source code

C# Recipe 1: How to calculate a leap year.

The Gregorian Calendar is the most widely used calendar in the world today.It is a reform of the Julian calendar, proposed by Aloysius Lilius, and decreed by Pope Gregory XIII, from whom it was named, on 24 February 1582 by papal bull Inter gravissimas

The changes made by Gregory also corrected the drift in the civil calendar which arose because the mean Julian calendar year was slightly too long, causing the vernal equinox, and consequently the date on which Easter was being celebrated, to slowly drift forward in relation to the civil calendar and the seasons. The Gregorian Calendar system dealt with these problems by dropping 10 days to bring the calendar back into synchronization with the seasons, and adopting the following leap year rule:


Every year that is exactly divisible by four is a leap year, except for years that are exactly divisible by 100; the centurial years that are exactly divisible by 400 are still leap years. For example, the year 1800 is not a leap year; the year 1984 is a leap year and the year 2000 too.

Fig 1 The following example calculates a leap year.

Fig 2 Running the sample, output 1

Fig 3 Running the sample, output 2


Download source code

Obtener el primer día del mes en curso con una función first_day() con PL/SQL en Oracle.

En PL/SQL existe la función LAST_DAY() con la que se obtiene el último día del mes en curso, entonces si tenemos que cumplir un requerimiento en donde necesitamos un campo o una variable con el último día del mes en curso simplemente ejecutamos esta función:

Ahora bien, si el requerimiento a cumplir se trata de obtener el primer día del mes en curso, no existe en PL/SQL Oracle una función predeterminada, por lo que para llegar a ese resultado basta con restarle un mes a la fecha en curso con la función ADD_MONTHS(), le aplicamos la función LAST_DAY() para obtener el último día del mes anterior y sumarle un día.

Aquí otra forma alterna de llegar al mismo resultado.


Descarga el código PL/SQL

Ruteo Inter-VLAN en un Router Cisco utilizando Router-on-a-stick

Una VLAN es técnicamente un dominio de broadcast diferente, por lo que de forma predeterminada no pueden comunicarse entre sí, salvo se usen diferentes técnicas de ruteo inter-vlan cada una de los cuales tiene sus ventajas y sus desventajas, a continuación mostraré un ejemplo de una técnica llamada “Router-on-a-stick”, que en resumen consiste en configurar una interfaz física de un Router para operar como un enlace troncal en el puerto de un switch, el Router efectua el ruteo intervlan de forma interna mediante el uso de subinterfaces, una subinterfaz es una interfaz virtual(vía software) que se crea en una interfaz física, por lo que se asocia cada subinterfaz con un número de VLAN, asi que podemos tener varias subinterfaces creadas en una misma interfaz física, lo cual presenta ventajas y desventajas que enumeramos a continuación.

Ventajas
  • Fácil de implementar solo se requiere crear una subinterfaz por cada VLAN en el Router.
  • Mucho más económica que tener un Router por VLAN.
  • Mucho mejor latencia que tener un Router por VLAN.
Desventajas
  • Los Routers son más lentos que los switches para ruteo inter-VLAN, lo ideal es tener un switch multicapa.
  • Si se necesita incrementar el número de puertos, entre más puertos requiera un Router más costoso resulta.
  • Estamos expuestos al buen funcionamiento de una sola interfaz física en el Router, esto es un único punto de fallo.

A continuación ejemplificaremos esta técnica con una práctica, los dispositivos son:

  • 4 PC’s
  • 2 switches
  • 1 router
  • 1 access point
  • 1 laptop

Al colocarlos en el WorkSpace del Packet Tracer debe ver más o menos como en la siguiente imagen:

Para la creación de las VLAN es conveniente el empleo de VTP para no teclear doblemente la configuración,asi que utilizamos el switch 1 (SW1,el que va unido al Router) como servidor y el switch 2 (SW2 el que tiene el access point) como cliente, empezamos la configuración en el SW1, con los siguientes comandos:

Comandos para el switch 1

En el SW2 tecleamos los mismos comandos para crear las troncales, la variante es la forma en que obtenemos las VLAN’s creadas en el SW1 por VTP.

Comandos para el switch 2

Para finalizar tecleamos los siguientes comandos en el router.

Comandos para el router


En la configuración IP de cada PC, debe de ponerse como gateway la ip de cada subinterfaz asociada a la VLAN dentro de la cual se encuentre configurada la PC.
Por ejemplo si una PC su ip es:192.168.20.2 y se encuentra en la VLAN 20 su gateway sera la IP 192.168.20.1 la cual se asigno a una subinterfaz asociada con la VLAN 20, como se muestra en las siguientes imágenes:

Igualmente si una PC su IP 192.168.30.2 es perteneciendo a la VLAN 30, entonces su gateway es la IP 192.168.30.1 que se asigno a la subinterfaz asociada con la VLAN 30

Aquí se muestra la comunicación inter-VLAN’s.

Descarga el archivo para packet tracer 5.3.2

Descarga los scripts con los comandos

¿Qué es el análisis postmortem en un proyecto de software?

En el contexto de los proyectos de desarrollo de software, un análisis Postmortem es el proceso de revisar la historia del proyecto para entender cómo cada uno de los eventos contribuyo al éxito o fracaso del proyecto.

En resumen: es el análisis retrospectivo realizado por todos los miembros del equipo de trabajo una vez que el proyecto concluye, sea exitosa o no esta conclusión.

Al realizar este análisis se busca identificar los aspectos positivos aplicados en el proyecto para que puedan repetirse, así como plantear soluciones y mejoras de los aspectos negativos, asimilando la experiencia para que no vuelvan a repetirse. Todo ello se conoce de forma simple como Lecciones Aprendidas.

Beneficios

Realizar un análisis de las experiencias buenas y malas adquiridas en el proyecto, es necesario para:

  • Identificar los aspectos que pueden mejorarse en proyectos futuros.
  • Obtener las experiencias de todos los involucrados en el proyecto, concentrando opiniones , puntos de vista y generando conclusiones en grupo.
  • Formar una base de conocimientos de “Lecciones Aprendidas” para que sean conocidas, revisadas y consideradas en otros proyectos con características similares.
  • Si hay un proyecto nuevo los recursos nuevos que tengan acceso a las lecciones aprendidas no tendrán justificación para repetir los mismos errores que se cometieron en sus proyectos anteriores.
  • Aplicar las lecciones aprendidas al proceso de estimación de un proyecto de software proporciona un par de beneficios, en principio, ayuda a la organización a prevenir desarrollar proyectos que no generan ganancias. Segundo, se orilla a que la estimación sea más precisa y exacta ya que la organización podría emplear un presupuesto inflado. Cuando la organización tiene confianza en sus estimaciones, es una organización más competitiva.

Actividades

  1. Aplicar cuestionario Postmortem.
  2. Realizar la reunión Postmortem.
  3. Registrar lecciones aprendidas.

Aplicar cuestionario Postmortem esta actividad se realiza para obtener las experiencias de los recursos que participan en algún momento en el proyecto y que por algún motivo salen antes de que este concluya. En la ejecución de esta actividad participan: el responsable del proyecto quien se asegura de que todos los recursos que salen antes de que el proyecto concluya, apliquen el cuestionario y el miembro del equipo de trabajo que sale del proyecto se requiere que conteste el cuestionario.
Los cuestionarios que se recopilen serán revisados por el responsable del proyecto para concentrar las experiencias obtenidas y resumirlas en la presentación Postmortem.

Realizar la reunión postmortem Los datos del proyecto que deben considerarse en esta presentación, son:

  • Datos generales del proyecto
  • Evaluación del alcance
  • Evaluación de la planeación
  • Evaluación de la capacitación
  • Evaluación de la calidad
  • Evaluación del proceso
  • Oportunidades y conocimientos adquiridos
  • Evaluación de la percepción del cliente

Registrar lecciones aprendidas: aquí se obtiene un resumen de las lecciones identificadas por todos los miembros del equipo de trabajo para clasificarlas y registrarlas en el repositorio de lecciones aprendidas de la organización.Registrar lecciones aprendidas: aquí se obtiene un resumen de las lecciones identificadas por todos los miembros del equipo de trabajo para clasificarlas y registrarlas en el repositorio de lecciones aprendidas de la organización.

Consideraciones

Al ejecutar esta actividad es muy importante tomar en cuenta los siguientes aspectos:

  • Planear las actividades necesarias para ejecutar el proceso postmortem en todos los proyectos.
  • La reunión postmortem debe ejecutarse inmediatamente al concluir el proyecto.
  • Es necesario contar con las aportaciones de todos los recursos que en algún momento se vieron involucrados en el proyecto.
  • Deben exponerse los aspectos positivos y negativos registrados en el proyecto.
  • Calificar al proyecto, no a las personas.
  • Realizar recomendaciones que complementen las lecciones aprendidas.
  • Los datos obtenidos en la presentación postmortem son utilizados en la presentación de cierre del proyecto.

Cuestionario Postmortem

La recopilación de las experiencias adquiridas por todos los recursos que participaron en algún momento en el proyecto se realiza a partir de la aplicación del cuestionario Postmortem en el caso de los recursos que participaron hasta el cierre del proyecto.
A continuación un ejemplo de las secciones de un cuestionario Postmortem

1.Datos generales

[Aquí describe tu participación dentro del proyecto]

  1. Nombre completo:
  2. Rol:
  3. Periodo de participación: [Total o parcial, especifique el periodo en el que permaneció en el proyecto, este será total si participo en todas las fases del proyecto, será parcial si solo participo en una fase del proyecto]
  4. Jefe inmediato/ Rol:[Especifique el nombre del jefe inmediato y su participación]

2. Evaluación de la planeación

[Sección dedicada a describir la percepción respecto a la planeación de actividades en el proyecto, poner las razones en cada respuesta]

  1. ¿Existieron diferencias entre el número planeado de artefactos/productos contra el real?
  2. ¿Se presentó alguna diferencia entre el tiempo planeado contra el real?
  3. ¿Existe alguna diferencia entre las disciplinas en las que se tiene planeada
    tu participación y en las que realmente participaste?

3. Evaluación de la Capacitación

[Aquí se pone la percepción respecto a las actividades de entendimiento del negocio]

  1. ¿Recibiste la capacitación técnica necesaria para realizar tus funciones?
  2. ¿Consideras que recibiste la capacitación necesaria del conocimiento del negocio de acuerdo a
    tu perfil?

4. Evaluación de la calidad

[Aquí indica los productos que fueron generados durante el proyecto, pudiendo ser documentos, código, modelos o diagramas]

5. Evaluación del Proceso

[Sección dedicada a evaluar el proceso de desarrollo de software]
En un proyecto similar, qué acciones, actitudes y decisiones tendrían que ser diferentes y cuáles podrían repetirse en cuanto a:

  1. La capacitación para el proyecto.
  2. Las disciplinas ejecutadas en el proyecto.
  3. Las herramientas utilizadas para el proyecto.
  4. La infraestructura con la que contó el proyecto.
  5. La administración del proyecto.

NOTA: Hay que tener en cuenta que los cuestionarios Postmortem pueden variar de acuerdo a la organización o a la metodología que se utilice.

La navaja de Ockham o principio KISS en el desarrollo de software

La navaja de Ockham o el principio de parsimonia es el principio metodológico ideado por William of Ockham (1285-1347) filósofo nominalista que se utiliza para “cortar” o “rasurar” todo aquel conocimiento que no provenga de los datos de los sentidos, es decir invalidar los conceptos que no sean comprobables por la experiencia misma.

La formulación correcta de Ockham es:

No hay que multiplicar los entes sin necesidad (entia non sunt multiplicanda praeter necessitaem).

La navaja funciona de la siguiente manera: cuando se nos ofrecen dos o más hipótesis en igualdad de circunstancias para explicar un determinado fenómeno, es razonable aceptar la hipótesis más simple o sea la que incluye menos supuestos no probados.

En otros campos del conocimiento la navaja de Ockham se utiliza para eliminar objetos o tipos de objetos que no aportan o cambian en nada las particularidades efectivas de las cosas.
En informática a la navaja de Ockham se le conoce como el principio KISS, siglas que significan:

Keep It Simple, Stupid! (Mantenlo simple, estúpido)

Aplicando el KISS al desarrollo de software tenemos que pequeño y sencillo es mejor que grande y complejo. En pocas palabras, entre más pequeño sea el número de componentes o de código involucrado en un proyecto menor será la cantidad de errores o problemas asociados al mantenimiento. Lo que incrementa la probabilidad de una entrega exitosa a tiempo.

Hay un principio de la filosofía UNIX que ejemplifica la aplicación de un principio KISS:

*“En lugar de tener pocos programas grandes, cada uno tratando de hacer muchas cosas, el sistema UNIX proporciona muchas herramientas simples que pueden combinarse para realizar un amplio rango de cosas.”

*Rosen Kenneth, Rosinki Richard, UNIX System V release 4. An introduction. Second Edition, Mc Graw Hill

Algunos ejemplos del KISS en el desarrollo de software son:

  • No intentes complicar el modelo de base de datos agregando entidades que nada aportan al negocio funcional. Solo agrega las entidades que requieren una persistencia.
  • No toda la persistencia necesita estar en una base de datos, hay ocasiones en que los archivos de texto plano son la mejor opción para el rendimiento.
  • No requieres un RDBMS para guardar una agenda de contactos.
  • No intentes optimizarlo si ni siquiera funciona o no esta terminado.
  • La complejidad de los algoritmos o el número de capas que se agreguen a una arquitectura son inútiles si estos no resuelven los requerimientos funcionales, y al serán ignorados por los usuarios finales.
Hay una frase que también es un claro ejemplo de este principio:

Premature optimization is the root of all evil. (la optimización prematura es la raíz de todos los males)

–Sir Charles Anthony Richard Hoare, inventor del algoritmo Quicksort.

Hay que aclarar que la navaja de Ockham no sostiene que la hipótesis más simple sea la correcta, sino sencillamente que es la que tiene más probabilidades de ser la correcta.