Hoy quiero compartirles algunas pruebas que realice con ZonedDateTime y OffsetDateTime.
En primer lugar podemos decir que tenemos un "Instant" que representa un instante determinado de tiempo, luego tenemos un OffsetDateTime que representa un instante de tiempo con el agregado de que este tiene un offset aplicado, luego tenemos un ZonedDateTime que es un instante de tiempo con un Offset aplicado y con reglas de TimeZone (ZoneRules) para las conversiones de horario de verano y otras particularidades de cada TimeZone.
Puede que tengan las dudas de cual debemos y cual no debemos usar ya que ambas son iguales a simple vista o parecidas pero a la realidad no lo son, por las particularidades ya mencione al principio.
Por lo general para guardar fechas en cualquier medio de almacenamiento debemos usar el OffsetDateTime ya que este no pierde información al momento de almacenarse, cosa que si pasa cuando usamos el ZonedDateTime, ya que se pierden las ZoneRules al momento de persistirse, por lo cual tenemos que tener en claro que el OffsetDateTime debemos usarlos en los modelos de persistencia y el ZonedDateTime cuando queremos realizar operaciones de complejas entre fechas ya que estas operaciones van a contemplar las reglas de cada TimeZone. Ahora si las operaciones son simples como determinar si una fecha es menor, igual o mayor podemos usar tranquilamente OffsetDateTime para este tipo de operaciones.
Resumiendo OffsetDateTime es para modelos de persistencia y ZonedDateTime para realizar operaciones con las fechas, y como ultimo comentario mencionar que podemos obtener un ZonedDateTime mediante un OffsetDateTime y viceversa.
Hola a todos, hace mucho que no me doy una vuelta por acá XD.
Hoy tengo ganas de escribir del trabajo en equipo, hace poco me tope con un articulo que habla de cuanto invierte Google en buscar cual es la mejor dinámica para trabajar en equipo. Y básicamente dice que los equipos trabajan mejor cuando no existe jerarquía o tiene una jerarquía plana, y esto es lo que ayuda a que ningún miembro del equipo sienta temor en contradecir una idea ya sea del líder o cualquier otro miembro del proyecto para demostrar que no es del todo correcto.
Si nos ponemos a pensar por lo general cuando queremos plantear una idea siempre tenemos el temor de contradecir a nuestros superiores o sentimos que podemos no ser valorados o aceptados en la propuesta de nuevas ideas o decir que una idea planteada no es del todo correcta.
Otra cosa que puede pasar es que a primera vista el equipo muestre que todas las ideas son bienvenidas y se arman reuniones para plantear ideas entre todos los miembros del equipo y lo que se termina haciendo es lo que un superior decide y eso a largo plazo termina perjudicando ya que se termina pensando: "Para que pensar en una alternativa si al final se hace lo que el jefe dice", esto en un contexto de un jefe que ni contempla las alternativas y solo quiere parecer un buen jefe.
Personalmente haciendo una retrospectiva de mi vida laboral, me doy cuenta que cuando mas rendí fue cuando mas cómodo estuve en cuanto a la aceptación de mis ideas (claro algunas fueron buenas, otras no tanto y otras fueron malisimas :( el proceso del aprendizaje), y en esos equipos que estuve el rol del "Líder/Jefe" siempre fue un rol de coordinador y moderador mas que un jefe, siempre fue uno mas que nosotros y nos hacia sentir que valoraba nuestras ideas a lo que atribuyo que esos lideres entendían y aplicaban la inteligencia emocional.
Para terminar, si sos líder o jefe aplica la inteligencia emocional, motiva al equipo y sobre todo, demostrá que sos uno de ellos y no solo el jefe.
Este post pretende mostrar los pasos a seguir para la migración del mongoDB 2.4 a 3.2.
¿Por qué debemos migrar a 2.6 primero?
En la versión 2.6 se cambia el modelo de datos para las credenciales de los usuarios, como así también se agregan nuevas herramientas de auditoria. En el proceso de migración a esta versión se realizan los cambios de modelos necesario y la verificación del buen funcionamiento de las nuevas herramientas. Estas verificaciones y cambios en versiones posteriores no se realiza.
La migración debe de comenzar por las réplicas secundarias siguiendo los siguientes pasos:
1- Conectarse a la réplica con el mongo 2.6:
./mongo host:puerto -> Cambien el host según la réplica que estén actualizando y el puerto.
2- En la Shell de mongo ejecutar:
rs.stepDown() -> Este solo hay que ejecutarlo si el nodo es el primario, hace que otro nodo sea el primario.
rs.slaveOk() -> Ese comando es la forma corta de ejecutar el siguiente comando: db.getMongo().setSlaveOk(), lo que hace es habilitar en la conexión actual las operaciones de lectura en el miembro secundario (En la réplica).
use admin -> selecciona la base de datos “admin”.
db.upgradeCheckAllDBs() -> Realiza una comprobación de compatibilidad de todos los datos almacenados.
3- Actualizamos los binarios del mongoDb en el nodo(servidor):
Ingresamos al nodo.
Nos conectamos al MongoDb.
use admin -> cambiamos a admin.
db.shutdownServer() -> paramos el server.
mv carpetaMongoBinarios carpetaMongoBinarios-2.4 -> renombramos la carpeta del mongo para instalar la nueva versión.
Descargamos la versión del MongoDB según nuestro Sistema Operativo (recordar que estamos migrando primero a la 2.6)
Levantamos el mongod nuevamente. Recuerden que tenemos que levantar el nodo con la misma configuración que tenia antes de migrar el binario. Este post supone que se tiene en una carpeta separada el archivo de configuración del mongod y el storage del mongo.
Esperamos que se ponga funcional.
Migración de 2.6 a 3.0
Los pasos para la migración de la versión 2.6 a la 3.0 son los mismos ya descritos para la migración de la 2.4 a la 2.6, solo hay que cambiar las referencias a las versiones 3.0 en donde corresponda.
¿Qué nos ofrece MongoDB 3.0?:
Nueva API de motor de almacenamiento de MongoDB que permite optimizar la base de datos para diferentes arquitecturas de hardware y cargas de trabajo de aplicaciones.
MongoDB 3.0 multiplica el rendimiento entre siete y diez veces, ofrece escalabilidad vertical para las cargas de trabajo de escritura intensiva mediante la recopilación y el bloqueo a nivel de documento. La compresión nativa reduce considerablemente los costes de almacenamiento hasta en un 80%. Ahora los conjuntos de réplicas pueden incluir hasta 50 miembros, lo que reduce la latencia al distribuir geográficamente los datos cerca de los usuarios.
Ampliación del marco de auditoría introducido en MongoDB 2.6 para incluir todas las operaciones de sistema y datos (DDL y DML) en la base de datos. Gracias a estas extensiones, ahora los administradores pueden crear y filtrar las trazas de auditoría de cualquier operación en MongoDB sin tener que recurrir a herramientas de terceros.
Definir el Engine WiredTiger
Para realizar correctamente el proceso hay que verificar los valores de los tamaños de los objetos almacenados y el tamaño de la base de datos antes de la migración al nuevo engine. Luego de la migración hay que volver a tomar los valores y comparar con los valores viejos, si los valores se redujeron la migración fue exitosa. Más grande sea la base más notorio va a ser la diferencia en el tamaño después de la migración.
Manos a la obra y a seguir los siguientes pasos:
1- Conectarse a la réplica que vamos a migrar (Comenzar por las secundarias y luego la primaria):
./mongo host:puerto -> Solo es un ejemplo, cambien el host según la réplica que estén actualizando y el puerto.
2- En la Shell de mongo ejecutar:
rs.stepDown() -> Este solo hay que ejecutarlo si el nodo es el primario, hace que otro nodo sea el primario.
rs.slaveOk() -> Ese comando es la forma corta de ejecutar el siguiente comando: db.getMongo().setSlaveOk(), lo que hace es habilitar en la conexión actual las operaciones de lectura en el miembro secundario (En la réplica).
use Database -> La base de datos que se va a usar para realizar la comparación con el antes y el despues de la migración.
db.stats(1024*1024) -> Json con el estado de la base de datos, entre esos datos tenemos el tamaño total de la base y el tamaño por objeto entre otros. Tener en cuenta que si ponemos la escala 1024 lo tenemos en KB y si ponemos 1024*1024 lo tenemos en MB.
3- Bajar el servidor, para hacer esto hay dos alternativas:
db.shutdownServer() -> Esta es una de las opciones, no es la más recomendada.
4- Eliminar el contenido de la carpeta que contiene los datos con el viejo formato, al eliminarlo forzará una re sincronización y al realizar el mismo comprimirá los datos con el nuevo engine. (Revisar que no haya una carpeta montada dentro - “df -h”)
rm -r carpetaMongoConData/*
5- Agregar al archivo de configuración el uso del nuevo engine:
“storageEngine=wiredTiger” -> agregar al archivo mongodb.conf
mongod --storageEngine wiredTiger -> De esta forma se puede especificar en el comando para levantar el mongo. Sí se esta usando el archivo de configuración esta linea no es necesaria
6- Levantar el servidor de mongo:
mongod --storageEngine wiredTiger -> comando alternativo pero poco recomendado. Recordar que si se esta usando un archivo de configuración no es necesario agregar el parámetro
7- Mientras se levanta se va a sincronizar los datos y mientras dure la sincronización el nodo va a estar desactivado en la réplica.
8- Cuando termine la sincronización hay que repetir el paso 1 y 2 para verificar los nuevos valores y comprarlos con los viejos.
9- Repetir los pasos anteriores con los demás nodos.
Los pasos descritos anteriormente es una alternativa de migrar el engine, la otra es hacer un dump de la base de datos y luego un restore, para más información de este proceso revisar el siguiente link.
Hola a todos, hoy les quiero hablar sobre una conversación que tuve con un compañero de trabajo, hoy en día es ¿mas fácil o mas difícil desarrollar?.
Hoy en día hay miles de Frameworks y librerías que nos facilitan muchísimo el desarrollo de nuevas aplicaciones, como ejemplo podemos tomar a Polymer, esté se basa en del desarrollo de webcomponents, la idea es construir o re-utilizar componentes desarrollados por otros o nosotros y de esta forma aceleramos el desarrollo de una web.(Tengamos en cuenta que hoy en día esta en su etapa beta, 0.9). Estos componentes desarrollados luego los usamos como si fueran un TAG mas de nuestro HTML, poner un mapa hoy en día en una web usando Polymer es tan fácil como poner el siguiente TAG:
Con esto nos olvidamos del JavaScript y de renegar haciendo los imports y todo eso. (MAS FÁCIL IMPOSIBLE!!).
O que tal cuando queremos construir una WEB con JAVA y SPRING, con tan solo usar el annotation @RequestMapping ya tenemos un controller (BASTA DE CONFIGURACIONES RARAS), y sin hablar si queremos usar JACKSON para convertir un objeto a JSON, con tan solo declararlo en el xml de spring como un ObjectMapper, una configuración de entre 5 y 10 lineas, no mas de eso, y tenemos un mapper a json en nuestros controllers. Recordemos que de lo contrario, tendríamos que realizar la conversión antes de retornar los datos en todos nuestros controllers.
Pero hasta acá todo fácil, si es que viviéramos en un mundo ideal, ¿qué pasa si es que falla nuestra aplicación en medio de lo que desconocemos?, imaginemos que tenemos un dato de entrada a nuestros controllers y no nos llega el dato esperado del lado del server, ¿cómo sabemos lo que paso? si lo que hace spring es lo mágico que nos facilita la vida. O que tal si nos ponemos en el caso de usar Polymer y algo fallara en el renderizado del mapa usando el TAG de Polymer, ¿Cómo sabríamos que fallo?, sí el funcionamiento interno es justamente lo que desconocemos y nos facilita la vida al desarrollar.
Eh aquí donde todos nos tenemos que darnos cuenta que si bien hoy en día teneos muchas herramientas que nos facilitan la vida a la hora de desarrollar, tenemos que tener un cierto nivel de conocimiento de las herramientas que usamos para poder afrontar los problemas que podamos llegar a enfrentar, y ahí es donde la experiencia y los conocimientos a bajo nivel (conocer las entrañas de las herramientas que usamos) nos es de buena ayuda.
Por todo esto yo diría que si bien hoy tenemos muchas herramientas que nos ayudan en el día a día en los desarrollos, el nivel de conocimientos que debemos tener hoy para solventar los posibles errores que debemos afrontar requieren un mayor nivel de conocimientos, en patrones, lenguajes, arquitecturas, tecnologías, en fin, en muchísimas mas cosas que las que requeríamos antes.
Me gustaría dejar la siguiente frase para que la tengamos en cuenta:
"Hoy en día es mas fácil iniciarnos en el mundo del desarrollo, y depende de nosotros profundizar los conocimientos"
En lo personal amo esta profesión porque siempre hay algo por aprender y tengo retos nuevos todos los días, conozco gente que admiro el como realiza las cosas, como las resuelve. Y siempre que me preguntan de que trabajo responde que yo no trabajo, hago lo que mas me gusta en el mundo.
Hakiemos nuestras vidas, nuestra forma de vivir, nuestra forma de aprender, hagamos divertido nuestro aprendizaje.
Hola a todos, hoy les quiero contar un poco lo que fue mi 2014.
Este año comenzo con muchos obstáculos por saltar y muchas metas por cumplir, se que no eh podido cumplir todas las metas, pero las principales gracias a dios si las pude cumplir :).
En lo personal crecí muchisimo :), y lo unico que les puedo contar es que el amor que nos tenemos con mi señora se duplico :).
En lo profesional, arranque el año Trabajando en Accenture, una empresa donde aprendí muchisimo, fue mi primer trabajo en el ambito laboral, arranque dentro de Accenture trabajando en c++ haciendo servicios web en Tuxedo para Movistar España, una gran experiencia, luego pase a un proyecto web, la www de personal (www.personal.com.ar) ahí seguí aprendiendo muchisimas cosas del mundo web y de Vignette (aunque no me guste mucho), tecnologías del back-end y del front-end :), y mis últimos meses estuve en un proyecto interno de Accenture, en ese proyecto aprendí mucho de como trabajar en equipo y que cosas no tengo que hacer cuando tengo a gente a cargo XD, aprendí como un equipo tiene que tirar y laburar a la par y la organización de la misma.
Luego gracias a dios pude cambiar de trabajo y entre a trabajar en el HSBC Banck (Mediante a Tecnosoftware), ahí conocí a una gran persona, ahí conocí a Gastón alvarez, para mi esa persona es lo que yo llamo Hacker, personas con una gran inteligencia y que cualquiera, si mantiene una charla de 10 minutos aprende cosas maravillosas, él re vivió en mi la pasión por el desarrollo y las ganas de incursionar en nuevos mundos de la informática, hoy en mi trabajo actual lo extraño mucho... ;), espero poder volver a compartir una charla con él. Otra persona interesante fue Nacho XD ese es un loco que me dejo muchas lecciones de la vida, Alan otra persona que me tuvo mucha paciencia jaja en fin, muchas personas de las cuales aprendí mucho en HSBC :).
Actualmente llevo 3 meses trabajando en despegar.com, estoy mas que chocho, lugar donde hay mucha gente que sabe y no es solo eso, actualmente estoy trabajando con tecnologías de punta, con desafíos constantes y aprendiendo mucho. :), actualmente puedo hablar de Agustin y de Lucas, dos personas que saben Bocha, Otra persona que puedo mensionar es Pablo, aunque no hablo mucho con el se nota que sabe... y la charla que dio para la comunidad de JavaScript me dejo anonadado XD, El equipo entero con el cual trabajo me deja con boca abierta, y eso, hace que sea un gusto estar trabajando con ellos, hoy deje de ser aquella persona que notaba cosas malas hechas en los proyectos que participaba, a una persona que aprende como se tienen que hacer bien las cosas :).
En cuanto a mi participación en el GDG (Google Developers Groups), fue un excelente año, hoy soy Manager del GDG La Plata, tratando de levantar la comunidad en La Plata, volví a participar en el DevFest en Buenos Aires, Conocí a Diego (Manager del GDG La Plata), una excelente persona, me hice de nuevos amigos y conocidos :), Participar en esta comunidad es lo mejor que me paso en cuanto a lo profesional, constantemente estoy conociendo a personas con un dominio de las tecnologías que da envidia jaja ojo de la buena, aquella que te contagia esas ganas de seguir aprendiendo, personas que alientan a uno a crecer constantemente y que ayudan a uno a dejar de tener los miedos al cambio, a esos cambios que nos ayudan en diferentes aspectos.
Este año fue un excelente año para mi, y la verdad que estoy super agradecido a dios y a mi querida virgen de Urkupiña por el gran año que me dieron.
Debajo les dejo los resúmenes del DevFest 2013 y 2014.
Felices fiestas a todos y les deseo un excelente 2015 :) Happy Hacking };)
Hola a todos, hoy vamos a repasar algunos conceptos y mencionar algunas cosas que hay que tener en cuenta a la hora de trabajar con archivos.
Marca de fin de Archivo: Todos los archivos tienen una marca de fin de archivo EOF y para consultar si estamos en el fin de archivo tenemos la sentencia eof(nombre_logico). Este nos retorna true si es que estamos en el fin del archivo.
Control de Tamaño de Archivo: Para controlar la cantidad de elementos del archivo tenemos la sentencia filesize(nombre_logico), que nos retorna un entero con la cantidad de elementos que guardamos en el archivo.
Control de posición dentro del Archivo: Tenemos una sentencia que nos retorna la posición actual del puntero (descriptor) , este es la variable que contiene la referencia lógica de nuestro archivo. La sentencia es la siguiente: Filepos(nombre_logico), y esta nos retorna un valor de 0 al tamaño del archivo.
Ubicación física en alguna posición del archivo: Con esta operación nos podemos posicionar en cualquier lugar del archivo para leer, modificar cualquier elemento o agregar nuevos elementos, la sentencia es: seek(nombre_logico, posición), por ejemplo podemos usar esta función para pararnos al final del archivo de la siguiente forma: seek(nombre_logico, filesize(nombre_logico)).
Algunas cosas que debemos recordar es que cuando leemos un dato del archivo este puntero al archivo (nombre_logico) avanza un lugar en el archivo y cuando escribimos pasa lo mismo, por lo cual no pensemos que se queda en el mismo lugar, si no mas bien avanza una posición en ambos casos.
Por otro lado comentarles que todas estas instrucciones tienen sus equivalentes en otros lenguajes, por lo cual son facilmente trasladables a otros lenguajes.
Por ahora es todo, en los proximos post comenzaremos con la algoritmia básica sobre archivos.
Hola a todos, hoy les voy a dejar un código donde se muestra como crear, cargar, leer y modificar los datos de un archivo en pascal.
Recuerden que este código lo pueden compilar y funciona perfectamente. También recuerden que las explicaciones de los mismos están como comentarios en el código.
