Archive for Desarrollo web

Agosto 10th 2016

Arquitectura del software y sus beneficios

Número de lecturas: 1320
{lang: 'es-419'}

¿Qué es la arquitectura?

La RAE define la arquitectura como:

1. f. Arte de proyectar y construir edificios.
2. f. Diseño de una construcción.

Aplicándolo al mundo del desarrollo de software podríamos redefinir arquitectura del software como:

1. f. Arte de proyectar y construir aplicaciones informáticas.
2. f. Diseño de una aplicación informática.

La definición que le damos a arquitectura viene del mundo de la construcción pero viene a significar lo mismo en nuestro mundo, solo que nosotros no construimos edificios, construimos software.

Una arquitectura define la forma de trabajar en un sistema, como construir nuevos módulos, pero también debe dejar intuir el tipo de aplicación que describe. Tal como comenta Uncle Bob, si mostráramos un dibujo arquitectónico de una iglesia o de un piso, simplemente con ver la forma que tiene ese dibujo podemos intuir que tipo de edificio está proyectando. Así pues, si observamos nuestro dibujo arquitectónico de software deberíamos de poder intuir qué tipo de aplicación va a ser construida. No es lo mismo una aplicación que controla un hospital que una aplicación de un cajero automático, cada una tendría un dibujo arquitectónico distinto.

Sin embargo, el dibujo arquitectónico en la construcción no deja claro los materiales con los que está hecha, así mismo en el dibujo arquitectónico de nuestro sistema no deberíamos dejar escapar detalles de nuestra implementación.

Así pues, considero el dibujo arquitectonico en un proyecto de software la propia estructura de modulos y carpetas o paquetes en el caso de Java o cualquier añadido que ayude a expresar la intención de nuestro sistema sin expresar el cómo está hecha.

Uncle Bob además define una serie de “arquitecturas limpias” que tienen una serie de objetivos en común:
1. Independiente de los frameworks. La existencia de esta forma de construir cosas en el sistema no depende de un framework.
2. Testable. Tu arquitectura hace que tu código pueda ser testado.
3. Independiente de la UI. Tus reglas de negocio no se ven alteradas por un requerimiento de UI, cuando desarrollas una funcionalidad nueva es la UI la que se adapta a tus reglas de negocio y nunca al revés.
4. Independiente de la base de datos. Puedes cambiar el motor de persistencia ya que tus reglas de negocio no son dependientes de la implementación concreta de la base de datos sino que es la base de datos la que se adapta a estas reglas.
5. Independiente de cualquier componente externo. Se aplica la misma regla descrita en la base de datos pero relacionada a componentes externos así como integraciones con otros sistemas, librerías, etc…

Si una arquitectura cumple estos objetivos podría entrar en el grupo de arquitecturas limpias.

Casos de uso

Un caso de uso es una acción que un usuario o agente externo realiza en nuestro sistema. Se nombran siempre con un verbo + nombre. Si estuviéramos desarrollando una aplicación en la que se venden productos, ListarProductos sería un nombre válido así como ComprarProducto.

Una manera común de identificar la intención de nuestro sistema es modelarlo en base a sus casos de uso. Son la forma de acceder a las reglas de negocio de nuestra aplicación, por lo tanto podríamos decir que representan la parte pública del dominio de nuestra aplicación. Al ser la parte pública hacen de entrada/salida de datos al dominio.

Los casos de uso nos ayudan a expresar con un lenguaje más natural las acciones posibles que nuestro sistema puede realizar y de esa forma listan las funcionalidades del mismo. Un listado de los casos de uso ordenados por funcionalidad nos ayudará a saber de qué trata la aplicación con la que estamos trabajando. Por ejemplo, en Java, si distribuimos los casos de uso separados por paquete de funcionalidad, nos dará esa visión de dibujo arquitectónico de la que hablábamos al inicio del post.

Para hacer la acción hablarán con elementos internos de nuestro dominio tales como servicios u objetos de modelo ricos para que mediante la colaboración de los mismos resuelvan la acción.

Estos casos de uso son pues el elemento de entrada de nuestra aplicación y controlan la secuencia de pasos de los elementos internos con los que colaboran. Para resolver un caso de uso como ComprarProducto quizá en nuestro sistema los datos de entrada tengan que pasar por un objeto validador y en el caso de que los datos sean válidos guardar ese objeto en persistencia, por lo que esos dos pasos estarían correlados en el caso de uso.

Secuencia de caso de uso

Reglas de negocio

Una regla de negocio es un requerimiento del encargado en definir cómo funciona una aplicación, en Agile usamos el rol de Product owner. Definen el comportamiento de nuestro sistema y cómo reacciona a las acciones por parte de un usuario o un agente externo si tuviera que interactuar con otros sistemas. Las reglas de negocio aportan valor al sistema que estamos construyendo.

Como hemos descrito hasta ahora nuestras reglas de negocio son el núcleo de nuestra arquitectura, todo depende de estas reglas, ya que al fin y al cabo creamos software para ofrecer una solución a una una necesidad.

¿Por qué es tan importante separar nuestras reglas de negocio? El software evoluciona, los frameworks, base de datos, librerías que usamos son solo herramientas con las que construimos un sistema, pero tal como van evolucionando, la forma de usarlas cambia o incluso son reemplazadas por unas mejores, será mucho más fácil reemplazar estas nuevas herramientas en nuestro sistema si están lo más aisladas posible.

Existe una única regla para usar una arquitectura limpia, la regla de dependencias. Esta regla expresa que la dependencia entre componentes de nuestro sistema debe de ser desde los detalles de implementación a nuestro dominio y nunca dejar que nuestro dominio conozca estos detalles. Esta es la herramienta que tenemos para aislar lo que realmente aporta valor a nuestra aplicación de la implementación o tecnologías que usamos.

Pero tu Product Owner difícilmente te va a explicar exactamente las reglas de su negocio, seguramente exprese lo que espera encontrar o cómo va a reaccionar la aplicación en determinado caso, somos nosotros los desarrolladores los encargados de traducir su lenguaje y extraer las reglas de negocio y modelar la aplicación en base a lo que llamamos un modelo de datos de dominio, siendo el dominio el negocio del que estamos hablando.

Este arte de transformar una especificación en algo tangible en el desarrollo del sistema es difícil y no tienes que preocuparte de que no sea perfecto en un primer momento ya que es algo que debería estar en continua evolución según se va ganando conocimiento sobre el dominio, a esto lo llamamos refinamiento continuo.

Para hacer este refinamiento continuo tenemos que cambiar partes de nuestro sistema para que reflejen claramente la intención. Un libro que te puede ayudar mucho a entender mejor el modelado del dominio de una aplicación y enseña ciertos “patrones” de como modelar objetos de dominio es Domain Driven Design de Eric Evans. Un libro que cualquier desarrollador debería leer.

Si cambiamos partes de nuestro sistema, deberíamos tener la seguridad de que estamos haciendo cambios sin dañar otras, para eso necesitamos que nuestra arquitectura sea testable.

Testing

Toda esta separación entre reglas de negocio y el resto de partes de nuestro sistema hacen que nuestros componentes sean testables ya que comunicamos las piezas que componen este puzzle con abstracciones. Las abstracciones son nuestros aliados a la hora de componer estas piezas ya que nos proporcionan 2 claras ventajas: dar significado semántico a los colaboradores de una clase e invertir la dependencia para poder mockear un colaborador en test.

Esta inversión de dependencias nos permite también cambiar el detalle de implementación de una clase lo que hace que nuestra arquitectura sea independiente de las herramientas que mencionábamos previamente ya que hay que distinguir entre el qué hacer (abstracción) y el cómo hacerlo (implementación).

Independiente de agentes externos

Nuestra aplicación, como hemos comentado, debe ser independiente de agentes externos tales como frameworks, bases de datos, UI, APIs externas u otros sistemas que no tenemos control. Para cumplir con esta regla debemos tener claro que cualquier agente externo puede ser dañino, ya que en cualquier momento puede ser reemplazado por otro que pueda cumplir con la misma misión en nuestro sistema.

Todo framework o librería que nos haga desarrollar código utilizando formas que no son standards en el lenguaje que estamos desarrollando deberían ser cubiertas con una abstracción, de forma que si en un futuro queremos cambiar esa librería por otra o incluso implementarlo nosotros mismos lo podamos hacer solo haciendo un cambio en cómo se crea la implementación para esa abstracción

Esto es aplicable también a otros agentes externos tales como bases de datos, que solo cumplen una misión en nuestro sistema, que es persistir objetos. Nuestro sistema solo está interesado en persistir el objeto X pero no en la forma en la que está implementado. Por eso mismo una abstracción nos da también semántica a nuestro código, porque la abstracción en este caso se llamaría XDataStorer y podría ser implementada de múltiples formas dependiendo de la tecnología que queramos usar.

Conclusión

Implementar una arquitectura nos ayuda a entender mejor de qué trata nuestro software, a centrarnos en el dominio de nuestra aplicación, que es el valor real y que al fin y al cabo es la razón que nos lleva a escribir software. Implementar un modelo rico basado en nuestro dominio hace que todos los miembros del equipo tengan el mismo vocabulario y fuerza a ponerle nombres a conceptos por lo que facilita el entendimiento. Nos facilita también que nuestro código sea más mantenible, testable y en consecuencia nos ayuda a cumplir con los principios SOLID.

Fuente:

devexperto.com

Agosto 3rd 2016

Desarrolla tu app básica a la velocidad de flash

Número de lecturas: 2483
{lang: 'es-419'}

Crear una app móvil a veces puede conllevar un proceso muy complejo y tedioso, pero puede traer grandes beneficios para un negocio. 

Ionic nos facilita este proceso puesto que no es necesario poseer amplios conocimientos sobre programación nativa de aplicaciones, de modo que con HTML, JS, CSS y algunos conocimientos de AngularJS podemos tener nuestra propia app en pocas horas.

Aún no sabes qué es una app Híbrida

Ionic es un Framework de desarrollo de aplicaciones móviles HTML5 dirigida a la creación de aplicaciones móviles híbridas.

Las aplicaciones híbridas son esencialmente pequeños sitios web que se ejecutan en el navegador del dispositivo,y ejecutan una aplicación que tiene acceso a la capa de plataforma nativa. Las aplicaciones híbridas tienen muchas ventajas sobre las aplicaciones nativas puras, específicamente en términos de soporte de la plataforma, la velocidad de desarrollo.

Para la creación de la mismas se usan frameworks basados en lenguajes de programación web como HTML, CSS y JS,o AngularJs para desarrollos más complejos

¡En nuestro caso el framework será Ionic!

Ionic no es sólo un marco HTML 5, si no que además define directivas y servicios Angular, estilos e incluso un conjunto de herramientas de terminal, que necesita una envoltura nativa  (“un puente de javascript a nativo”) como Cordova o PhoneGap con el fin de funcionar como una aplicación nativa.

Actualmente la fluidez y el tiempo de respuesta no es igual al de una app nativa pero van camino de conseguirlo, de hecho es uno de los principales objetivos de Ionic(en su web dicen estar obsesionados por el rendimiento). Y podríamos decir que  es cierto puesto que desde los inicios de ionic hasta ahora se aprecia un gran aumento en la fluidez y capacidad de procesamiento de las aplicaciones generadas.

Para ampliar información sobre el concepto de app híbrida podéis mirar aquí.

Vayamos a lo importante, qué es Ionic

Ya sabemos que es un app híbrida, así que ahora vamos a ver qué es Ionic.

Ionic es un framework libre y de código abierto, que proporciona la optimización para dispositivos móviles de HTML,CSS y JS, proveyendo de las herramientas necesarias para crear un aplicación básicamente con estos 3 lenguajes. Ionic está construido con Sass y optimizado por AngularJS.

*http://ionicframework.com/


El grueso de una aplicación IONIC se basará en HTML, Javascript y CSS. Los desarrolladores que quieran adentrarse más en el mundo Ionic  también podrán trabajar en la capa nativa, creando plugins personalizados con Cordova o código nativo, pero no es necesario para obtener una gran aplicación.

Ionic utiliza como envoltura nativa (“un puente de javascript a nativo”), Cordova, lo que significa que en su
núcleo es una aplicación PhoneGap con el fin de funcionar como una aplicación nativa.

Ionic también utiliza AngularJS para una gran parte de la funcionalidad básica del framework. No es totalmente necesario conocer angular,pero sí se recomienda invertir tiempo en aprender, ya que es una de las mejores maneras de construir aplicaciones basadas en navegadores de hoy.

No es una app nativa pero a pesar de ello sigue el modelo de desarrollo de un app móvil nativa, por lo que es fácil de entender para cualquier persona que ha construido una aplicación nativa para iOS o Android. De aquí surge el término platform continuity del que podemos saber más e este artículo que te dejo aquí.

Por qué híbrida y no nativa

Ya hemos visto muchas de las ventajas que aporta Ionic, ahora veremos algunas más.
Desarrollamos un código único multiplataforma de modo que con nuestra base HTML, CSS, JS y AngularJS podremos generar nuestra app tanto para Android como para iOS.Lo que nos aporta rapidez y eficiencia en el desarrollo.

Se trata de código abierto mantenido por una comunidad muy amplia de desarrolladores y respaldado por el propio Ionic.

Documentación y API sencilla. El código y los distintos componentes de Ionic está muy bien explicados y documentados los que nos ayuda en gran medida.

La velocidad del desarrollo es notable puesto que se basa en tecnologías sencillas pero muy potentes de modo que con poco tiempo podemos hacer grandes cosas.

Como ya hemos visto Ionic tiene una comunidad de desarrollo bastante amplia. Ionic posee un foro para dudas y bugs que puedas tener en tu código donde gente de lacomunidad o los propios desarrolladores de Ionic pueden ayudarte.

*http://ionicframework.com/

Vamos a aprender Ionic

Ejemplos. Si te surge alguna duda durante este tutorial o después de leerlo hay numerosos tutoriales, demos y ejemplos por toda la red con los que aprender Ionic.

Foro/comunidad. Si nos surge un problema seguro que le haya ocurrido a alguien antes así que seguro podrán ayudarte

Si tienes alguna duda no dudes en hacerlo los comentarios de este post 😉
Algunas páginas que podrían ayudarte son estas:

Manos a la obra

Bueno vamos a lo importante  cómo creamos un app con Ionic desde la base.

Primero vamos a instalar los paquetes necesario, en esta sección veremos cómo hacerlo en un sistema Linux.

Debemos instalar node.js y cordova.

Node

 $ curl -sL https://deb.nodesource.com/setup_0.12|sudo bash -
 $ sudo apt-get install nodejs
 $ sudo apt-get install -y build-essential

para comprobar que está instalado

 node -v

Cordova

$ sudo npm install -g cordova

Bower

$ sudo npm install bower -g

Ionic

$ sudo npm install -g ionic

En esta web tenemos las instrucciones necesarias para instalar el módulo androidpara poder generar las apps para esta plataforma (adb y sdk):
http://cordova.apache.org/docs/en/3.4.0/guide/platforms/android/index.html#Android%20Platform%20Guide

Para iOS:
http://cordova.apache.org/docs/en/3.4.0/guide/platforms/ios/index.html#iOS%20Platform%20Guide

¿Tienes todo listo?

Pues vamos a comenzar a desarrollar con Ionic. Pasaremos a crear el proyecto.

 Aquí podemos optar por tres tipos de starter para la app, una app en blanco, una basada en pestañas, y por último una basada en menú lateral. Para ello debemos hacerlo desde la terminal ejecutando los siguientes comandos:

*http://ionicframework.com/

Generará  el siguiente árbol de directorios:

bower.json     // dependencias bower
config.xml     // configuración cordova
gulpfile.js    // tareas gulp
hooks          // configuración cordova para ejecutar comandos específicos
ionic.project  // configuración ionic
package.json   // dependencias de node
platforms      // construcción del código para iOS/Android
plugins        // donde tus plugins cordova/ionic se instalarán
scss           // código scss,donde se obtendrá la salida para www/css/
www            // app – código JS and libs, CSS, imágenes, etc.

Ya tenemos la base para nuestra app ya sólo tenemos que personalizarla con los elementos Ionic que deseemos.

Generar y compilar nuestra app.

Entramos en el directorio que previamente hemos creado para almacenar nuestra app:

$ cd myApp



Añadimos la plataforma del tipo de app que deseamos emular:

$ ionic platform add ios / $ ionic platform add android

 



$ ionic build ios / $ ionic build android

 



$ ionic emulate ios / $ ionic emulate android

 



Si queremos probarla directamente en nuestro dispositivo, conectándolo a nuestro pc podemos instalarla de forma directa ejecutando:

$ ionic run ios / $ ionic run android

 



También podemos probarla en el navegador de nuestro pc de desarrollo con:

$ ionic serve -scss

 



Bueno una vez tenemos la base de nuestra app, solamente tenemos que personalizar como queramos añadir componentes, añadir secciones y páginas a nuestra app, etc.

Trabajaremos básicamente sobre el directorio /www/ que nos crea automáticamente. y ahí añadiremos nuestro o código o modificaremos a nuestro antojo el que nos genera Ionic. Si queremos añadir vistas debemos modificar el fichero /www/js/app.js


Para modificar el aspecto es aconsejable usar las clases que el propio Ionic proporciona, pero si aun así queremos modificar el aspecto podemos modificar /www/css/style.css.

Nuestras plantilla debemos añadirlas en /www/templates y añadirlas en el /www/js/app.js.

Por último nuestras imágenes o archivos externos podemos añadirlos en /www/img/, también podremos añadir los directorios que necesitemos pero en principio bastaría con eso.

Tunea tu app

Además de crear tu app, hay diversos temas que podremos acoplar a nuestra aplicación para cambiar su aspecto. Aquí veremos IonicMaterial de Zach Fitzgerald. Podemos ver como añadirlo en http://ionicmaterial.com/ y un ejemplo de ello en http://ionicmaterial.com/demo/.

En esta web:


podemos descargar un modelo base para crear nuestra app. En que tenemos una demo de juego de tronos y una demo con los distintos componentes

         


Nosotros hemos modificado este ejemplo  y le hemos dado nuestro toque mobile haciendo solamente unos cuantos cambios y nos ha quedado así.

Ahora…¡A darle vida a nuestra app!

Además de las funcionalidades básicas hay plugins o addons que pueden complementar nuestra app aportando más funcionalidad a nuestra app.

Aquí podemos encontrar algunos.
https://market.ionic.io/plugins

O simplemente describiendo la funcionalidad brevemente en google seguido de la palabra Ionic plugin podremos encontrar el plugin que buscamos.
Los pluglin los podemos instalar:


$ ionic plugin add

 



$ cordova plugin add

 



Hemos visto las nociones básicas de cómo hacer una app híbrida con Ionic.

Fuente:

intelligenia.com

Agosto 3rd 2016

Propuesta de una metodología para el proceso de Migración de Datos en entornos empresariales

Número de lecturas: 2379
{lang: 'es-419'}

Por razones de trabajo me he visto en la necesidad de revisar alguna documentación adicional que permita identificar algunos casos de menos registros pero con importantes lecciones.

Download (PDF, 351KB)

Información adicional:

Migración de Datos

Mayo 31st 2016

Tu oficina en casa

Número de lecturas: 1653
{lang: 'es-419'}

Si eres un autónomo, un freelance, o simplemente alguien que tiene la necesidad de atender sus asuntos desde su propio hogar este post te interesa. El entorno de trabajo afecta de forma determinante nuestra productividad. Tanto si trabajas, desarrollas proyectos personales, o dedicas tiempo a una afición, necesitas definir un espacio para centrarte y sacar el mayor rendimiento a tu tiempo y energía. En las siguientes líneas hablo de algunas pautas para crear nuestra oficina en casa, dedico el post a hablar a todos aquellos que pueden disponer de un espacio propio, a los que no ya hablaremos sobre el tema en próximos posts : )

El primero, y más importante, es crear una separación entre el lugar de trabajo y donde realizamos nuestra vida personal. Si somos profesionales freelance o autónomos lo ideal sería contar con una oficina externa a la vivienda, ya que muchos no nos podemos permitir ese lujo, tendremos que crear una serie de costumbres que fijen una separación – mental – entre el espacio profesional y personal.

Cuando entremos en nuestro espacio será para trabajar, o para hacer algo relacionado con el trabajo. Nada de tiempo de relax, ni escuchar música, ni videojuegos etc… Lleva la costumbre al límite: reserva tu archivo para temas del trabajo, evitarás las interrupciones de terceras personas que vienen a buscar no se qué documento, o vete a saber qué libro. Que los niños no entren, nada de jugar con el ordenador, ni utilizar los recursos de la oficina. Si ves este punto difícil marca unas horas determinadas dejándolos con claridad que sólo se entra para trabajar y que lo que hay allí son herramientas, no juguetes.

Nos rodearemos de lo indispensable para trabajar, apartando todo aquello que no tenga una razón funcional. Todo lo que escape a este principio nos distrae y nos empuja hacia una zona de dispersión, donde nuestra productividad baja y la calidad de nuestro trabajo se diluyen. Extiende este principio a los recursos que uses en tus ordenadores.

Podemos conservar fotografías de la familia o algún recuerdo, pero te recomiendo que no los tengas en tu escritorio, te pueden llegar a hacer perder el hilo de lo que estás haciendo. Por ejemplo si miras las fotos de tus hijos, o tu mujer, la carga sentimental te puede hacer pensar en temas/problemas familiares que tengas en ese momento.

Para mantener la fuerza de la simplicidad y que ésta se convierta en eficiencia crea la costumbre de ubicar tus herramientas en un mismo lugar, para que cuando las necesites no tengas que realizar la acción ‘buscar herramienta’. Crea el hábito de devolver las herramientas a su lugar al final de cada jornada, o cuando ya las hayas utilizado y no las necesites más.

Ordenar periódicamente nuestro despacho nos ayudará a mantener el orden y la pulcritud. Aparte de la indispensable limpieza semanal, debemos establecer revisiones periódicas de nuestro archivo físico y virtual para evitar que en lugar de ordenar, se convierta en un emplazamiento donde acumular o apilar. La sedimentación de documentación no es una buena forma de almacenar tu información.

Convierte tu emplazamiento en un lugar atractivo, donde te resulte fácil estar. Más allá de la mención a la simplicidad del entorno, podemos crear una office at home con cierta sofisticación y simplicidad, sólo con una capa de pintura, con una buena combinación de colores y cuatro detalles, crearemos nuestro espacio en casa. Si no quieres, o no puedes invertir todo lo que se necesitaría, mi consejo es que te centres en descargar el despacho de todos los muebles innecesarios, reubica los que ya tienes y maximiza el espacio útil sobre el escritorio (un escritorio demasiado ocupado ahoga). Mejora la iluminación del habitáculo, bombillas de bajo coste y luz blanca y un plexo (o similar) para el escritorio.

Aparte de atractivo debe ser un emplazamiento agradable y tranquilo. Si trabajamos en casa nos aseguraremos de que esté suficientemente aislado de la vida familiar. Hablamos de un lugar que hacemos nuestro y que lo dedicamos a trabajo, nuestros proyectos. Si no cuentas con un lugar exclusivamente para ti tendrás que llegar con acuerdos con el resto de la familia, o personal que te acompañe, para crear un ambiente idóneo. Nada de ruido, nada de niños (al menos mientras estés trabajando), y por favor, nada de aquellas costumbres tanto molestas como fumar o comer en el lugar de trabajo. Una oficina no es un bar, aunque sólo estés tú solo trabajando, mantén la costumbre de separar trabajo y otras actividades.

Algo fundamental para crear un entorno agradable, y por tanto favorecer la productividad, es mantener una temperatura constante y una iluminación adecuada. Si descuidamos cualquiera de los dos factores degradará nuestra energía y nuestra atención al trabajo. Trabajar con una mala iluminación puede generar dolores de cabeza, y trabajar con una temperatura inadecuada nos fatiga.

Sólo siguiendo la recomendación de dividir el espacio para la vida familiar y el trabajo, marcando unas pautas de comportamiento para todos los que lo utilizan, simplificando y renovando un poco el entorno, experimentaremos una mejora notable.

Fuente:

http://blog.davidtorne.com/