Como sabrán algunos trabajo en una empresa que se llama hexacta. Esta empresa se encuentra entre las mejores 100 compañías de outsourcing del mundo dado esto la revista digital insider hizo el siguiente reportaje a un socio de hexacta:
http://insiderlatam.com/como-logra-una-empresa-argentina-figurar-entre-las-mejores-100-companias-de-outsourcing-del-mundo
Translate
sábado, 24 de marzo de 2018
miércoles, 21 de marzo de 2018
Conjuntos de datos distribuidos resistentes en Spark
Conjuntos de datos distribuidos resistentes o Resilient distributed datasets (RDD) esta basado en Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing” (Matei et al 2012) este es el concepto base de Apache Spark.
RDD es como una tabla en una base de datos, la cual puede guardar datos de cualquier tipo. Spark guarda datos en RDD en diferentes particiones.
RDD ayudan a reorganizar los cálculos y a optimizar el procesamiento de datos. También son tolerantes a fallas porque el RDD sabe cómo recrear y volver a calcular los conjuntos de datos.
RDDs son inmutables (podemos ver la programación funcional de scala en este aspecto). Es decir se puede procesar un RDD pero esto retornara un nuevo RDD con el resultado de la transformación.
RDD soporta 2 tipos de acciones:
- Transformaciones: esto no retorna un valor pero retorna un nuevo RDD. Algunas funciones de transformación: map , filter , flatMap , groupByKey , reduceByKey , aggregateByKey , pipe y coalesce.
- Acciones: operaciones que retornan un valor. Cuando una acción es llamada los datos son procesados y un valor es retornado. Algunas funciones de acción: reduce , collect , count , first , take , countByKey y foreach.
martes, 20 de marzo de 2018
Cursos Gugler
El Laboratorio de Investigación Gugler de la Facultad de Ciencia y Tecnología (U.A.D.E.R) tiene como Misión: "Promover, capacitar y difundir el uso del Software Libre en la región".
Algo muy importante es que los cursos se pueden hacer presenciales o a distancia.
Acá les dejo más info:
Y el link:
https://inscripciones.gugler.com.ar/
https://www.gugler.com.ar/
domingo, 18 de marzo de 2018
Arquitectura de Apache Spark
Apache Spark esta
compuesto por tres componentes:
- Data store
- API
- Framework de gestion de recursos
Data store: Apache
Spark utiliza el sistema de archivos de hadoop, es decir utiliza
hdfs. Por lo tanto es compatible con almacenamiento de hadoop y
framework que utilizan este almacenamiento como hbase, casandra, etc.
API: La API permite
crear aplicaciones basadas en Spark, utilizando una interfaz
estandar. Spark provee esta API para java, scala, python y R.
Gestion de recursos:
Spark puede ser deployado en un servidor stand-alone o sobre una
infraestructura distribuida sobre frameworks como Mesos o YARD
Ecosistema Spark
Como hemos dicho
anteriormente un ecosistema big data cuenta normalmente con varios
productos, los cuales proveen diferentes funcionalidades.
En el caso de spark, no es una excepción. Apache Spark incluye:
Spark Streaming, Se utiliza para procesar información en tiempo real. Esto apoyados en un pequeño sistema micro-batch. A la vez esto usa Dstream que es una serie de RDDs que se procesan en tiempo real. Y para él que no sabe que es RDD (como yo) RDD es Resilient Distributed Dataset (RDD), la abstracción básica en Spark. Representa una colección de elementos inmutables y divididos que se pueden operar en paralelo.
Spark SQL permite exponer datos de dataset de spark bajo una API Jdbs y permite ejecutar consultas SQL-like con datos de Spark. Tambie permite estraer datos en diferentes formatos.
Spark MLlib : es una librería de maching learning de spark. Esta consiste en los algoritmos comunes de maching learning y utilidades.
Spark GraphX : Es la
API de Grafos y procesamiento de grafos en paralelo. GraphX amplía a
Spark RDD al introducir las propiedades de gráfos distribuidos
resistente: un multi-grafo dirigido con propiedades asociadas a cada
vértice y borde. Para admitir el cálculo de grafos, GraphX expone
un conjunto de operadores fundamentales (por ejemplo, subgraph,
joinVertices y aggregateMessages) y una variante optimizada de Pregel
API. Además, GraphX incluye una creciente colección de algoritmos y
constructores de grafos para simplificar el análisis de grafos.
Aparte de estas
librerías, hay otros framework que se integran muy bien con Spark:
Alluxio
(anteriormente conocido como Tachyon) es un sistema de archivos
distribuidos centrado en memoria, que permite compartir archivos de
forma segura en un cluster basado en Spark y mapReduce. Este
framework cachea un conjunto de datos en memoria, evitando ir a disco
a buscar los conjunto de datos frecuentes. Esto permite acelerar el
trabajo con Spark.
BlinkDb: es un motor
de consulta aproximada para ejecutar consultas SQL interactivas en
grandes volúmenes de datos. Permite a los usuarios intercambiar la
precisión de la consulta por el tiempo de respuesta. Funciona en
grandes conjuntos de datos ejecutando consultas en muestras de datos
y presentando resultados con un rango de error significativas. Las
versiones posteriores de BlinkDB se mantienen bajo un nuevo proyecto
llamado iOLAP.
viernes, 16 de marzo de 2018
Replicas en Oracle 10g con streams parte 2
Continuemos con la captura y replicación de flujos de datos.
En un entorno Streams podemos capturar los eventos de la siguiente manera: Proceso de captura o aplicación personalizada.
Los cambios de objetos de la base son escritos en el area de redologs, dado que ante un error oracle puede volver a una versión consistente y estable. Un proceso de captura es un proceso en segundo plano de Oracle que lee el registro de redolog de la base de datos para capturar los cambios de DML y DDL realizados a los objetos de la base de datos. La base de datos de origen es la base de datos donde se generó el cambio en el registro de redolog. Un proceso de captura formatea estos cambios en mensajes llamados LCR y los envía a una cola. Como un proceso de captura en ejecución captura automáticamente los cambios en función de sus reglas, la captura de cambios mediante un proceso de captura a veces se denomina captura implícita.
Hay dos tipos de LCR: una LCR de fila contiene información sobre un cambio en una fila de una tabla resultante de una operación de DML, y una LCR de DDL contiene información sobre un cambio de DDL en un objeto de base de datos. Se debe utiliza reglas para especificar qué cambios se capturan. Una sola operación DML puede cambiar más de una fila en una tabla. Por lo tanto, una sola operación DML puede generar más de una LCR de fila, y una sola transacción puede consistir en múltiples operaciones DML.
Los cambios son capturados por capture user o usuario de captura, el capture user captura todos los cambios que cumplan con el conjunto de reglas (DML o DDL)
Un proceso de captura de procesos, puede capturar cambios de una base local o de una base remota.
Downstream capture significa que un proceso de captura se ejecuta en una base de datos que no sea la base de datos de origen. Se pueden configurar de la siguiente manera :
- Una configuración Downstream capture en tiempo real, significa que los servicios de transporte redolog utilizan el log writer process (LGWR) o proceso de escritura de redolog como origen para enviar datos desde el registro de redolog en línea a la base de datos downstream. En la base de datos downstream, un proceso de servidor de archivos remoto (RFS) recibe los datos de redolog y los almacena en el registro de redolog como en espera, y el archivador en la base de datos descendente archiva los datos de redolog en el registro de redolog en espera. El proceso Downstream en tiempo real captura los cambios desde el registro de redolog en espera siempre que sea posible y desde el registro de redolog archivado siempre que sea necesario.
- Una configuración archived-log downstream capture, significa que los archivos de redolog archivados de la base de datos de origen se copian en la base de datos Downstream. Puede copiar los archivos de redolog archivados en la base de datos downstream utilizando los servicios de transporte de redolog, el paquete DBMS_FILE_TRANSFER, el protocolo de transferencia de archivos (FTP) o algún otro mecanismo.
Un proceso de captura Downstream en tiempo real lee el registro de redolog en espera siempre que sea posible y, de lo contrario, los redologs archivados
La otra manera de capturar datos es con una aplicación personalizada. Esta aplicacion puede capturar los datos desde los logs de transacciones, triggers o otros metodos. La aplicacion debe capturar el cambio y debe convertir este cambio a LCR y luego debe encolar este LCR en la cola de la base destino para hacer esto se pueden utilizar los paquetes DBMS_STREAMS_MESSAGING o DBMS_AQ. La aplicación debe commitiar despues de encolar los LCRs de cada transacción.
Una vez capturados los cambios debemos propagarlos.
En un entorno de replicación de Streams, los procesos de propagacion propagan los cambios capturados. Las propagaciones permiten propagar los LCR origen a las bases de datos destinos.
Las siguientes secciones describen la puesta en escena y la propagación en un entorno de replicación de Streams:
LCR Staging : Los LCR capturados se organizan en un área de preparación. En Streams, el área de preparación es una cola que puede almacenar LCR y DDL LCR, así como otros tipos de mensajes. Los LCR capturados se organizan en una cola, que es la System Global Area (SGA) asciada con una cola.
Los LCR pueden propagarse mediante una propagación o aplicarse mediante un proceso de aplicación, y un LCR Staging determinado puede propagarse y aplicarse. Una propagación en ejecución propaga automáticamente las LCR basadas en las reglas de sus conjuntos de reglas, y un proceso de aplicación en ejecución aplica LCR automáticamente .
LCR Propagation:En un entorno de replicación de Streams, una propagación normalmente propaga LCR desde una cola en la base de datos local a una cola en una base de datos remota. La cola a partir de la cual se propagan los LCR se denomina cola de origen, y la cola que recibe los LCR se denomina cola de destino. Puede haber una relación de uno a muchos, muchos a uno o muchos a muchos entre las colas de origen y destino.
Incluso después de que un LCR se propaga por una propagación o se aplica mediante un proceso de solicitud, puede permanecer en la cola de origen si también ha configurado Flujos para propagar el LCR a una o más colas diferentes. Además, observe que una cola ANYDATA puede almacenar mensajes de usuario que no sean LCR. Normalmente, los mensajes de usuario que no son de LCR se utilizan para aplicaciones de mensajería, no para la replicación.
Puede configurar un entorno de replicación de Streams para propagar LCR a través de una o más bases de datos intermedias antes de llegar a una base de datos de destino. Tal entorno de propagación se llama red dirigida. Un LCR puede o no ser procesado por un proceso de solicitud en una base de datos intermedia. Las reglas determinan qué LCR se propagan a cada base de datos de destino y puede especificar la ruta que recorrerán los LCR en su camino hacia una base de datos destino.
La ventaja de usar una red dirigida es que una base de datos de origen no necesita tener una conexión de red física con la base de datos de destino. Entonces, si desea que los LCR se propaguen de una base de datos a otra, pero no hay conexión de red directa entre las computadoras que ejecutan estas bases de datos, puede propagar los LCR sin reconfigurar su red, siempre que una o más bases de datos intermedias conecten el base de datos de origen a la base de datos de destino. Si usa redes dirigidas, y un sitio intermedio se apaga durante un período de tiempo prolongado o si se elimina, entonces es posible que necesite reconfigurar la red y el entorno de Streams.
Dejo link: https://docs.oracle.com/cd/B19306_01/server.102/b14228/gen_rep.htm
martes, 13 de marzo de 2018
Características de Apache Spark
Spark mejora MapReduce con menos costos de procesamiento de datos.
Con capacidades como el almacenamiento de datos en memoria y el procesamiento casi en tiempo real, puede ejecutarse varias veces más rápido que otras tecnologías de big data.
Spark también soporta evaluación perezosa de consulta big-data, lo que ayuda a optimizar los pasos en los flujos de trabajo de procesamiento de datos. Proporciona una API de nivel superior para mejorar la productividad del desarrollador y una arquitectura coherente para soluciones de big-data.
Spark guarda los resultados intermedios en memoria en lugar de escribirlos en el disco, lo que es eficiente, especialmente cuando tenemos que trabajar en el mismo conjunto de datos varias veces. Está diseñado para ser un motor de ejecución que funciona tanto en la memoria como en el disco. Los operadores de Spark realizan operaciones externas cuando los datos no entran en la memoria. Spark se puede usar para procesar conjuntos de datos que exceden la memoria agregada en un cluster.
Spark intentará almacenar tantos datos en la memoria como sea posible y luego guardara en disco. Puede almacenar parte de un conjunto de datos en la memoria y los datos restantes en el disco. Con este almacenamiento de datos en memoria luego en disco, Spark consigue la ventaja de rendimiento.
Otras características incluyen:
- Soporta más que las funciones map y reduce
- La Api soporta Scala, Java y Python
- La consola interactiva soporta Scala y Python.
Spark fue escrito en Scala por lo que corre en la JVM y actualmente soporta para el desarrollo:
- Scala
- Java
- Python
- R
- Clojure y los lenguajes soportados por la Jvm
lunes, 12 de marzo de 2018
Replicas en Oracle 10g con streams
La replicación es el proceso de compartir objetos y datos de bases de datos en múltiples bases de datos. Los datos y los objetos de la base de datos se mantienen sincronizados en todas las bases de datos en el entorno de replicación. En un entorno de replicación de Streams, la base de datos donde se origina un cambio se denomina base de datos fuente, y una base de datos donde se comparte un cambio se denomina base de datos de destino.
Podemos replicar DDL y/o DML, para esto necesitamos hacer los siguientes pasos:
1.Capturar un cambio o un conjunto de cambios (logical change records o LCRs) y encolarlo en la cola dentro de la cola de cambios. Un LCR es mensaje con un formato determinado que especifica un cambio. EL LCR encapsula los cambios a realizar.
2.Propagar el LRC a otras colas, es decir a otras base de datos.
3.Aplicar el LRC a la base destino, esto se puede hacer desde la cola o de forma directa tambien.
Por lo tanto los pasos 1 y 3 son obligatorios y el 2 es opcional dado que se puede aplicar el LRC de forma directa.
A la vez tenemos reglas de replicación, una regla indica una acción cuando ocurre un evento y si se cumple una condición. Las reglas son evaluadas por el motor de reglas de oracle. Cada uno de los siguientes pasos son ejecutados por un motor de reglas:
- Captura de proceso
- Propagación
- Aplicar proceso
Se puede tener control del comportamiento de los clientes Streams usando reglas. Un conjunto o set de reglas es una colección de reglas. En un entorno de replicación, un clinte hace una acción si el LCR sateface el conjunto de reglas.
En general, un cambio satisface los conjuntos de reglas para un cliente de Streams si ninguna regla en el conjunto de reglas negativas se evalúa como TRUE para el LCR, y al menos una regla en el conjunto de reglas positivas se evalúa como TRUE para el LCR. Si un cliente de Streams está asociado con un conjunto de reglas positivas y negativas, entonces el conjunto de reglas negativas siempre se ejecutara antes.
Específicamente, podemos controlar el flujo de información en un entorno de replicación de Streams de las siguientes maneras:
- Especifique los cambios que se deben capturar desde el area de redolog. Si hay un cambio en el area de redolog que aplica el conjunto de reglas este sera capturado.
- Especifique los LCR una propagación debe propagar.
- Especifique las LCR se deben aplicar o descarta en una cola destino.
Debemos utilizar el paquete de pl/sql DBMS_STREAMS_ADM para crear reglas de replicación. Podemos crear reglas en los siguientes niveles:
- Tabla: Contiene reglas para el cambio de una tabla en particular
- Esquema: Contiene reglas para el cambio de un esquema en particular
- Global: Se aplica a toda la base de datos.
A la vez, podemos discriminar las reglas en las que aplican DML o DDL pero no las 2 al mismo tiempo.
Streams replication soporta que se repliquen objetos que no tengan la misma estructura. Es decir en la base destino puede cambiar su estructura. Para esto es necesario utilizar una lregla de transformación, la cual lleve al cambio al formato destino.
Hay 2 tipos de reglas de transformación: declarativas o personalizadas. Las reglas declarativas de transformación o Declarative rule-based transformations (en ingles) permiten cambios en un conjunto de tablas o esquemas. Podemos cambiar el esquema o nombre de tabla o agregar una columna o eliminarla, etc.
En cambio las reglas personalizadas o custom, llaman a una función pl/sql que hace la transformación.
Streams también admite subconjuntos de datos de tablas mediante el uso de reglas de subconjuntos. Si una tabla compartida en una base de datos en un entorno de replicación de Streams contiene solo un subconjunto de datos, entonces puede configurar Flujos para administrar los cambios en una tabla, de modo que solo el subconjunto de datos apropiado se comparta con la tabla de subconjuntos. Por ejemplo, una base de datos particular puede mantener datos para los empleados en un departamento particular solamente. En este caso, puede usar reglas de subconjunto para compartir cambios en los datos para los empleados en ese departamento con la tabla de subconjuntos, pero no para los empleados de otros departamentos.
La subconjunto puede realizarse en cualquier punto del flujo de información de flujos. Es decir, un proceso de captura puede usar una regla de subconjunto para capturar un subconjunto de cambios en una tabla particular, una propagación puede usar una regla de subconjunto para propagar un subconjunto de cambios a una tabla particular y un proceso de aplicación puede usar una regla de subconjunto para aplicar solo un subconjunto de cambios a una tabla en particular.
Por ahora esta la idea general, en proximos post seguiremos en más detalle.
Dejo link: https://docs.oracle.com/cd/B19306_01/server.102/b14228/gen_rep.htm
domingo, 11 de marzo de 2018
Linux esta disponible en la Microsoft Store
Ya esta, lo he visto todo... Puedo morir en paz.
Si si, Linux esta disponible en la Microsoft Store. Es decir podemos instalar virtuales de linux desde el Microsoft Store. En realidad no son virtuales, son como virtuales. Internamente usa el sistema WSL (windows subsystem for Linux)
WSL proporciona una interfaz de kernel compatible con Linux desarrollada por Microsoft (que no contiene ningún código de kernel de Linux), que luego puede ejecutar un sistema operativo Linux.
Actualmente podemos instalar :
- Ubuntu
- Debian
- SUSE Linux Enterprise Servers
- OpenSUSE
- Kali Linux
Igualmente es mejor instalar Linux y listo!!
jueves, 8 de marzo de 2018
Java EE se transforma en Jakarta EE
Me hago eco de esta noticia (medio tarde)
Dado que oracle quiere soltar Java EE pero no quiere soltar el nombre Java por lo tanto ahora se va a llamar Jakarta EE.
Y varios proyectos han cambiado nombres dado este cambio. Ahora que Java EE es Jakarta EE, Glassfish pasa a ser Eclipse Glassfish, Java Community Process (JCP) pasa a llamarse Eclipse EE.next Working Group (EE.next), y Oracle development management ahora es Eclipse Enterprise for Java (EE4J) y Project Management Committee (PMC).
Y eso es toda la noticia, bien no se como estirar más ...
Dejo link:
miércoles, 7 de marzo de 2018
Oracle Live sql
Dada la llegada de oracle 18 c. Oracle se le ocurrio liberar Oracle Live sql. Que es la mejor forma de aprender a escribir y correr sql.
Con esta aplicación podes aprender a escribir sql y a obtener información de esto.
Antes teniamos unas bases de ejemplo que traia oracle pero ahora solo nos conectamos a la web y listo, a practicar.
Dejo link: https://livesql.oracle.com/apex/livesql/file/index.html
Con esta aplicación podes aprender a escribir sql y a obtener información de esto.
Antes teniamos unas bases de ejemplo que traia oracle pero ahora solo nos conectamos a la web y listo, a practicar.
Dejo link: https://livesql.oracle.com/apex/livesql/file/index.html
lunes, 5 de marzo de 2018
Apache Spark y Hadoop
Hadoop tiene alrededor de 10 años y ha demostrado ser una buena solución big data.
MapReduce es una gran solución para cálculos de un solo paso, pero no es eficiente para casos de uso que requieren cálculos y algoritmos de múltiples pasos.
Cada paso en el flujo de trabajo de procesamiento de datos tiene una fase de map y una fase de reduce y para usar esta tecnica tendremos que convertir cada paso en un patrón de MapReduce.
La salida del procesamiento de cada paso es guardado en discos distribuidos y luego esto es tomado como entrada para el siguiente paso. Como se puede ver no es una visión muy eficiente. También Hadoop generalmente se utiliza en cluster que son difíciles de configurar. A la vez Hadoop necesita otras herramientas para la integración como Apache storm para el manejo de streaming y Mahout para machine learning.
Si quisiéramos hacer algo complicado, tendríamos que encadenar una serie de trabajos de MapReduce y ejecutarlos en secuencia. Cada uno de esos trabajos tiene una alta latencia, y ninguno podría comenzar hasta que el trabajo anterior había terminado por completo.
Spark permite a los programadores desarrollar tuberías de datos complejas de varios pasos usando el patrón de gráfico acíclico dirigido (DAG). También es compatible con el uso compartido de datos en memoria en los DAG, por lo que diferentes trabajos pueden funcionar con los mismos datos sin tener que volver a calcular los datos para cada paso.
Spark se ejecuta sobre la infraestructura existente del sistema de archivos distribuidos Hadoop (HDFS) para proporcionar funcionalidad adicional. Proporciona soporte para implementar aplicaciones Spark en un clúster Hadoop v1 existente (con SIMR: Spark Inside MapReduce), Hadoop v2 YARN cluster, o incluso Apache Mesos.
Deberíamos considerar a Spark como una alternativa a Hadoop MapReduce para nuevas aplicaciones si ya estamos usando Hadoop en nuestra organización, en lugar de reemplazar completamente a Hadoop. Spark no pretende reemplazar a Hadoop, sino proporcionar una solución integral y unificada para administrar los diferentes requisitos de big data y casos de uso.
domingo, 4 de marzo de 2018
Que es Apache Spark?
Apache Spark es un framework de procesamiento de datos big data open source. Construido con las premisas de ser rápido y fácil de usar. Este Framework fue desarrollado en el 2009 en la universidad de Berkeley’s AMPLab y desde el 2010 fue liberado bajo la tutela de la organización Apache.
Es la competencia directa de Hadoop pero lejos de querer remplazarlo, se integra muy bien con el ecosistema Hadoop. Pero Apache Spark tiene varias ventajas comparado con otro framework Map-Reduce y big data.
Primero de todo, Apache Spark ofrece una forma coherente para procesar datos de diferentes naturalezas como video, texto, imágenes y de diferentes fuentes como red, online streaming, datos web online, etc.
A la vez, Spark permite correr aplicaciones en el clusters de Hadoop se ejecuten hasta 100 veces más rápido en memoria y 10 veces más rápido en disco.
Spark permite programar las aplicaciones en Python, Java o Scala. A la vez viene con un conjunto integrado de más de 80 operadores de alto nivel. Y podemos usarlo de forma interactiva para consultar datos dentro del shell.
Ademas las operaciones Map y Reduce, soportan consultas por sql, por streaming, maching learning y procesamiento por grafos. Los desarrolladores pueden usar estas capacidades solos o combinarlas para ejecutar en una sola información.
Dejo link: https://spark.apache.org/
Programando en Clojure en visual code
Como dije hace tiempo Clojure esta ganando cada vez más espacio, uno de los problemas que tenemos a la hora de empezar con este lenguaje es la falta de entornos de desarrollo.
A la vez, visual code es una ide liguera y que esta ganando muchos adeptos, más que nada por la facilidad de extensión y la cantidad de plugins que hay en el mercado.
Clojure no podía ser la excepción y hay un plugin para este lenguaje.
Esta extensión trae todo lo que necesitamos de una IDE: Intellisense, subraya cuando hay errores, un REPL interactivo, etc.
Esta muy completo e invito a que lo prueben.
Dejo link: https://marketplace.visualstudio.com/items?itemName=stiansivertsen.visualclojure#overview
miércoles, 28 de febrero de 2018
Un resumen de Scala for the Impatient, parte 38
Si un unapply método extrae un solo valor este debe retornar un Optional por ejemplo:
object Number {
def unapply(input: String): Option[Int] =
try {
Some(input.trim.toInt)
} catch {
case ex: NumberFormatException => None
}
}
Con este extractor podemos extraer el numero de un string :
val Number(n) = "1729"
Un extractor puede chequear un valor en este caso debe retornar un booleano:
object IsCompound {
def unapply(input: String) = input.contains(" ")
}
Se puede utilizar un extractor para agregar un test en una expresión
pattern matching:
author match {
case Name(first, IsCompound()) => …
case Name(first, last) => …
}
El método unapplySeq
Si utilizamos el extract en una secuencia, estaremos llamando a unapplySeq que retorna Option[Seq[A]] , donde A es el valor extraído:
object Name {
def unapplySeq(input: String): Option[Seq[String]] =
if (input.trim == "") None else Some(input.trim.split("\\s+"))
}
Dado este método ahora podemos utilizar un conjunto de parámetros:
author match {
case Name(first, last) => …
case Name(first, middle, last) => …
case Name(first, “van”, “der”, last) => ...
}
Ojo, no se puede tener un método unapply y un unapplySeq con similar parámetros.
Scala es un lenguaje de tipado estático y fuertemente tipado. Es decir que informa los errores de tipo en momento de compilación.
Si un tipo extiende de el trait scala.Dynamic, entonces el método llamadas, getters y setters se reescriben como llamadas a métodos especiales que pueden inspeccionar el nombre de la llamada original y los parámetros, y luego tomar acciones arbitrarias.
Veamos algunos ejemplos. Supongamos que la persona es una instancia de un tipo que se extiende
de Dynamic. Una declaración:
person.lastName = "Doe"
se puede remplazar:
person.updateDynamic ("lastName") ("Doe")
La clase Person debe tener dicho método:
clase Persona {
...
def updateDynamic (campo: String) (newValue: String) {...}
}
Depende de nosotros si implementamos el método updateDynamic.
Otro ejemplo:
val name = person.lastName
puede ser remplazado por:
val name = name.selectDynamic("lastName")
El metodo selectDynamic debe retornar un valor simple.
En scala existe DynamicProps que extiende a Dynamic y sobre escribe sus métodos:
class DynamicProps(val props: java.util.Properties) extends Dynamic {
def updateDynamic(name: String)(value: String) {
props.setProperty(name.replaceAll("_", "."), value)
}
def selectDynamic(name: String) =
props.getProperty(name.replaceAll("_", "."))
}
}
Suscribirse a:
Entradas (Atom)