Apache Spark infografía

Quiero compartir esta infografía sobra apache Spark :

Dejo la fuente: https://intellipaat.com/apache-spark-scala-training/#about-course

Deploying Reactive Microservices

Quiero compartir el siguiente ebook, dado que es muy interesante el tema de los deploy en una arquitectura multiservicio. La verdad es que no tengo claro como hacerlo de forma practica y al parecer este libro te lo cuenta.

Dejo link:
http://post.oreilly.com/rd/9z1z9nleet9l259ived56o2srkjieg5gquk49qomong

Try laravel

Es genial tener muchos cursos tipo try de codeschool, ahora presentan un curso de laravel que para ser honesto era un framework php que no conocia.

Si más dejo la info:

Watch Course Intro

1. 

   Level 1 Free Level 2 Videos | 8 Challenges

   Welcome to Laravel

   Get a quick overview of Laravel and learn about CRUD actions.
2. 

   Level 2 Free Level 2 Videos | 7 Challenges

   Models & Views

   Learn how to get and display data from the database using models and views.
3. 

   Level 3 Free Level 2 Videos | 7 Challenges

   Controllers & Routing

   Explore how controllers manage the heavy lifting with logic and how routing helps direct the traffic of our application.

Complete these levels to unlock

Course Completion Badge

Dig into an overview of the Laravel framework and learn how to start building PHP applications with MVC architecture.

Dejo link: http://campus.codeschool.com/courses/try-laravel/

Un resumen de Scala for the Impatient, parte 25

La herencia de jerarquías en Scala.

El siguiente gráfico muestra la jerarquía de clases en Scala. Los tipos primitivos de java extienden de AnyVal.

Las referencias a clases o subclases extienden de AnyRef, que es sinónimo de Object de java o .net.
AnyVal y AnyRef extienden de Any, el inicio de la jerarquía.

La clase Any define los métodos isInstanceOf, asInstanceOf y métodos generales como equals o hashcode.

AnyVal no agrega ningún método, solo representa el tipo de los valores.

AnyRef agrega métodos de monitoreo como wait, notify o notifyAll (que son métodos de la clase Object) , también tiene un método synchronized, el cual puede recibir como parámetro una clausura, la cual va ser ejecutada como threed safe.

Todas las clases de scala implementan la interface ScalaObject, que no tiene métodos.

En el otro extremo de la jerarquía están los tipos Nothing y Null. Null es un tipo que tiene una sola instancia null, el desarrollador puede asignar null a cualquier referencia pero no a cualquier valor. Por ejemplo no se le puede asignar null a un valor entero.

El tipo Nothing no tiene instancia, ocasionalmente es útil para constructores genéricos o por ejemplo para definir Nil (que en una lista vacía) de tipo List[Nothing]

Ojo Nothing no es igual que void de Java o C, void en scala se representa con el tipo Unit, que es un tipo que tiene un solo valor ().  Tenga en cuenta que Unit no es un supertipo de ningún otro tipo. Sin embargo, el compilador permite que Any sea reemplazado por Unit.

Igualdad de objetos

En scala, el método eq esta definido en la clase AnyRef y comprueba si dos referencias referencian al mismo objeto. El método equals en AnyRef llama eq. Cuando implemente una clase, debe considerar la posibilidad sobrescribir el método equals para proporcionar una noción natural de igualdad para los objetos.
 
Por ejemplo, si definimos class Item(val description: String, val price: Double) se debe sobrescribir el método equals como en Java:

final override def equals(other: Any) = {
val that = other.asInstanceOf[Item]
if (that == null) false
else description == that.description && price == that.price
}

Cuando defina iguales, recuerde definir también hashCode como en Java. El código de hash se debe calcular sólo a partir de los campos que se utilizan en la comprobación de igualdad. Por ejemplo:

final override def hashCode = 13 * description.hashCode + 17 * price.hashCode

Generalmente no se llama el método eq o equals. Simplemente utilice el operador ==. Para tipos de referencia, llama a equals después de hacer la comprobación adecuada para los operandos nulos.

Curso gratuitos online!!

Quiero compartir estos cursos gratuitos online, que a simple vista estan muy buenos: 
 

Diplomado Tecnico Big Data 

 

Diplomado Tecnico en Sistemas Informaticos 


 

Diplomado Técnico en Integridad Web 


 

Gestion de Ambientes Virtuales de Aprendizaje 


 

Desarrollo de Estrategias Digitales de Aprendizaje 


 

Desarrollo de sitios web y aplicaciones moviles 

Introducción a la programación en Python I: Aprendiendo a programar con Python

Encontré este curso sobre python, y a simple vista esta bueno, esta dictado por la universidad Pontificia Universidad Católica de Chile y es gratuita y esta en castellano.

Dejo link: https://www.coursera.org/learn/aprendiendo-programar-python

Functional Programming in Haskell: Supercharge Your Coding

Me encontré con este curso en futureLearn y ya me anote. Es un curso introductorio a Haskell, el lenguaje de programación funcional cada vez más popular y es un curso de la Universidad de Glasgow.

Comienza el 18 de septiembre del 2017 y es gratuito pero hay que pagar para aceder a la certificación.

Dejo link: https://www.futurelearn.com/courses/functional-programming-haskell

El patrón de arquitectura space-based

El patrón de arquitectura space-based (también llamado a veces patrón de la arquitectura de la nube) minimiza los factores que limitan el escalamiento de la aplicación. Este patrón obtiene su nombre del concepto de espacio de tupla, la idea de memoria compartida distribuida. La alta escalabilidad se logra eliminando la restricción de la base de datos central y utilizando replicas en un grid de datos de memoria. Los datos de la aplicación se guardan en la memoria y se replican entre todas las unidades de proceso activas. Las unidades de procesamiento pueden arrancarse y apagarse dinámicamente a medida que aumenta y disminuye la carga del usuario, con lo que se aborda la escalabilidad variable. Debido a que no existe una base de datos central, el cuello de botella de la base de datos se elimina, proporcionando escalabilidad casi infinita dentro de la aplicación.

La mayoría de las aplicaciones que se ajustan a este patrón son sitios web estándar que reciben una solicitud de un navegador y realizan algún tipo de acción. Un sitio de subastas de licitación es un buen ejemplo de esto. El sitio recibe continuamente ofertas de los usuarios de Internet a través de una solicitud de navegador. La aplicación recibirá una puja por un elemento en particular, registrará esa puja con una marca de tiempo y actualizará la última información de puja para el elemento y enviará la información al navegador.

El componente de la unidad de procesamiento contiene los componentes de la aplicación (o partes de los componentes de la aplicación). Esto incluye componentes basados en web, así como lógica de negocio de back-end. El contenido de la unidad de procesamiento varía en función del tipo de aplicación: las aplicaciones basadas en web más pequeñas probablemente se desplegarán en una sola unidad de procesamiento, mientras que las aplicaciones más grandes pueden dividir la funcionalidad de la aplicación en múltiples unidades de procesamiento basadas en las áreas funcionales de la aplicación. La unidad de procesamiento contiene típicamente los módulos de aplicación, junto con un grid de datos en memoria y un almacén persistente asíncrono opcional para salvar errores. También contiene un motor de replicación que es utilizado por el middleware virtualizado para replicar los cambios de datos realizados por una unidad de procesamiento a otras unidades de procesamiento activas.

El middleware virtualizado es esencialmente el controlador de la arquitectura y administra solicitudes, sesiones, replicación de datos, procesamiento de solicitud distribuida y despliegue de unidades de proceso. Hay cuatro componentes de arquitectura principales en el middleware virtualizado: grid de mensajería, grid de datos, grid de procesamiento y el gestor de despliegue.

Grid de mensajería, administra la solicitud de entrada y la información de la sesión. Cuando una solicitud llega al componente middleware virtualizado, el grid de mensajería determina qué componentes activos de procesamiento están disponibles para recibir la solicitud y reenvía la solicitud a una de esas unidades de procesamiento. La complejidad de grid de mensajería puede ir desde un simple algoritmo round-robin hasta un algoritmo más complejos.

Grid de datos es quizás el componente más importante y crucial en este patrón. Grid de datos interactúa con el motor de replicación de datos en cada unidad de procesamiento para gestionar la replicación de datos entre unidades de procesamiento cuando se producen actualizaciones de datos. Puesto que Grid de mensajería puede enviar una solicitud a cualquiera de las unidades de procesamiento disponibles, es esencial que cada unidad de procesamiento contenga exactamente los mismos datos en su grid de datos en memoria. La replicación de datos síncrona entre unidades de procesamiento, se hace en paralelo asincrónicamente y muy rápidamente, a veces completando la sincronización de datos en cuestión de microsegundos (una millonésima de segundo).

Grid de procesamiento es un componente opcional dentro del middleware virtualizado que gestiona el procesamiento de solicitud distribuida cuando hay varias unidades de procesamiento, cada una de las cuales maneja una parte de la aplicación. Si entra una petición que requiere coordinación entre los tipos de unidades de procesamiento (por ejemplo, una unidad de procesamiento de pedidos y una unidad de procesamiento de clientes), es grid de procesamiento la que media y ordena la solicitud entre esas dos unidades de procesamiento.

El componente de gestor de despliegue gestiona el arranque dinámico y el apagado de las unidades de procesamiento en función de las condiciones de carga. Este componente monitorea continuamente los tiempos de respuesta y las cargas del usuario, e inicia nuevas unidades de procesamiento cuando aumenta la carga, y cierra las unidades de procesamiento cuando la carga disminuye. Es un componente crítico para lograr las necesidades de escalabilidad variable dentro de una aplicación.

El modelo de arquitectura space-based es un patrón complejo y costoso de implementar. Es una buena opción de arquitectura para aplicaciones web más pequeñas con carga variable (por ejemplo, sitios de medios sociales, sitios de pujas y subastas). Sin embargo, no es adecuado para aplicaciones de bases de datos relacionales de gran escala tradicionales con grandes cantidades de datos operativos.

Dejo link; https://www.oreilly.com/ideas/software-architecture-patterns/page/6/space-based-architecture

El patrón de arquitectura microservicios

El patrón de arquitectura microservicios está ganando rápidamente terreno en la industria como una alternativa viable a las aplicaciones monolíticas y arquitecturas orientadas al servicio. Debido a que este patrón de arquitectura sigue evolucionando, hay mucha confusión en la industria acerca de lo que es este patrón y cómo se implementa. 

Independientemente de la topología o el estilo de implementación elegidos, hay varios conceptos básicos comunes que se aplican al patrón de arquitectura general. El primero de estos conceptos es la noción de unidades desplegadas separadamente. Cada componente de la arquitectura de microservicios se despliega como una unidad separada, permitiendo un despliegue más fácil a través de una tubería de entrega efectiva y simplificada, mayor escalabilidad y un alto grado de aplicación y desacoplamiento de componentes dentro de su aplicación.

Quizás el concepto más importante para entender con este patrón es la noción de un componente de servicio. En lugar de pensar en los servicios dentro de una arquitectura de microservicios, es mejor pensar en los componentes del servicio, que pueden variar en granularidad de un solo módulo a una gran parte de la aplicación. Los componentes de servicio contienen uno o más módulos (por ejemplo, clases de Java) que representan una función de un solo propósito (por ejemplo, proporcionar el tiempo para una ciudad o ciudad específica) o una parte independiente de una aplicación empresarial grande. Diseñar el nivel adecuado de granularidad del componente de servicio es uno de los mayores desafíos dentro de una arquitectura de microservicios.

Otro concepto clave dentro del patrón de arquitectura de microservicios es que es una arquitectura distribuida, lo que significa que todos los componentes dentro de la arquitectura están completamente desacoplados entre sí y se accede a través de algún tipo de protocolo de acceso remoto (por ejemplo, JMS, AMQP, REST, SOAP, RMI, etc.). La naturaleza distribuida de este patrón de arquitectura es cómo consigue algunas de sus características de escalabilidad y despliegue superiores.

Existen docenas de implementaciones de este patrón arquitectonico, pero las más comunes son: basado en un API REST, basado en una aplicación REST y de mensajería centralizada.

La topología de API REST es útil para los sitios web que desean exponer servicios atravez de una API. Un ejemplo de estos son las APIs que proveen servicios de Google, Yahoo o/y Amazon.

La topologia basada en REST es un tanto diferente a la anterior dado que las solicitudes del cliente se reciben a través de pantallas de aplicaciones empresariales tradicionales basadas en web o en clientes en lugar de a través de una simple capa API. La capa de interfaz de usuario de la aplicación se despliega como una aplicación web separada que accede de forma remota a componentes de servicio desplegados por separado (funcionalidad empresarial) a través de simples interfaces basadas en REST. Los componentes de servicio en esta topología difieren de los de la topología basada en API-REST en que estos componentes de servicio tienden a ser más grandes, de grano más grueso y representan una pequeña porción de la aplicación empresarial general. Esta topología es común para las aplicaciones empresariales pequeñas y medianas que tienen un grado relativamente bajo de complejidad.

Otro enfoque común dentro del patrón de arquitectura de microservicios es la topología de mensajería centralizada. Esta topología es similar a la topología anterior basada en REST, excepto que en lugar de usar REST para acceso remoto, esta topología utiliza un intermediario de mensajes centralizado ligero (por ejemplo, ActiveMQ, HornetQ, etc.). Es de vital importancia al considerar esta topología no confundirlo con el patrón de arquitectura orientada al servicio o considerarlo "SOA-Lite". El agente de mensajes ligeros que se encuentra en esta topología no realiza ninguna orquestación, transformación o enrutamiento complejo. Es sólo un transporte ligero para acceder a los componentes de servicio remotos.

La topología de mensajería centralizada se encuentra típicamente en aplicaciones de negocios más grandes o aplicaciones que requieren un control más sofisticado sobre la capa de transporte entre la interfaz de usuario y los componentes de servicio. Los beneficios de esta topología sobre la simple topología basada en REST discutida anteriormente son mecanismos avanzados de colas, mensajería asíncrona, monitoreo, manejo de errores y mejor balanceo de carga y escalabilidad. El único punto de fallo y los problemas de cuello de botella arquitectónico generalmente asociados con un intermediario centralizado se abordan a través de la agrupación de intermediarios y de la federación de intermediarios (dividir una única instancia de intermediario en múltiples instancias de intermediario para dividir la carga de procesamiento de mensajes en función de las áreas funcionales del sistema).

El patrón de arquitectura de microservicios resuelve muchos de los problemas comunes encontrados tanto en aplicaciones monolíticas como en arquitecturas orientadas a servicios. Dado que los principales componentes de la aplicación se dividen en unidades más pequeñas, desplegadas por separado, las aplicaciones creadas utilizando el patrón de arquitectura de microservicios son generalmente más robustas, proporcionan una mejor escalabilidad y pueden soportar más fácilmente la entrega continua.

Otra ventaja de este patrón es que proporciona la capacidad de realizar despliegues de producción en tiempo real, lo que reduce significativamente la necesidad de los tradicionales despliegues mensuales o de fin de semana de "big bang". Dado que el cambio se suele aislar a componentes de servicio específicos, sólo es necesario desplegar los componentes de servicio que cambian. Si sólo tiene una única instancia de un componente de servicio, puede escribir código especializado en la aplicación de interfaz de usuario para detectar un despliegue en caliente activo y redirigir a los usuarios a una página de error o una página de espera. Alternativamente, puede intercambiar varias instancias de un componente de servicio durante y después de una implementación en tiempo real, lo que permite una disponibilidad continua durante los ciclos de implementación (algo que es muy difícil de hacer con el patrón de arquitectura en capas).

Una última consideración a tener en cuenta es que, dado que el patrón de arquitectura de los micro-servicios es una arquitectura distribuida, comparte algunos de los mismos problemas complejos encontrados en el patrón de arquitectura impulsado por eventos, incluyendo creación de contrato, mantenimiento y administración, disponibilidad remota del sistema, autenticación y autorización de acceso remoto.

El patrón de arquitectura microkernel

Leyendo el libro, "Software Architecture Patterns" les dejo este pequeño resumen:

El patrón de arquitectura microkernel (a veces denominado patrón de arquitectura de plug-in) es un patrón natural para implementar aplicaciones basadas en productos. Una aplicación basada en producto es una que está empaquetada y está disponible para su descarga en versiones como un producto de terceros típico. Sin embargo, muchas compañías también desarrollan y liberan sus aplicaciones empresariales internas, como productos de software, con versiones, notas de lanzamiento y características conectables. Estos son también un ajuste natural para este patrón. El patrón de arquitectura de microkernel le permite agregar funciones de aplicación adicionales como complementos a la aplicación principal, proporcionando extensibilidad, así como separación y aislamiento de características.

Esta arquitectura esta compuesta por 2 componentes, el sistema core y los modulos plug-in. El core contiene la minima funcionalidad y los módulos plug-in son componentes autónomos e independientes que contienen procesamiento especializado, características adicionales y código personalizado que está diseñado para mejorar o ampliar el sistema central para producir capacidades empresariales adicionales. Generalmente, los módulos plug-in deben ser independientes de otros módulos plug-in, pero ciertamente puede diseñar plug-ins que requieran que otros plug-ins estén presentes. De cualquier manera, es importante mantener la comunicación entre plug-ins a un mínimo para evitar problemas de dependencia.

Cuando leemos esto lo primero que se nos viene a la mente es OSGi, porque este estándar nació para darle soporte a este tipo de arquitecturas y el ejemplo más significativo de esta arquitectura sea eclipse.

Dejo link: https://www.oreilly.com/ideas/software-architecture-patterns/page/4/microkernel-architecture

El patrón arquitectónico Event-Driver

Leyendo el libro, "Software Architecture Patterns" les dejo este pequeño resumen:

El patrón arquitectónico Event-Driver se utiliza para crear arquitecturas escalables, se puede utilizar  en grandes aplicaciones como en pequeñas.

Este patrón arquitectónico tiene 2 topologías, el mediador y el broker (corredor, como es una fea traducción dejo su nombre en ingles).

La topología del mediador se utiliza comúnmente cuando se necesita orquestar múltiples pasos dentro de un evento a través de un mediador central, mientras que la topología de broker se utiliza cuando se desea encadenar sucesos sin el uso de un mediador central. Debido a que las características de la arquitectura y las estrategias de implementación difieren entre estas dos topologías, es importante entender cada una de ellas para saber cuál es la más adecuada para cada  situación particular.

La topología del mediador es útil para eventos que tienen varios pasos y requieren algún nivel de orquestación para procesar el evento.

Hay cuatro tipos principales de componentes de arquitectura dentro de la topología del mediador: colas de eventos, un mediador de eventos, canales de eventos y procesadores de eventos. El flujo de eventos comienza con un cliente que envía un evento a una cola de eventos, que se utiliza para transportar el evento al mediador de eventos. El mediador de eventos recibe el evento inicial y orquesta dicho evento enviando eventos asíncronos adicionales a los canales de eventos para ejecutar cada paso del proceso. Los procesadores de eventos, que escuchan en los canales de eventos, reciben el evento del mediador de eventos y ejecutan lógica empresarial específica para procesar el evento.

La implementación más simple y más común del mediador de eventos es a través de frameworks open source como Spring Integration, Apache Camel o Mule ESB. Los flujos de eventos en estos frameworks se implementan típicamente a través de código Java o un DSL (lenguaje específico de dominio). Para una mediación y una orquestación más sofisticadas, puede utilizar BPEL (lenguaje de ejecución de procesos empresariales) junto con un motor BPEL open source como Apache ODE. BPEL es un lenguaje XML estándar que describe los datos y los pasos necesarios para procesar un evento inicial. Para aplicaciones muy grandes que requieren una orquestación mucho más sofisticada (incluyendo pasos que involucran interacciones humanas), puede implementar el mediador de eventos utilizando un gestor de procesos empresariales (BPM) como jBPM.

La topología broker se diferencia de mediador porque no hay un mediador central y único, sino que el flujo de eventos esta distribuido a través de los componentes del procesador de eventos de una manera similar a una cadena a través de un agente de mensajes ligero (por ejemplo, ActiveMQ, HornetQ, etc.). Esta topología es útil cuando se tiene un flujo de procesamiento de eventos relativamente simple y no desea (o necesita) orquestación de eventos centrales.

Hay dos tipos principales de componentes de arquitectura dentro de la topología de intermediario: un componente de broker y un componente de procesador de sucesos. El componente de broker puede centralizarse o federarse y contiene todos los canales de eventos que se utilizan en el flujo de eventos.

El patrón de arquitectura event-driver es un patrón relativamente complejo de implementar, principalmente debido a su naturaleza asincrónica distribuida. Al implementar este patrón, debe abordar varios problemas de arquitectura distribuida, como la disponibilidad de procesos remotos, la falta de capacidad de respuesta y la lógica de reconexión de intermediarios en caso de un fallo del intermediario o mediador.

Una consideración a tener en cuenta al elegir este patrón de arquitectura es la falta de transacciones atómicas para un solo proceso de negocio. Debido a que los componentes del procesador de eventos están altamente disociados y distribuidos, es muy difícil mantener una unidad transaccional de trabajo a través de ellos. Por esta razón, al diseñar su aplicación utilizando este patrón, debe pensar continuamente sobre qué eventos pueden y no pueden ejecutarse de forma independiente y planificar la granularidad de los procesadores de sucesos en consecuencia. Si descubre que necesita dividir una sola unidad de trabajo en los procesadores de eventos, es decir, si utiliza procesadores independientes para algo que debería ser una transacción indivisa, probablemente no sea el patrón adecuado para su aplicación.

Dejo link: http://radar.oreilly.com/2015/02/variations-in-event-driven-architecture.html

Libros gratuitos sobre tecnología Microsoft

Microsoft nos regala muchísimos libros de tecnologías microsoft desde .net, powershell, azure hasta office y windows.

Sin más comentarios dejo link:
https://blogs.msdn.microsoft.com/mssmallbiz/2017/07/11/largest-free-microsoft-ebook-giveaway-im-giving-away-millions-of-free-microsoft-ebooks-again-including-windows-10-office-365-office-2016-power-bi-azure-windows-8-1-office-2013-sharepo/

Concurrent Programming in Erlang

Luego de terminar el curso de Erlang en future learn, ahora me entero que hay un curso de concurrencia en erlang. Aunque comienza en agosto, vale la pena publicar, (y para no olvidarme) luego haré un post para recordarles.

Si bien estos cursos son gratuitos hay que pagar para recibir la certificación.

Entre información general podemos decir que el curso esta dictado en ingles (con subtitulos) por la universidad de Kent (creo que no tiene nada que ver con superman).

Y el contenido es el siguiente:

• Processes and messages in Erlang
• Message-passing concurrency
• Designing for robustness
• Handling errors and dealing with exceptions
• Testing and fixing concurrency
• Multicore and distributed Erlang
• OTP: The Open Telecom Platform

Dejo link:
https://www.futurelearn.com/courses/concurrent-programming-erlang/

Real World OCaml

Quiero compartir este libro online gratuito, es sobre OCaml un lenguaje que desconozco totalmente.


Dejo link:
https://realworldocaml.org/

Keras, la red neuronal neutral escrita en Python

Como lo dije anteriormente Keras el la red neuronal neutral escrita en Python y con la capacidad de correr cualquier TensorFlow, CNTK o Theano.

Esta librería fue desarrollada con el foco a permitir una experimentación rápida.

Utilice Keras si necesita una librería de aprendizaje que:

• Permite un prototipado fácil y rápido (a través de la facilidad de uso, modularidad y extensibilidad).
• Soporta redes convolucionales y redes recurrentes, así como combinaciones de los dos.
• Se ejecuta sin problemas en la CPU y la GPU.

La estructura de datos de Keras es un modelo, una forma de organizar capas. El modelo más simple es el modelo Sequential, una pila lineal de capas. Para arquitecturas más complejas, debe utilizar la API funcional de Keras, que permite crear gráficos arbitrarios de capas.

Veamos una secuencia:

from keras.models import Sequential

model = Sequential()
from keras.layers import Dense, Activation

model.add(Dense(units=64, input_dim=100))
model.add(Activation('relu'))
model.add(Dense(units=10))
model.add(Activation('softmax'))

Una vez que su modelo se vea bien, se configura el proceso de aprendizaje con .compile ():

model.compile(loss='categorical_crossentropy',
              optimizer='sgd',
              metrics=['accuracy'])

Si es necesario, puede configurar su optimizador. Un principio básico de Keras es hacer las cosas razonablemente simples, mientras que permite al usuario tener totalmente el control cuando lo necesitan (el control final es la fácil extensibilidad del código fuente).

model.compile(loss=keras.losses.categorical_crossentropy,
              optimizer=keras.optimizers.SGD(lr=0.01, momentum=0.9, nesterov=True))

Ahora puede iterar en sus datos de entrenamiento:

# x_train and y_train are Numpy arrays --just like in the Scikit-Learn API.
model.fit(x_train, y_train, epochs=5, batch_size=32)

Alternativamente, puede alimentar lotes a su modelo manualmente:

Model.train_on_batch (x_batch, y_batch)

Evalúe su rendimiento en una sola línea:

Loss_and_metrics = model.evaluate (x_test, y_test, batch_size = 128)

O generar predicciones sobre nuevos datos:

Classes = model.predict (x_test, batch_size = 128)

Y listo!

Dejo link: https://keras.io/