sábado, 23 de febrero de 2019

Constructores de páginas Web que utilizan el framework Bootstrap

Sin la necesidad de saber escribir código

La realización de páginas Web utilizando constructores en línea se encuentra en pleno auge. Por eso en esta ocasión queremos listarte cinco constructores de páginas Web que utilizan el framework de Bootstrap. Estos creadores Bootstrap soportan la acción de arrastrar y soltar para los diseños Web. Con esta tecnología, puedes crear un completo portal Web o bien un componente específico para tu sitio.

Las capacidades de framework Bootstrap, te dan la posibilidad de crear una página desde cero o bien desde una plantilla, y modificar con su editor cosas como: el estilo, las fuentes, los colores, la escala, los márgenes y otros parámetros. Bootstrap: Es un framework HTML/CSS, JavaScript que dispone de muchas clases para ser utilizadas en código HTML.

SAUL tools

SAUL tools es una herramienta en línea gratuita que utiliza Bootstrap para la creación de páginas Web. La plataforma dispone de algunas plantillas que puedes personalizas, pero también podrás crear un sitio Web desde cero. En la interfaz del entorno encontrarás un potente editor desde donde podrás personalizar el portal mediante las clases de Bootstrap (también puedes manipular el código). Al terminar el trabajo, podrás exportar la página en un archivo ZIP que contiene el HTML, CSS, JavaScript, etcétera. Su editor soportar la acción de arrastrar y soltar para la creaciones de portales Web o secciones específicas (formularios de contacto, etcétera). La plataforma necesita registro.

Muy buena interfaz

Layoutit

Layoutit es un sencillo creador de páginas Web basado en Bootstrap. Te ofrece un editor intuitivo, donde podrás diseñar insertando bloques. La plataforma soporta la acción de arrastrar y soltar. También puedes crear un diseño en cuadrículas, para luego insertar elementos HTML y en JavaScript. Al terminar el trabajo, puedes exportar el código en formato Zip. El servicio no requiere registro o inicio de sesión.

Creador de páginas Web

Bootsnip

Bootsnip ha sido creado para diseñar un elemento específico de una página Web con el framework Bootstrap. Gracias a sus acciones de arrastrar y solar puedes crear secciones, acordeones, carruseles, galerías, páginas de precios, etcétera. Al terminar el trabajo, obtendrás el código HTML. Al solo obtener este lenguaje, tendrás que conectar manualmente el archivo Bootstrap en la sección creada. El servicio no requiere de registro.

Crear formularios

Bootply free bootstrap builder

Bootply es un potente creador de páginas Webs basado en Bootstrap. El único inconveniente de la plataforma es que no podrás descargarte el código creado, pero puedes copiar el código HTML que se encuentra entre las etiquetas <body> </body>. El entorno no soporta la acción de arrastrar y soltar, por este motivo cuando quieras ingresar un módulo, lo tendrás que hacer desde la inserción de bloques de código. Los puedes seleccionar desde un menú desplegable. Para utilizar el servicio no tienes que crearte una cuenta. Para poder descargarte el código y ampliar sus prestaciones tendrás que pasarte a un plan comercial.

Dispone de planes comerciales

Bootstrap 2 Form Builder

Terminaremos con Bootstrap 2 Form Builder, un servicio en línea para crear formularios de Bootstrap. En la gran mayoría de los portales Web se necesitan crear formularios, botones, cuadros de búsqueda, cuadros de texto, etcétera. Lo realizarás insertando diferentes elementos mediante la acción de arrastrar y soltar. Pero lo mejor de la utilidad es que no necesitas escribir una línea de código para crear las secciones. Desde la pestaña “Rendered” puedes descargar el código del elemento creado.

Crear formularios

Con los cinco servicios para crear páginas Web mediante el framework Bootstrap, tendrás diferentes opciones para maquetar sitios Web totalmente Responsive.

viernes, 14 de septiembre de 2018

FUENTE: https://www.campusmvp.es/recursos/post/Que-son-las-Aplicaciones-Web-Progresivas-o-Progressive-Web-Apps.aspx

Qué son las Aplicaciones Web Progresivas o "Progressive Web Apps"

Últimamente se está escuchando mucho una nueva buzzword, PWAs, que se refiere a las Aplicaciones Web Progressivas o Progressive Web Apps en sus siglas en inglés.

Si nos atenemos a lo que se oye, deben de ser lo mejor que se ha visto en desarrollo web desde que se inventó JavaScript, pero ¿qué hay de cierto y qué hay de "hype" en todo esto? ¿Son para tanto o es más una moda?

En este artículo vamos a aprender qué son las Aplicaciones Web Progresivas, qué problemas tratan de solucionar, en qué se basan para hacerlo, el soporte que existe actualmente en los sistemas y si merece la pena tanto revuelo.

Las limitaciones de las aplicaciones web en los móviles

Como sabemos, es posible crear aplicaciones para móviles utilizando desarrollo nativo o bien lo que se ha dado en llamar desarrollo híbrido. Este desarrollo híbrido consiste en crear aplicaciones web pensadas para trabajar en un móvil y luego convertirlas en aplicaciones nativas usando algún envoltorio como Apache Cordova/Phonegap.

Sin embargo, y aunque cueste creerlo a estas alturas, la idea original cuando se lanzó el primer iPhone en 2007 (el dispositivo que marcó la senda de lo que hoy son los móviles), era que las aplicaciones fueran en su mayoría aplicaciones web. El desarrollo nativo tardó todavía 1 año en habilitarse. La idea era crear aplicaciones web, anclarlas a la pantalla de inicio y trabajar con ellas.

Lo cierto es que este concepto no funcionó y hay muy pocas aplicaciones web que funcionen de esta manera. En primer lugar porque casi nadie ancla nada a la pantalla de inicio, pero también porque no son tan ágiles normalmente como las nativas, no tienen un aspecto igual de natural y, sobre todo, porque las aplicaciones web carecen de muchas de las capacidades que se necesitan en una aplicación nativa (trabajar sin conexión, enviar notificaciones, almacenar datos localmente...).

Por supuesto, muchas de estas limitaciones se eliminan si utilizas un envoltorio como Cordova, que ofrece a tu aplicación web acceso al hardware subyacente mediante unas sencillas bibliotecas JavaScript.

Pero si lo que quieres es crear una aplicación web "pura", sin envoltorio, que funcione en un navegador móvil casi de la misma manera que si fuera una aplicación nativa, la cosa es muy complicada.

Es ahí donde entran las AWPs.

¿Qué es una Aplicación Web Progresiva?

Google ha sido el que ha promovido este tipo de aplicaciones. En su página dedicada al tema ofrece una definición breve pero bastante descriptiva de qué es una PWA, que sería más o menos la siguiente:

Una PWA utiliza las últimas tecnologías disponibles en los navegadores para ofrecer una experiencia en móviles lo más parecida a la de una aplicación nativa.

La verdad es que es como no decir nada, y al mismo tiempo decirlo todo.

La idea que transmite esta definición es que los objetivos que debemos buscar al crear una PWA son:

Que tenga el mayor rendimiento posible en móviles y que cargue de manera casi instantánea
Una buena interfaz que se parezca lo máximo posible a una nativa
La posibilidad de trabajar sin conexión
Poder enviar notificaciones a los usuarios, como una app nativa

Básicamente con estas cuatro premisas estaríamos cubiertos, así que detrás de ese nombre lo que hay es realmente una idea sencilla.

Tecnologías que aprovechan las PWA

Vale. Ahora que ya sabemos lo que queremos conseguir, ¿cómo podemos hacerlo?

Para conseguirlo, las PWAs se basan en unos conceptos bastante simples:

Responsive Web Design, animaciones CSS y frameworks específicos para crear interfaces móviles con aspecto de nativas
Service Workers
App Shell
Manifiesto de aplicación

No voy a entrar hoy en lo primero, pero veamos qué es cada una de las otras 3 cosas...

Service Workers

Los Service workers son una tecnología muy interesante y a la vez bastante compleja que nos permite ejecutar servicios en segundo plano en los navegadores.

Van más allá de lo que ofrece un Web Worker. Éstos últimos nos permiten ejecutar código pesado en segundo plano (en un subproceso dedicado) y comunicarnos con ellos, de modo que una o varias tareas largas no bloqueen la interfaz de usuario. Pero los Service Workers son más potentes y complejos, puesto que pueden ejecutarse de manera independiente a la aplicación (es decir, estar en ejecución aunque la página de nuestra app web esté cerrada) y ofrecen capacidades avanzadas como la intercepción de las comunicaciones, el cacheado de información, la descarga en segundo plano de contenidos, el trabajo sin conexión o la posibilidad de enviar notificaciones.

En realidad para algunas cosas no es necesario utilizar un Service Worker. Por ejemplo, es posible crear aplicaciones web que funcionen off-line (sin conexión) utilizando la API de AppCache. El Service Worker nos puede dar más funcionalidad, sobre todo si necesitamos tomar decisiones a la hora de cachear la información y no solo asegurar que se encuentra almacenada, pero no son estrictamente necesarios. Es decir, para crear una PWA no es necesario estrictamente usar Service Workers salvo que requiramos ciertas funcionalidades avanzadas.

En el momento de escribir esto los únicos navegadores que permiten el uso de Service Workers son Chrome (el promotor de los mismos) y Firefox. En el caso que nos ocupa, los móviles, el único navegador móvil que ofrece soporte para esta tecnología es Chrome 51 o posterior en Android. Si queremos que la PWA funcione también en iOS, Windows Phone o teléfonos Android que no sean muy recientes, no estamos de suerte.

App Shell

App Shell no es una tecnología, sino un modelo o patrón a la hora de crear las aplicaciones. La idea es muy sencilla: separar la aplicación entre funcionalidad y contenido y cargarlos por separado.

Lo cierto es que la mayor parte de las aplicaciones de tipo Single Page (SPAs) ya suelen usar una u otra forma de hacer eso.

Lo suyo es tener, por un lado, la aplicación en sí cacheada para uso off-line (con Service Workers o no) de modo que cargue a toda velocidad, y luego el contenido (los datos) que cargue por otro lado, bien de una caché inicial también y luego se actualicen, o directamente desde la web si hay conexión.

Esto, bien realizado, hace que la percepción que tiene el usuario de la velocidad de carga de la app sea mayor. Parece que carga mucho más rápido porque al cargar el "shell" antes de nada y desde una caché, el usuario verá la app enseguida.

En mi opinión no es más que una "buzzword" para algo que cualquier programador preocupado por el rendimiento y la usabilidad ya debería estar haciendo. Pero no está mal que nos lo recuerden y nos "fuercen" a ello si queremos que nuestra aplicación web se pueda considerar "progresiva".

Manifiesto de aplicación

Como comentaba al principio, desde los primeros smartphones como hoy los conocemos, siempre ha sido posible anclar al inicio una página web desde el navegador para luego poder ir directamente a ella. Para controlar el aspecto que tendrá el icono que los usuarios van a anclar es posible utilizar diversas técnicas dependiendo del navegador y el sistema operativo. Así, en iOS o Windows Phone eso se controla a través de unas cabeceras de tipo "meta" que podemos añadir a la página principal de la aplicación web. En el caso de Android y Chrome se utiliza un archivo llamado "Manifiesto" cuyo nombre es manifest.json (que funciona hace años, desde la versión 38 de Chrome en 2014).

Hace poco Google ha hecho que cuando se añade una aplicación al menú de inicio de Android salga un banner de instalación como el de una aplicación real, todo ello conducente a que la experiencia cada vez sea más parecida a la de las aplicaciones nativas. Pero no deja de ser una cuestión cosmética.

Esto, nuevamente, solo funciona con Chrome en Android, así que no sirve de mucho en otros sistemas, aunque todos tienen algo similar para definir el aspecto de los accesos directos.

En resumen

Aunque las PWAs ahora parecen estar muy de moda y pueda parecer que nos quedamos atrás por no "controlarlas", en mi opinión hay mucho de hype detrás de ellas.

Realmente lo más importante y complejo que tienen es el uso de los Service Workers. No obstante hay que tener en cuenta que los usos de esta tecnología son los que son y ya existen multitud de bibliotecas que nos dan muchas de las funcionalidades hechas, y algunos frameworks de desarrollo están metiendo ya la funcionalidad de serie, sin que tengamos que hacer nada.

Que nadie me malinterprete. No quiero decir con esto que las PWAs no sean interesantes o que no haya nada que aprender acerca de ellas. Al contrario. Simplemente quiero desmitificarlas un poco y resaltar que no se trata de una tecnología nueva y maravillosa que acaba de aparecer y que tenemos que aprender desde cero. Es más bien un conjunto de tecnologías pre-existentes, técnicas y patrones sencillos que nos ayudan a conseguir aplicaciones web orientadas a móviles que se comportan cada vez más como aplicaciones nativas.

De momento muchas de las técnicas que necesitan las PWAs solo están disponibles para Chrome sobre Android, y además solo en versiones recientes del navegador, así que la audiencia es limitada. Sin embargo, teniendo en cuenta que Android representa el 85% del mercado de móviles puede que en el medio plazo lleguemos a mucha más gente.

Ahora sería estupendo que el resto de navegadores y sistemas operativos siguieran la estela marcada por Google y dieran soporte para todo esto en su software.

En la página de Google para las Progressive Web Apps puedes encontrar varios ejemplos de aplicaciones web creadas de esta manera así como abundante documentación.

Espero haberte aclarado las ideas alrededor de esta tecnología de moda :-)

sábado, 14 de octubre de 2017

La nueva era de la autentificación: Claims

En noviembre de 2005 con la llegada de ASP.NET 2.0 aparece el primer sistema que unifica la autentificación y autorización de los usuarios, ASP.NET Membership. En él se proporciona un servicio integrado a través de la autentificación de formularios, Form Authentification, y el uso de una base de datos SQL para validar y almacenar las credenciales del usuario y los datos del perfil. Las desventajas principales de este servicio eran que el esquema de base de datos fue diseñado para SQL Server y no se podía cambiar y, además, estaba basado solo en la autenticación de formularios, no dando soporte para inicios de sesión que utilizan proveedores externos como cuentas de Microsoft, Facebook, etc. Microsoft realizó varios avances para mejorar este sistema como fueron ASP.NET Simple Membership o ASP.NET Universal Providers. Pero la mejora más importante vino con el framework ASP.NET 4.5, el sistema ASP.NET Identity.

ASP.NET Identity permite la autenticación basada en notificaciones o claims (claims based authentication), donde la identidad del usuario se representa como un conjunto de notificaciones.

.NET utiliza las interfaces IIdentity e IPrincipal como base para la autenticación y autorización. La interfaz IIdentity representa la identidad de un usuario en .NET. Los métodos que contiene son Name, para almacenar el nombre del usuario, IsAuthenticated, para identificar si el usuario ha sido autenticado, y AuthenticationType, que almacena la descripción del mecanismo de autenticación del usuario. La interfaz IPrincipal se ocupa del control de acceso basado en roles y contiene la propiedad de tipo IIdentity, junto con un único método para comprobar si el usuario posee un rol particular o no.

Las dos novedades principales que se introdujeron con fueron ASP.NET Identity fueron las clases ClaimsIdentity y ClaimsPrincipal dentro del namespace System.Security.Claims. ClaimsIdentity es la clase derivada de la interfaz IIdentity, donde esta nueva versión añade una colección de Claims de identidad del usuario. ClaimsPrincipal deriva de la interfaz IPrincipal, donde incluye la colección de ClaimsIdentity.

Para crear nuestro conjunto de claims, utilizamos la clase ClaimsIdentity, donde estarán encapsulados todos los claims del usuario.

Cada claim es un fragmento de información sobre el usuario, como pueden ser, nombre de usuario, correo electrónico, rol, localidad a la que pertenece, etc. La forma más sencilla de crear un Claim es proporcionando un tipo y un valor en el constructor del Claim. El valor del claim se representa con un valor string. Para representar el tipo del claim tenemos la clase ClaimTypes, donde se representan los tipos predefinidos de claims más comunes. Normalmente son en formato URI, por ejemplo el tipo de email es http://schemas.microsoft.com/ws/2008/06/identity/claims/email.

La representación de los claims se nos figura en la siguiente tabla:

También podemos crear nuestro propio tipo de claim que no esté representado en el objeto ClaimTypes. La forma más sencilla es crearnos una clase de constantes donde tengamos representados nuestros tipos de claims y luego asociarlos al Claim correspondiente.

Para acceder a los claims de la identidad del usuario, utilizamos la clase de Thread.CurrentPrincipal. En este ejemplo accederemos al valor del email.

También podemos crear la excepción de credenciales fallidas del usuario:

Otra de las novedades que nos trae este sistema es que podemos crear un ClaimsIdentity para un usuario que todavía no está autenticado. Es un importante cambio, ya que en las versiones previas a ASP.NET Identity, cuando la clase Identity poseía un nombre en la propiedad Name, se consideraba al usuario autenticado. Pero con la clase ClaimsIdentity, es posible añadir una colección de claims a un usuario anónimo.

Por último, destacar que la compatibilidad de ASP.NET Identity con el sistema basado en OWIN. OWIN incluye componentes de middleware para la autentificación, donde podemos autenticar al usuario de manera local con el uso de la credenciales en nuestra aplicación, o utilizar sistemas externos como cuentas de Microsoft, Google, Twitter, Facebook… y nombres de usuarios que utilizan cuentas de organización como Active Directory o Windows Azure Active Directory.

Con OWIN Authentication además podemos generar la cookie utilizando OWIN CookieAuthentication. Anteriormente se utilizaba la autenticación de formularios y su trabajo consistía en generar una cookie para representar al usuario conectado actual. ClaimsIdentity contiene la información acerca de todas los claims del usuario. Para guardar en la cookie los claims del usuario, en el método SignIn agregamos los claims del usuario.

Para finalizar, el cierre de sesión con OWIN authentication manager se implementa llamado al método SignOut, el cual elimina la cookie generada:

Gracias a la integración de OWIN, al utilizar proveedores externos para la autentificación, son los propios proveedores externos lo que nos deben devolver los Claims del usuario, permitiéndonos aplicar a nivel de negocio las restricciones necesarias para decidir qué funcionalidad se le ofrece al usuario. Para poder utilizar este sistema, necesitaremos que nuestra aplicación soporte el sistema OWIN.

Fuente : https://itblogsogeti.com/2015/07/23/la-nueva-era-de-la-autentificacion-claims-amaia-baigorri-sogeti/

Servicio REST Parte 1: Creación Servicio REST Con MVC4 .NET

viernes, 13 de octubre de 2017

Hacia dónde vamos? Tendencias de la Arquitectura de Software

Santiago Urrizola (Director de Flux IT) y Gustavo Yasue (Red Hat) en el evento Arquitectura IT: Innovación &Tendencias organizado por Flux IT. www.fluxit.com.ar

viernes, 29 de enero de 2016

FACTURACION ELECTRONICA SUNAT - PERU

Esta es una copia literal de un entrada de msdn de un amigo al cual agradezco apoyarme cuando lo necesite para implementar la facturación electrónica en la empresa en la que laboro...

Ayuda para trabajar el proyecto de la SUNAT en .NET

2

Votado

Hola, hice un programa para resolver algunos problemas que podría encontrar la gente.
Concierne la parte boletas de vente y notas / resumen de diario, he utilizado algunos ejemplos de documento que fueron enviados a mí sin verificar mi código.
Ahora, el código esta disponible en vb.net y en C#, pero seria posible de añadir otras lenguajes de programación.
Para trabajar en colaboración conmigo, podría contactarme en la siguiente dirección de correo electrónico : basilicsan64(at)hotmail.fr
--------------------------------------------------------------------------
El link de su aplicativo es el siguiente :
https://www.dropbox.com/s/cenoxmpkbrhph8f/Project_SUNAT.MSI?dl=0
Yo lo tengo realizado en C#...
cualquien pregunta comunicarse conmigo
-trifolius7@gmail.com
-hfacho@integrens.com

jueves, 16 de octubre de 2014

Los mejores servicios en la nube para desarrolladores

Github, el repositorio de proyectos más grande del mundo

Github es una herramienta fundamental para cualquier desarrollador. Es el lugar preferido para alojar su repositorio público y poder colaborar de forma distribuida con otros desarrolladores.

Muchos de los proyectos más populares Open Source utilizan Github para alojar su código o realizar integración continua utilizando todo tipo de plugins y herramientas que se conectan con la API de Github y los mágicos hooks de git.

Si bien, no es un servicio en la nube al uso como podríamos pensar si hablamos de PaaS o IaaS, con Github podemos crear las páginas de soporte de nuestros proyectos gracias a su GitHub page, distribuir nuestro código para que cualquier desarrollador lo clone o haga un fork usando git. Además de todos el sistema de tickets, wiki, milestone para gestionar los proyectos a gran escala.

Más información | Github

Google App Engine, la nube de Google cada vez más grande

La competencia entre los PaaS es dura. Google ha ido metiendo la cabeza en esa lucha especialmente contra Amazon ofreciendo su alternativa muy ligada a cómo se escalan servicios en Google. Google App Engine apareció de forma muy básica allá por 2008 soportando tan sólo Python, aunque rápidamente incorporó Java y más adelante se han ido añadiendo Groovy, JRuby, Scala, Clojure o el más reciente PHP y su experimento con Go.

La mayor diferencia frente a servicios como EC2 es su facilidad de despliegue en la nube. Como buen PaaS, simplemente nos debemos de preocupar de desarrollar la aplicación y el propio App Engine lo escalará a las maquinas que sean necesaria de forma totalmente transparente. Cuenta con varios plugins y SDK para Eclipse para facilitar la tarea de programación y despliegue.

El ecosistema de Google App Engine ha ido creciendo incorporando más servicio de Google Cloud como Google Cloud SQL, Google Cloud Storage o Google Cloud Endpoints para crear el backends de apps móviles.

Más información | Google App Engine

Windows Azure, la nube de microsoft

Tengo que reconocer que cuando empecé a escuchar que Microsoft estaba preparando un servicio en la nube tenía mis reparos sobre si sería demasiado enfocado a plataformas Windows. Todo lo contrario, Azure está abierto a diversas tecnologías como Java, PHP, Ruby, Python o Node.js, sin olvidarnos de .NET. Y sus SDKs están disponibles para Mac, Windows o Linux, un acierto esa apertura.

Por supuesto, las maquinas virtuales o algunas de las bases de datos que ofrece son propietarias de Microsoft, aunque su fiabilidad en la nube es incuestionable.

Entre los servicios que ofrece como plataforma en la nube nos encontramos servicios para plataformas móviles iOS, Android, Windows Phone o Xamarin para el envío de notificaciones y backend, big data, almacenamiento, la propia de infraestructura de nuestra aplicación, etc..

Más información | Windows Azure

Conclusiones: muy difícil quedarse con tan sólo tres servicios en la nube

Aunque en esta selección del repaso de tecnologías del 2013 sólo queríamos mencionar los tres más destacados, esta categoría tiene un un gran número de plataformas y servicios increíbles para los desarrolladores. Y más que aparecerán en este 2014. Es el mayor filón para muchas empresas que han visto que ofrecer servicios a los desarrolladores tiene unas altas expectativas de monetización. Ellos nos ofrecen las herramientas y nosotros podemos crear aplicaciones de forma más ágil y eficaz. Si ahora creas una startup es imprescindible que uses un servicio de los mencionados para poder ir escalando tu infraestructura según tus necesidades.

A continuación algunos de los servicios en la nube que no podíamos dejar de mencionar:

Amazon Web Services para muchos de nosotros aunque no haya sido seleccionado entre los tres más destacados, quizás porque es algo habitual contar con EC2 o un S3 en nuestros proyectoscabe un mención muy especial. Y este año hemos conocido más servicios que se unen a su tremendo ecosistemas como los más recientes Amazon Kinesis o Amazon Simple Notification Services (SNS).

Parse, sin duda, si nos planteamos añadir a nuestras aplicaciones notificaciones push es uno de los primeros servicios en la nube al que recurriríamos. Nos ofrece un amplio abanico de servicios para el envío y gestión de notificaciones tanto a Android como iOS, así como ejecutar script en la nube para llevar parte de la lógica del envío a un backend distribuido con su reciente servicio Cloud Code.

Apigee es un servicio en la nube que nos permite manejar nuestra API con un potente panel de herramientas que van desde la gestión de la seguridad, caché, estadísticas como el mantenimiento de distintas versiones o tratamiento y transformación de los datos. Además nos permite crear en sencillo paso una consola sandbox para poder enseñar el uso de nuestra API a los desarrolladores. Empresas como Twitter la usan para este fin.

Y simplemente enlazando al resto de servicios que teníamos en nuestra lista Heroku, Cloud Foundry,Simperium o Bitbucket.