Mi experiencia en el FOSDEM 2014 – No deberías perdértelo

FOSDEMposterEste año he asistido al FOSDEM 2014  por primera vez y tengo que decir que ha sido una experiencia genial, las charlas han sido de primer nivel a los que he asistido y estaba muy interesado, pero también tengo que decir que tenía otras charlas de las que nada tiene que ver con las cosas que normalmente hago, pero recomiendo a todos aquellos que estén pensando en ir, que se apunten y se organicen bien a lo que quieren asistir, hay mucha gente y los más seguro es que te quedes sin entrar, como les ha ocurrido a muchos.

Sobre el tema del alojamiento, recomiendo estar lo más próximo al campus ULB, ya que me pasó a mi, que estaba un poco lejos, tenía que coger transporte público pero se tardaba en llegar, tenía que combinar metro y tranvía o autobús. Eso si como estaba en centro de Bélgica, es un ventaja si vas de turismo, pero en mi caso, poco he hecho. Lo que hacía era madrugar un poco para dar un paseo matinal y disfrutar de las calles vacías del centro y hacer tiempo para llegar a las charlas.
Seguir leyendo

Algunas claves a la hora de diseñar nuestros datos: Schema Design con MySQL vs Schema Design con MongoDB

Think Different WordleEn estos últimos tiempos, se está viendo que hay un emergente mundo y un crecimiento de soluciones de base de datos y yo, como desarrollador, me estoy haciendo muchas preguntas, tales como: ¿Debo usar SQL o NoSQL? ¿cuándo debo usar una u otra? ¿Cuál es la diferencia? ¿Cuál debo utilizar para mi proyecto? ¿Puedo o debería utilizar los dos? son preguntan cuando te cuestionas cosas como: déjalo así “es que esto se ha hecho siempre de esta forma”. Pienso que tenemos la obligación, como desarrolladores, el saber las diferentes posibilidades disponibles para obtener los mejores resultados de nuestros proyectos y esto quedará reflejado en nuestros clientes.

En la mayoría de los proyectos estamos utilizando las bases de datos relacionales como algo implícito en nuestros proyectos, no quiero decir que esté mal, pero tampoco creo que esté bien, si se ha puesto implícitamente una base de datos relacional. Además, el cambio de paradigma y pensamiento a la hora de utilizar soluciones NoSQL como MongoDB, nos trae retos muy interesantes.

Uno de los retos a los que me enfrentado cuando he comenzado a utilizar una base de datos NoSQL, es el diseño del esquema, a pesar que una NoSQL como MongoDB es Schemaless, pero esto no quiere decir que no necesites pensar en un esquema. Pues bien, si mientras que en el mundo relacional, la normalización es desde dónde siempre se arranca la manera de diseñar la funcionalidad de nuestro proyecto, ahora nos tenemos que plantear el ¿cómo debemos diseñar nuestras colecciones y documentos, al crear una nueva aplicación de MongoDB?
Seguir leyendo

Sidekiq, una gema y solución a un problema concreto

Ruby & George April 07En esta ocasión vamos a hablar de Sidekiq, una gema muy interesante, en la que se me ha planteado un problema y voy a contar cómo lo he resuelto. El tema de la elección de Sidekiq ha sido por el tratamiento de los workers mediante threads y no mediante procesos forks, como es el caso de utilizar Resque. Si quieres ver ambas gemas, te dejo los links de Sidekiq y de Resque, pero veamos algunas aclaraciones antes.

Los Forks: cuando trabajamos con procesos Forks lo que estamos haciendo es crear una copia completa del proceso en si mismo y podríamos decir que copiamos el espacio de direcciones y de todos los descriptores.  Sin meterme en mucha más profundidad y como parte de una aclaración en las posibilidades que puedes tener, si el lenguaje de programación (MRI Ruby) no admite el nivel kernel level threading, entonces esta es la única manera de difundir el trabajo a través de múltiples núcleos, ya que cada proceso se consigue un núcleo diferente. También ganas un poco de estabilidad, pero por contra tienes la posibilidad de que si un proceso padre se cuelga los procesos hijos de este, quedan en estado zombies.

Los threads: podríamos decir que consumen menos recursos, ya que comparten el espacio de direcciones, la memoria y permiten tener una comunicación más fácil, si hacemos una comparación con la comunicación entre procesos forks. El cambio de contexto entre los threads dentro del mismo proceso también es generalmente mucho mejor que los forks. Dependiendo del tiempo de ejecución que se utiliza, cualquier problema que pueda ocurrir con los threads (por ejemplo, necesidad de utilizar grandes cantidades de memoria para una tarea) pueden ser manejados por el recolector de basura en su mayor parte. Finalmente una ventaja es con respecto a los procesos zombies, es que no hay que preocuparse, ya que mueren en el momento que el proceso muere, evitando los procesos zombies.

El problema que se me ha planteado es el siguiente: Seguir leyendo

Mi guía para especificar las relaciones en los modelos: Active Record – RubyOnRails

Beer on RailsEn esta guía de referencia, quiero hablar sobre las relaciones en los modelos de RubyOnRails, que además considero que hay que tener las ideas y los conceptos muy claros para poder trabajar con soltura. Nuestro protagonista de esta sesión es Active Record. Cuando venimos de otros lenguajes y modelados de Bases de Datos en los que uno mismo tiene que pensar en muchos detalles y como todo, en un primer encuentro, incluso en alguno que otro más con Active Record, tienes que cambiar la forma de pensar y de aprender. Pues como digo, hay que cambiar la forma de pensar y enfocar las relaciones para que no tengas confusiones y esto te lleve a problemas, hay pensar que estamos tratando con objetos de modelo y sus relaciones y no con filas y columnas ya que parte de la magia de ORM es que puede convertir las relaciones de clave externa hacia otra tabla referenciada Foreign Key en mapeos entre objetos de alto nivel o un lenguaje natural y ayudar a que Active Record entienda las relaciones que queremos abordar en nuestra Base de Datos.

Para eso tenemos las relaciones mediante claves externas que hacen que ORM entienda como se ven entra ellas y como podemos nosotros circular entre esas relaciones. Pongamos un ejemplo, si tenemos una tabla Productos y otra Categorías en la que necesitamos una tercera tabla denominada “Tabla de Unión”, para relacionar ambos modelos de Productos y Categorías en la que tendremos por convención las claves id de ambas tablas, product_id y category_id, para que pueda relacionarlas RubyOnRails con ORM. La convención de nomenclatura Active Record dice que la columna clave externa debería llamarse después del nombre de la tabla destino y añadiendo el guión bajo más el id, tal como hemos visto anteriormente.

Es importante pensar en los índices que creemos para no ralentizar las búsquedas y por otro lado, en el caso de que utilicemos otros nombres que no sea capaz de reconocer automáticamente, deberemos declarar las Foreign Key, Seguir leyendo

Si no tienes una solución, créala!! 10 preguntas claves No-SQL

Database Architechs Master Data ManagementHace tiempo que hablé sobre las bases de datos noSQL Bases de datos: RBBMS vs No-SQL, una R-Evolución en un modo general pero hoy quería hablar sobre Cassandra, una base de datos No-SQL que a partir de un problema de escalabilidad se crea una solución.  Cassandra una base de datos NoSQL cuyas características principales son resistencia, escalabilidad y la gran comunidad de desarrolladores por la que es apoyada.

En Cassandra por ejemplo, es posible especificar al leer o escribir dependiendo del nivel de consistencia que quieres tener en la operación, desde el más bajo, que indica que al leer o escribir basta con completar la operación en uno de los nodos, un estado intermedio donde en la mitad más uno para dar por terminada la operación y hasta realizar operaciones con máxima consistencia, donde todos los nodos deben replicarse al escribir o bien responder en la lectura. Pero no es mi intención por ahora, describir cómo funciona.
Seguir leyendo

Bases de Datos: RDBMS vs No-SQL, una R-Evolución

Schweppes

Es realmente fascinante e interesante los nuevos pensamientos y soluciones para cubrir los actuales paradigmas ante la aparición de las nuevas necesidades que las actuales RDBMS no las satisfacen, a este nuevo concepto se le denomina NoSQL Not Only SQL y fue acuñado en el año 1998 para hacer referencia a una base de datos relacional de código abierto que no usaba el lenguaje de consultas SQL (Structured Query Language).

Seguir leyendo