PRENSA GUGLER LAB 20192019 | |||||
NOTICIAS ACTUALES
| OFERTA ACADÉMICA | ||||
Estimado Goette Emanuel :
Esta instancia de inscripción especial comienza hoy, hasta el Lunes 18 de Marzo, luego se abren las inscripciones al público en general, publicando las mismas en todos los medios oficiales.
Las clases estarían iniciándose el miércoles 3, jueves 4, viernes 5 o sábado 6 de Abril,según el curso y modalidad que elegiste.
Inscribirte: clic aquí
Horarios y comisiones: clic aquí.
Saludos cordiales y te esperamos!!.
| Dictamos nuestros cursos en la Facultad de Ciencia y Tecnología, perteneciente a la Universidad Autónoma de Entre Ríos. En nuestro portafolio de capacitación encontrarás: MODALIDAD PRESENCIAL
| ||||
MÁS INFORMACIÓN | LABORATORIO DE INVESTIGACIÓN GUGLER | ||||
Si deseas comunicarte con nosotros, te recordamos que podes hacerlo a través de los siguientes portales, en los cuales encontrarás información sobre Gugler. TEL: (0343) - 4975066 Interno 108 Sitio Oficial: www.gugler.com.ar Campus: campusvirtual.gugler.com.ar Sistema de Gestión Cursos: sgc.gugler.com.ar Sistema de Gestión Cursos Móvil: Aquí Sistema de Documentación: sgd.gugler.com.ar Sistema de Validación: giua.gugler.com.ar |
| ||||
GUGLER PRESS | |||||
Translate
viernes, 15 de marzo de 2019
Inscripciones Abiertas 2019 a cursos Gugler!!
Me llego este mail de los cursos de Gugler. Puede anotarse, el curso de Java esta muy bueno:
martes, 12 de marzo de 2019
Parámetros y argumentos: una manera fácil de recordar la diferencia en Kotlin
Si alguna vez has tenido problemas para recordar la diferencia entre parámetros y argumentos:
Es un parámetro cuando estás dentro de la definición.
Es un argumento cuando estás fuera de la definición.
La forma más fácil de recordar la diferencia entre los dos es asociar la palabra argumento con la palabra afuera.
Aquí hay una función simple que calcula el cuadrado de un entero. ¿Qué datos se pasarán? Solo el número que queremos al cuadrado.
fun square(number: Int): Int {
return number * number
}
Aquí, dentro de la definición de esta función, decimos que el número es un parámetro.
Ahora que hemos definido nuestra función, vamos a usarla. Pasaremos algunos datos a nuestra función cuando la llamemos.
val radius = 5
val area = Math.PI * square(radius)
Aquí, fuera de la definición de la función, decimos que el radius es un argumento de la función square ().
Una clase genérica es aquella que tiene varibles o funciones que no tienen un tipo determinado. Por ejemplo, aquí hay una clase Box muy simple que simplemente envuelve algún otro objeto.
class Box<T>(var item: T)
Aquí, dentro de la definición de la clase, decimos que T es un parámetro de tipo.
Usar esta clase es bastante fácil: simplemente invocamos a su constructor y pasamos los datos que queremos ajustar.
val box = Box <String> ("Hola")
Aquí, fuera de la definición de la clase Box, lo construimos con un argumento de tipo String.
De hecho, Kotlin hace una inferencia de tipo fantástica, por lo que ni siquiera tenemos que especificarlo explícitamente:
caja de val = caja ("Hola")
En este caso, todavía hay un argumento de tipo, y sigue siendo String. Simplemente está implícito en el tipo de argumento "Hola" que le estamoResumen
Es un parámetro cuando estás dentro de la definición.
Es un argumento cuando estás fuera de la definición.
La forma más fácil de recordar la diferencia entre los dos es asociar la palabra argumento con la palabra afuera.
Aquí hay una función simple que calcula el cuadrado de un entero. ¿Qué datos se pasarán? Solo el número que queremos al cuadrado.
fun square(number: Int): Int {
return number * number
}
Aquí, dentro de la definición de esta función, decimos que el número es un parámetro.
Ahora que hemos definido nuestra función, vamos a usarla. Pasaremos algunos datos a nuestra función cuando la llamemos.
val radius = 5
val area = Math.PI * square(radius)
Aquí, fuera de la definición de la función, decimos que el radius es un argumento de la función square ().
Una clase genérica es aquella que tiene varibles o funciones que no tienen un tipo determinado. Por ejemplo, aquí hay una clase Box muy simple que simplemente envuelve algún otro objeto.
class Box<T>(var item: T)
Aquí, dentro de la definición de la clase, decimos que T es un parámetro de tipo.
Usar esta clase es bastante fácil: simplemente invocamos a su constructor y pasamos los datos que queremos ajustar.
val box = Box <String> ("Hola")
Aquí, fuera de la definición de la clase Box, lo construimos con un argumento de tipo String.
De hecho, Kotlin hace una inferencia de tipo fantástica, por lo que ni siquiera tenemos que especificarlo explícitamente:
caja de val = caja ("Hola")
En este caso, todavía hay un argumento de tipo, y sigue siendo String. Simplemente está implícito en el tipo de argumento "Hola" que le estamoResumen
viernes, 8 de marzo de 2019
Seminario web de MongoDB
Me llego un mail de la gente de MongoDB y quería compartirlo con ustedes:
|
miércoles, 6 de marzo de 2019
Libros gratuitos de Java Code Geeks
Download Dev Guides!
martes, 5 de marzo de 2019
Snitches en Cassandra
El trabajo de un snitch es determinar la proximidad del host relativa para cada nodo en un clúster, que se utiliza para determinar de qué nodos leer y escribir. Los snitches recopilan información sobre la topología de su red para que Cassandra pueda enrutar las solicitudes de manera eficiente. El snitch descubrirá dónde están los nodos en relación con otros nodos.
A modo de ejemplo, examinemos cómo participa el snitch en una operación de lectura. Cuando Cassandra realiza una lectura, debe contactar una cantidad de réplicas determinadas por el nivel de consistencia. Para admitir la velocidad máxima para las lecturas, Cassandra selecciona una única réplica para consultar el objeto completo y solicita réplicas adicionales para los valores de hash para garantizar que se devuelva la última versión de los datos solicitados. La función de el snitch es ayudar a identificar la réplica que devolverá este dato de forma rápida, y esta es la réplica que se consulta para obtener los datos completos.
El snitch predeterminado (el SimpleSnitch) es la topología inconsciente; es decir, no conoce los racks y los centros de datos en un clúster, lo que lo hace inadecuado para implementaciones de centros de datos múltiples. Por esta razón, Cassandra viene con varios snitches para diferentes entornos de nube, incluyendo Amazon EC2, Google Cloud y Apache Cloudstack.
Los snitches se pueden encontrar en el paquete org.apache.cassandra.locator. Cada snitch implementa la interfaz IEndpointSnitch.
Si bien Cassandra proporciona una manera conectable de describir de forma estática la topología de su clúster, también proporciona una función llamada "snitching dinámico" que ayuda a optimizar el enrutamiento de las lecturas y escrituras a lo largo del tiempo. Así es como funciona. Su snitch seleccionado se envuelve con otro snitch llamado DynamicEndpointSnitch. El snitch dinámico obtiene su comprensión básica de la topología de la snitch seleccionada. A continuación, supervisa el rendimiento de las solicitudes a los otros nodos, e incluso realiza un seguimiento de cosas como qué nodos realizan la compactación. Los datos de rendimiento se utilizan para seleccionar la mejor réplica para cada consulta. Esto permite a Cassandra evitar las solicitudes de enrutamiento a réplicas que tienen un bajo rendimiento.
La implementación de snitching dinámico utiliza una versión modificada del mecanismo de detección de fallas Phi utilizado por los Gossiper(que hablamos el post anterior). El "umbral de maldad" es un parámetro configurable que determina cuánto peor debe realizar un nodo preferido que el nodo con el mejor desempeño para perder su estado preferencial. Las puntuaciones de cada nodo se restablecen periódicamente para permitir que un nodo con un rendimiento deficiente demuestre que se ha recuperado y reclamar su estado preferido.
A modo de ejemplo, examinemos cómo participa el snitch en una operación de lectura. Cuando Cassandra realiza una lectura, debe contactar una cantidad de réplicas determinadas por el nivel de consistencia. Para admitir la velocidad máxima para las lecturas, Cassandra selecciona una única réplica para consultar el objeto completo y solicita réplicas adicionales para los valores de hash para garantizar que se devuelva la última versión de los datos solicitados. La función de el snitch es ayudar a identificar la réplica que devolverá este dato de forma rápida, y esta es la réplica que se consulta para obtener los datos completos.
El snitch predeterminado (el SimpleSnitch) es la topología inconsciente; es decir, no conoce los racks y los centros de datos en un clúster, lo que lo hace inadecuado para implementaciones de centros de datos múltiples. Por esta razón, Cassandra viene con varios snitches para diferentes entornos de nube, incluyendo Amazon EC2, Google Cloud y Apache Cloudstack.
Los snitches se pueden encontrar en el paquete org.apache.cassandra.locator. Cada snitch implementa la interfaz IEndpointSnitch.
Si bien Cassandra proporciona una manera conectable de describir de forma estática la topología de su clúster, también proporciona una función llamada "snitching dinámico" que ayuda a optimizar el enrutamiento de las lecturas y escrituras a lo largo del tiempo. Así es como funciona. Su snitch seleccionado se envuelve con otro snitch llamado DynamicEndpointSnitch. El snitch dinámico obtiene su comprensión básica de la topología de la snitch seleccionada. A continuación, supervisa el rendimiento de las solicitudes a los otros nodos, e incluso realiza un seguimiento de cosas como qué nodos realizan la compactación. Los datos de rendimiento se utilizan para seleccionar la mejor réplica para cada consulta. Esto permite a Cassandra evitar las solicitudes de enrutamiento a réplicas que tienen un bajo rendimiento.
La implementación de snitching dinámico utiliza una versión modificada del mecanismo de detección de fallas Phi utilizado por los Gossiper(que hablamos el post anterior). El "umbral de maldad" es un parámetro configurable que determina cuánto peor debe realizar un nodo preferido que el nodo con el mejor desempeño para perder su estado preferencial. Las puntuaciones de cada nodo se restablecen periódicamente para permitir que un nodo con un rendimiento deficiente demuestre que se ha recuperado y reclamar su estado preferido.
lunes, 4 de marzo de 2019
Gossip y Detección de fallos en Apache Cassandra
Para admitir la descentralización y la tolerancia de partición, Cassandra usa un protocolo de Gossip que permite a cada nodo realizar un seguimiento de la información de estado sobre los otros nodos en el clúster. El gossiper se ejecuta cada segundo en un temporizador.
Los protocolos de Gossip (a veces llamados "protocolos epidémicos") generalmente asumen una red defectuosa, se emplean comúnmente en sistemas de redes muy grandes y descentralizados, y se usan a menudo como un mecanismo automático para la replicación en bases de datos distribuidas.
Toman su nombre del concepto de chisme humano, una forma de comunicación en la que los compañeros pueden elegir con quién desean intercambiar información y no solo intercambian información de ellos mismos sino tambien de otros compañeros, lo que permite disminuir el trafico de la red, ya que no todos se comunican con todos.
El protocolo de Gossip en Cassandra se implementa principalmente mediante la clase org.apache.cassandra.gms.Gossiper, que es responsable de administrar los chismes para el nodo local. Cuando se inicia un nodo de servidor, se registra con el gossiper para recibir información del estado del punto final.
Debido a que los Gossip de Cassandra se usan para la detección de fallas, la clase Gossiper mantiene una lista de nodos que están vivos y muertos.
Así es como funciona el Gossiper:
- Una vez por segundo, el Gossiper elegirá un nodo aleatorio en el clúster e iniciará una sesión de chismes con él. Cada ronda de chismes requiere tres mensajes.
- El iniciador de chismes envía a su amigo elegido un GossipDigestSynMessage.
- Cuando el amigo recibe este mensaje, devuelve un GossipDigestAckMessage.
- Cuando el iniciador recibe el mensaje de acuse de recibo del amigo, le envía un mensaje de GossipDigestAck2 para que complete la ronda de chismes.
Cuando el Gossiperer determina que otro punto final está muerto, "condena" ese punto final al marcarlo como muerto en su lista local y registrar ese hecho.
Cassandra tiene un soporte robusto para la detección de fallas, como lo especifica un algoritmo popular para la computación distribuida llamada Phi Accrual Failure Detection. Esta forma de detección de fallas se originó en el Instituto Avanzado de Ciencia y Tecnología en Japón en 2004.
La detección del fracaso acumulado se basa en dos ideas principales. La primera idea general es que la detección de fallas debe ser flexible, lo que se logra al desacoplarla de la aplicación que se está monitoreando. La segunda y más novedosa idea desafía la noción de detectores de falla tradicionales, que se implementan mediante simples "latidos" y deciden si un nodo está muerto o no, según si se recibe un latido o no. Pero la detección de fallos acumulados decide que este enfoque es ingenuo, y encuentra un lugar entre los extremos de muertos y vivos, un nivel de sospecha.
Por lo tanto, el sistema de monitoreo de fallas genera un nivel continuo de "sospecha" con respecto a la confianza de que un nodo ha fallado. Esto es deseable porque puede tener en cuenta las fluctuaciones en el entorno de red. Por ejemplo, solo porque una conexión quede atrapada no significa necesariamente que todo el nodo esté muerto.
Por lo tanto, la sospecha ofrece una indicación más fluida y proactiva de la posibilidad de falla más débil o más fuerte basada en la interpretación (el muestreo de los latidos), en lugar de una simple evaluación binaria.
La detección de fallos se implementa en Cassandra mediante la clase org.apache.cassandra.gms.FailureDetector, que implementa la interfaz org.apache.cassandra.gms.IFailureDetector. Juntos, permiten operaciones que incluyen:
- isAlive (InetAddress) : Lo que el detector informará sobre la vida de un nodo dado.
- interpret (InetAddress): Utilizado por el Gossiper para ayudarlo a decidir si un nodo está vivo o no basado en nivel de sospecha alcanzado mediante el cálculo de Phi.
- report (InetAddress) : Cuando un nodo recibe un latido, invoca este método.
domingo, 3 de marzo de 2019
La arquitectura de Cassandra
Vamos a examinar la arquitectura de Apache Cassandra, para entender como trabaja. Los nodos interactúan de un modo peer-to-peer o punto a punto, y para conocer donde están los datos utilizan técnicas de gossip, anti-entropy y hinted handoff que vamos a ir desarrollando en este post y los próximos.
Cassandra nos permite separar nuestros nodos en racks y datacenters, esto nos da ventajas a la hora de tener los datos separados en diferentes ubicaciones geográficas. Un rack en un conjunto de nodos , físicamente tiene en cuenta que un rack siempre son maquinas que están próximas, idealmente en un mismo rack. Un datacenter es un conjunto de rack que se encuentran en el mismo edificio físico y conectadas a la misma red.
Cassandra aprovecha la información que proporciona sobre la topología de su clúster para determinar dónde almacenar los datos y cómo encaminar las consultas de manera eficiente. Cassandra intenta almacenar copias de sus datos en múltiples centros de datos para maximizar la disponibilidad y la tolerancia de partición, mientras que prefiere enrutar las consultas a los nodos en el centro de datos local para maximizar el rendimiento.
sábado, 2 de marzo de 2019
Quiero recomendar el curso “AI for Everyone”
El amigo Andrew Ng me invito a hacer un curso gratuito en coursera sobre Inteligencia artificial:
Yo que ustedes le hago caso y me anoto!!
| |||||||||||||
|
Yo que ustedes le hago caso y me anoto!!
miércoles, 27 de febrero de 2019
Libros de Java Code Geeks
|
Modelo lógico de datos de Apache HBase
Hbase provee row
keys, concepto que podemos mapear con las primary keys de las bases
de datos relacionales. Nosotros podemos trabajar sin grandes
operaciones de lectura y escritura, dado que las filas estan
divididas en columns families y columnas. Esto soporta escalado
vertical y horizontal de las tablas.
Una tabla esta
compuesta por filas→ familias de columnas → columnas → celdas
Por lo tanto podemos
pensar en una fila como un conjunto no vacio de familias de columnas,
la familia de columnas como un conjunto no vacio de columnas y las
columnas son estan formadas (made up) por celdas. Y los datos son
accedidos por el row key.
Nosotros podemos o debemos consultar por row key más el column family y el nombre de la
columna.
A nivel conceptual,
las tablas de hbase vistas como un conjunto separado de filas pero a
nivel fisico, se guardan conjuntos de columnas que son las familias
de columnas.
A nivel conceptual, una tabla HBase se puede ver como un conjunto disperso de filas, pero en el almacenamiento real, se almacena según una familia de columnas. Al definir una tabla, las columnas se pueden agregar o especificar en la ejecución en una familia de columnas. Debemos decidir el número y el nombre de la familia de columnas en el momento de la reactivación de la tabla, pero las columnas se pueden agregar según sea necesario en cualquier momento mientras se almacenan los datos, y esta es la belleza de la ausencia de esquemas cuando usamos HBase.
Una columna siempre se representa y se accede utilizando el nombre de la familia de columnas como prefijo (columnfamilyname: columnname) para que sepamos a qué familia de columnas se accede. Las columnas que no contienen valores no se almacenan.
En las versiones anteriores de HBase, no teníamos un concepto de base de datos; sin embargo, existía el concepto de Tabla. La versión más reciente de HBase introduce un concepto llamado espacio de nombres (compatible con HBase 0.96 y versiones posteriores) que agrupa las tablas de forma lógica, lo que brinda una representación más estructurada y organizada, y un almacenamiento de tablas.
domingo, 24 de febrero de 2019
Relacional vs. HBase Schemas
No hay una asignación uno a uno de las bases de datos relacionales a HBase. En el diseño relacional, el enfoque y el esfuerzo están alrededor de describir la entidad y su interacción con otras entidades.
Pero con HBase, tiene un diseño de esquema de "consulta primero"; todas las posibles consultas deben identificarse primero, y el modelo de esquema debe diseñarse en consecuencia. Debes diseñar tu esquema HBase para aprovechar las fortalezas de HBase. Piense en sus patrones de acceso y diseñe su esquema para que los datos que se leen juntos se almacenen juntos. Recuerde que HBase está diseñado para agrupación. Por lo tanto tenemos que tener en cuenta estos 3 puntos a la hora de diseñar una estema hbase:
- Los datos distribuidos se almacenan y se accede juntos.
- Se centra en las consultas, así que concéntrese en cómo se leen los datos
- Diseño para las consultas.
En una base de datos relacional, la normalización de el esquema tiene como beneficios:
- No tiene que actualizar varias copias cuando se produce una actualización, lo que hace que las escrituras sean más rápidas.
- Reduce el tamaño de almacenamiento al tener una sola copia en lugar de varias copias.
- Sin embargo, esto provoca uniones o joins. Como los datos deben recuperarse de más tablas, las consultas pueden tardar más tiempo.
En un almacén de datos des-normalizado, almacena en una tabla lo que serían múltiples índices en un mundo relacional. La des-normalización puede considerarse como un reemplazo para las uniones. A menudo, con HBase, des-normaliza o duplica datos para que los datos se accedan y almacenen juntos.
Este es un ejemplo de desnormalización en HBase, si sus tablas existen en una relación de uno a varios, es posible modelarlo en HBase como una sola fila. Esto hace que las lecturas sean mucho más rápidas que unir tablas.
La clave de fila corresponde al ID de entidad principal, el Id. para HBase puede ser una familia de columnas para los datos. Este tipo de diseño de esquema es apropiado cuando la única forma de acceder a las entidades secundarias es a través de la entidad principal.
jueves, 21 de febrero de 2019
Amazon Corretto
Amazon me esta sorprendiendo y para bien, ultimamente.
Amazon permite bajar su OpenJDK: Amazon Corretto. La cual no tiene costo, es multiplataforma y lista para producción.
Corretto viene con soporte a largo plazo que incluirá mejoras de rendimiento y correcciones de seguridad. Para el que no la conocía, Amazon ejecuta Corretto internamente en miles de servicios de producción y Corretto está certificado como compatible con el estándar Java SE. Con Corretto, puede desarrollar y ejecutar aplicaciones Java en sistemas operativos populares, incluidos Linux, Windows, macOS y hasta Docker.
Actualmente podemos bajar la version 8 o la preview de la 11 :
Installation Guides for Corretto 8
Installation Guides for Corretto 11 Preview
Dejo link: https://aws.amazon.com/corretto/
martes, 19 de febrero de 2019
AdoptOpenJDK
El código de Java es de código abierto y está disponible en la OpenJDK. AdoptOpenJDK proporciona binarios OpenJDK creados previamente a partir de un conjunto de código totalmente abierto de scripts de compilación e infraestructura.
Con AdoptOpenJDK podemos obtener imágenes de Docker en Docker Hub, con la open que necesitemos. A la vez podemos obtener las últimas versiones. Y se pueden obtener Nightly builds.
Las plataformas que son soportadas son:
Linux x64
jdk8u202-b08
Windows x32
jdk8u202-b08
Windows x64
jdk8u202-b08
macOS x64
jdk8u202-b08
Linux s390x
jdk8u202-b08
Linux ppc64le
jdk8u202-b08
Linux aarch64
jdk8u191-b12
Solaris sparcv9
jdk8u202-b08
AIX ppc64
jdk8u202-b08
Docker
Official Image
Dejo link: https://adoptopenjdk.net/releases.html
Suscribirse a:
Entradas (Atom)