Hace una semana me contactaron para el timbrado de unos CFDI's de nomina, por alguna razon me caen regularmente proyectos ya en el dead-line.

Como ya tenia la programacion para el timbrado con mi app .net, solo fue cosa de generar el sello y enviar a timbrar, el PAC con el que trabajo es ECODEX y creo que dan una buena solucion muy documentada con sus webservices, pero es otro tema.

Para la creacion del PDF, regularmente trabajo con iTextSharp o bien con Crystal Reports en Visual Studio 2010 (sorry x que se que no son temas de Java, pero iTextSharp afortunadamente tambien funca en Java).

Aunque el diseño en Crystal Reports en muy sencillo, como me pidieron que el recibo se repitiera en la misma hoja me atore un poco, asi que decidi irme por el camino que mas conozco para solucionarlo con iTextSharp.

Actualice mi version de IBM Lotus Symphony, que es freeware, cree un archivo de texto (ODT) que uso como plantilla y lo guarde como PDF, esto me permite generar los campos editables accesibles con programacion mediante los Acrofields del componente iTextSharp.

Recientemente se han timbrado los CFDI de nomina que generamos en la empresa...
en una entrada anterior a mi Blog expongo la solución para eso.... ahora para llevar un control interno de los mismos ocupamos meterlos a una BD, para lo cual la solución a la que YO llegué fue leer el contenido y depositarlo en la BD..

Expongo aquí lo siguiente.

Bienvenidos sean a otra emisión de su podcast favorito vivecodigo.org el episodio numero 11 de la temporada numero 1.

En esta ocasión una entrevista remota desde Varsovia con nuestro amigo Hector Zarate - @iOSCowboy, quien nos platica su interesante trayectoria profesional como desarrollador de software, el cual se desempeña en el desarrollo de aplicaciones móviles y que se encuentra escribiendo un libro titulado "Guia de referencia para el desarrollo y distribución de aplicaciones en plataformas móviles"

Nos habla sobre cuales son las claves del desarrollo de una aplicación móvil pero sobre todo cuales son las premisas para que una aplicación móvil sea exitosa:

• Satisfacer una necesidad
• Planear el desarrollo de software
• Experiencia al usuario (usabilidad)
• Marketing

Un tema muy interesante sobre el desarrollo para este tipo de plataformas.

En Lo nuevo en Java 8 describimos brevemente las expresiones lambda en esta nueva versión de Java. Es necesario asociar a esas expresiones un tipo para de esta manera satisfacer la comprobación de tipos que el lenguaje utiliza. La interfaces funcionales cumplen ese objetivo, además de poder ser usadas como siempre.
Una interfaz funcional es una interfaz que contiene un único método abstracto, además de algunos métodos implementados. Estos últimos se conocen como métodos de default o métodos de extensión virtual. Las interfaces también pueden contener funciones estáticas, aunque esto último nada tiene que ver con el adjetivo funcional que se les da.
Una expresión lambda encapsula una funcionalidad específica y parece "normal" asignarle a ellas un tipo dado por una interfaz que declara la firma de esa función.
Ya estamos acostumbrados a utilizar una interfaz con un solo método para precisamente manipular la funcionalidad de ese método y poder reutilizarlo. El ejemplo más común es el de las interfaces que definen los "event handlers" en Swing y otros APIs.

Oracle ha liberado recién la nueva versión de Java. En casi 20 años de historia el lenguaje dispone de 8 versiones y de innumerables actualizaciones para cada una de las que han existido. Sigo el lenguaje desde que nació y lo he usado para varias cosas, entre ellas para enseñar programación orientada a objetos cuando el sombrero que llevo puesto es el de profesor.
Escribo entre comillas la palabra nuevo para satisfacer a aquellos que consideran que no hay innovación alguna en las cosas que en la nueva versión se introducen. Casi siempre se cumple eso de que "no hay nada nuevo bajo el sol", pero siempre se recibe son agrado si los que diseñan el lenguaje que usas para ganarte el pan de cada día, incorporan a ese lenguaje las cosas buenas que otros han incorporado. Sucede aunque con menos frecuencia, que también se incorporan cosas malas.

Pues ahora que ya salió oficialmente Java 8, lo instalé y empecé a hacer pruebas, con un proyecto grande que ya llevo desde hace varios años (empezó en Java 1.4 y lo he migrado a Java 5, 6, 7 y ahora seguirá la 8).

Cuando he migrado, las etapas suelen ser así:

Primero correr las aplicaciones tal cual están, sin modificar nada, sobre la nueva JVM. Eso parece que está funcionando bien (pero tendrán que estar en observación varios días obviamente).

Luego, compilar el código tal cual está, sin modificar nada, con el nuevo compilador. Aquí es donde me di de topes ya desde ahorita. Pasaron dos cosas:

Utilizo Lombok para reducir código en varios lugares y facilitarme la vida en general cuando programo en Java. Una de las cosas que trae es la anotación @SneakyThrows, que permite tratar una excepción verificada como si fuera RuntimeException al momento de compilar. Pero al compilar código que utiliza esta anotación en Java 8:

Y esto es usando la versión 1.12.6 que se supone ya trae soporte para Java 8.

Como el titulo lo indica: No mas Spring Templates, me encontre con esto al querer actualizar el HibernateTemplate que uso en una aplicacion hecha con Spring y en donde hago uso de un DAO Generico con el soporte HibernateDaoSupport del paquete: org.springframework.orm.hibernate3.HibernateTemplate;

Quise actualizar mi HibernateTemplate para que ahora apuntara al paquete: org.springframework.orm.hibernate4.HibernateTemplate;

Pero este ya no existe para Hibernate 4 :(

Por lo que he investigado, esto se cambio asi para evitar de alguna forma el acoplamiento que existia entre la implementacion y el DAO:

Sugieren como buena practica utilizar la API de Hibernate directamente en lugar de HibernateTemplate para desacoplar efectivamente la implementación de la capa DAO de Spring por completo.

Cuando el soporte de hibernación para las sesiones contextuales salió, el HibernateTemplate esencialmente se volvió obsoleto, de hecho, el javadoc de la clase se ha actualizado con este consejo:

Link:

Retomando el "curso" de javafx daremos una introducción a lo que son los layouts.

¿Qué es un layout?

Layout en español tiene varias traducciones según su uso: disposición, diseño gráfico, plan. Pero el termino es usado para referirse a un esquema de distribución de elementos.

Los layouts en JavaFX

En javafx los layouts son llamados panels (paneles), estos son espacios/areas/regiones que siguen ciertas reglas para acomodar y cambiar el tamaño de los nodos en relación con sus propios tamaños. También se nos da la posibilidad de especificar una posición fija de nuestros componentes.

Características básicas de los layouts en JavaFX

Para conocer todos los paneles en JavaFX veamos la estructura de los nodos en la siguiente imagen: http://www.javamexico.org/system/files/JavaFX_0.png y nos vamos hasta la clase javafx.scene.layout.Pane, empecemos definiendo algunas de las características de cada tipo de panel:

• VBox este panel nos brinda una forma simple para acomodar nodos en una fila.
• HBox este otro panel nos brinda una forma simple para acomodar nodos en una columna.