Seguimos con scala : https://emanuelpeg.blogspot.com/2019/09/funciones-con-funciones-como-parametros.html
Cuando pasamos un función por parámetro Scala infiere el tipo de la función y lo chequea con el tipo esperado, esto no es más que el chequeo por tipo que realiza cualquier lenguaje de tipado estático.
Veamos un ejemplo:
valueAtOneQuarter((x: Double) => 3 * x) // 0.75
Dado que la función valeAtOneQuarter espera un (Doble) => Doble por lo tanto Scala puede inferir que es un double y de esta manera podemos escribir :
valueAtOneQuarter((x) => 3 * x)
También podemos quitar los paréntesis :
valueAtOneQuarter(x => 3 * x)
También podemos utilizar azúcar sintáctica, dado que la variable x no representa algo en particular y no hay muchas lógica aquí :
valueAtOneQuarter(3 * _)
De esta manera, como la función tiene el tipo declarado Scala lo puede inferir pero si nosotros hacemos :
val fun = 3 * _
Vamos a tener un error dado que no se puede inferir el tipo, pero esto se puede soluciónar así :
val fun = 3 * (_: Double)
o
val fun: (Double) => Double = 3 * _
Especificar el tipo de _ es útil para convertir los métodos en funciones. Por ejemplo, (_: String) .length es una función String => Int, y (_: String) .substring (_: Int, _: Int) es una función (String, Int, Int) => String.
Translate
sábado, 12 de octubre de 2019
jueves, 10 de octubre de 2019
Libros de Java geek
martes, 8 de octubre de 2019
Design Patterns in Go
Quiero compartir esta gran pagina que muestra implementaciones de los patrones de diseño GOF en Go. Sería GOF en Go. Esta bueno como nombre de la página "Gof in Go" , bueno...
Ustedes pensarán igual que yo, como van implementar patrones Gof si Go no es orientado a objetos, pero si, con su polimorfismo en las estructuras, puede.
La verdad es que me cautiva porque en tantas cosas no estoy de acuerdo con esta pagina, pero a la vez me parece un genial ejercicio para aprender. Por ejemplo cuando afirma que Go es orientado a objetos pero no tiene ni clases, ni objetos. No sé, por algun lado no me cierra.
En fin, esta en castellano, así que aprovechen.
Dejo link: https://www.designpatternsingo.com/
Hacer diagramas de secuencia súper fáciles con sequencediagram.org
Cada tanto te encontras con una herramienta que vale la pena compartir y este es el caso.
sequencediagram.org es un editor de diagramas de secuencia, súper fácil que se basa en texto para generar nuestros diagramas.
Tenes un lenguaje generador de diagramas que es muy fácil de utilizar y a medida que escribimos nuestro código se va generando el diagrama. Este código tiene instrucciones básicas y no ten básicas que permiten generar y embellecer nuestros diagramas.
Generado nuestro diagrama, podemos exportarlo a imagen (png), guardar le texto, compartirlo, guardarlo en un google drive, etc.
Sin más dejo el link: https://sequencediagram.org/
Cómo dividir cadenas separadas por comas y usarlas en una cláusula IN en un select en oracle
Veamos dijo Stevie Wonder, en el trabajo por x motivos guardamos un campo con ids separados por comas.
Más allá de si esto esta bien o mal, necesitaba cortarlo y buscar por estos datos, como lo hice? :
select regexp_substr(columnasConIdsSeparadosPorComa,'[^,]+', 1, level) from tabla;
y bueno, esta query puede estar en un in :
select * from OtraTabla ot
where ot.id in ( select regexp_substr(columnasConIdsSeparadosPorComa,'[^,]+', 1, level) from tabla )
Y eso es todo amigos!
domingo, 6 de octubre de 2019
Channels en Go
Continuamos con en go
Los channels o canales son las tuberías que conectan las goroutinas concurrentes. Puede enviar valores a canales desde una goroutine y recibir esos valores en otra goroutine.
Se puede crear un nuevo channel con make (chan val-type). Los channels o canales están tipificados por los valores que transmiten.
Veamos un ejemplo:
package main
import "fmt"
func main() {
messages := make(chan string)
go func() { messages <- "ping" }()
msg := <-messages
fmt.Println(msg)
}
$ go run channels.go
ping
Como se puede ver en el ejemplo, se crea un chanel y luego envía valor a este chanel utilizando la sintaxis <-. En el ejemplo enviamos "ping" al canal messages que hicimos arriba, desde una nueva rutina.
La sintaxis <- permite recibir un valor del canal. Aquí recibiremos el mensaje de "ping" que enviamos arriba y lo imprimimos.
Cuando ejecutamos el programa, el mensaje "ping" se pasa con éxito de una rutina a otra a través de nuestro canal.
Por defecto se envían y reciben datos hasta que el emisor como el receptor estén listos. Esta propiedad nos permite esperar al final de nuestro programa el mensaje "ping" sin tener que usar ninguna otra sincronización.
Dejo link: https://gobyexample.com/channels
Los channels o canales son las tuberías que conectan las goroutinas concurrentes. Puede enviar valores a canales desde una goroutine y recibir esos valores en otra goroutine.
Se puede crear un nuevo channel con make (chan val-type). Los channels o canales están tipificados por los valores que transmiten.
Veamos un ejemplo:
package main
import "fmt"
func main() {
messages := make(chan string)
go func() { messages <- "ping" }()
msg := <-messages
fmt.Println(msg)
}
$ go run channels.go
ping
Como se puede ver en el ejemplo, se crea un chanel y luego envía valor a este chanel utilizando la sintaxis <-. En el ejemplo enviamos "ping" al canal messages que hicimos arriba, desde una nueva rutina.
La sintaxis <- permite recibir un valor del canal. Aquí recibiremos el mensaje de "ping" que enviamos arriba y lo imprimimos.
Cuando ejecutamos el programa, el mensaje "ping" se pasa con éxito de una rutina a otra a través de nuestro canal.
Por defecto se envían y reciben datos hasta que el emisor como el receptor estén listos. Esta propiedad nos permite esperar al final de nuestro programa el mensaje "ping" sin tener que usar ninguna otra sincronización.
Dejo link: https://gobyexample.com/channels
sábado, 5 de octubre de 2019
Goroutines
Continuamos con en go
Supongamos que tenemos que llamar una función de forma asíncrona en Go, para eso son las goroutines, veamos un ejemplo :
package main
import (
"fmt"
"time"
)
func f(from string) {
for i := 0; i < 3; i++ {
fmt.Println(from, ":", i)
}
}
func main() {
f("direct")
go f("goroutine")
go func(msg string) {
fmt.Println(msg)
}("going")
time.Sleep(time.Second)
fmt.Println("done")
}
Como se ve, llamamos una función de forma directa sincrona, y otras 2 con goroutines. El resultado va ser :
$ go run goroutines.go
direct : 0
direct : 1
direct : 2
goroutine : 0
going
goroutine : 1
goroutine : 2
done
Si venimos de lenguajes como C podemos decir que Go con las goroutines crea un hilo por geroutin.
Si venimos de lenguajes como C podemos decir que Go con las goroutines crea un hilo por geroutin.
Dejo link: https://gobyexample.com/goroutines
jueves, 3 de octubre de 2019
Microsoft anuncia la disponibilidad de .NET Core 3
Microsoft anuncia la disponibilidad de .NET Core 3 en linux, windows y Mac.
Primero empiezo con lo que no me gusto, Windows Presentation Foundation (WPF), no esta soportado en Linux. Y no me gusto porque tengo muchas ganas de jugar con ventanas en linux, si bien hoy todo tiende a la web, todavía se utiliza el escritorio y sobre todo en las aplicaciones base. Y me gustaría que se implemente el concepto de look and feel similar a java (pero esto ya soñando)
Cosas que vienen bien:
- incluir una notable mejora del rendimiento frente a versiones anteriores,
- nuevas API de JSON
- soporte para los lenguajes de programación C# 8 y F# 4.7.
- aumenta el conjunto de tipos que se puede usar en el código tanto en .NET Core como Xamarin
- un recolector de basura que ahora usa menos memoria
- la inclusión por defecto de ejecutables en las aplicaciones de .NET Core, soporte para Raspberry Pi y otros chips ARM, además de haberse mejorado el desempeño del framework en los contenedores Docker.
.NET Core 3.0, al igual que las versiones anteriores, es Open Source (licencia MIT) y multipltaforma, pudiendo ser descargado para Linux (Ubuntu, RHEL, Fedora, openSUSE, Debian, CentOS y SLES), Windows, Mac y como contenedor Docker.
Dejo link: https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/
miércoles, 2 de octubre de 2019
Anonymous fields en Go
Continuamos con en go
Como podemos aplicar composiciones a un lenguaje no orientado a objeto y que no se vea forzado? Y la respuesta la tiene Go con Anonymous fields. En Go solo tenemos estructuras y funciones que trabajan con dichas estructuras. Si bien Go tiene una forma de escribir estas estructuras y su interacción con las funciones que hace imaginar a objetos, esto no es así.
Pero Go utiliza composiciones, como lo hace? componiendo estructuras: Go permite definir una estructura que tiene campos pero sin nombres de variables. Estos campos se llaman campos anónimos. Hagamos algunos ejemplos para descubrir cuáles son y cómo serán útiles.
En el siguiente ejemplo, hemos definido una estructura de Cocina, que solo contiene el número de platos como un campo. Definimos otro campo llamado House, que contiene una instancia de Kitchen como campo, pero es un campo anónimo, porque no le hemos dado un nombre de variable.
Los campos anónimos en las estructuras Go nos permiten atajar la notación de puntos, así como también nos permiten usar composiciones para agregar métodos a un tipo. Veamos un ejemplo :
La estructura C contiene a la estructura A, por lo tanto la estructura C esta compuesta. Y podemos llamar a campos de C por medio de los campos descriptos en A o B :
c := C {}
c.AValue.X = 1
Podemos pasar a C de modo anónimo por lo tanto queda así :
type C struct {
A
B
}
nos permite reducir el uso de la notación de puntos y acceder a X en A como si fuera un campo dentro de la estructura C en sí, es decir
c := C {}
c.X = 1
De acuerdo, pero ¿qué pasaría si B struct ahora reemplazara el nombre del campo Z con X?
type A struct {
X int
Y int
}
type B struct {
X int
}
Ahora tenemos una situación en la que tanto A como B tienen el mismo nombre de campo, bueno, aún podemos usar campos anónimos, pero volvemos a usar más notación de puntos nuevamente para evitar el conflicto obvio de nombre de campo, es decir:
c := C {}
c.A.X = 1
c.B.X = 2
Los inicializadores no admiten accesos directos, es decir :
c := C{ A : A{2, 4}, B : B { 12 }}
// or
c := C{ A : A{X : 2, Y : 4}, B : B { Z: 12 }}
Más poderoso que el azúcar sináptico de los campos anónimos, es que también podemos usar la composición para aumentar los métodos disponibles en la estructura C. Por ejemplo, ahora agreguemos un método al tipo A que nos permite mover nuestro punto X, Y
func (a *A) Move(amount int) {
a.X += amount
a.Y += amount
}
Ahora podemos llamar al método con C :
c.Move(10)
También podemos crear más métodos a través de un patrón de composición en el tipo C si queremos usar tipos vacíos, supongamos que tenemos el tipo D y amplia la composición del tipo C, bueno podemos :
type D struct {}
type C struct {
A
B
D
}
ahora podemos agregar métodos a D y, por supuesto, estarán disponibles como parte de C. Entonces, por ejemplo, tal vez D actúa como un receptor para los métodos que serializan datos a JSON, ahora nuestro tipo C también parecerá tener esos métodos.
martes, 1 de octubre de 2019
Diagramas de Chebotko
Con frecuencia es útil presentar diseños de modelos de datos lógicos y físicos visualmente. Para lograr esto en Cassandra, podemos utilizar Diagrama de Chebotko, que presenta un diseño de esquema de base de datos como una combinación de esquemas de tabla individuales y transiciones de flujo de trabajo de aplicaciones basadas en consultas. Algunas de las ventajas de los Diagramas de Chebotko, en comparación con los scripts de definición de esquemas de CQL regulares, incluyen una legibilidad general mejorada, una inteligibilidad superior para modelos de datos complejos y una mejor expresividad con esquemas de tabla y sus consultas de aplicaciones compatibles. Los diagramas de nivel físico contienen información suficiente para generar un script CQL que instancia un esquema de base de datos y puede servir como documentos de referencia para desarrolladores y arquitectos que diseñan y mantienen una solución basada en datos.
Dentro de la comunidad de Cassandra han propuesto anotaciones para capturar modelos de datos en forma de diagrama. Y se popularizo el diagrama creado por Artem Chebotko que proporciona una forma simple e informativa de visualizar las relaciones entre consultas y tablas en nuestros diseños.
Cada tabla se muestra con su título y una lista de columnas. Las columnas de clave principal se identifican mediante símbolos como K para columnas de clave de partición y C ↑ o C ↓ para representar columnas de agrupamiento. Las líneas se muestran entrando en tablas o entre tablas para indicar las consultas que cada tabla está diseñada para admitir.
Modelado de datos en Cassandra
Nosotros en casandra podemos guradar algun id y verlo como una foreign key pero este concepto no existe en realidad, el motor de base de datos no realiza ningun checkeo.
En el diseño de bases de datos relacionales, a menudo se nos enseña la importancia de la normalización. Esto no es una ventaja cuando se trabaja con Cassandra porque funciona mejor cuando el modelo de datos está desnormalizado. A menudo ocurre que las empresas también terminan desnormalizando datos en bases de datos relacionales.
Hay dos razones comunes para esto:
Uno es el rendimiento. Las empresas simplemente no pueden obtener el rendimiento que necesitan cuando tienen que hacer tantas uniones en datos, por lo que desnormalizar puede ser una solución para la performance. Esto termina funcionando, pero va en contra de la forma en que se pretende diseñar las bases de datos relacionales por lo tanto no tiene sentido usar base de datos relacionales.
Una segunda razón es conservar un historial. El ejemplo común aquí es con las facturas. Ya tiene tablas de clientes y productos, y pensaría que podría hacer una factura que referencie esas tablas. Pero esto nunca debe hacerse en la práctica. La información del cliente o del precio podría cambiar, y luego perdería la integridad del documento tal como estaba en la fecha de la factura, lo que podría violar auditorías, informes o leyes, y causar otros problemas.
En el mundo relacional, la desnormalización viola las formas normales de Codd y tratamos de evitarla. Pero en Cassandra, la desnormalización es, bueno, perfectamente normal.
En cassandra existen una tecnicas para modelar nuestros datos :
Query-first design o diseño orientado a consultas: En cassandra podemos comenzar modelando de los datos desde las consultas, la información se debe organizar según las consultas que necesitamos. De esta manera vamos a tener un monton de datos repetidos pero esto no es significativo, dado que con cassandra el hardware es relativamente barato y la escritura muy rapida.
En las base de datos relacionales muchas veces es transparente como se organiza la base a como se guardan los datos en disco. En cambio en cassandra cada tabla es guardada en un archivo diferente en el disco. Por lo tanto es importante mantener columnas relacionadas en la misma tabla. Un objetivo de cassandra es minimizar el numero de particiones donde hay que buscar con el objetivo de satisfacer una query. Pensemos que buscar los datos en una partición puede ser sumamente más performate que buscarlo en nodos separados.
En las base de datos relacionales es muy facil cambiar el orden en una consulta con la instrucción ORDER BY. Y no se puede especificar el orden con los que se guardan los datos y por defecto los datos son recuperados según fueron grabados. En cassandra esto cambia un poco dado que esta es una decisión de diseño. El order es fijo y esta determinado por las clustering columns. Es decir el select permite utilizar el order by pero solo en las clustering columns.
En el diseño de bases de datos relacionales, a menudo se nos enseña la importancia de la normalización. Esto no es una ventaja cuando se trabaja con Cassandra porque funciona mejor cuando el modelo de datos está desnormalizado. A menudo ocurre que las empresas también terminan desnormalizando datos en bases de datos relacionales.
Hay dos razones comunes para esto:
Uno es el rendimiento. Las empresas simplemente no pueden obtener el rendimiento que necesitan cuando tienen que hacer tantas uniones en datos, por lo que desnormalizar puede ser una solución para la performance. Esto termina funcionando, pero va en contra de la forma en que se pretende diseñar las bases de datos relacionales por lo tanto no tiene sentido usar base de datos relacionales.
Una segunda razón es conservar un historial. El ejemplo común aquí es con las facturas. Ya tiene tablas de clientes y productos, y pensaría que podría hacer una factura que referencie esas tablas. Pero esto nunca debe hacerse en la práctica. La información del cliente o del precio podría cambiar, y luego perdería la integridad del documento tal como estaba en la fecha de la factura, lo que podría violar auditorías, informes o leyes, y causar otros problemas.
En el mundo relacional, la desnormalización viola las formas normales de Codd y tratamos de evitarla. Pero en Cassandra, la desnormalización es, bueno, perfectamente normal.
En cassandra existen una tecnicas para modelar nuestros datos :
Query-first design o diseño orientado a consultas: En cassandra podemos comenzar modelando de los datos desde las consultas, la información se debe organizar según las consultas que necesitamos. De esta manera vamos a tener un monton de datos repetidos pero esto no es significativo, dado que con cassandra el hardware es relativamente barato y la escritura muy rapida.
En las base de datos relacionales muchas veces es transparente como se organiza la base a como se guardan los datos en disco. En cambio en cassandra cada tabla es guardada en un archivo diferente en el disco. Por lo tanto es importante mantener columnas relacionadas en la misma tabla. Un objetivo de cassandra es minimizar el numero de particiones donde hay que buscar con el objetivo de satisfacer una query. Pensemos que buscar los datos en una partición puede ser sumamente más performate que buscarlo en nodos separados.
En las base de datos relacionales es muy facil cambiar el orden en una consulta con la instrucción ORDER BY. Y no se puede especificar el orden con los que se guardan los datos y por defecto los datos son recuperados según fueron grabados. En cassandra esto cambia un poco dado que esta es una decisión de diseño. El order es fijo y esta determinado por las clustering columns. Es decir el select permite utilizar el order by pero solo en las clustering columns.
sábado, 28 de septiembre de 2019
Optimice y mejore el rendimiento de PostgreSQL con VACUUM, ANALYZE y REINDEX
Si tenes una base de datos PostgreSQL y te anda lenta, podes usar unos comandos para mejorar y optimizar el rendimiento: VACUUM, ANALYZE y REINDEX
Para evitar problemas es preferible ejecutar estos comandos durante el periodo de mantenimiento cuando nadie usa la base.
En la configuración por defecto de PostgreSQL, el demonio AUTOVACUUM debe estar habilitado y todos los parámetros de configuración necesarios se configuran según sea necesario. El demonio ejecutará VACUUM y ANALYZE a intervalos regulares. Para confirmar si el daemon de autovacuum se está ejecutando en UNIX o Linux, podes hacer :
$ ps aux | grep autovacuum | grep -v grep
postgres 334 0.0 0.0 2654128 1232 ?? Ss 16Mar17 0:05.63 postgres: autovacuum launcher process
En la base, se puede verificar el estado de autovacuum en pg_settings con la siguiente consulta:
select name, setting from pg_settings where name = 'autovacuum' ;
El comando VACUUM recuperará el espacio que todavía utilizan los datos que se han actualizado.
En PostgreSQL, las tuplas de clave-valor actualizadas no se eliminan de las tablas cuando se cambian las filas, por lo que el comando VACUUM debe ejecutarse ocasionalmente para hacer esto.
VACUUM se puede ejecutar solo o con ANALYZE.
Veamos algunos ejemplos, ojo el nombre de la tabla es opcional, por eso se escribe así [nombre de tabla]. Sin una tabla especificada, VACUUM se ejecutará en las tablas disponibles en el esquema actual al que el usuario tiene acceso.
VACUUM simple: libera espacio para reutilizar
VACUUM [tablename]
VACUUM FULL: bloquea la tabla de la base de datos y reclama más espacio que un VACUUM simple
/* Before Postgres 9.0: */
VACUUM FULL
/* Postgres 9.0+: */
VACUUM(FULL) [tablename]
VACUUM completo y ANALYZE: realiza un VACUUM completo y recopila nuevas estadísticas sobre las rutas de ejecución de consultas utilizando ANALIZAR
/* Before Postgres 9.0: */
VACUUM FULL ANALYZE [tablename]
/* Postgres 9.0+: */
VACUUM(FULL, ANALYZE) [tablename]
Verbose Full VACUUM and ANALYZE: Igual que el anterior, pero con salida de progreso detallado
/* Before Postgres 9.0: */
VACUUM FULL VERBOSE ANALYZE [tablename]
/* Postgres 9.0+: */
VACUUM(FULL, ANALYZE, VERBOSE) [tablename]
ANALYZE recopila estadísticas para el planificador de consultas para crear las rutas de ejecución de consultas más eficientes. Según la documentación de PostgreSQL, las estadísticas precisas ayudarán al planificador a elegir el plan de ejecución más apropiado y, por lo tanto, a mejorar la velocidad del procesamiento de la consulta.
En el siguiente ejemplo, [nombre de tabla] es opcional. Sin una tabla especificada, ANALYZE se ejecutará en las tablas disponibles en el esquema actual al que el usuario tiene acceso.
ANALYZE VERBOSE [tablename]
El comando REINDEX reconstruye uno o más índices, reemplazando la versión anterior del índice. REINDEX se puede usar en muchos escenarios, incluidos los siguientes:
- Un índice se ha dañado y ya no contiene datos válidos. Aunque en teoría esto nunca debería suceder, en la práctica los índices pueden corromperse debido a errores de software o fallas de hardware. REINDEX proporciona un método de recuperación.
- Un índice se ha "hinchado", es decir, contiene muchas páginas vacías o casi vacías. Esto puede ocurrir con índices de árbol B en PostgreSQL bajo ciertos patrones de acceso poco comunes. REINDEX proporciona una forma de reducir el consumo de espacio del índice escribiendo una nueva versión del índice sin las páginas muertas.
- Ha modificado un parámetro de almacenamiento (como el factor de relleno) para un índice y desea asegurarse de que el cambio haya tenido pleno efecto.
- Una construcción de índice con la opción CONCURRENTEMENTE falló, dejando un índice "inválido". Dichos índices son inútiles, pero puede ser conveniente usar REINDEX para reconstruirlos. Tenga en cuenta que REINDEX no realizará una compilación concurrente. Para construir el índice sin interferir con la producción, debe borrar el índice y volver a crearlo con el comando CREATE INDEX CONCURRENTLY.
Veamos unos ejemplos, cualquiera de estos puede forzarse agregando la palabra clave FORCE después del comando:
Recree un solo índice, myindex:
REINDEX INDEX myindex
Recrea todos los índices en una tabla, mytable:
REINDEX TABLE mytable
Recree todos los índices en el esquema público:
REINDEX SCHEMA public
Recree todos los índices en la base de datos postgres:
REINDEX DATABASE postgres
Recree todos los índices en los catálogos del sistema en bases de datos de postgres:
REINDEX SYSTEM postgres
jueves, 26 de septiembre de 2019
Libros Gratuitos desde Java Geek!!
|
martes, 24 de septiembre de 2019
44 vídeos para aprender a programar con Python lanzado por Microsoft
Microsoft Developer nos regala un set de 44 vídeos sobre Python, no sé que más decir!!
Eso es todo, a disfrutar!!!
Dejo link: https://www.youtube.com/watch?v=jFCNu1-Xdsw
Y a la lista de reproducción: https://www.youtube.com/playlist?list=PLlrxD0HtieHhS8VzuMCfQD4uJ9yne1mE6
Eso es todo, a disfrutar!!!
Dejo link: https://www.youtube.com/watch?v=jFCNu1-Xdsw
Y a la lista de reproducción: https://www.youtube.com/playlist?list=PLlrxD0HtieHhS8VzuMCfQD4uJ9yne1mE6
Tuneando base de datos postgresql con pgtune
Tenes una base de datos postgresql que anda lento? no modificaste postgresql.conf?
Bueno esta aplicación te permite tunear la base postgreslq con parámetros del hardware que estas utilizando. Lo importante es que toma solo el hardware por lo tanto es solo el comienzo, luego tenemos que seguir tuneando según el uso.
Sin más dejo el link: https://pgtune.leopard.in.ua/#/
Suscribirse a:
Entradas (Atom)