Novedades

Desarrollo de Aplicaciones Móviles con NativeScript

ana2lp — Mon, 12 Dec 2016 21:54:30 +0000

Desarrollo de Aplicaciones Móviles con NativeScript

ana2lp Mon, 12/12/2016 - 15:54

Publicado en

SG #53

Novedades

Autor

Alejandro Mercado

El mundo móvil ha venido cambiando drásticamente, haciendo sumamente difícil para los desarrolladores crear y mantener sus aplicaciones móviles. Para alcanzar la mayor audiencia posible, las aplicaciones desarrolladas necesitan mantenerse en muchas plataformas y dispositivos. Para seguir al ritmo de este mundo cambiante, los desarrolladores comenzaron a ubicar en un lugar preponderante un solo código base para escribir y mantener las aplicaciones.

En este contexto podemos incluir una larga lista de empresas y tecnologías alrededor de la creación y entrega de aplicaciones móviles de plataforma cruzada (cross-platform mobile apps), las cuales, en su mayoría plantean un solo código base para el desarrollo y entrega de aplicaciones móviles para diferentes plataformas: tecnologías como PhoneGap/Cordova, React Native, Appcelerator Titanium y Xamarin entre otras.

Asimismo, podemos mencionar que el mundo del desarrollo móvil se sustenta en 4 grandes categorías: nativo, híbrido, compilación cruzada y justo a tiempo (just in time –JIT– por sus siglas en inglés,).

Figura 1. Diferentes tipos de aplicaciones móviles y sus frameworks más populares.

Las aplicaciones JIT o compiladas justo a tiempo son aquellas aplicaciones que son compiladas en tiempo de ejecución (runtime) en oposición a aquellas que son compiladas antes de la ejecución de la aplicación. Por ejemplo, en una aplicación JIT el código fuente no es compilado a código máquina nativo sino hasta el último minuto, o inmediatamente antes de ejecutar cada sentencia. NativeScript es JIT, compila justo a tiempo.

Conociendo NativeScript

NativeScript es un entorno de trabajo de código abierto (open-source mobile framework) para construir aplicaciones móviles para las plataformas iOS, Android —y próximamente Windows— usando JavaScript, CSS y XML. De manera opcional, podemos utilizar TypeScript y Angular 2 para obtener un mejor desempeño, manejo y escalamiento de nuestras aplicaciones.

NativeScript difiere de otros entornos de desarrollo de muchas maneras. La más importante es que se trata de un entorno de trabajo que verdaderamente permite escribir una sola vez y entregar a todas las plataformas. Con Nativescript podemos:

Aprovechar el conocimiento existente (no tienes que saber Objective C, Swift o Java). NativeScript ha sido diseñado para ser aprovechado por desarrolladores con diferentes formaciones.
Implementación de hojas de estilo CSS. Podemos cambiar la apariencia y estilo de vistas y elementos en una aplicación NativeScript de manera similar a como lo hacemos en una aplicación web, usando hojas de estilo o cambiando el estilo del objeto de los elementos en JavaScript. Sin embargo, sólo un subconjunto del lenguaje CSS es soportado.
Acceso a las APIs nativas de la plataforma. Si el framework de Nativescript no expone una API nativa que necesitemos, podemos implementar plugins con NativeScript.
Tu código se escribe una vez. En experiencias pasadas, trabajando con otros frameworks cross-platform, he visto que se requiere usar muchos shims (código de cuña) para que la aplicación funcione bien en las distintas plataformas; por ejemplo, puede que necesitemos agregar un poco de código para desplegar un botón sólo en la versión de Android o, tal vez, necesitamos escribir código adicional para hacer que un menú de lista se vea bien en iOS. Pero en NativeScript esto rara vez es necesario.

¿Cómo funciona NativeScript ?

Tal vez la característica más importante de NativeScript es su mecanismo para brindar acceso directo a las APIs nativas de cada plataforma. Pero, ¿cómo funciona?. Examinemos el siguiente código de una aplicación NativeScript para Android.

var time =new android.text.format.Time();
time.set(12,12,2016);
console.log( time.format("%D"));

Te preguntarás: ¿es código JavaScript creando una instancia de un objeto Java? Sí, JavaScript crea una instancia del objeto, android.text.format.Time(), invoca su método set() y luego manda al log de la consola el valor de retorno de su método format, el cual es la cadena “12/12/16”.

Veamos un ejemplo de una aplicación NativeScript para iOS.

var alert =new UIAlertView();
alert.message ="Hello world!";
alert.addButtonWithTitle("OK");
alert.show();

Figura 2. Ejemplo de ventana de diálogo con NativeScript

Este código JavaScript crea una instancia de una clase de Objective-C llamada UIAlertView, establece su propiedad message y luego llama a sus métodos addButtonWithTitle() y show().

Vale la pena aclarar que estos casos en los que accedemos a las APIs nativas invocando objetos específicos de Android o iOS, son excepciones. NativeScript incluye muchos módulos para tareas comunes, como hacer una petición HTTP, construir componentes UI, etc. Sin embargo, a veces las aplicaciones necesitan acceso a las APIs, y el runtime de NativeScript hace este acceso muy sencillo cuando se requiere.

NativeScript Runtime

El runtime de NativeScript es donde se hace la magia. Todo comienza con la máquina virtual de JavaScript que utiliza NativeScript para ejecutar comandos JavaScript. Específicamente NativeScript usa V8 en Android y JavaScriptCore en iOS. Así que todo el código que escribimos para tener acceso a las APIs nativas necesitan las construcciones y sintaxis de JavaScript que V8 y JavaScriptCore entienden.

Esta es la primera parte del proceso, regresemos a la primer línea de código del ejemplo que mostramos anteriormente para Android:

var time =new android.text.format.Time();

En el runtime de NativeScript en Android, este código es compilado justo a tiempo y ejecutado por V8. Pero, ¿cómo sabe V8 qué es android.text.format.Time()?

V8 sabe qué es Android porque el runtime de NativeScript lo inyecta, pues resulta que V8 tiene una tonelada de APIs que nos permiten configurar muchas cosas acerca del ambiente JavaScript. Podemos insertar nuestro propio código C++ para perfilar el uso del CPU de JavaScript, manejar la recolección de basura y cambiar cómo trabajan las variables internas, entre otras cosas.

Entre estas APIs existen algunas clases de “Contexto” que permiten manipular el alcance global, haciendo posible a NativeScript inyectar un objeto android global. Este es, de hecho, el mismo mecanismo que usa Node.js para hacer públicas sus APIs globales —por ejemplo, require( )— y NativeScript lo usa para inyectar APIs que permiten el acceso al código nativo.

JavaScriptCore tiene un mecanismo similar que hace la misma técnica posible para iOS.

Regresemos a nuestro ejemplo:

var time =new android.text.format.Time();

Sabemos que nuestro código corre en V8 y que éste sabe qué es android.text.format.Time() porque NativeScript inyecta los objetos necesarios en el alcance global. Ahora bien, ¿cómo sabe NativeScript qué APIs inyectar o qué hacer cuando la llamada a Time() sea realizada? NativeScript usa la técnica de reflexión (reflection) para construir la lista de APIs que están disponibles en la plataforma en que corre. La reflexión es la capacidad que tiene un programa para examinar su estructura y comportamiento en tiempo de ejecución, y es una técnica común en el lenguaje Java. NativeScript utiliza reflexión para construir una lista exhaustiva de las APIs de cada plataforma, incluyendo en este caso android.text.format.Time.

Generar esta información no es trivial desde una perspectiva de desempeño, es por eso que NativeScript lo hace antes de tiempo y embebe los metadatos generados previamente durante el paso de construcción en Android/iOS.

Invocando código nativo

La respuesta a cómo NativeScript invoca código nativo nuevamente recae en las APIs de las máquinas virtuales JavaScript. En esta ocasión, veremos una serie de llamadas que nos permiten ejecutar código C++ en puntos determinados durante la ejecución de JavaScript.

Por ejemplo, el código new android.text.format.Time() invoca una función JavaScript, para la cual V8 tiene una devolución de la llamada o callback. Así es como V8 tiene un callback que permite que NativeScript intercepte la llamada a la función, ejecutar ciertas acciones en un código C++ personalizado y proveer un nuevo resultado.

En el caso de Android, el código del runtime de NativeScript en C++ no puede acceder directamente a las APIs de Java como android.text.format.Time. Sin embargo, Android JNI o Java Native Interface provee la habilidad para hacer el puente entre C++ y Java, así que NativeScript utiliza JNI para hacer el salto. En iOS este puente extra no es necesario ya que el código C++ puede invocar directamente las APIs de Objective-C.

Dicho lo anterior regresemos a nuestra línea de código.

var time =new android.text.format.Time();

Sabemos que este código corre en V8 y que éste conoce qué es android.text.format.Time porque NativeScript inyecta dicho objeto. Posteriormente, NativeScript corre un proceso para la generación de los metadatos para obtener esas APIs y sabemos que cuando Time() se ejecuta, ocurre lo siguiente:

La función callback de V8 se ejecuta.
El runtime de NativeScript usa los metadatos para saber qué significa Time() y qué necesita para crear una instancia del objeto android.text.format.Time.
El runtime de NativeScript usa JNI para crear una instancia del objeto android.text.format.Time y guarda un referencia a éste.
El runtime de NativeScript regresa un objeto JavaScript que provee una interfaz (proxy) al objeto Java Time.
El control regresa a JavaScript donde el objeto proxy se almacena como una variable local time.

El objeto proxy es la manera como NativeScript mantiene un mapeo entre los objetos JavaScript y los objetos nativos.

Veamos la siguientes líneas de código de nuestro ejemplo anterior:

var time =new android.text.format.Time();
time.set(1,0,2015);

Debido a los metadatos generados, NativeScript sabe todos los métodos que tiene que poner en el objeto proxy. En este caso, el código invoca el método del objeto Time set(). Cuando este método corre, V8 nuevamente invoca su función callback. NativeScript detecta que ésta es una llamada al método y luego NativeScript utiliza el Android JNI para hacer la correspondiente llamada al método en el objeto Time de Java.

Bastante bueno, ¿no? De manera general así trabaja NativeScript, porque convertir Objective-C y objetos Java en objetos JavaScript puede ser complejo, especialmente cuando consideramos los diferentes modelos de herencia que cada lenguaje usa.

NativeScript CLI (command line interface).

La línea de comandos de NativeScript o CLI es el pegamento que mantiene todo el desarrollo unido. Esta línea de comandos está involucrada en todas las etapas del desarrollo, desde los andamios hasta la entrega de una aplicación en un emulador o en un dispositivo físico.

Para resumir y desde una vista a 10,000 pies: la CLI de NativeScript abstrae la complejidad de las herramientas nativas y SDKs, brindando al desarrollador un conjunto de comandos agnósticos a la plataforma para construir, mantener y entregar sus aplicaciones móviles.

Figura 3. Componentes utilizados para producir una aplicación [2].

TypeScript

Los desarrolladores NativeScript que prefieran la programación orientada a objetos pueden utilizar TypeScript.

TypeScript es un lenguaje originalmente creado por Microsoft pero posteriormente liberado como software libre. TypeScript se originó a partir de las deficiencias “percibidas” de JavaScript para el desarrollo de aplicaciones grandes, como entre los clientes externos. Los retos de lidiar con código JavaScript complejo conduce a una demanda de herramientas específicas para facilitar el desarrollo de componentes en el lenguaje. Cabe mencionar que Anders Hejlsberg arquitecto líder de C#, creador de Delphi y Turbo Pascal trabajó en el desarrollo.

TypeScript actualmente es trans-compilado, es decir Typescript es un superconjunto tipado de JavaScript que compila a JavaScript plano, pero se espera que eventualmente no sea así a medida de que las máquinas virtuales JS y navegadores den soporte el estándar ES6.

Angular 2

Angular 2 es la nueva versión del popular MV* framework de Google para construir aplicaciones complejas en el navegador (y más allá). Podemos decir que Angular 2 ha mutado de ser un framework a una plataforma y no simplemente una nueva versión. Angular 2 es una solución completa. Incluye rendering, compilación, vinculación, comunicación a servidor y pruebas unitarias, todo junto. Sin preocupaciones de escoger entre 20 librerías diferentes cuando solamente se necesita hacer una llamada HTTP.

Google liberó Angular 2 en septiembre de este año y ya tiene planeado liberar Angular 3 en marzo de 2017. Actualmente NativeScript se integra con Angular 2 y se espera una mayor integración y soporte para la nueva versión. Los equipos de desarrollo de ambas empresas han trabajado juntos para lograr esto. De tal forma que, si ya conoces Angular 2, estás listo para desarrollar aplicaciones móviles con NativeScript con un poder y desempeño 100% nativo.

Componentes UI para NativeScript

Se estima que un gran porcentaje del tiempo de un proyecto de desarrollo móvil se invierte en la creación de componentes de la interfaz de usuario y, en general, en la interfaz de usuario. De ahí que, en vez de desarrollar los componentes uno a uno, resulta mejor en términos de productividad utilizar componentes prediseñados. En este sentido, Telerik, la empresa creadora de NativeScript, provee Telerik UI que es un conjunto de componentes nativos de interfaz de usuario, que agrega muchas características avanzadas por encima de la capa de componentes por defecto que se entregan en el framework de NativeScript. Telerik tiene una larga historia desarrollando componentes UI para distintas plataformas (.Net, PHP, Node) que van desde listas, botones, formas de captura, y componentes de visualización de datos como gráficas, calendarios, etcétera.

Estatus actual y futuro

Actualmente NativeScript se encuentra en la versión 2.4, la cual ha tenido importantes y significativas mejoras, además de más de 360 plugins, lo cual es un claro indicador de que la comunidad está produciendo mucho más código que el equipo que lleva el núcleo. Esto es un gran logro para cualquier proyecto de código abierto.

Algunas de las principales mejores en esta versión son: Flexbox layouts, web workers, soporte a Angular 2.2, Node 6 LTS, ECMAScript 2015 (ES6) y ES7. La versión 2.5 se planea estará lista para enero de 2017.

Si quieres aprender más acerca de NativeScript, el mejor lugar para empezar son las guías y entrenamientos oficiales que puedes encontrar en www.nativescript.org y en www.telerik.com

Si estás en la Ciudad de México, hay un meetup de NativeScript con reuniones mensuales a las que puedes asistir.

¡Feliz NativeScript-ing!

Referencias

NativeScript. http://nativescript.org
N. Branstein. What NativeScript means to Mobile Development. http://swgu.ru/s8

Bio

Alejandro Mercado Peña es Director de Tecnología en KMMX, socio de entrenamiento Progress-Telerik en México. amercado@kmmx.mx

Guía de Arranque para VR con Oculus y Leap Motion Orion

sg — Wed, 12 Oct 2016 06:30:46 +0000

Guía de Arranque para VR con Oculus y Leap Motion Orion

sg Wed, 10/12/2016 - 01:30

Publicado en

SG #52

Novedades

Autor

Ernesto Riestra

Desde sus inicios, la realidad virtual ha sido una gran promesa de interacción con los sistemas digitales. Actualmente esta promesa ya es una realidad gracias a plataformas y dispositivos como Oculus Rift y Leap Motion.

Para poder lograr una sensación de inmersión completa, la realidad virtual incorpora dos elementos clave en su parte visual: primeramente la estereoscopía, que significa proyectar dos imágenes diferentes para cada ojo, de manera que logremos la sensación de profundidad, el tracking de la posición y orientación de la cabeza.

El segundo elemento es la interacción. La reacción inmediata al entrar a un entorno de VR, es extender las manos y tratar de tocar o alcanzar las cosas que están en el mismo. Aunque existe la posibilidad de usar controladores físicos, como gamepads, joysticks y sistemas de tracking de posición 3D, no hay nada como la idea de usar las propias extremidades para interactuar. Justamente esta es la idea detrás de innovaciones como Kinect de Microsoft o Leap Motion, un sensor que detecta movimientos y gestos hechos con las manos, lo cual permite interacciones más libres e intuitivas.

En este recorrido vamos a explorar todos los pasos necesarios para desarrollar un entorno de VR basado en Oculus y Unity, soluciones disponibles y accesibles en México. También revisaremos algunos ejemplos con Orion, la versión más reciente de software para Leap Motion.

Prerrequisitos e instalación básica

Para poder realizar este tutorial se necesita lo siguiente:

Computadora con requerimientos mínimos para Oculus y sistema operativo Windows
Unity 5.3.5
Oculus Runtime 1.3
Leap Motion Orion Software

En este tutorial utilizamos una computadora Alienware X51 R2, con tarjeta gráfica AMD Radeon R9 370 de 4GB y sistema operativo Windows 10 Home.

Aunque Oculus nos señalaba que nuestro equipo era una computadora no soportada, no experimentamos ningún problema de rendimiento con la versión Developer Kit 2 (DK2). Lamentablemente Oculus dejó de soportar hardware de Apple, por lo que no es posible reproducir este tipo de experiencias en sus equipos, al menos con el soporte y versiones más recientes al momento de escribir el presente artículo.

Nota: Para configurar el hardware hay que seguir las guías de producto de Oculus y de Leap Motion respectivamente. La instalación de Unity puede ser la versión Personal Edition sin costo.

Esta ya contiene las librerías básicas de compatibilidad, así que es necesario descargar de la página de Oculus los drivers más recientes para evitar inconvenientes.

Leap Motion Orion en Unity

Una vez instalado todo el hardware necesario, es momento de configurar Unity para desarrollo con Leap Motion Orion. Aunque se trata de una versión Beta, tiene enormes mejoras en la reducción de ruido y detección de gestos con las manos.

1. Para configurarlo dirígete a la página de desarrollo de Leap Motion Orion. Visita la sección de Unity: https://developer.leapmotion.com/unity, y da click en Download Core Assets. Además podrás descargar todos los add-on modules; funciones que no son parte de los core assets, pero que contienen metáforas de interacción interesantes y son soluciones a la medida de frecuente uso. Todos estos elementos se presentan como .unitypackage, formato comprimido de Unity para almacenar activos que puedes integrar en un proyecto.

2. El segundo paso es abrir Unity y crear un proyecto nuevo (o usar un proyecto previo si se cuenta con él). Ya dentro del proyecto dirígete a la ruta: Asset/Import Package/Custom Package… para instalar los paquetes.

3. Ahora selecciona cada paquete; automáticamente se almacenarán assets, scripts, scenes y otros elementos en la librería (ver figura 1).

Figura 1. Árbol de carpetas.

Las escenas de ejemplo están disponibles en las carpetas LeapMotion y LeapMotionModules; puedes probar algunas de las más interesantes. Describo algunos a continuación:

Leap_Hands_Demo_VR. Encontrarás este demo bajo LeapMotion/Scenes. La escena muestra un entorno VR básico en el que se utiliza Oculus y Leap Motion para mostrar las manos del usuario. La sensación de inmersión, aun con un fondo en gris, es increíble. Además se puede constatar la precisión de seguimiento y registro, es decir, la coincidencia entre la imagen virtual y nuestra sensación de dónde están nuestras manos (ver figura 2).

Figura 2. Demo de registro de manos.

ExampleUIScene. Esta escena se encuentra dentro de la carpeta LeapMotionModules/UIInput/Scenes y contiene ejemplos de interfaces de usuario 2D insertadas en un entorno de VR. La interacción es realmente fluida y los botones de ejemplo (tipo click, toggle y slider) reaccionan muy bien.

Figura 3. Interacción con componentes 2D.

PinchDrawDemo. Es otro ejemplo muy interesante. Con un poco de práctica es posible escribir y dibujar en un espacio 3D (ver figura 4). La encontrarás en LeapMotionModules/DetectionExamples/Scenes.

Figura 4. PinchDrawDemo.

Integrando Leap Motion a tu escena

Para integrar Leap Motion a una escena hay que crear algunos objetos desde la carpeta de prefabs de Leap Motion. Estos objetos contienen una cámara configurada para ser el punto de vista en VR y que el visor de Oculus lo pueda controlar, también están disponibles los objetos que representan las manos derecha e izquierda.

La escena utilizada para este tutorial es muy básica, un par de cubos animados que se desplazan relativamente (ver figura 5).

Figura 5. Escena básica

Figura 6. Configuración de Hand Pool

Para realizar dicho recorrido:

Ir a LeapMotion/Prefabs en la ventana de assets y arrastrar el prefab LMHeadMountedRig a la escena.
En la jerarquía de LMHeadMountedRig, hay un objeto llamado LeapHandController.
Desde el folder LeapMotion/Prefabs/HandModelsNonhuman, arrastrar los prefabs CapsuleHand_L y CapsuleHand_R a la ventana de la jerarquía y meter bajo LeapHandController.
Desde el folder LeapMotion/Prefabs/HandModelsPhysical, arrastrar el prefab RigidRoundHand_L y RigidRoundHand_R a la ventana de la jerarquía y meterlos igualmente bajo LeapHandController.
En la ventana del inspector, ubicar el objeto HandPool que está dentro de LeapHandController.
Debes crear un array en Model Pool; para hacerlo, escribe en Size el valor 2.
Arrastrar cuatro objetos en la escena (manos derecha e izquierda respectivamente), para que el controlador los pueda referir. Como se muestra a continuación, esto corresponde a dos manos gráficas y dos manos físicas.
Una vez creado este array de dos elementos, marcar los checkboxes IsEnabled y CanDuplicate de cada set de manos.
Hay que asegurarse de que esté habilitado el soporte a VR; ubicar el checkbox en Edit/Project Settings/PlayerSettings/OtherSettings/Virtual Reality Supported.
Para la interacción con objetos es importante que se trate de objetos rígidos (agregando un componente rigidBody a los mismos).

Figura 7. Interacción con objetos rígidos.

Conclusiones

Con estos sencillos pasos, puedes crear tu propio entorno en VR. Además tienes la oportunidad de verificar el gran avance que hay en cuanto a estas dos tecnologías; combinadas permiten realizar grandes cosas como escenas VR con interacción a través de las manos y no de dispositivos de apoyo.

Lo mejor es que cualquiera puede revisar y analizar estas herramientas y escenas demo, para integrarlas en sus propios desarrollos. Espero que este tutorial haya sido de tu interés, y que te anime a desarrollar tus propias ideas en un entorno de realidad virtual

Bio

Ernesto Riestra es cofundador y líder de investigación y desarrollo en Metagraphos, firma dedicada a la creación de experiencias digitales para transformar la productividad y el conocimiento de personas y organizaciones. Es Ingeniero Mecánico Electricista egresado de la UNAM y tiene una Maestría en Mecatrónica por la Universidad Técnica de Hamburgo.

Novedades de SQL Server 2016

sg — Thu, 02 Jun 2016 23:58:46 +0000

Novedades de SQL Server 2016

sg Thu, 06/02/2016 - 18:58

Publicado en

SG #51

Novedades

Autor

Pedro Galván

SQL Server 2016 ya está disponible de forma general, y recientemente participé en un taller a fondo sobre las nuevas características que incorpora esta nueva versión y puedo decir que quedé gratamente sorprendido. A continuación comparto un resumen de las capacidades que más me han llamado la atención.

Desempeño

SQL Server 2016 tiene un gran enfoque en mejorar el desempeño, y mucho de esto se logra gracias a mejoras en el soporte de cómputo en memoria. SQL Server 2014 ya soportaba tablas en-memoria, pero la implementación tenía muchas limitaciones (por ejemplo, no soportaba llaves foráneas y solo se podían tener tablas de máximo 256 GB). Esto ha mejorado drásticamente en SQL Server 2016; ya se soportan llaves foráneas, constraints únicos, operaciones paralelas, y ahora es posible tener tablas en memoria de hasta 2 TB. La figura 1 ilustra las mejoras en desempeño.

Seguridad

Una de las limitantes en términos de seguridad de versiones anteriores de SQL Server era que no soportaba seguridad a nivel de renglones (row-level security) para restringir que ciertos usuarios sólo tuvieran acceso a un determinado rango de datos. Esto es clave en escenarios multi-tenant. SQL Server 2016 ya soporta esto.

Otra capacidad interesante es el cifrado transparente ("transparent queryable encryption"). Los datos se guardan cifrados en la base de datos, y se mantienen cifrados a través del canal de comunicación, y solo son descifrados hasta que llegan a la aplicación final (el driver se encarga de hacer el cifrado y descifrado). Esto tiene dos ventajas: Si los datos son extraídos del servidor o captados en la red por un atacante, los datos estarán cifrados; la segunda ventaja es que al hacerse el cifrado y descifrado en el mismo punto, se pueden utilizar algoritmos de llave simétrica, que son mucho más rápidos. Este cifrado se puede configurar a nivel de columnas individuales.

Compatibilidad con herramientas de Big Data

SQL Server 2016 tiene muy buenas capacidades de interoperación con herramientas de analytics y big data. Entre ellas:

Soporte a R - SQL Server 2016 incluye soporte para R, permitiendo que los científicos de datos puedan realizar experimentos de datos directamente sobre las bases de datos, sin necesidad de exportar hacia archivos de texto. De la misma manera, los desarrolladores pueden programar stored procedures que incluyan código R para hacer analítica compleja de forma estandarizada y parametrizada, lo cual fomenta su reutilización.
Polybase - Un conector para integración con Hadoop. Permite interactuar con datos en Hadoop desde SQL Server de forma sencilla, sin necesidad de entrar en detalles de HDFS o MapReduce ni usar un ETL. Polybase no es una tecnología nueva, ya se ofrecía como parte del Microsoft Analytics Platform System, y ahora se incluye en SQL Server 2016.
Soporte a JSON - SQL Server 2016 permite que los resultados de un query se exporten como JSON, y también permite tomar un JSON e importarlo como SQL hacia una tabla.

Extender datos a la nube

SQL Server 2016 está diseñada para aprovechar las ventajas de la nube. Un reflejo de esto es la capacidad "stretch". Esto permite que podamos elegir qué partes de nuestra base de datos pueden almacenarse en la nube, en lugar de nuestro data center local. Todo esto se hace de forma transparente para el usuario y el desarrollador. El administrador de base de datos simplemente define las políticas bajo las cuales los datos se pueden poner en la nube (ej. datos más viejos o con menor riesgo) y SQL Server gestiona esto de manera transparente. Al realizar un query, SQL Server se encarga de traer los datos donde quiera que estén, ya sea en la base de datos local o en la nube, y entregarlos como un solo conjunto de resultados. Esto se puede combinar con la capacidad de cifrado de punta a punta, de manera que los datos que se extienden hacia la nube siempre están cifrados.

Futuro y conclusiones

Para algunas empresas, el principal problema de SQL Server no es el producto como tal sino el hecho de que solo funcione sobre Windows. La buena noticia es que hace un par de meses Microsoft anunció que se está trabajando para crear una versión de SQL Server para Linux. Ese producto todavía no está listo y se espera que sea lanzado hasta mediados del 2017. Aun así, vemos esto como una señal positiva de hacia dónde van las cosas.

En general, podemos decir que SQL Server tiene un conjunto muy atractivo de nuevas capacidades, y tiene un rumbo prometedor.

Bio

Pedro Galván es cofundador y director editorial de Software Guru.

Conociendo Docker

sg — Fri, 19 Sep 2014 23:13:16 +0000

Conociendo Docker sg Fri, 09/19/2014 - 18:13

Publicado en

SG #45

Novedades

Autor

Borja Burgos

Docker, hoy en boca de todos, nació en Marzo de 2013 como un proyecto “open source” de dotCloud, startup que por aquel entonces era un proveedor de PaaS al estilo de Heroku. En tan solo 18 meses Docker se ha convertido en uno de los proyectos más populares en GitHub. El proyecto ha sido tan exitoso, que dotCloud mismo pasó a llamarse Docker, Inc. y en Junio de 2013 organizaron la primera conferencia DockerCon en San Francisco con el apoyo de compañías como Google, RedHat o Rackspace.

Pese a todo esto, todavía existe mucha confusión acerca de qué exactamente es Docker, qué aporta sobre tecnologías existentes, la razón de su éxito, y lo más importante, por qué lo necesitamos y cómo va a cambiar nuestra manera de desarrollar, construir, probar y desplegar nuestras aplicaciones de software.

Contenedores: un concepto simple

Docker es, en esencia, un intento exitoso por estandarizar la tecnología de contenedores de Linux de la que hemos gozado en los últimos años. Para explicar lo que es un contenedor de software, el equipo de marketing de Docker acostumbra usar la analogía de un contenedor de mercancías. Pero dado el perfil de la audiencia de SG, tal vez resulte más familiar para todos nosotros pensar en otra analogía: la máquina virtual. Si pensamos que el sistema operativo que se ejecuta dentro de una máquina virtual está siendo “engañado” para que piense que corre en su propio hardware, entonces la analogía resulta sencilla. Una aplicación o proceso que corre dentro de un contenedor también está siendo “engañado” para pensar que corre dentro de su propio sistema operativo. Al igual que con las máquinas virtuales, donde el hardware que el sistema operativo “ve” no tiene por qué ser el mismo que el hardware que existe en la realidad, un contenedor puede “ver” un sistema operativo distinto al del sistema operativo donde se está ejecutando. Cabe destacar que, pese que existen similitudes entre ambos, un contenedor resuelve cuellos de botella de software, mientras que una máquina virtual resuelve cuellos de botella de hardware. Ambos son complementarios, y no excluyentes.

¿Y qué tipo de problemas resuelven los contenedores? Seguro que todos en algún momento de nuestras carreras nos hemos topado con el problema de una aplicación que corre satisfactoriamente en un servidor (virtualizado o no), pero se comporta erráticamente en otro. O el código de un desarrollador, que funciona en su computadora, pero luego falla cuando lo mandamos al entorno de “staging” o producción. Esto se debe a que dos copias exactas de una misma aplicación se comportan de manera distinta en dos entornos con configuraciones distintas. La falta de una dependencia, como una librería, o que exista pero con una versión distinta, o que una variable de entorno sea distinta, o incluso que la versión del sistema operativo varíe puede ocasionar que nuestra aplicación deje de funcionar correctamente. Docker resuelve este problema de manera elegante, con Docker empaquetar aplicaciones en contenedores autosuficientes es una tarea sencilla. Una vez que tenemos la aplicación en un contenedor, desplegarla es una operación rápida y ligera, independientemente del tipo de servidor, del sistema operativo (sólo Linux, eso sí), o del proveedor de infraestructura que utilicemos. Y porque la aplicación, configuración y todas sus dependencias están “contenidas” en el contenedor, dejamos de preocuparnos por versiones y configuraciones de librerías, sistemas operativos, servidores de aplicaciones, etcétera. Se podría decir que desplegar una aplicación con Docker es análogo a instalar una aplicación móvil en un celular corriendo Android o iOS. La instalación es trivial para el usuario. Una vez desplegado el contenedor, las aplicaciones exponen servicios e interfaces al sistema operativo y a otras aplicaciones que deseen hacer uso de ellas. Las aplicaciones que corren dentro de un contenedor quedan a su vez aisladas del sistema operativo donde corren.

Un ecosistema en crecimiento

Además de las herramientas y la tecnología “open source” que facilitan a desarrolladores y administradores el empaquetar y desplegar sus propias aplicaciones, Docker, Inc. también ha lanzado un servicio online llamado Docker Hub (http://hub.docker.com). Éste se está convirtiendo en un repositorio público de aplicaciones open source. Al día de hoy cuenta con más de cien mil imágenes públicas. Por ejemplo, en Docker Hub encontraremos imágenes de aplicaciones populares como bases de datos MySQL, PostgreSQL, MongoDB, ... o aplicaciones CMS (Content Management System) como Wordpress, Drupal o Joomla. Es gracias a este repositorio de imágenes públicas que instalar una aplicación open source en nuestro servidor es tan sencillo como instalar una aplicación en nuestros celulares.

Sin lugar a dudas, el elevado número de beneficios y las casi inapreciables desventajas de utilizar contenedores para nuestras aplicaciones harán que esta tecnología se convierta en el estándar a la hora de empaquetar y desplegar nuestras aplicaciones en la nube. Conoce más sobre Docker en https://www.docker.com

Bio

Borja Burgos (@borja_burgos) es un emprendedor, ingeniero y hacker que disfruta diseñar y construir soluciones para problemas nuevos y existentes. Actualmente es CEO de Tutum, empresa proveedora de servicios de hosting para contenedores Docker. https://www.tutum.co

Novedades

Desarrollo de Aplicaciones Móviles con NativeScript

Publicado en

Autor

Conociendo NativeScript

¿Cómo funciona NativeScript ?

NativeScript Runtime

Invocando código nativo

NativeScript CLI (command line interface).

TypeScript

Angular 2

Componentes UI para NativeScript

Estatus actual y futuro

Tags

Guía de Arranque para VR con Oculus y Leap Motion Orion

Publicado en

Autor

Prerrequisitos e instalación básica

Leap Motion Orion en Unity

Integrando Leap Motion a tu escena

Conclusiones

Novedades de SQL Server 2016

Publicado en

Autor

Desempeño

Seguridad

Compatibilidad con herramientas de Big Data

Extender datos a la nube

Futuro y conclusiones

Conociendo Docker

Publicado en

Autor

Contenedores: un concepto simple

Un ecosistema en crecimiento