Translate
lunes, 18 de febrero de 2019
Apache ZooKeeper
Ya hablamos de Apache ZooKeeper varias veces, pero de costado. Es decir hablando de otros productos relacionados con el mundo hadoop, y a la vez hablamos de él. Y por que tantas veces tuvimos que hablar de este producto? porque este producto, como lo indica su nombre, se encarga de cuidar las bestias que son todos los productos hadoop.
ZooKeeper tiene integración con todos los productos, dado que es es encargado de monitoriar su trabajo. ZooKeeper es un servicio centralizado para mantener la información de configuración, asignar nombres, proporcionar sincronización distribuida y proporcionar servicios de grupo. Todos estos tipos de servicios son utilizados de una forma u otra por las aplicaciones distribuidas. Cada vez que se implementan, hay un montón de trabajo que consiste en solucionar estos problemas. Debido a la dificultad de implementar este tipo de servicios, al principio las aplicaciones generalmente los escatiman, lo que los hace frágiles este tipo de aplicaciones frente al cambio y difíciles de administrar. Incluso cuando se realizan correctamente, las diferentes implementaciones de estos servicios conducen a la complejidad de la administración cuando se implementan las aplicaciones.
ZooKeeper apunta a destilar la esencia de estos diferentes servicios en una interfaz muy simple a un servicio de coordinación centralizado. El servicio en sí es distribuido y altamente confiable. El servicio implementará los protocolos de consenso, administración de grupos y presencia para que las aplicaciones no tengan que implementarlas por su cuenta. Los usos específicos de la aplicación consistirán en una mezcla de componentes específicos de ZooKeeper y las convenciones específicas de la aplicación. ZooKeeper Recipes muestra cómo este simple servicio se puede usar para construir abstracciones mucho más poderosas.
Espero que este post les abra el apetito del conocimiento dado que vamos a analizar más este producto. Dejo link: https://zookeeper.apache.org/
Spark y HBase
Tuve que conectar una aplicación spark con hbase con scala y sbt y scalatra... etc...
primero vamos a ver a build.sbt :
val ScalatraVersion = "2.6.3"
organization := "com.hexacta"
name := "Sparklatra"
version := "0.1.0-SNAPSHOT"
scalaVersion := "2.11.8"
resolvers += Classpaths.typesafeReleases
resolvers += "Cloudera Repository" at "https://repository.cloudera.com/content/repositories/releases/"
resolvers += "Cloudera Repository2" at "https://repository.cloudera.com/artifactory/cloudera-repos/"
libraryDependencies ++= Seq(
"org.scalatra" %% "scalatra" % ScalatraVersion ,
"org.scalatra" %% "scalatra-scalatest" % ScalatraVersion % "test" ,
"ch.qos.logback" % "logback-classic" % "1.2.3" % "runtime" ,
"org.eclipse.jetty" % "jetty-webapp" % "9.4.9.v20180320" % "container" ,
"javax.servlet" % "javax.servlet-api" % "3.1.0" % "provided" ,
"com.sun.jersey" % "jersey-core" % "1.19.4" ,
"com.sun.jersey" % "jersey-server" % "1.19.4" ,
"org.apache.spark" % "spark-core_2.11" % "2.3.1",
"org.apache.spark" %% "spark-sql" % "2.3.1",
"org.apache.spark" %% "spark-streaming" % "2.3.1" ,
"org.apache.hbase" % "hbase-spark" % "2.1.0-cdh6.1.1" intransitive() ,
"org.apache.hbase" % "hbase-server" % "2.1.0-cdh6.1.1" intransitive() ,
"org.apache.hbase" % "hbase-mapreduce" % "2.1.0-cdh6.1.1" intransitive() ,
"org.apache.hbase" % "hbase-common" % "2.1.0" exclude("com.fasterxml.jackson.core", "jackson-databind"),
"org.apache.hbase" % "hbase-client" % "2.1.0" exclude("com.fasterxml.jackson.core", "jackson-databind")
)
enablePlugins(SbtTwirl)
enablePlugins(ScalatraPlugin)
Ahora vamos hacer un ejemplito, de un metodo get que insertar y consultar :
get(s"/testSparkHbase/:key/:value") {
val conf : Configuration = HBaseContext.getConf()
// cree la tabla
// create 'TableTest', 'info'
// put 'TableTest', 'rowkey1', 'info:test', 'ejemplo'
val connection = ConnectionFactory.createConnection(conf)
val hbaseContext = new org.apache.hadoop.hbase.spark.HBaseContext(SparkContext.getSc, conf)
val tableName = "TableTest"
val columnFamily = "info"
val rdd = SparkContext.getSc.parallelize(Array(
(Bytes.toBytes(params("key")),
Array((Bytes.toBytes(columnFamily), Bytes.toBytes("test"), Bytes.toBytes(params("value")))))))
hbaseContext.bulkPut[(Array[Byte], Array[(Array[Byte], Array[Byte], Array[Byte])])](rdd,
TableName.valueOf(tableName),
(putRecord) => {
val put = new Put(putRecord._1)
putRecord._2.foreach((putValue) =>
put.addColumn(putValue._1, putValue._2, putValue._3))
put
});
Ok("ok")
}
get(s"/testSparkHbase/:key") {
val conf : Configuration = HBaseContext.getConf()
// cree la tabla
// create 'TableTest', 'info'
// put 'TableTest', 'rowkey1', 'info:test', 'ejemplo'
val connection = ConnectionFactory.createConnection(conf)
val hbaseContext = new org.apache.hadoop.hbase.spark.HBaseContext(SparkContext.getSc, conf)
val tableName = "TableTest"
val columnFamily = "info"
val rdd = SparkContext.getSc.parallelize(Array(Bytes.toBytes(params("key"))))
val getRdd = rdd.hbaseBulkGet[String](hbaseContext, TableName.valueOf(tableName), 2,
record => {
System.out.println("making Get"+ record.toString)
new Get(record)
},
(result: Result) => {
val it = result.listCells().iterator()
val b = new StringBuilder
b.append(Bytes.toString(result.getRow) + ":")
while (it.hasNext) {
val cell = it.next()
val q = Bytes.toString(CellUtil.cloneQualifier(cell))
if (q.equals("counter")) {
b.append("(" + q + "," + Bytes.toLong(CellUtil.cloneValue(cell)) + ")")
} else {
b.append("(" + q + "," + Bytes.toString(CellUtil.cloneValue(cell)) + ")")
}
}
b.toString()
})
getRdd.collect().foreach(v => println(v))
var result = ListBuffer[String]()
getRdd.collect().foreach(v => result += v)
Ok(compact(render(result)))
}
}
Dejo el git: https://github.com/emanuelpeg/spark-scalatra
martes, 12 de febrero de 2019
Download Minibooks!
lunes, 11 de febrero de 2019
HackerRank Developer Skills Report
Quiero compartir esta encuesta hecha por hackerrank, lo que más me llamo la atención es que el lenguaje que esperan aprender este 2019 es Go, kotlin, python, etc...
Sin más que agregar, dejo link: https://research.hackerrank.com/developer-skills/2019
Sin más que agregar, dejo link: https://research.hackerrank.com/developer-skills/2019
miércoles, 6 de febrero de 2019
Libros de Java Code Geeks
|
Istio, control operativo sobre la malla de servicio
Las plataformas en la nube proporcionan una gran cantidad de beneficios para las organizaciones que los utilizan. Sin embargo, no se puede negar que la adopción de la nube puede poner tensiones en los equipos de DevOps. Los desarrolladores deben utilizar los microservicios para crear arquitecturas, mientras que los operadores están administrando implementaciones híbridas y de múltiples nubes extremadamente grandes. Istio le permite conectarse, asegurar, controlar y observar servicios.
A un alto nivel, Istio ayuda a reducir la complejidad de estas implementaciones y alivia la presión sobre los equipos de desarrollo. Es una malla de servicio de código completamente abierto que se distribuye de manera transparente en las aplicaciones distribuidas existentes. También es una plataforma, incluidas las API que le permiten integrarse en cualquier plataforma de registro, telemetría o sistema de políticas. El conjunto diverso de funciones de Istio le permite ejecutar una arquitectura de microservicio distribuida de manera exitosa y eficiente, y proporciona una manera uniforme de proteger, conectar y monitorear los microservicios.
Istio aborda los desafíos a los que se enfrentan los desarrolladores y operadores a medida que las aplicaciones monolíticas pasan a una arquitectura de microservicio distribuido.
El término malla de servicio se utiliza para describir la red de microservicios que conforman dichas aplicaciones y las interacciones entre ellas. A medida que la malla de servicios crece en tamaño y complejidad, puede ser más difícil de entender y administrar. Sus requisitos pueden incluir descubrimiento, equilibrio de carga, recuperación de fallas, métricas y monitoreo. Una malla de servicios a menudo también tiene requisitos operativos más complejos, como limitación de velocidad, control de acceso y autenticación de extremo a extremo.
Istio proporciona perspectivas de comportamiento y control operativo sobre la malla de servicios en su conjunto, ofreciendo una solución completa para satisfacer los diversos requisitos de las aplicaciones de microservicio.
Dejo link: https://github.com/istio/
domingo, 3 de febrero de 2019
Kubeflow
Kubeflow es una plataforma de código abierto nativa de Kubernetes para desarrollar, organizar, implementar y ejecutar cargas de trabajo de aprendizaje automático escalables y portátiles.
La construcción y capacitación de modelos son solo una pequeña parte de los flujos de trabajo de aprendizaje automático (ML). Otras cosas que debe abordar incluyen la transformación de datos a un formato determinado y la ubicación accesible de dichos datos; limpieza de datos e ingeniería de características; analizando tus modelos entrenados; gestión de versiones de modelos; sirviendo de manera escalable a tus modelos entrenados; y evitar el sesgo de entrenamiento. Este es particularmente el caso cuando los flujos de trabajo deben ser portátiles, repetibles y tienen muchas partes móviles que deben integrarse.
Además, la mayoría de estas actividades se repiten en múltiples flujos de trabajo, quizás solo con diferentes parametrizaciones. A menudo, está ejecutando un conjunto de experimentos que deben realizarse de manera auditable y repetible. A veces, parte o la totalidad de un flujo de trabajo de ML debe ejecutarse en las instalaciones, pero en otros contextos puede ser más productivo usar servicios en la nube administrados, lo que facilita la distribución y la ampliación de los pasos del flujo de trabajo y la ejecución de varios experimentos en paralelo. También tienden a ser más económicos para cargas de trabajo "reventadas".
La construcción de cualquier sistema ML listo para la producción involucra varios componentes, a menudo mezclando proveedores. Conectar y administrar estos servicios para configuraciones incluso moderadamente sofisticadas puede introducir barreras de complejidad. A menudo, las implementaciones están tan vinculadas a los clústeres que se han implementado que estas pilas están inmóviles, lo que significa que mover un modelo de una computadora portátil a un clúster de nube altamente escalable, o de un entorno de experimentación a un contexto listo para la producción, es efectivamente imposible Sin re-arquitectura significativa. Todas estas diferencias se suman a un esfuerzo inútil y crean oportunidades para introducir errores en cada transición.
Kubeflow ayuda a abordar estas preocupaciones. Es una plataforma de código abierto nativa de Kubernetes para desarrollar, organizar, implementar y ejecutar cargas de trabajo ML escalables y portátiles. Ayuda a la reproducibilidad y la colaboración en los ciclos de vida del flujo de trabajo de ML, lo que le permite administrar la orquestación de punto a punto de las tuberías de ML, para ejecutar su flujo de trabajo en entornos híbridos o múltiples (como el intercambio entre los bloques de construcción locales y de la nube, según el contexto). ), y para ayudarlo a reutilizar bloques de construcción en diferentes flujos de trabajo. Kubeflow también proporciona soporte para visualización y colaboración en su flujo de trabajo ML.
Kubeflow Pipelines es un componente recientemente agregado de Kubeflow que puede ayudarnos a componer, implementar y administrar flujos de trabajo ML, de manera opcional, híbridos de extremo a extremo. Debido a que Pipelines es parte de Kubeflow, no hay bloqueo en la transición desde la creación de prototipos a la producción. Kubeflow Pipelines admite la experimentación rápida y confiable, con una interfaz que facilita el desarrollo en un portátil Jupyter, por lo que puede probar muchas técnicas de ML para identificar qué funciona mejor para su aplicación.
Hay muchas ventajas al construir una pila de ML sobre Kubernetes. No es necesario volver a implementar los fundamentos que se requerirían para dicho grupo, como el soporte para la replicación, las revisiones de estado y la supervisión. Kubernetes admite la capacidad de generar especificaciones declarativas sólidas y crear definiciones de recursos personalizadas adaptadas para ML. Por ejemplo, TFJob de Kubeflow es un recurso personalizado que facilita la ejecución de trabajos de capacitación distribuidos de TensorFlow en Kubernetes.
Kubernetes ofrece la escalabilidad, la portabilidad y la reproducibilidad requeridas para el soporte de flujos y experimentos de ML consistentemente ejecutados. Ayuda a crear y componer pasos de flujo de trabajo reutilizables y bloques de construcción de ML y facilita la ejecución de los mismos flujos de trabajo en diferentes clústeres a medida que pasan del prototipo a la producción o se mueven de un clúster local a la nube.
Dejo link:
https://github.com/kubeflow/kubeflow
https://www.kubeflow.org/
miércoles, 30 de enero de 2019
Eclipse GlassFish fue liberado!!
Eclipse Glassfish fue liberado!!
Según lo que tengo entendido es el primer release desde que Glassfish es de la organización Eclipse. Si bien se encuentra en incubadora, es un contenedor JEE muy confiable y estable, dado sus años de desarrollo, prueba y uso.
Espero que tome fuerza y crezca en popularidad como se lo merece.
Sin más, dejo link : https://projects.eclipse.org/projects/ee4j.glassfish/downloads?utm_content=83778533&utm_medium=social&utm_source=facebook&hss_channel=fbp-259655700571
Probando Linux deepin 15.9
Probe linux deepin y es una muy buena opción, muy elegante y facil de usar. Para los que no la conocen Deepin es una distribución de Linux basada en la arquitectura de Debian.
Está enfocado en "proveer un sistema operativo elegante, amigable con el usuario, estable y seguro". El desarrollo de Deepin es liderado por la compañía China Wuhan Deepin Technology Co., Ltd., que genera ingresos mediante la venta de soporte técnico y otros servicios relacionados con Deepin.
La verdad me sorprendió, muy intuitivo y con aplicaciones propias que la rompen.
Sin más dejo link: https://www.deepin.org/es/
y screenshots:
domingo, 27 de enero de 2019
AWS lanza una nueva base de datos orientada a documentos compatible con MongoDB
AWS acaba de lanzar un servicio de base de datos, denominado Amazon DocumentDB, que almacena datos semiestructurados dentro de un servicio administrado escalable y de alta disponibilidad. Mientras ofrece una API compatible con MongoDB, DocumentDB no ejecuta software de MongoDB, pero ofrece una API para compatibilidad.
Amazon posicionó DocumentDB como un reemplazo directo que está "diseñado para ser compatible con sus aplicaciones y herramientas MongoDB existentes". AWS afirma que DocumentDB ofrece la escalabilidad, disponibilidad y rendimiento necesarios para las cargas de trabajo MongoDB de grado de producción. DocumentDB ofrece hasta 64 TB de almacenamiento que crece automáticamente (en comparación con la asignación previa) junto con su uso. Los clientes también tienen una opción de tamaños de "instancia" que se pueden ampliar hasta 488 GiB de memoria. Para disponibilidad, DocumentDB replica datos 6x en tres zonas de disponibilidad. También permite a los usuarios crear hasta quince réplicas de lectura. Y para el rendimiento, DocumentDB se ejecuta en el almacenamiento SSD y está diseñado para operaciones de lectura de baja latencia. DocumentDB incluye una serie de capacidades de gestión de bases de datos integradas.
Algunos especulan que DocumentDB se basa en AWS Aurora PostgreSQL, pero está claro que NO está ejecutando el software MongoDB. MongoDB, Inc. es una de las pocas compañías que recientemente han cambiado su licencia para disuadir a los proveedores de la nube de ofrecer partes de su software de código abierto como un servicio.
Dejo links:
https://aws.amazon.com/blogs/aws/new-amazon-documentdb-with-mongodb-compatibility-fast-scalable-and-highly-available/
https://aws.amazon.com/documentdb/
sábado, 26 de enero de 2019
4 libros gratuitos de java code geeks!
Download Dev Guides!
|
| ||||||
|
|
domingo, 20 de enero de 2019
Que es Gradle?
Todos debemos estar al tanto de las herramientas de construcción de proyecto. Si vienen del mundo java seguro concen Maven, si vienen de Scala sbt, si vienen javascript npm, etc...
Gradle es una herramienta de automatización de compilación de proyectos de tecnología java, es de código abierto centrado en la flexibilidad y el rendimiento. Los scripts de compilación de Gradle se escriben utilizando un DSL Groovy o Kotlin. Lea sobre las características de Gradle para aprender lo que es posible con Gradle.
Altamente personalizable: Gradle se modela de una manera que es personalizable y extensible de la manera más fundamental.
Rápido: Gradle completa las tareas rápidamente, reutilizando los resultados de ejecuciones anteriores, procesando solo las entradas que han cambiado y ejecutando tareas en paralelo.
Potente: Gradle es la herramienta de compilación oficial para Android y es compatible con muchos lenguajes y tecnologías populares.
Porque tendria que usar Gradle en vez de Maven algunas razones son: flexibilidad, rendimiento, experiencia de usuario y administración de dependencias. En cuanto a la performance
Aunque los IDE son importantes, un gran número de usuarios prefieren ejecutar operaciones de compilación a través de una interfaz de línea de comandos. Gradle proporciona un CLI moderno que tiene características de detección como "tareas de gradle", así como un mejor registro y finalización de la línea de comandos.
Finalmente, Gradle proporciona una interfaz de usuario basada en la web interactiva para depurar y optimizar construcciones: análisis de compilación. También se pueden alojar en las instalaciones para permitir a una organización recopilar el historial de compilación y hacer análisis de tendencias, comparar compilaciones para depurar o optimizar el tiempo de compilación.
Que esperas para aprender y usar Gladle?
Dejo link: https://gradle.org
Gradle es una herramienta de automatización de compilación de proyectos de tecnología java, es de código abierto centrado en la flexibilidad y el rendimiento. Los scripts de compilación de Gradle se escriben utilizando un DSL Groovy o Kotlin. Lea sobre las características de Gradle para aprender lo que es posible con Gradle.
Altamente personalizable: Gradle se modela de una manera que es personalizable y extensible de la manera más fundamental.
Rápido: Gradle completa las tareas rápidamente, reutilizando los resultados de ejecuciones anteriores, procesando solo las entradas que han cambiado y ejecutando tareas en paralelo.
Potente: Gradle es la herramienta de compilación oficial para Android y es compatible con muchos lenguajes y tecnologías populares.
Porque tendria que usar Gradle en vez de Maven algunas razones son: flexibilidad, rendimiento, experiencia de usuario y administración de dependencias. En cuanto a la performance
Aunque los IDE son importantes, un gran número de usuarios prefieren ejecutar operaciones de compilación a través de una interfaz de línea de comandos. Gradle proporciona un CLI moderno que tiene características de detección como "tareas de gradle", así como un mejor registro y finalización de la línea de comandos.
Finalmente, Gradle proporciona una interfaz de usuario basada en la web interactiva para depurar y optimizar construcciones: análisis de compilación. También se pueden alojar en las instalaciones para permitir a una organización recopilar el historial de compilación y hacer análisis de tendencias, comparar compilaciones para depurar o optimizar el tiempo de compilación.
Que esperas para aprender y usar Gladle?
Dejo link: https://gradle.org
jueves, 17 de enero de 2019
Propiedades y campos en Kotlin parte 2
Los campos no pueden ser declarados directamente en las clases de Kotlin. Sin embargo, cuando una
propiedad necesita un campo de respaldo, Kotlin lo proporciona automáticamente. Se puede hacer referencia a este campo de respaldo en los accesores utilizando el identificador de campo:
var counter = 0 // Nota: el inicializador asigna el campo de respaldo directamente
valor ajustado) {
if (valor> = 0) campo = valor
}
El identificador de campo solo se puede utilizar en los accesores de la propiedad.
Se generará un campo de respaldo para una propiedad si utiliza la implementación predeterminada de al menos uno de los accesores, o si un descriptor de acceso personalizado lo hace referencia a través del identificador de campo.
Por ejemplo, en el siguiente caso no habrá ningún campo de respaldo:
val isEmpia: booleano
get () = this.size == 0
Si desea hacer algo que no se ajuste a este esquema de "campo de respaldo implícito", siempre puede recurrir a una propiedad de respaldo:
private var _table: Map<String, Int>? = null
public val table: Map<String, Int>
get() {
if (_table == null) {
_table = HashMap() // Type parameters are inferred
}
return _table ?: throw AssertionError("Set to null by another thread")
}
En todos los aspectos, esto es lo mismo que en Java, ya que el acceso a las propiedades privadas con captadores y configuradores predeterminados está optimizado para que no se introduzca la sobrecarga de llamadas a funciones.
Las propiedades cuyo valor se conoce en tiempo de compilación se pueden marcar como constantes de tiempo de compilación utilizando el modificador const. Tales propiedades deben cumplir los siguientes requisitos:
Tales propiedades pueden ser utilizadas en anotaciones:
const val SUBSYSTEM_DEPRECATED: String = "This subsystem is deprecated"
@Deprecated(SUBSYSTEM_DEPRECATED) fun foo() { ... }
Normalmente, las propiedades declaradas con un tipo no nulo deben inicializarse en el constructor. Sin embargo, bastante a menudo esto no es conveniente. Por ejemplo, las propiedades pueden inicializarse a través de la inyección de dependencia, o en el método de configuración de una prueba de unidad. En este caso, no puede proporcionar un inicializador que no sea nulo en el constructor, pero aún así desea evitar las comprobaciones nulas al hacer referencia a la propiedad dentro del cuerpo de una clase.
Para manejar este caso, puede marcar la propiedad con el modificador lateinit:
public class MyTest {
lateinit var subject: TestSubject
@SetUp fun setup() {
subject = TestSubject()
}
@Test fun test() {
subject.method() // dereference directly
}
}
El modificador se puede usar en las propiedades var declaradas dentro del cuerpo de una clase (no en el constructor principal, y solo cuando la propiedad no tiene un captador o definidor personalizado) y, desde Kotlin 1.2, para propiedades de nivel superior y variables locales . El tipo de propiedad o variable no debe ser nulo y no debe ser un tipo primitivo.
El acceso a una propiedad de inicio tardío antes de que se haya inicializado genera una excepción especial que identifica claramente la propiedad a la que se accede y el hecho de que no se ha inicializado.
Para verificar si ya se ha inicializado una var de lateinit, use .isInitialized en la referencia a esa propiedad:
if (foo::bar.isInitialized) {
println(foo.bar)
}
Esta verificación solo está disponible para las propiedades que son accesibles léxicamente, es decir, declaradas en el mismo tipo o en uno de los tipos externos, o en el nivel superior en el mismo archivo.
propiedad necesita un campo de respaldo, Kotlin lo proporciona automáticamente. Se puede hacer referencia a este campo de respaldo en los accesores utilizando el identificador de campo:
var counter = 0 // Nota: el inicializador asigna el campo de respaldo directamente
valor ajustado) {
if (valor> = 0) campo = valor
}
El identificador de campo solo se puede utilizar en los accesores de la propiedad.
Se generará un campo de respaldo para una propiedad si utiliza la implementación predeterminada de al menos uno de los accesores, o si un descriptor de acceso personalizado lo hace referencia a través del identificador de campo.
Por ejemplo, en el siguiente caso no habrá ningún campo de respaldo:
val isEmpia: booleano
get () = this.size == 0
Si desea hacer algo que no se ajuste a este esquema de "campo de respaldo implícito", siempre puede recurrir a una propiedad de respaldo:
private var _table: Map<String, Int>? = null
public val table: Map<String, Int>
get() {
if (_table == null) {
_table = HashMap() // Type parameters are inferred
}
return _table ?: throw AssertionError("Set to null by another thread")
}
En todos los aspectos, esto es lo mismo que en Java, ya que el acceso a las propiedades privadas con captadores y configuradores predeterminados está optimizado para que no se introduzca la sobrecarga de llamadas a funciones.
Las propiedades cuyo valor se conoce en tiempo de compilación se pueden marcar como constantes de tiempo de compilación utilizando el modificador const. Tales propiedades deben cumplir los siguientes requisitos:
- Nivel superior, o miembro de una declaración de objeto o un objeto complementario.
- Inicializado con un valor de tipo String o un tipo primitivo
- Sin adjetivo personalizado
Tales propiedades pueden ser utilizadas en anotaciones:
const val SUBSYSTEM_DEPRECATED: String = "This subsystem is deprecated"
@Deprecated(SUBSYSTEM_DEPRECATED) fun foo() { ... }
Normalmente, las propiedades declaradas con un tipo no nulo deben inicializarse en el constructor. Sin embargo, bastante a menudo esto no es conveniente. Por ejemplo, las propiedades pueden inicializarse a través de la inyección de dependencia, o en el método de configuración de una prueba de unidad. En este caso, no puede proporcionar un inicializador que no sea nulo en el constructor, pero aún así desea evitar las comprobaciones nulas al hacer referencia a la propiedad dentro del cuerpo de una clase.
Para manejar este caso, puede marcar la propiedad con el modificador lateinit:
public class MyTest {
lateinit var subject: TestSubject
@SetUp fun setup() {
subject = TestSubject()
}
@Test fun test() {
subject.method() // dereference directly
}
}
El modificador se puede usar en las propiedades var declaradas dentro del cuerpo de una clase (no en el constructor principal, y solo cuando la propiedad no tiene un captador o definidor personalizado) y, desde Kotlin 1.2, para propiedades de nivel superior y variables locales . El tipo de propiedad o variable no debe ser nulo y no debe ser un tipo primitivo.
El acceso a una propiedad de inicio tardío antes de que se haya inicializado genera una excepción especial que identifica claramente la propiedad a la que se accede y el hecho de que no se ha inicializado.
Para verificar si ya se ha inicializado una var de lateinit, use .isInitialized en la referencia a esa propiedad:
if (foo::bar.isInitialized) {
println(foo.bar)
}
Esta verificación solo está disponible para las propiedades que son accesibles léxicamente, es decir, declaradas en el mismo tipo o en uno de los tipos externos, o en el nivel superior en el mismo archivo.
Propiedades y campos en Kotlin
Las clases en Kotlin pueden tener propiedades. Se pueden declarar como mutables, usando la palabra clave var o de solo lectura usando la palabra clave val.
class Address {
var name: String = ...
var street: String = ...
var city: String = ...
var state: String? = ...
var zip: String = ...
}
Para usar una propiedad, simplemente nos referimos a ella por su nombre, como si fuera un campo en Java:
fun copyAddress(address: Address): Address {
val result = Address() // there's no 'new' keyword in Kotlin
result.name = address.name // accessors are called
result.street = address.street
// ...
return result
}
La sintaxis completa para declarar una propiedad es
var <propertyName>[: <PropertyType>] [= <property_initializer>]
[<getter>]
[<setter>]
El inicializador, getter y setter son opcionales. El tipo de propiedad es opcional si se puede inferir del inicializador (o del tipo de devolución del captador, como se muestra a continuación).
Ejemplos:
var allByDefault: Int? // error: explicit initializer required, default getter and setter implied
var initialized = 1 // has type Int, default getter and setter
La sintaxis completa de una declaración de propiedad de solo lectura difiere de la mutable en dos formas: comienza con val en lugar de var y no permite un definidor:
val simple: Int? // has type Int, default getter, must be initialized in constructor
val inferredType = 1 // has type Int and a default getter
Podemos definir accesores personalizados para una propiedad. Si definimos un captador personalizado, se llamará cada vez que accedamos a la propiedad (esto nos permite implementar una propiedad computada). Aquí hay un ejemplo de un captador personalizado:
val isEmpty: Boolean
get() = this.size == 0
Si definimos un configurador personalizado, se llamará cada vez que asignemos un valor a la propiedad. Un setter personalizado se ve así:
var stringRepresentation: String
get() = this.toString()
set(value) {
setDataFromString(value) // parses the string and assigns values to other properties
}
Por convención, el nombre del parámetro de establecimiento es valor, pero puede elegir un nombre diferente si lo prefiere.
Desde Kotlin 1.1, puede omitir el tipo de propiedad si se puede deducir del captador:
val isEmpty get() = this.size == 0 // has type Boolean
Si necesita cambiar la visibilidad de un elemento de acceso o anotarlo, pero no necesita cambiar la implementación predeterminada, puede definir el elemento de acceso sin definir su cuerpo:
var setterVisibility: String = "abc"
private set // the setter is private and has the default implementation
var setterWithAnnotation: Any? = null
@Inject set // annotate the setter with Inject
Seguiremos en otro post, por lo pronto dejo link:
https://kotlinlang.org/docs/reference/properties.html
class Address {
var name: String = ...
var street: String = ...
var city: String = ...
var state: String? = ...
var zip: String = ...
}
Para usar una propiedad, simplemente nos referimos a ella por su nombre, como si fuera un campo en Java:
fun copyAddress(address: Address): Address {
val result = Address() // there's no 'new' keyword in Kotlin
result.name = address.name // accessors are called
result.street = address.street
// ...
return result
}
La sintaxis completa para declarar una propiedad es
var <propertyName>[: <PropertyType>] [= <property_initializer>]
[<getter>]
[<setter>]
El inicializador, getter y setter son opcionales. El tipo de propiedad es opcional si se puede inferir del inicializador (o del tipo de devolución del captador, como se muestra a continuación).
Ejemplos:
var allByDefault: Int? // error: explicit initializer required, default getter and setter implied
var initialized = 1 // has type Int, default getter and setter
La sintaxis completa de una declaración de propiedad de solo lectura difiere de la mutable en dos formas: comienza con val en lugar de var y no permite un definidor:
val simple: Int? // has type Int, default getter, must be initialized in constructor
val inferredType = 1 // has type Int and a default getter
Podemos definir accesores personalizados para una propiedad. Si definimos un captador personalizado, se llamará cada vez que accedamos a la propiedad (esto nos permite implementar una propiedad computada). Aquí hay un ejemplo de un captador personalizado:
val isEmpty: Boolean
get() = this.size == 0
Si definimos un configurador personalizado, se llamará cada vez que asignemos un valor a la propiedad. Un setter personalizado se ve así:
var stringRepresentation: String
get() = this.toString()
set(value) {
setDataFromString(value) // parses the string and assigns values to other properties
}
Por convención, el nombre del parámetro de establecimiento es valor, pero puede elegir un nombre diferente si lo prefiere.
Desde Kotlin 1.1, puede omitir el tipo de propiedad si se puede deducir del captador:
val isEmpty get() = this.size == 0 // has type Boolean
Si necesita cambiar la visibilidad de un elemento de acceso o anotarlo, pero no necesita cambiar la implementación predeterminada, puede definir el elemento de acceso sin definir su cuerpo:
var setterVisibility: String = "abc"
private set // the setter is private and has the default implementation
var setterWithAnnotation: Any? = null
@Inject set // annotate the setter with Inject
Seguiremos en otro post, por lo pronto dejo link:
https://kotlinlang.org/docs/reference/properties.html
martes, 15 de enero de 2019
NoSQL Performance Benchmark 2018
Me llego esta mail de la gente de Couchbase :
Si está pensando en cambiar a una base de datos NoSQL, es importante pensar con anticipación. Una opción popular como MongoDB ™ podría funcionar ahora para sus aplicaciones NoSQL a pequeña escala. Pero cuando llega el momento de escalar, las cosas pueden complicarse muy rápidamente.
Lee el NoSQL Performance Benchmark 2018 de Altoros para descubrir cómo Couchbase:
- Supera constantemente a MongoDB ™ y DataStax
- Maneja fácilmente diferentes configuraciones y cargas de trabajo masivas
- Ofrece una agilidad, flexibilidad y rendimiento inigualables en cualquier escala
- Obtendrá un análisis en profundidad del rendimiento de Couchbase, MongoDB ™ y DataStax en 3 configuraciones de clúster diferentes y 4 cargas de trabajo diferentes utilizando el Yahoo Cloud Serving Benchmark.
Dejo link: https://resources.couchbase.com/c/altoros-nosql-performance-benchmark?x=N-I_ik&mkt_tok=eyJpIjoiTVROalpqQTBNRFV3WVdVdyIsInQiOiJRbWxoWGdEMUd3M1dCVW5EeVhTXC9ZbkkwMmRnb2xXWnNLd3g4cjVCM3JIbktVK0JScENpU2pXWVJONmNqRVBzWFVtbHh3YkRsNHZPOXgrNzd2NUZjWThtRHUxamVGK3ArU0d2SjdvMTdDSG54NHQ1YUhTVTNXeU94TlwvNmY4SlpXIn0%3D
Suscribirse a:
Entradas (Atom)