Posts Tagged ‘nodejs’


Esta es una continuación de la serie sobre desarrollo en móviles que comencé aquí. Les recomiendo comenzar a escribir el código fuente desde la parte 1 ya que no se publica el código para descarga.

En este punto debemos hacer un repaso y considerar algunos puntos que potencian la aplicación.

Primero, comencemos que el código está disponible en Github en la siguiente dirección:

https://github.com/victorpease/SuperDatos

Para que comiencen a verlo funcionar tendrán que seguir los siguientes pasos:

  1. Crear una cuenta en cloudant.com
  2. Crear una base de datos
  3. Crear una key en la sección de permisos y asignarle permisos de Writer
  4. Actualizar la key y la clave en el archivo services.js
  5. Actualizar la url de la base de datos también en el archivo services.js

Con esto ya podrán tener funcionando su propio lector de noticias y verán que cada vez que alguien lea una noticia, un registro será añadido a la base de datos y podrán con esa información hacer reportes sobre las noticias más populares, que luego podremos incluir como un reporte en la misma aplicación.

Bien, ahora los consejos:

  • Hasta ahora hemos considerado la sincronización Live, pero tengan en cuenta que genera mucho tráfico y por lo tanto costo, además, el cobro es por transacción, así que no importa mucho el tamaño de la base de datos. En Cloudant dan gratis un saldo de 50 dólares y eso es bastante, pero para una aplicación seria esto se puede salir de control. Lo mejor es que desactiven Live y que sincronicen manualmente cuando ocurra algún evento relevante. Para que vean la diferencia, Live sincroniza datos cada 25 segundos, así que si cambian que la sincronización sea cada 1 minuto, ya estarían bajando su consumo a la casi la mitad.
  • Si pensamos en este modelo “Offline-First”, es porque no confiamos en el acceso a la red. El mayor impacto es la primera sincronización. Piensen en usar el plugin PouchDB Load, que permite que hagan una carga inicial de datos en el móvil en lugar de esperar los datos de la red. El archivo de texto tiene que ser generado mediante el plugin PouchDB Dump Cli.
  • En el código actual tenemos un estado llamado Splash donde podemos ejecutar todas estas acciones  de inicialización antes de entrar a la aplicación.

Sobre las vistas:

  • Las vistas en PouchDB se generan la primera vez que las llamamos, por lo que pueden demorar un poco mas de lo normal durante la primera vez. Ante esto, pueden controlar que la vista se genere de forma automática sobre todo durante la primera sincronización mediante la siguiente línea:
    pouch.query('vista', {stale: 'update_after'});
  • Hasta ahora hemos usado Map/Reduce para las vistas, y puede ser algo confuso. La alternativa principal es utilizar los índices, no hay nada mas simple y más rápido. La otra alternativa es utilizar PouchDB Find, que es el futuro de las consultas en todo el ecosistema CouchDB. Personalmente, aun me gusta más Map/Reduce aunque sea algo confuso y limitado por una razón: PouchDB Find es simplemente una máscara que hace las cosas fáciles, pero no agrega velocidad.
  • Finalmente, ya les había mencionado que las vistas ocupan sitio

Sobre los límites de espacio:

  • PouchDB maneja varios métodos para almacenar los datos siendo WebSQL (sqlite) y IndexedDB los disponibles en los móviles, estando igualmente sujetos a las restricciones de espacio del navegador del sistema. Aquí pueden revisar los límites . Un truco es utilizar el plugin SQLite que les permite saltarse esos límites y tener un almacenamiento casi ilimitado. Entiendan que esto es solamente recomendado cuando su base de datos esté por los 50 mb. Además, aún tiene algunos problemitas con las vistas.
  • IndexedDB es la alternativa estándar, de hecho WebSQL ya no es mantenido. De hecho es bastante rápido, además que IndexedDB no es tan fácil de abrir que WebSQL, así que les da un nivel de seguridad a los datos.

Sobre la seguridad:

  • Los que utilizan SQLite en Android están acostumbrados a ponerle una clave a la base de datos para protegerla. Esto no está disponible en el modelo Híbrido pero pueden usar el plugin Crypto Pouch que nos permite encriptar los datos.
  • CouchDB tiene usuarios y Cloudant también puede manejar algo parecido. Pueden acceder a esta lista de usuarios mediante el plugin PouchDB Authentication. Recuerden que esto significa que la red es necesaria. Personalmente, prefiero hacer un servicio externo que autentique y que distribuya las key y pass de Cloudant.

Modelamiento:

  • Modelar en NoSQL no es igual que en Relacional, pero hay trucos. Personalmente, prefiero el modelo minimalista de NoSQL pero existe un plugin Relational Pouch que permite utilizar la misma estructura relacional

Finalmente, como verán en algún comentario que hice, pueden tener toda su lógica en la aplicación cliente, siempre y cuando se quieran pegar al modelo “Offline-First”, pero si es que necesitan operaciones en línea, necesitaran de una capa más de lógica.

NOTA Principal: El problema principal con CouchDB y obviamente con Cloudant, es como integrarlo con nuestras bases en SQL. Es un trabajo en progreso en realidad, y no hay una herramienta porque en CouchDB el modelamiento está en función de la velocidad y de la aplicación que va a utilizar los datos, y eso puede ser muy diferente a lo que tenemos en SQL donde se programa para tener consistencia. Hay tantos modelos y tantas transformaciones posibles que una herramienta no puede hasta ahora hacer el trabajo. Felizmente, no es tan complicado porque ya en la base de datos hemos usando db.changes() , Así que el flujo sería:

  • Lenguaje recomendado: Python ( tiene una gran librería de acceso a Cloudant). También pueden usar NodeJS
  • Un script accede a la base de datos SQL y crea los documentos en Cloudant uno por uno según el modelo que hayamos fijado. Podemos cruzar dos tablas para crear documentos Maestro-Detalle siempre que no sean muchos detalles. No es tan rápido y lo ideal es usar BulkDocs para insertar por lotes.
  • Luego se invoca el comando db.changes()  donde cada documento cambiado es actualizado a la base de datos. Otra vez, puede ser como un insert, delete o update, todo depende de como sea su modelo.

Hasta ahora, todo esto es a medida por lo que mejor es que practiquen sus habilidades en NodeJS o Python.

Advertisements

Si eres programador y sobre todo fanático de las herramientas que se instalan y ya funcionan, te habrá pasado alguna vez que sin razón alguna, uno de esos programas deja de funcionar como debe, sin que haya ocurrido problema alguno. Muy probablemente, lo que ha pasado es que se hayan malogrado tus variables de entorno, en especial la variable PATH.

Desde tiempos de DOS, las variables de entorno fueron un tema crítico. Configurar adecuadamente tu autoexec.bat y tu config.sys era básico para todo usuario que empezaba a usar mouse o que tenia la suerte de tener módulos de memoria adicional, querias crear discos virtuales o simplemente querias jugar Accolade o Digger en colores en tu super modern monitor CGA.

Para la gran mayoria de usuarios finales, estos conceptos simplemente son innecesarios porque la evolución de Windows es manejar todo en la parte gráfica y de preferencia en forma automática. Para los programadores la cosa es diferente porque simplemente no todo lo que usamos es visual.

Para tener en cuenta:

  • Las variables de entorno no tienen un máximo de longitud por si mismas, pero si todo el bloque de entorno. Además, ya que no hay ni un autoexec.bat (windows antiguo) o init_profile (Linux) tienes que ir a esta pantalla para organizar tus variables de entorno

environment

  • En este artículo se explica de forma práctica como es eso del límite en las variables de entorno, pero lo más importante es que nos dice que ya que si estamos usando esa pantallita que graba todo en el registro, hay un límite de longitud de 2048 caracteres. ¿Podría ser mas largo? si, teóricamente podríamos llegar hasta 32000 caracteres pero por usar el registro y la pantalla esa, no hay mas.
  • Las variables de entorno pueden llenarse y nadie te va a avisar. Por lo general los nuevos valores se agregan al final, pero he visto que algunos programas agregan valores al inicio. Consecuencia: rutas borradas de la variable
  • PATH es una variable de entorno muy importante, incluso programas “visuales” la siguen usando. Ademas, hay otras como JAVA_HOME,ADT_HOME y otros que afectan increiblemente el funcionamiento de algunos programas y si has llegado hasta aquí es porque eres programador y sabes de lo que hablo.

Con todo esto en la cabeza, pues será muy lógico seguir estos consejos:

  • Guarda un backup del contenido de tus variables de entorno. Si te toca jugar con Java, Perl, Ruby, Python y esas cosas pues te toca cuidar tus variables de entorno como oro.
  • Instala tus programas mas importantes en carpetas con nombres cortos. Hasta ahora odio al cliente de SQL server porque instala sus cosas en rutas larguisimas que van directo al PATH, mal.
  • Si tienes una ruta larga que se repite varias veces, crea una variable de entorno. Por ejemplo:
    • Tiene que agregar las rutas ‘c:\ruta muy larga\sub carpeta mas larga aun\bin’ y ‘c:\ruta muy larga\sub carpeta mas larga aun\tools’.
    • Crea la variable LARGO con valor ‘c:\ruta muy larga\sub carpeta mas larga aun’
    • A la variable PATH agregarás: %LARGO%\bin y %LARGO\tools

¿Porqué pasa todo esto? porque Windows incluso en la version 10, está orientado a la interacción visual, y un programador está orientado a todo tipo de interacción. En los sistemas operativos basados en Linux como Ubuntu o Mac OSX, esto de la configuración del entorno es pan de cada día y directamente a los archivos, en este caso no hay una pantalla tan amigable como la que tiene Windows que sin querer impuso el límite de 2048 caracteres.

Así que ya sabes, si por ahí tu Android SDK no funciona o tu Perl dejó de trabajar, revisa la variable de entorno PATH que seguro algún instalador la modificó.





%d bloggers like this: