Links paara entender opciones de persistencia en Java

Conceptos de persistencia en Java - JPA, Hibernate, DAO pattern y Repository pattern con Spring Data.

Simplify the DAO with Spring and Java Generics 

JPA Composite Primary Keys 

Taller JPA Spring Data 

Introduction to Spring Data JPA 

 

DAO vs Repository Patterns 

CrudRepository, JpaRepository, and PagingAndSortingRepository in Spring Data 

Spring Data Examples (JPA pitfalls and modern alternatives: JDBC and R2DBC) 

The Difference Between JPA, Hibernate and EclipseLink

Macro en Excel para copiar una tabla filtrando sus comunas

Dejo un link que lleva a un vídeo que trata sobre una macro en Excel para copiar una tabla con posibilidad de filtrar columnas. 

En la descripción del vídeo se encontrará un link para descargar el código fuente de la Macro.

Macro en Excel para copiar una tabla filtrando columnas

Integraciones innovadoras (parte 1: ¿qué son?)

El estilo de desarrollo de software basado en componentes de terceros propone algo así como integrar piezas que están mejor desarrolladas de lo que nosotros mismos podríamos lograr si las hiciéramos desde cero. Si en el inconsciente colectivo de los informáticos, el camino de referencia es codificar todo desde cero, este otro camino nos acerca a trabajos que han realizado otros, adquiriendo conocimiento a medida que indagamos sobre cada componente que consideremos. Es así que para aprender sobre el uso que debemos hacer de algún componente cualquiera, primero transitamos por aprender la finalidad con la cual este fue creado. Ahora, ¿se puede también agarrar un componente que exista, y usarlo de una manera que no estaba pensada? La pregunta anterior toca un concepto que incluso sin ser desarrolladores, los usuarios lo practican de forma inconsciente. Por ejemplo, hoy dia es muy común que las herramientas de edición de texto vengan con funciones de corrección ortográfica incorporada. aun así, se pueden enumerar tantos editores de texto que no cuentan con ayuda ortográfica entre sus funciones. mientras uno considere que lo que está escribiendo no tiene errores, uno se queda en su herramienta elegida aunque esta no tenga corrector ortográfico. apenas aparece una palabra sospechosa, hay que salir a buscar una solución. veamos esta manera de resolver la necesidad: uno copia la palabra en un programa que preste servicios de ortografía (puede ser un procesador de textos en la misma computadora o una aplicación remota accedida vía web), en donde la palabra se marca en rojo si está mal escrita, ante lo que uno ordenaría que se cambie la palabra por la que esté bien escrita, y se volvería a copiar la palabra pisando la otra en su lugar de origen, para continuar escribiendo normalmente. Sigamos viendo lo que ha pasado. Se optó por utilizar un editor con corrección ortográfica, pero sólo con la palabra que necesitaba recibir la corrección. Sobre el modo de empleo que se hizo al ingresar en él una única palabra, y sobre el servicio que se recibió al extraer de él la versión mejorada de la palabra, que estos dos hechos respondan o no al objetivo de su autor, no lo sabemos. Simplemente la herramienta fue integrada de esta manera y listo. Si la manera de usarla fuera nueva porque nunca antes se la había utilizado así, entonces estaremos hablando de una integración innovadora.

Notas finales sobre el artículo de Aho y Johnson

Esto viene a ser un cierre a una serie de escritos en torno a un artículo titulado L.R. Parsing, autoría de A.V. Aho y S.C. Johnson. Varias de ellas son glosas y otras ejercicios resueltos. Al pie se detallan las referencias.

Notas finales:
Entre right parse y righmost derivation puede establecerse una relación, entendida como que cada una de las reescrituras de una right derivación se emparentan con cada uno de los estadíos de un right parse de modo que los símbolos de dicho estadío son prefijo de la cadena reescrita, y lo que no es prefijo, es una cadena de símbolos terminales igual al input que falta incorporar al right parse en ese estadío. Además, dicho prefijo no es cualquiera, sino que es siempre un viable prefix.

La closure operation tiene un operando y un resultado, ambos definidos bajo el nombre de "ítem". El hecho de que para esta operación se exija que los símbolos del lookahead set previo estén concatenados a la cadena de cuya derivación se extraerá el nuevo lookeahead set tiene un significado importante. Algunas derivaciones podrían realizarse que sean válidas en forma aislada pero que no pudieran formar una right sentential form en el lugar desde donde se están generando. Concatenando a estas derivaciones los símbolos del lookahead set previo queda en evidencia su falta de sentido, y por otro lado, la validez de las derivaciones que sí la tienen.

Artículos anteriores de esta serie:
Ejercicio de La Sección 6.4, "Computing Lookahead Sets"
Ejercicio LR Parsing Sección 6.2, "Constructing the Collection of Accessible Set of Items"
Ejercicio Propuesto En El Artículo LR Parsing En La Sección 6.1, "Sets Of Items"
Notas Sobre El Artículo L.R. Parsing
Parseo Simple
Otro Ejercicio del Artículo L.R. Parsing
Ejercicios del Artículo L.R. Parsing

Ejercicio de la sección 6.4 computing lookahead sets

The reader should verify that the complete collection of sets of items for G₁ is:

I₀: [ACCEPT → ⋅ LIST], {'$'}
[LIST → ⋅ LIST ',' ELEMENT], {',', '$'}
[LIST→ ⋅ ELEMENT], {',', '$'}
[ELEMENT → ⋅ 'a'], {',', '$'}
[ELEMENT →  ⋅ 'b'], {',', '$'}
I₁: [ACCEPT → LIST ⋅ ], {'$'}
[LIST → LIST ⋅ ',' ELEMENT], {',', '$'}
I₂: [LIST → ELEMENT ⋅ ], {',', '$'}
I₃: [ELEMENT → 'a' ⋅ ], {',', '$'}
I₄: [ELEMENT → 'b' ⋅ ], {',', '$'}
I₅: [LIST → LIST ',' ⋅ ELEMENT], {',', '$'}
[ELEMENT → ⋅ 'a'], {',', '$'}
[ELEMENT → ⋅ 'b'], {',', '$'}
I₆: [LIST → LIST ',' ELEMENT ⋅ ], {',', '$'}



Teniendo en cuenta que hay 2 formas de generar los sets de items, se elegirá uno teniendo en cuenta lo siguiente.

Una de las formas tiene más que ver con las definiciones de viable prefix y valid item, y la otra con un símbolo especial (ACCEPT) que expande la gramática con una nueva regla, una operación llamada closure que completa los items de cada set. Ambas tienen en cuenta uno y sólo un símbolo de desplazamiento en el cálculo de cada nuevo estado, El 2do. método es más natural a lo realizado por un parser en ejecución: partir de un estado, desplazar un símbolo y cambiar a un nuevo estado. El 1er. método requiere una cadena auxiliar para usarla de viable prefix al aplicar la definición de valid item. Es auxiliar en el sentido de que sólo forma parte del proceso de construcción pero no del parser construido.
Finalmente, por simplicidad se elegirá el 2do. método para este ejercicio.
Los sets de items I₀, I₁, I₂, I₃ e I₄ ya fueron calculados en la sección 6.2, de la cual el cálculo de los lookehead sets no formaba parte. También fueron calculados, en la sección 6.4, los lookahead sets para I₀ e I₃, más allá de que este último sea referido en dicha sección como I₂, cosa que aquí no tiene importancia.
Dando por hecho los sets de items y lookahead sets mencionados, se procederá a completar la collección, aplicando las definiciones de las secciones 6.2 y 6.4.

El único ítem de I₁ surge de desplazarse a través de LIST sobre el ítem [ACCEPT → ⋅ LIST] {$} y conservando su lookahead set al no haber closure operation aplicable. Como resultado se tiene:
I₁: [ACCEPT → LIST ⋅ ], {'$'}

Para I₂ el razonamiento por ende es el mismo lookahead set que el del ítem del cual procede, que es [LIST→ ⋅ ELEMENT], {',', '$'}. Según esto:
I₂: [LIST → ELEMENT ⋅ ], {',', '$'}

Lo mismo pasa con el único ítem de I₄ (I₃, como se dijo, se da por hecho), cuyo antecesor es [ELEMENT →  ⋅ 'b'], {',', '$'}, y 'b' el símbolo "atravesado" (a través del cual nos desplazamos), siendo pues:
I₄: [ELEMENT → 'b' ⋅ ], {',', '$'}

Se resolverá un nuevo set de items por medio de GOTO(I₁, ','):
Desplazándose a través de un símbolo ',' sobre un ítem de I₁ único donde esto tiene sentido se genera el ítem [LIST → LIST ',' ⋅ ELEMENT], {',', '$'}. Siendo que no hay símbolos entre ELEMENT y el final de la regla, su lookahead set tiene el mismo potencial de formar right sentential form en presencia de esta instancia de ELEMENT como así de todas sus derivaciones por derecha, de modo que el lookahead set no cambia. Conociendo la closure operation sobre ELEMENT, el estado completo queda:
[LIST → LIST ',' ⋅ ELEMENT], {',', '$'}
[ELEMENT → ⋅ 'a'], {',', '$'}
[ELEMENT → ⋅ 'b'], {',', '$'}
Que viene a ser I₅.

GOTO(I₅, ELEMENT) da como resultado exactamente I₆, no habiendo ni closure operation que valga ni posibilidad de que el lookahead set sea modificado, por razonamientos similares a los seguidos hasta aquí.

Por más GOTO(I,X) que se intente, ya no queda forma de expandir la colección de sets de items. Queda pues verificado el enunciado.

Ejercicio LR Parsing sección 6.2, "Constructing the Collection of Accessible Sets of Items"

Ejercicio propuesto por el enunciado

The reader should verify that these two items 
[ACCEPT → LIST .]
[LIST → LIST . ',' ELEMENT]
are the only items valid for the viable prefix LIST.

La verificación será realizada a partir de los items generados por la gramática
ACCEPT → LIST
LIST → LIST ',' ELEMENT
LIST → ELEMENT
ELEMENT → 'a'
ELEMENT → 'b'
estableciendo γ y α a valores apropiados según cada ítem y comprobando que los 2 del enunciado son los únicos que validan los datos del enunciado contra la definición de valid item. La tabla siguiente comprende la resolución del ejercicio según lo explicado.

Ítem	γ	α	β	A	γ.A	¿γA válido? / ¿Hay alguna forma de hacer γα=LIST para γA?
ACCEPT → ⋅ LIST	LIST	''	LIST	ACCEPT	LIST ACCEPT	no / sí
ACCEPT → LIST ⋅	''	LIST	''	ACCEPT	ACCEPT	sí / sí
LIST → ⋅ LIST ',' ELEMENT	LIST	''	LIST ',' ELEMENT	LIST	LIST LIST	no / sí
LIST → LIST ⋅ ',' ELEMENT	''	LIST	',' ELEMENT	LIST	LIST	sí / sí
LIST → LIST ',' ⋅ ELEMENT	''	LIST ','	ELEMENT	LIST	LIST	sí / no
LIST → LIST ',' ELEMENT ⋅	''	LIST ',' ELEMENT	''	LIST	LIST	sí / no
LIST → ⋅ ELEMENT	LIST	''	ELEMENT	LIST	LIST LIST	no / sí
LIST → ELEMENT ⋅	''	ELEMENT	''	LIST	LIST	sí / no
ELEMENT → ⋅ 'a'	LIST	''	'a'	ELEMENT	LIST ELEMENT	no / sí
ELEMENT → 'a' ⋅	''	'a'	''	ELEMENT	ELEMENT	sí / no
ELEMENT → ⋅ 'b'	LIST	''	'b'	ELEMENT	LIST ELEMENT	no / sí
ELEMENT → 'b' ⋅	''	'b'	''	ELEMENT	ELEMENT	sí / no

Ejercicio propuesto en el artículo "LR Parsing" en la sección 6.1, "Sets of Items"

Nada mejor que hacer los ejercicios propuestos por el texto que uno lee para afianzar conocimientos. En este caso, se trata del ejercicio del artículo LR Parsing, A.V. Aho & S. C. Johnson, propuesto en la sección 6.1, "Sets of Items", bajo el enunciado:

The reader can (and should) verify that the state corresponding to the viable prefix LIST ',' is associated with the set of items:
[LIST → LIST ',' . ELEMENT]
[ELEMENT → . 'a']
[ELEMENT→ . 'b']



Por definición, dado un viable prefix γα, compuesto por cualquier cadena derivable a partir de γ seguido de cualquier cadena derivable de α, cualquier ítem de la forma [A → α.β] es válido si γA es un viable prefix.

1.  γ = '', α = LIST ',', β = 'ELEMENT', A = LIST
   Luego, γA = LIST, es un viable prefix válido.
2. γ = LIST ',', α = '', β = 'a', A = ELEMENT
   Luego, γA = LIST ',' ELEMENT, es un viable prefix válido.
3. γ = LIST, α = '', β = 'b', A = ELEMENT
   Luego, γA = LIST ',' ELEMENT, es un viable prefix válido.

Bueno, a lo mejor el ejercicio completo debe constar de las comprobaciones con todos los items de la gramática.