import feedparser
import urllib2 #lo utilizamos mas adelante
import re #lo utilizamos mas adelante
parse = feedparser.parse(url_de_rss)

Si tenemos conexión a internet, esas líneas nos deberían bajar el feed completo que nos ofrece la página con la que queremos trabajar. Solo queda sacar lo que nos importa, en este caso el título, la noticia y las fotos si las hubiera. Como trabajamos offline no tendrín que haber links de ningun tipo

noticias = '<ol>\n'
for i in range(0,10):
    titulo = parse.entries[i].title
    resumen =  re.sub('((<a){1}(.)+(</a>)?)|((<img){1}(.)+(/img>)?)|((<table){1}(.)+(</table>)?)', '',parse.entries[i].summary_detail.value)
    try:
        img_url = urllib2.urlopen(parse.entries[i].enclosures[0].href).read()
        f = open("images/imagen_%s.jpg"%i,"w")
        f.write(img_url)
        imagen = '<img src="images/imagen_%s.jpg" alt=""/>'%i
    except:
        imagen = ''
    noticias += '<li>%s<br/>%s<br/>%s</li>\n'%(titulo,resumen,imagen)
 
noticias += '</ol>'
archivo_noticias = open("templates/_noticias.html","w")
archivo_noticias.write(noticias)

En la línea 1 simplemente inicializamos la variable que luego pondremos en el html correspondiente, vamos a utilizar una lista ordenada.
En la línea 2 empezamos nuestro bucle diciendo que sólo vamos a querer 10 noticias. Con un simple for podemos hacerlo, debido a que vamos a trabajar con la clave entries del diccionario, esta clave contiene un array, donde cada elemento es otro diccionario con sus propias claves. Las que vamos a utilizar en esta ocasión son:
title: Trae el título de la noticia.
summary_detail: Es donde está el resúmen de la noticia, este tiene como valor otro diccionario, de donde utilizaremos la clave value, donde está el resúmen propiamente dicho.
enclosures: es donde se guardan los adjuntos de la noticia, en este caso nos interesan las imágenes, pero como trabajamos offlines tenemos que descargarlas para ello utilizamos urllib2 asi la guardamos en nuestro sistema de archivos. A modo de ejemplo puse que la imagen tenga como nombre el indice de la noticia. Si sólo trabajamos con un diario no sería inconveniente, para más de un diario puede haber problemas porque los archivos se sobreescribirían y no se mostrariacutean las correctas. Esta parte pongo dentro de un try, porque no siempre traen imágenes y el parse nos tira una excepción, en caso de que pase cargamos la variable con nada, sino creamos el tag html de imágenes.
En la línea 3 creamos una variable donde se guarda el título de nuestra noticia
En la línea 4 guardamos el resúmen en una variable, puede parecer un poco complejo el código, pero es bastante fácil. Utilizamos la librería re para poder trabajar con expreciones regulares y con el método sub eliminamos del string las cosas que no queremos. A mi no me interesaba ningún
link:

 ((<a){1}(.)+(</a>)?)

imágen:

((<img){1}(.)+(/img>)?)

tabla:

((<table){1}(.)+(</table>)?

que haya en el resúmen, entonces cuando encuentre algo de eso que simplemente lo reemplace por nada.
Finalmente cerramos nuestra lista fuera del for y tendríamos un resultado parecido a este:

<ol>
<li>Titulo1<br/>Resumen1<br/><img src="images/imagen_1.jpg" alt=""/></li>
<li>Titulo2<br/>Resumen2<br/><img src="images/imagen_2.jpg" alt=""/></li>
<li>Titulo3<br/>Resumen3<br/><img src="images/imagen_3.jpg" alt=""/></li>
<li>Titulo4<br/>Resumen4<br/><img src="images/imagen_4.jpg" alt=""/></li>
<li>Titulo5<br/>Resumen5<br/><img src="images/imagen_5.jpg" alt=""/></li>
<li>Titulo6<br/>Resumen6<br/><img src="images/imagen_6.jpg" alt=""/></li>
<li>Titulo7<br/>Resumen7<br/></li>
<li>Titulo8<br/>Resumen8<br/><img src="images/imagen_8.jpg" alt=""/></li>
<li>Titulo9<br/>Resumen9<br/></li>
<li>Titulo10<br/>Resumen10<br/></li>
</ol>

Para poder guardarlo en el archivo _noticias.html
Ya tenemos toda una lista de noticias lista para ser leída offline, sólo queda cargarlo en nuestro index y problema resulto, para eso podemos hacer uso de jquery (se puede hacer directamente con javascript, pero una página web tiene bastante código javascript hoy en día y jquery es un framework muy copadito
para escribir poco ).

En el index.html tendríamos:

<div id="#noticias"></div>
 
<script type="text/javascript">
    $("#noticias").load('_noticias.html');
</script>

Este fue mi pequeño paso por python, la verdad una experiencia muy linda, es un muy buen lenguaje. En realidad si querés hacer un script de manera muy rápida es una buena opción.
Les dejo los links de feedparser y mod-python
Feedparser: http://code.google.com/p/feedparser/
Mod-Python: http://www.modpython.org/
Bueno espero que les haya gustado y hasta la próxima

  find /proyectos/app/ -name *.erb -exec ls -l {} \; | wc -l
  #busco todos los que terminan en .erb, porque es un proyecto en Rails

Me dió la módica suma de 444 archivos. Ahora si se complicaba demasiado hacerlo a mano.
Me puse a incursionar un poco en bash y salió esto:

a=$(find $1 -name "*.erb"); #busco los archivos y guardo los paths en una lista
for i in $a; do #recorro la lista
   cat $i | egrep 'class="' | awk -F 'class=' '{print $2}' | awk -F '"' '{print $2}' | awk -F ' ' '{for (j=1; j<=NF; j++)  print $j; print "\n"}' >> clases.txt
done  
 
sort clases.txt >> clases2.txt #ordeno el archivo y lo guardo en otro
rm clases.txt #elimino el primer archivo
uniq -u clases2.txt >> clases.txt #borro las l&iacute;neas duplicadas (ya que las clases no son &uacute;nicas)
rm clases2.txt #elimino el archivo auxiliar

La tercer linea del script la explico aca abajo, sino no se iba a entender nada

cat $i: muestra el contenido del path que le estamos pasando.
egrep ‘class=”‘: Me muestra solo las líneas que contienen ‘class=”‘, que es como definimos una clase en html.
awk -F ‘class=’ ‘{print $2}’:Hago como un split a un string separando por ‘class=’ y mostrando solo el segundo valor, es decir todas las clases que tenga ese tag.
awk -F ‘ ‘ ‘{for (j=1; j<=NF; j++) print $j; print "\n"}': Como ya tenemos en una sola línea todas las clases de un tag, y sabemos que las clases se separan con un espacio, hacemos nuestro split por espacios y recorremos todas las variables y las vamos imprimiendo con un salto de linea al final. Esto nos haría una lista con todas las clases que existan en los archivos html.
Después habriendo el archivo clases.txt, vemos las clases ordenadas y únicas

Quizá se pueda costumizar más, no usar 2 archivos sino solo uno. También se podria recorrer el archivo .css y compararlo con nuestro archivo, eliminando las líneas que necesitamos. Pero para salir del apuro anda perfecto. Y si queremos encontrar los id, es cuestión de reemplazar la búsqueda nomá, aunque me tira algunos datos sucios, ya que también se usa en javascript y en ruby, entonces por ahi se complicaba un poco más, pero les dejo como tarea para la casa jeje
Bueno espero les pueda servir y cualquier consulta no duden en comentar.

Para configurarlo, este recurso brinda un conjunto de parámetros, objetos y eventos como:
*Opciones para definir meses, años, si el elemento es arrastrable, la transparencia del elemento arrastrado, titulo, etc.
*Eventos para proveer los datos.
*Eventos que se disparan al hacer clic en un día, al cargar, al arrastrar, al soltar, etc.
*Objetos del calendarios como título, fecha, hora, etc.
*Ademas es de código abierto

De acuerdo a mis necesidades y a mi lenguaje utilizado, lo implemente de la siguiente manera:
Se descarga el archivo ZIP de la biblioteca JQuery, el plugin y demos funcionales y los incluís a tu archivo que contienen tus scripts.

Inicialmente en tu formulario donde vas a presentarlo, lo llamas con un simple identificador

Luego en la parte del codigo javascript, incluís el conjunto de parámetros que te sea mas útil.

A modo de ejemplo les muestro algunos que utilice:

<table>
  <tr>
  <a><%= link_to 'Nuevo Evento', turno_tarea_turnos_path %></a>
 
// Este link_to nos llevara a los distintos eventos que serán mostrados en el calendario (en el caso de mi aplicación)
 
 </tr>
</table>
 
<table>  
<div id='calendar'></div>  
 
Acá comenzamos a configurar el calendario
<script type="text/javascript">
  $(document).ready(function(){
$('#calendar').fullCalendar({   
          editable: true,
          header: {
              left: 'prev,next',
              center: 'title'
              /*right: 'month,agendaWeek,agendaDay'*/
          },
          defaultView: 'agendaWeek',      
          height: 600,
          slotMinutes: 30,
          minTime : 8,
          maxTime : 21,
          firstDay : 1,
          allDaySlot : false,
          columnFormat:'ddd d/M',       
           titleFormat : "MMM d[ yyyy]{ '&#8212;'[MMM] dd 'del' yyyy}",
          weekends: false,
          defaultEventMinutes : 30,        
          buttonText: {prev: '&nbsp;&#9668;&nbsp;',
		next: '&nbsp;&#9658;&nbsp;',
		prevYear: '&nbsp;&lt;&lt;&nbsp;',
		nextYear: '&nbsp;&gt;&gt;&nbsp;',
                today : 'Hoy'},
 
          unselectAuto: false,
          weekMode : false,
          monthNamesShort : ['Enero' , 'Febrero' , 'Marzo' , 'Abril' , 'Mayo' , 'Junio' , 'Julio' ,
                        'Agosto' , 'Septiembre' , 'Octubre' , 'Noviembre' , 'Diciembre' ],
          dayNamesShort : ['Domingo', 'Lunes', 'Martes', 'Miercoles', 'Jueves', 'Viernes', 'Sabado'],
 
 
  // Este pequeño array nos va a permitir visualizar los eventos
          events:[
 
            <% for turno in @turnos = Turno.all   -%>
              {
               id : 'turno: <%= turno.id.to_s %>',
               title  : 'Profesional: <%= turno.profesional.nombre %> Duracion: <%= turno.duracion %>minutos Paciente: <%= turno.paciente.nombre  %> ' ,
               start : 'Fecha: <%= turno.fecha_hora.iso8601 %>',
               end : 'Duracion: <%= (turno.fecha_hora + (60 * turno.duracion)) %>',
               allDay : false,
               url: '<%= eliminar_turno_path(turno) %>'
 
              },
 
            <% end %>           
 
              ],
 
          timeFormat: 'h:mm t{ - h:mm t} ',
          dragOpacity: "0.5",
 
 
 
          eventDrop: function(event, dayDelta, minuteDelta, allDay, revertFunc){
              if (confirm("Are you sure about this change?")) {
                  moveEvent(event, dayDelta, minuteDelta, allDay);
              }
              else {
                revertFunc();
              }
          },
 
          eventResize: function(event, dayDelta, minuteDelta, revertFunc){
              if (confirm("Are you sure about this change?")) {
                  resizeEvent(event, dayDelta, minuteDelta);
              }
              else {
                 revertFunc();
              }
          },        
 
 
// En este caso, al hacer click sobre el evento, me llevara a la url especificada para ese evento (se muestra mas arriba)
 
 eventClick: function(event, jsEvent){
             if (event.url) {
              if (confirm('Esta seguro de eliminar? Esta accion no se podra deshacer')){
                event.url;
              //return false;
              }else{
                return false;
              }
 
        }
          }
}
 
</script>

Espero que les guste y lo implementen.

Para descargar los archivos js: http://arshaw.com/fullcalendar/
Otro ejemplo que me sirvió lo podes ver en http://fullcalendar.vinsol.com/

Fecha : 02 de Octubre de 2010

Lugar : Edificio 9 de julio . 9 de Julio 1449  - Corrientes -Cap-

Dirigido a estudiantes de la carrera de sistemas y pùblico en general. Las acreditaciones se realizan el mismo dìa, se entregaran certificados.

Cronograma de charlas

A continuación comparto con ustedes una serie de artículos escritos por David Chelimsky del por qué cambiar:

La mayoría del software que escribimos nunca se utilizará. No es nada personal,
es sólo que es una industria en la que no somos muy buenos dándole a la gente lo que
que quieren. La razón subyacente de esto es que los métodos tradicionales de software están diseñados para fallar -trabajan realmente en contra nosotros-. Individuos heroicos ofrecen software a pesar de su proceso de desarrollo y no a causa de él. Veremos cómo y por qué los proyectos fallan, y enfocaremos la atención en algunos de los desafíos que enfrenta el Desarrollo Ágil de Software.

Cómo fallan los procedimientos tradicionales
Los proyectos tradicionales fallan por muchas razones. Una buena manera de identificar los diferentes modos de fallo es preguntarle a tu jefe de proyecto lo que hace por la noche. (Es bueno hacerlo de vez en cuando, ayuda a su autoestima.) Es probable que nuestro jefe de proyecto se planteará una lista de temores similares a los nuestros:

Entrega tardía según el presupuesto

Estimamos, planificamos, tenemos todas las contingencias hasta la enésima potencia y luego, sucede la verdadera decepción de la vida real. Cuando nos deslizamos de la primera fecha, a nadie le importa demasiado. Es decir, sólo será un par de semanas. Si esto sigue sucediendo semanalmente, y así mensualmente, el suficiente número de personas, se han ido y se han unido a que podamos finalmente, poner el proyecto fuera de su miseria. Dieciocho meses a dos años suele ser suficiente. Este es software que no tiene importancia.

Entregando la cosa incorrecta

La mayoría de nosotros usamos un software que se entregó con retraso y más presupuesto en nuestros escritorios, en nuestros teléfonos móviles, en nuestras oficinas y hogares. De hecho nos hemos acostumbrado a los sistemas que se actualizan con correcciones de errores y nuevas características en forma de service packs y actualizaciones del sistema, o sitios web que ofrecen nuevas características con el tiempo. Pero ninguno de nosotros utiliza el software que no resuelve el problema que tenemos.
Es sorprendente cuánto esfuerzo de gestión de proyectos se dedica a cuidar el calendario o el presupuesto cuando el software persigue fines infinitamente más útiles que los mencionados.
Entonces, ¿cómo sucede esto? Tal vez los requisitos cambian después de que estuvimos de acuerdo con ellos, porque el negocio siguió adelante. Tal vez no fueron lo suficientemente claros en primer lugar. Puede ser que entregamos lo que la empresa pidió en vez de que lo que necesitaban. En cualquier caso ponemos una carga de esfuerzo en entregar el proyecto, dentro del presupuesto y a tiempo, pero resulta que nadie conseguirá realmente ningún beneficio de ello. Este es software que no tiene importancia.

Inestable en producción

¡Hurra! El proyecto llegó a tiempo y dentro del presupuesto, los usuarios lo miraron y decidieron que les gustó, por lo que lo ponemos producción. El problema es que el software falla dos veces al día. Creemos que es algo de memoria, o algo de la configuración, o algo de clustering, o de infraestructura, o …, pero ¿a quién estamos engañando? Nosotros no sabemos realmente lo que está causando la excepción, lo que es
más bien embarazoso y nos está costando mucho dinero. Si tan solo hubiéramos pasado más tiempo en probarlo!. La gente lo utilizará esta vez y se dará por vencido cuando se cae “constantemente”. Este es software que no tiene importancia.

Costoso de mantener
Hay una serie de cosas que no necesitamos considerar si estamos escribiendo software disponible. Mantenibilidad es uno de ellas. Sin embargo, si esperamos seguir con la Versión 1, Versión 2, Versión 3, o incluso una versión 2010 Professional Super Vaca Power Edition entonces fácilmente nos podemos pintar en una esquina, por no considerarnos desarrolladores río abajo.
Para empezar es probable que no participamos en la puesta en producción anticipada (early release) y no estamos al tanto de las decisiones y conversaciones que condujeron al diseño actual. Si el código no es obvio, los desarrolladores tendrán que luchar para entenderlo. Del mismo modo si el diseño no es obvio, si hay un montón de acoplamiento o redundancia innecesaria, si un montón de trozos fueron copiados y pegados y éste cambió ligeramente, entonces tendrán que luchar para resolver las implicaciones de los cambios que se hacen, lo cual es un éxito seguro a la hora de introducir defectos de regresión.
Con el tiempo el ritmo al que se pueden introducir nuevas características disminuirá hasta que los desarrolladores terminarán gastando más de su tiempo rastreando regresiones inesperadas y desarmando el “código spaguetti”. En algún momento, costará más mejorar el software que los ingresos que puede generar. Este es software que no tiene importancia.

Seguir leyendo la segunda parte

Traducido al castellano de “The Rspec Book, BDD with Rspec, Cucumber and Friends” Chapter 7 de David Chelimsky http://www.pragprog.com/titles/achbd/the-rspec-book ISBN: 978-1-93435-637-1

La mayoría de estos modos de fallo ocurre con personas inteligentes tratando de hacer un buen trabajo. Para la mayor parte del software, las personas son diligentes y bien intencionadas. También es poco probable que los
errores en los proyectos son el resultado de la incompetencia o la incapacidad. Debe haber otra razón.
Tal vez este tipo de fracaso es un resultado inevitable del enfoque que hemos estado tomando (el método tradicional o cascada de entrega de software). No importa cuán inteligentes o bien intencionadas sean las personas, las cosas se pueden crear para el fracaso, y es sólo por los esfuerzos sobrehumanos que el software se entrega totalmente terminado.

Cómo funcionan los proyectos tradicionales

La mayoría de los proyectos de software se basan en la secuencia familiar de Planificación, Análisis, Diseño, Código, pruebas, implementación. Su proceso puede tener diferentes nombres, pero las actividades básicas en cada fase será bastante consistente. (Estamos asumiendo una especie de justificación de negocio que ya ha ocurrido, aunque incluso, no es siempre el caso)

Empezamos con la Fase de planificación: ¿cuánta gente, cuánto tiempo, qué recursos se necesitan, básicamente, ¿cual es el costo de entregar este proyecto y qué tan pronto vamos a ver algo funcionando?
Luego nos adentramos en una fase de análisis. Aquí es donde se articula en detalle el problema que estamos tratando de resolver, lo ideal sería sin prescribir cómo debe ser resuelto, aunque esto casi nunca es así.

Entonces tenemos una fase de diseño. Aquí es donde pensamos en cómo podemos utilizar un sistema informático para resolver el problema que tenemos articulado en análisis. Durante esta fase que pensamos sobre el diseño y la arquitectura, las decisiones técnicas a gran y pequeña escala, las diversas normas en torno a la organización, y poco a poco se descompone el problema en fragmentos manejables para que podemos producir especificaciones funcionales.

Ahora pasamos a la fase de codificación, donde escribimos el software que va a resolver el problema, de acuerdo a las especificaciones que salieron de la fase de diseño. Una suposición común es que en esta etapa, todo es coser y cantar, porque todo el pensamiento duro ya se hizo. Esto no es tan malo como parece, lo que estamos diciendo es que ahora se deben realizar las actividades de programación y pruebas (testing) a un riesgo relativamente bajo debido a que ya hicimos la planificación por adelantado (el análisis y diseño).

Ahora ya somos adultos responsables que tienen una fase de testing en la que probar el software para asegurarse de que hace lo que tenía que hacer. Esta fase incluye actividades con nombres como Testing de aceptación por los usuarios o Performance testing para destacar que nos estamos acercando a la entrega final.

Finalmente llegamos a la fase de implementación en la que desplegamos la aplicación en producción. Con un nivel adecuado de fanfarronería, se desliza nuevo software en producción y comenzamos a ganar dinero!

Todas estas fases son necesarias. No se puede comenzar a resolver un problema que no se ha articulado, no se puede iniciar la aplicación de una solución que no se han descrito, no se puede probar software que no existe y no se puede (o al menos no se debería) implementar software que no ha sido probado.
Por supuesto, en realidad, se pueden hacer cualquiera de estas cosas pero por lo general termina en lágrimas.

¿Cómo funcionan realmente los proyectos tradicionales

Hemos entregado proyectos en más o menos de esta manera desde que empezamos a escribir los sistemas informáticos. Ha habido varios intentos de mejorar el proceso y hacerlo más eficiente y menos propenso a errores, utilizando los documentos para formalizar la mano de fuerza, la creación de plantillas para los documentos, montaje de comités de revisión de las plantillas de los documentos, el establecimiento de normas y la acreditación formal para los comités de examen. . . . Por supuesto que podemos ver cuando el esfuerzo se ha ido.

La razón de toda esta ceremonia alrededor del hands-offs, opiniones, y cosas semejantes es más tarde en el ciclo de vida de entrega de software, detectar un defecto -o introducir un cambio- es más caro que ir por el camino correcto. Y no sólo un poco más – de hecho, la evidencia empírica en los últimos años ha demostrado que es exponencialmente más caro cuanto más tarde se averigua.

Con esto en mente, tiene sentido de adelantar el proceso. Queremos asegurarnos de que hemos reflexionado sobre los posibles resultados y cubierto todos los ángulos de manera temprana para que no nos sorprendamos por “desconocidos desconocidos” al final del día.

Están también, por supuesto, las cuestiones de la rendición de cuentas y responsabilidad cuando las cosas van mal inevitablemente. En una organización con una cultura de culpa tradicional cada grupo tiene que ser capaz de demostrar que no era culpa de ellos: los analistas, los arquitectos, los programadores, testers, el equipo de operaciones y en última instancia, el director del proyecto. Esto hace que, al reunir a un grupo de personas para firmar una declaración de que un artefacto -un plan de proyecto, un documento de requerimientos, especificación funcional, código – cumple con el nivel adecuado de fiabilidad. Si algo va mal ahora, debe ser debido a un error humano (es decir, la incompetencia, y más importante incompetencia de otra persona ) más adelante en el proceso.

Pero esto no es toda la historia. Sin embargo somos diligentes en cada una de las fases de desarrollo, cualquiera que haya entregado el software de manera tradicional hará constar la cantidad de trabajo que ocurre “debajo del radar”. El equipo de programación firma el plan del proyecto, resplandeciente en su detalle, las dependencias, los modelos de recursos, y gráficos de Gantt. Entonces los analistas comienzan a recibir a los apretones el detalle del problema y decir cosas como: “Hmm, esto parece estar más complicado de lo que pensábamos. Nos gustaría mejorar el plan, esta va a ser algo grande. ”

A continuación, los arquitectos empiezan a trabajar sobre sus características funcionales, que descubren una serie de preguntas y ambigüedades sobre los requisitos. ¿Cómo estos datos se refieren a esa pantalla? ¿Qué pasa si este mensaje no es recibido por ese otro sistema? A veces los analistas de inmediato pueden responder a la pregunta, pero más a menudo que significa que necesitamos más tiempo de análisis y por lo tanto más de los analistas. Mejor actualización de dicho plan. Y conseguir que fuera firmado. Y firmar el nuevo documento, mayores exigencias.

Usted puede ver cómo este costo de coordinación puede montar rápidamente para arriba. Por supuesto que realmente se inicia durante la fase de prueba. Cuando el probador plantea un defecto, el programador pone sus manos en el aire y dice que hizo lo que había en la especificación funcional, el arquitecto culpa al analista de negocios, y así, sobre derechos de copia de seguridad de la cadena. Es fácil ver donde este coste exponencial viene.

En este ir y venir se convierte más en una carga, nos volvemos con más miedo de hacer cambios, lo que significa que la gente hace el trabajo fuera del proceso y los documentos fuera de sincronización entre sí y con el propio software. Las Pruebas se comprimen, la gente trabaja tarde en la de noche, ya la liberación del software se caracteriza generalmente por llanto y el crujir de los dientes, los ojos inyectados en sangre, y varios intentos fallidos de descifrado las instrucciones de las notas de publicación.

Esto se ve agravado por el hecho de que las personas suelen trabajar en una fase de un proyecto y luego seguir adelante, así que para cuando el probador está señalando los defectos que el analista de negocios hace tiempo que se unió a un proyecto diferente y ya no está disponible.

Una profecía autocumplida

En resumen, los proyectos se vuelven exponencialmente más caros al cambior cuanto más nos adentramos en ellos, debido al efecto acumulativo de mantenimiento de todos los artefactos de proyecto en sincronía, por lo que adelantar el proceso con una gran cantidad de planificación para mitigar los riesgos, actividades de análisis y diseño para reducir la posibilidad de reelaboración.

Ahora, ¿cuántos de estos artefactos (el plan del proyecto, la especificación de requisitos, la alta y documentos de diseño de bajo nivel, el software en sí) existían antes de que comenzó el proyecto? Eso es, exactamente ninguno! Así que todo ese esfuerzo -que crece exponencialmente- se debe a que ejecutamos los proyectos de la manera en que hacemos! Así que ahora tenemos una situación de gallina y el huevo o un bucle de refuerzo en la Terminología del Pensamiento Sistémático.

La ironía del enfoque tradicional de los proyectos es que el propio proceso hace el coste exponencial de cambio! Cuando les preguntamos a nuestros jefes de proyecto la forma en que planifican este coste exponencial de los cambios que nos dicen es “a través de la experiencia.”
Han visto suficiente de proyectos en situaciones bastante pasar por el mismo dolor.

La respuesta de nuestra industria ha de ser reforzar el bucle en lugar de intentar algo que podría romper el ciclo completo. Sin embargo el desarrollo de software es todavía una industria muy joven, así que ¿de dónde viene esta curva de costes, en primer lugar?

Yendo más profundo, resulta que la curva se origina en la ingeniería civil. Tiene sentido que es posible que se desee pasar mucho tiempo en las fases de diseño de un puente o una embarcación. Una vez que los pilares de hormigón estén armados, si se hunden y la infraestructura de hierro fundido está en su lugar, las cosas se vuelven muy caras de corregir!

Sin embargo, estas normas sólo se aplican al desarrollo de software, porque se lo permitimos! El software es, así, suave. Se supone que es la parte que es fácil de cambiar, y con el enfoque correcto y algunas herramientas decentes puede ser muy maleables. Así que utilizando la metáfora de la ingeniería civil e igualando software con acero y concreto, nos hemos hecho a nosotros mismos un flaco favor.

Seguir leyendo la tercera parte

Traducido al castellano de “The Rspec Book, BDD with Rspec, Cucumber and Friends” Chapter 7 de David Chelimsky http://www.pragprog.com/titles/achbd/the-rspec-book ISBN: 978-1-93435-637-1

No todo es pesimismo sin embargo. Hay muchos equipos por ahí que hacen sus entregas de proyectos a tiempo, dentro del presupuesto, y deleitan a sus participantes titulares, y se las arreglan para hacer una y otra vez. No es fácil. Se necesita disciplina y dedicación, y se basa en un alto grado de comunicación y colaboración, pero es posible.

El Desarrollo Orientado al Comportamiento es una de varias metodologías ágiles. En concreto se trata de una metodología ágil de segunda generación, construído sobre el labor de unos muchachos realmente inteligentes. Vamos a ver cómo estos métodos Agiles se produjeron y cómo abordar los riesgos de los proyectos tradicionales, entonces podemos ver cómo BDD nos permite concentrarnos en la escritura de software, que es realmente lo que importa.

Cómo hacen frente a los riesgos del proyecto los métodos Ágiles

Los autores del manifiesto van mucho más allá de las pocas líneas antes mencionadas en el mismo. También documentaron los principios que sustentan su pensamiento. Cabe destacar en este es un deseo de “ofrecer software de trabajo con frecuencia, desde un par de semanas a un par de meses, con una preferencia a la escala de tiempo más corto.”
Imaginemos por un momento que usted puede hacer esto, a saber, la distribución de software de calidad de producción cada dos semanas para sus grupos de interés, en su proyecto actual, en su organización actual, con su equipo actual, a partir de mañana. ¿Cómo se hace frente a los riesgos tradicionales de entrega que se indicaron antes?

No más entregas tardías según el presupuesto

Como las entregas son pequeñas, iteraciones de una o dos semanas o mini proyectos, utilizando un equipo pequeño, de tamaño fijo, es fácil de calcular nuestro presupuesto del proyecto: se trata simplemente de la velocidad de producción del equipo en el número de semanas, además de algunos de hardware y licencias.

Siempre partimos de una suposición razonable en el tamaño total del proyecto, es decir cuánto estamos dispuestos a invertir en la solución del problema de negocio en el primer lugar, y se da prioridad a las características apropiadamente, entonces el equipo puede entregar las cosas realmente importantes en las iteraciones tempranas. (Recuerde, estamos entregando por característica, no por módulo). Así
a medida que hacia el momento en que el dinero se acaba, debemos, por definición, trabajar en funciones de menor prioridad. También podemos medir la cantidad que realmente se produce en cada iteración, conocida como nuestra velocidad o rendimiento, y usar esto para predecir cuando en realidad estamos con probabilidades de terminar.

Si, como nos acercamos a la fecha límite, las partes (clientes) siguen teniendo ideas y características nuevas y ven las cosas maravillosas sucediendo, pueden optar por financiar el proyecto de unas pocas iteraciones más. A la inversa que pueden decidir antes el plazo que es suficiente para la funcionalidad que ha sido entregada, o bien que quieren terminar temprano. Esta es otra opción que tienen.

No más entregas de cosas incorrectas

Estamos entregando los programas necesarios para los interesados cada dos semanas (por ejemplo), lo que significa que estamos ofreciendo características demostrables. No tenemos dos semanas de “repetición de esquema de base de datos” o “repetición de middleware.” Después de cada iteración podemos demostrar las nuevas características para los interesados y pueden hacer ningún ajuste o corregir cualquier malentendido cuando la obra está aún fresca en el desarrollo equipo de la mente. Estos regulan, a pequeña escala micro-correcciones que garantizan que no se terminan hasta varios meses abajo de la línea con el software que simplemente no hace lo que los actores querían.

Para dar inicio a la siguiente iteración podemos reunirnos con los interesados para reevaluar las prioridades de las características en caso de que algo ha cambiado desde el pasado tiempo. Esto significa que cualquier nueva idea o sugerencia se pueden programar, y la cantidad correspondiente de trabajo puede ser descomprimida (tiempo extra)

No más inestable en Producción

Estamos entregando cada iteración, lo que significa que tenemos que ser buenos en la construcción y en el despliegue de la aplicación. De hecho contamos con la automatización en gran medida en proceso para manejar esto por nuestra cuenta. No es raro que un equipo Agil con experiencia produzca más de 100 construcciones de buen software cada semana.
En este contexto, liberar a la producción o pruebas de hardware puede ser considerado simplemente otra costrucción para otro ambiente. Los servidores de aplicaciones se configuran automáticamente y se inicializan, esquemas de bases de datos que se actualizan automáticamente, el código es automáticamente incorporado, montado y desplegado a través del cable, todo tipo de pruebas se ejecuta automáticamente para asegurar que el sistema se está comportando como se esperaba. De hecho, en un entorno ágil, la relación entre el equipo de desarrollo y las operaciones “río abajo” y los DBA es a menudo mucho más saludable y más solidaria.

Ya no es costoso mantener

Este último es uno de los mayores beneficios tangibles de un proceso ágil. Después de su primera iteración el equipo está en modo de mantenimiento eficaz. Ellos son la adición de características a un sistema que “funciona” por lo que tienen que ser muy cuidadosos.
Suponiendo que pueden resolver las cuestiones de la seguridad de cambiar el código existente a fin de no introducir a los defectos de regresión, sus prácticas de trabajo deberían ser exactamente las mismas que los desarrolladores de apoyo intermedio. No es raro que un equipo de desarrollo ágil trabaje en varias versiones de una aplicación al mismo tiempo, la adición de características a la nueva versión, la prestación de apoyo directo a una versión temprana recientemente publicada, y proporción de corrección de errores apoyando a una versión de producción de más edad

Traducido al castellano de “The Rspec Book, BDD with Rspec, Cucumber and Friends” Chapter 7 de David Chelimsky http://www.pragprog.com/titles/achbd/the-rspec-book ISBN: 978-1-93435-637-1

3) Ahora vamos al código:

require 'java'

#Importamos algunas librerías que vamos a utilizar
import 'java.awt.image.BufferedImage'
import 'java.io.OutputStream'
import 'java.io.FileOutputStream'

#Importamos las librerías de los códigos de barras (Barcode4j) que necesitamos
import 'org.krysalis.barcode4j.impl.code39.Code39Bean'
import 'org.krysalis.barcode4j.impl.code128.Code128Bean'
import 'org.krysalis.barcode4j.impl.int2of5.Interleaved2Of5Bean'
import 'org.krysalis.barcode4j.impl.codabar.CodabarBean'
import 'org.krysalis.barcode4j.impl.code128.EAN128Bean'
import 'org.krysalis.barcode4j.impl.pdf417.PDF417Bean'
import 'org.krysalis.barcode4j.impl.upcean.EAN13Bean'
import 'org.krysalis.barcode4j.impl.upcean.EAN8Bean'
import 'org.krysalis.barcode4j.impl.upcean.UPCABean'
import 'org.krysalis.barcode4j.impl.datamatrix.DataMatrixBean'
import 'org.krysalis.barcode4j.output.bitmap.BitmapCanvasProvider'
import 'org.krysalis.barcode4j.tools.UnitConv'

#Creamos el Bean y establecemos los dpi y wide_factor
bean = Interleaved2Of5Bean.new()
dpi = 150
bean.wide_factor = 3

#Creamos la imagen
ofile = java.io.File.new('/home/laptop/barcodes/barcode.png')
out = FileOutputStream.new(ofile)
canvas = BitmapCanvasProvider.new(out,"image/x-png", dpi, BufferedImage::TYPE_BYTE_BINARY, false, 0)

#Generamos el código de barras
#El segundo parámetro que pasamos es el número del que deseamos generar el codigo de barras
bean.generate_barcode(canvas, '1234567890');
canvas.finish
out.close

Con esto, generamos una imagen con nuestro codigo de barras en /home/laptop/barcodes/barcode.png la cual se puede incluir en cualquier pdf/html/odf, etc.

Espero les sea útil. Cualquier duda, no duden en comentar.

Para poder incluir un reporte realizado con JasperReports en nuestra aplicación Jruby necesitamos:

1) Descargar I-Report, la herramienta de administracion de reportes de JasperReports. http://jasperforge.org/projects/ireport y descomprimirlo.

2) Dentro del directorio del i-report, ir a modules/ext/ y copiar todos los archivos .jar (si, todos ) al directorio lib de la instalación de JRuby. De esta manera, ya incluimos las librerías necesarias y tenemos preparado nuestro JRuby para utilizar JasperReports.

3) Nos resta crear un reporte para prueba, si nunca hiciste un reporte con i-report: http://jasperforge.org//website/ireportwebsite/IR%20Website/ir_design_a_report.html?header=project&target=ireport

4) Finalmente el código para correr nuestro reporte es el siguiente:

require 'java'
import 'oracle.jdbc.OracleDriver' #Aqui necesitas Utilizar el Driver de la Base de datos que estas usando, en mi caso es oracle
import 'net.sf.jasperreports.engine.JasperCompileManager'
import 'org.apache.commons.dbcp.BasicDataSource'
import'java.util.HashMap'
import'net.sf.jasperreports.engine.JasperFillManager'
import'net.sf.jasperreports.engine.JasperExportManager'                                                                             

#Creo el datasource
basicdatasource = BasicDataSource.new
basicdatasource.driver_class_name = 'oracle.jdbc.OracleDriver'
basicdatasource.username = 'usuario'
basicdatasource.password = 'password'
basicdatasource.url = 'jdbc:oracle:thin:@localhost:1521:XE'
basicdatasource.connection
conexion = basicdatasource.connection

#Compilamos el reporte
jasperReport = JasperCompileManager.compile_report('/url_de_tu_archivo_jrxml/reporte.jrxml')
#Para pasar los parámetros, definimos un objeto HashMap
m = HashMap.new
m.put('parametro_1','valor_parametro_1')
m.put('parametro_2','valor_parametro_2')
m.put('parametro_n','valor_parametro_n')

#Genero el reporte
jasperPrint = JasperFillManager.fill_report(jasperReport, m,conexion)                           

#Exporto el PDF
JasperExportManager.export_report_to_pdf_file(jasperprint, 'path_al_archivo_PDF.pdf')

Si deseamos generar reportes en Rails, podemos por ejemplo ubicar los reportes en el directorio public/reportes y utilizar send_file para enviarlos, por ejemplo:

JasperExportManager.export_report_to_pdf_file(jasperprint, RAILS_ROOT+"/public/reportes/reporte.pdf")
send_file RAILS_ROOT+"/public/reportes/reporte.pdf"

Espero les sea de utilidad, cualquier cosa comenten y trataré de despejar dudas

Para aquellos desarrolladores que utilizan el IDE Eclipse y el sistema de control de versiones git les va a interesar esta info: org.eclipse hizo pública la primera versión del plug-in EGit que proporciona soporte integrado para el SCM distribuído git, utilizando JGit.
JGit es una biblioteca que implementa Git en Java. EGit, a diferencia de Eclipse Subversion, no tiene dependencias externas o de los requisitos del código nativo.

En la página del proyecto hay un manual muy completo.