Mostrando entradas con la etiqueta oracle. Mostrar todas las entradas
Mostrando entradas con la etiqueta oracle. Mostrar todas las entradas

miércoles, agosto 03, 2011

Presentaciones interesantes de OSCON 2011

OSCON 2011, se realizó la semana pasada (Julio 2011) con muchas presentaciones bastante interesantes, que están disponibles en Youtube. Las siguiente, son cuatro presentaciones cortas que rondan entre los 10 y 20 minutos, en las que se discuten temas que en lo personal me parecieron de lo más interesantes:

Open Source, Java, and Oracle -- Cracking the Code:



Twitter: From Ruby on Rails to the JVM:



Java: The Good, Bad, and Ugly Parts:



Data Flow at Netflix:



Espero que les guste la selección de presentaciones, si desean ver más no duden en visitar el canal de O'Rielly Media: http://www.youtube.com/user/OreillyMedia
¿Qué les parecen estas presentaciones? ¿Cuales son sus favoritas?

miércoles, septiembre 02, 2009

¿Qué es ORM?

Object Relational Mapping, u ORM, O/RM y O/R mapping, es una técnica empleada en la programación, para convertir datos entre sistemas incompatibles, como lo son las bases de datos relacionales y los lenguajes de programación. Esta conversión de datos entre los sistemas crea un efecto una base de datos virtual de objetos, que puede ser usada en el programa (en esa forma).



Hay implementaciones comerciales y libres disponibles para crear el "mapeo" (mapping) objeto-relación, aunque algunos programadores (o mejor dicho empresas) optan (por ignorancia o espiritu de aventura... o ambas quizas) por crear sus propias herramientas ORM.


Las empresas siempre poseerán una base de datos normalizada, para "ahorrar espacio" (como algunos individuos administrativos lo ven). Para un programador, la tarea de leer estos datos, manipularlos y finalmente modificarlos o eliminarlos pende de un hilo, de acuerdo al grado de ignorancia a la hora de elegir a las herramientas y/o librerías de software (de ORM) empleadas para tales fines.


Una librería de ORM (como Hibernate, Oracle Toplink o Linq) siempre, absolutamente siempre reducirá la cantidad de código, porque habrá algo que permitirá realizar el proceso de mapeo (como el IDE), y se encargara de crear las clases equivalente u homologas con las tablas en la base, además permitirá manejar diversos tipos de relaciones entre las tablas (uno a uno,
uno a muchos, etc), reducirá la cantidad de defectos en esta delicada area, y todo esto, para beneficio del programador, que se concentrara más en codificar la lógica del negocio, que en hacer "INSERT", "UPDATE", "DELETE" y "SELECT" en la base. Otra razón por la que una librería ORM reduce la cantidad de código, es porque permite centralizar los procesos de búsqueda de datos en la base, liberándonos de escribir consultas ad-hoc innecesarias o "quemadas" en el código. Sin mencionar que, también gestionara el pool de conexiones a la base de datos.
Todo para que el programador, no se convierta en un esclavo codificando algo que ya existe, ustedes ya saben que en una empresa el codigo es el enemigo... y que de nada sirve estar reinventando la rueda...



Queda en claro, que una librería ORM, generara el mapeo de tablas a clases de base de datos (que esperamos que este BIEN diseñada) de una forma completamente automatizada. Netbeans por ejemplo, posee una excelente integración con JPA usando Oracle TopLink, y genera el código necesario para manipular toda la información de la base, en menos de un minuto... para 42 (cuarenta y dos) tablas.

¿Me pregunto cuanto se podría tardar una persona, haciendo el proceso a "pie"?

Si estas en un proyecto de software, en el que NO te permiten emplear librerías para ORM, eso simplemente refleja la ignorancia de tus inmediatos superiores o de los encargados de tu proyecto. Si ya tienes algo que te asista en el proceso, bien por ti!, pero deberías de estar pensando en emplear herramientas que son prácticamente el estándar de la industria (Hibernate), de comprobado rendimiento (Oracle Toplink) y que existen, para que nadie tenga que codificar como esclavo, algo que se puede generar en un par de clics y en no mas de "cien segundos".
ORM esta, para facilitar la vida de los programadores, reducir a la mínima expresión un proceso que es terriblemente tedioso, y también, para mejorar y producir mejor software.


¿Cuantos de ustedes utilizan tecnologías ORM en su trabajo o en la Universidad para proyectos de software?

Más información sobre ORM en la Wikipedia.

¿Qué es ORM?

Object Relational Mapping, u ORM, O/RM y O/R mapping, es una técnica empleada en la programación, para convertir datos entre sistemas incompatibles, como lo son las bases de datos relacionales y los lenguajes de programación. Esta conversión de datos entre los sistemas crea un efecto una base de datos virtual de objetos, que puede ser usada en el programa (en esa forma).



Hay implementaciones comerciales y libres disponibles para crear el "mapeo" (mapping) objeto-relación, aunque algunos programadores (o mejor dicho empresas) optan (por ignorancia o espiritu de aventura... o ambas quizas) por crear sus propias herramientas ORM.


Las empresas siempre poseerán una base de datos normalizada, para "ahorrar espacio" (como algunos individuos administrativos lo ven). Para un programador, la tarea de leer estos datos, manipularlos y finalmente modificarlos o eliminarlos pende de un hilo, de acuerdo al grado de ignorancia a la hora de elegir a las herramientas y/o librerías de software (de ORM) empleadas para tales fines.


Una librería de ORM (como Hibernate, Oracle Toplink o Linq) siempre, absolutamente siempre reducirá la cantidad de código, porque habrá algo que permitirá realizar el proceso de mapeo (como el IDE), y se encargara de crear las clases equivalente u homologas con las tablas en la base, además permitirá manejar diversos tipos de relaciones entre las tablas (uno a uno,
uno a muchos, etc), reducirá la cantidad de defectos en esta delicada area, y todo esto, para beneficio del programador, que se concentrara más en codificar la lógica del negocio, que en hacer "INSERT", "UPDATE", "DELETE" y "SELECT" en la base. Otra razón por la que una librería ORM reduce la cantidad de código, es porque permite centralizar los procesos de búsqueda de datos en la base, liberándonos de escribir consultas ad-hoc innecesarias o "quemadas" en el código. Sin mencionar que, también gestionara el pool de conexiones a la base de datos.
Todo para que el programador, no se convierta en un esclavo codificando algo que ya existe, ustedes ya saben que en una empresa el codigo es el enemigo... y que de nada sirve estar reinventando la rueda...



Queda en claro, que una librería ORM, generara el mapeo de tablas a clases de base de datos (que esperamos que este BIEN diseñada) de una forma completamente automatizada. Netbeans por ejemplo, posee una excelente integración con JPA usando Oracle TopLink, y genera el código necesario para manipular toda la información de la base, en menos de un minuto... para 42 (cuarenta y dos) tablas.

¿Me pregunto cuanto se podría tardar una persona, haciendo el proceso a "pie"?

Si estas en un proyecto de software, en el que NO te permiten emplear librerías para ORM, eso simplemente refleja la ignorancia de tus inmediatos superiores o de los encargados de tu proyecto. Si ya tienes algo que te asista en el proceso, bien por ti!, pero deberías de estar pensando en emplear herramientas que son prácticamente el estándar de la industria (Hibernate), de comprobado rendimiento (Oracle Toplink) y que existen, para que nadie tenga que codificar como esclavo, algo que se puede generar en un par de clics y en no mas de "cien segundos".
ORM esta, para facilitar la vida de los programadores, reducir a la mínima expresión un proceso que es terriblemente tedioso, y también, para mejorar y producir mejor software.


¿Cuantos de ustedes utilizan tecnologías ORM en su trabajo o en la Universidad para proyectos de software?

Más información sobre ORM en la Wikipedia.

Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...