PaaSOS ERP es uno de los productos empresariales de PaaSOS, le permitirá gestionar el ciclo completo de compra/venta de su empresa.

PaaSOS ERP es un sistema de gestión empresarial colaborativa que integra muchos de los aspectos de distribución y comercialización relacionados con empresas que producción de bienes o servicios.

Su fuerte integración con nuestras tecnologías colaborativas le permitirá adaptarlo fácilmente a sus necesidades.

Su funcionamiento es simple e intuitivo e integra muchas funcionalidades empresariales que le facilitan su puesta en funcionamiento y su fácil entendimiento.

PaaSOS ERP está especialmente recomendado para pymes, micropymes y trabajadores autónomos debido a su sencillez y su bajo coste.

También es recomendable para empresas que desean crear sus soluciones empresariales adaptadas a bajo coste.

Blog | Tienda

Programa de facturación

Veamos como empieza el año para nosotros (en lo tecnológico y comunidad. Dejo el tema negocio para más adelante).

Velneo V7

Hablemos de Velneo, hablemos de V7.

Novedades

• ¿Será el año de Android?. Si, todo apunta a que Android ocupará un hueco importante. Veremos también como Windows Phone 7 se incorpora al mercado de Smartphones intenta hacer lo propio.
• ¿El cliente de Android está maduro?. No, aún le falta un par de releases más. Hay aún problemas importantes en el port de Android de Qt, por lo que estos problemas serán arrastrados a nuestra plataforma.
• QML y JavaScript seguramente serán lanzados en Febrero. ¿Será bueno para Velneo la apertura?. Si, pero…
• ¿Tendremos que aprender mucho?. La comunidad necesitará bastante trabajo y dedicación para aprovechar QML. JavaScript será más sencillo, pero abre un mundo de posibilidades que habrá que explorar, por lo que su aprovechamiento será lento.
• ¿No será demasiado complicado?. Lo será, habrá muchas cosas nuevas.
• ¿Qué cosas podré hacer?. Consumo de servicios web, aplicaciones para tablet’s, más dinamismo en los UI, API en JavaScript para manejar el motor y el UI…

Este año será muy divertido en lo tecnológico, es lo que tocaba.

Habrá algunas novedades importantes: QML, vJavaScript, SuperRejilla, vDebugger y Android.

Madurez de la plataforma

La verdad es que existe un descontento generalizado (especialmente en la comunidad v6 que no se introdujo en V7) que evidencia ciertas carencias o problemas de la plataforma.

Como sabéis hemos sido abanderados en la adopción de V7, conocemos en detalle las versiones precedentes v6 y otros entornos (especialmente .NET). Nuestra percepción es que la plataforma es madura en ciertos aspectos y es inmadura en otros. Por lo que la percepción de la madurez de la plataforma dependerá de la óptica y enfoque.

Estado del arte

• Desarrollo rápido. Con V7 desarrollarás rápido, muy rápido. Eso sí te costará empezar a hacerlo ya que V7 no es v6, es otra cosa.
• Curva de aprendizaje media-baja. V7 es complejo respecto a su prima v6, pero es mucho menos complejo que .NET. La curva de aprendizaje es media, tardarás entre uno y dos años en dominar V7 (.NET se tarda de dos a tres años).
• Ejecución multiplataforma. Es una de nuestras apuestas. A día de hoy la compatibilidad en Win/Lin/MacOSX es muy alta. La multiplataforma es un factor de peso en la elección ya que el mercado está explosivo, se introducen continuamente nuevos S.O. y por lo tanto hay que estar preparados para cualquier futuro tecnológico (nadie puede concretar como será el mercado dentro de cinco años).
• SaaS/PaaS. Otra de nuestras apuestas. V7 es un gran producto para entornos colaborativos, colaborar en el desarrollo de aplicaciones es una de las claves del presente y futuro. Poder distribuir, desarrollar y administrar nuestros sistemas de esta forma es otro factor de peso en la elección.
• Base de datos. La base de datos de Velneo V7 es una base de datos adecuada para entornos empresariales pequeños-medianos. Es estable y robusta aunque más lenta que v6 en ciertos escenarios.
• Qt. El crecimiento de Qt desde que Nokia abandonó Meego es confuso. La nueva versión 4.8 muestra la dirección que tomará Qt, mayor apertura, más plataformas soportadas, gobierno abierto… Pero todos estos cambios y la salida de Nokia, genera muchas dudas respecto al futuro tecnológico de Qt. Desde nuestro punto de vista Qt sufrirá bastante ya que las empresas participes de la nueva etapa como Canonical, KDE, ICS, Dixia, etc tienen enfoques totalmente distintos en el apartado de movilidad al que tenía Nokia.

V7 es un gran entorno de desarrollo para aplicaciones de gestión empresarial donde el coste, la eficiencia y la colaboración son factores críticos.

Hablemos del presente, hablemos de SaaS

• ¿Para cuando?. Está al caer…
• ¿y estará madura?. No creo, será más bien una versión lite.
• ¿y que hacemos?. Continuar el trabajo de nuestra SaaS.
• ¿Y nuestra web? En proceso… mejorándose para facilitar la entrada, integración y pago.
• ¿LOPD y LSSI para la cuestión fundamental?. Tendremos que ver como está el patio.
• ¿Hay que aprender algo más?. Poco queda, pero es importante seguir avanzado con paso firme.

Hemos aprendido mucho sobre Velneo V7, WordPress, Prestashop, JavaScript, JQuery, Phyton, ShellScript y Amazon EC2/S3. Ahora toca avanzar en lo demás, QML, OAuth, node.js (thanks, @FranVarona), LXC, Qt, Comunicaciones unificadas…

Comunidad

• ¿Que es lo que más cuesta en la adopción?. Hay muchas cosas, pero después de tres años de trabajo con V7, creo que lo más duro es el cambio de filosofía respecto a v6. Hay que aprender a no usar ciertos patrones de diseño de V6 (tenemos que centrarnos en diseños modulares y funcionales), evitar columnas calculadas (son mucho más lentas), evitar duplicidades de código en la medida de lo posible (incrementa el peso y mantenimiento)…
• ¿Habrá negocio para todos en V7?. Si. Surgirán oportunidades en este entorno, pero cuidado, pueden ser contraproducentes. Hay que ser prudentes, centrarse y caminar correctamente alineados.

Con V7 hay que hacer las cosas con otra mentalidad, con otra visión de negocio. Cuando haces el cambio consigues cosas muy interesantes con muy buena salida comercial y empresarial.

Hay que dar tiempo a los desarrolladores, el mercado irá marcando las pautas.

Blog | Tienda

Cuesta de enero

Intentaremos explicar paso a paso como realizar un cliente de twitter básico mediante OAuth y API’s REST/XML.

Conceptos básicos OAuth: Usuarios, OAuth Consumer y OAuth Service Provider

Para poder hablar de OAuth, se necesitan tres partes, un servidor o proveedor de servicios, usuarios y un consumidor:

• OAuth Service Provider o proveedor de servicios OAuth: Sitios o servicios web que contienen información de usuarios cuyo acceso es restringido. Algunos de los más conocidos son Facebook, Twitter o Youtube. Estos proveedores ponen a disposición de los desarrolladores una API que soporta el protocolo de autenticación OAuth.
• Usuarios: Sin los usuarios, no existiría OAuth. Por usuario se entiende cualquier persona que tiene una cuenta de usuario en un Service Provider.
• OAuth Consumer: Cualquier sitio o aplicación web, móvil o de escritorio que solicita permiso a un usuario para acceder a sus datos de acceso restringido que alberga un Service Provider. El usuario puede autorizar o denegar el acceso del consumer a sus datos.

API Key y Callback URL

Cada OAuth Service Provider os proporcionará un API Key (un string de letras y números) para identificar que las peticiones que recibe mediante su API vienen de un OAuth Consumer autorizado, es decir, vuestra aplicación.

A su vez, cada OAuth Service Provider os pedirá que indiquéis un Callback URL, es decir, una dirección URL que apunte a un archivo de vuestra aplicación el cual se encargará de procesar la respuesta de autorización (o desautorización) de acceso a los datos de la cuenta del Usuario en el OAuth Service Provider.

Fujo en OAuth 1.0a

• Obtenemos un Request Token
• Solicitamos la autorización del Usuario (para acceder a los datos de su cuenta) enviándole a una página especial de login del Service Provider.
• Cambiamos el Request Token por un Access Token

Punto de partida

Como punto de partida utilizaremos un ejemplo implementado íntegramente en QML y javascript (https://gitorious.org/qt-qml-demo-playground/qt-qml-demo-playground/trees/master/twitter-oauth)

Este ejemplo contiene dos librerías javascript importantes:

• sha1.js: Una librería que implementa SHA-1
• OAuth.js: Una librería que implementa OAuth 1 (no usar en producción)

Obtenemos un Request Token

Realizamos la solicitud del token (OAuth.qml – línea 70):

Obteniendo el token y la clave secreta (línea 78 y 79).

Solicitamos la autorización del Usuario (para acceder a los datos de su cuenta) enviándole a una página especial de login del Service Provider.

Preparamos la petición de autorización (línea 83).

Realizamos la petición de autorización (línea 88).

Rellenamos los datos de autenticación (línea 94 y 95).

Aceptamos el formulario (Línea 96)

Cambiamos el Request Token por un Access Token

Para ello recogemos el pin (línea 99).

Componemos una nueva solicitud (en este caso para el access_token) pasándole como parámetros el pin, token y secret (línea 100).

Ya estamos autenticados.

Realizamos las llamadas a la API

Ahora que estamos autenticados podemos realizar cualquier llamada a la API de twitter, por ejemplo… a la timeline.

Esperamos que esta introducción os sea de ayuda para hacer vuestro primeros pinitos con OAuth.

¿Te gustaría tener un cliente de Facebook o twitter integrado en tú aplicación empresarial?

Desde hace unos meses estamos trabajando en sendos clientes de twitter y facebook para PaaSOS. Estos dos clientes están implementados íntegramente mediante QML y JavaScript. Llegado el momento serán 100% funcionales en Velneo V7.

Se utilizan las API REST de twitter y facebook. También se utilizan los protocolos de Autenticación OAuth 1a y 2 por lo son un buen punto de partida para el estudio de la implementación mediante javascript de sendos clientes para API’s REST y OAuth .

Blog | Tienda

Servicios web – III

Con la proliferación de los servicios web en Internet, surgió un problema de relevancia, la autenticación. Los servicios disponibles han crecido enormemente, y la mayoría de usuarios utilizan  múltiples aplicaciones de terceros: por ejemplo, un usuario consulta su correo en un sistema de webmail, desde el teléfono o desde su cliente de correo. También es habitual la participación en redes sociales como facebook, linkedin, tuenti o twitter, etc. La mayoría de esas aplicaciones requieren que el usuario se autentique; es decir, que demuestre de algún modo (habitualmente usando un identificador de usuario único y una contraseña asociada) que es quien dice ser.

Al tratarse de aplicaciones independientes entre sí, en principio cada una de ellas utilizaría  su propio sistema de autenticación y de gestión de datos personales, lo cual implica inconvenientes al usuario cada vez más graves a medida que el número de sistemas que utiliza crece.

Surge la necesidad de conocer cuales son las tendencias actuales respecto a la autenticación y autorización en Internet.

Autenticación vs. autorización

Antes de seguir, es necesario hacer una distinción clara entre dos tipos de servicios ofrecidos por las tecnologías que vamos a describir.

• Autenticación: consiste en un sistema para certificar que el usuario es quien dice ser; lo más común es utilizar una combinación de identificador de usuario único y contraseña.
• Autorización: consiste en dar acceso a una serie de recursos a un usuario o sistema (para ello, el usuario o el sistema previamente tendrán que haberse autenticado).

Protocolos y estándares ampliamente adoptados

Una primera solución evidente al problema de la autenticación sería el uso  de algún tipo de certificado personal (basado, por ejemplo, en el estándar X.509) emitido y validado por alguna autoridad central  de confianza. Si bien este tipo de certificados son útiles para gestiones  con determinadas entidades,  no son prácticos en general para el acceso a servicios de Internet. Por este motivo han surgido varios protocolos de autenticación y autorización en Internet.

OpenID

El protocolo abierto OpenID, cuya primera versión fue definida en 2005 para su uso en el sitio web LiveJournal, es un protocolo de autenticación federada, y consiste básicamente en que el usuario selecciona un servidor externo (el “proveedor” de OpenID) que va a ser el que va a validar su identidad en un sistema determinado (el “consumidor” de OpenID).

Problemas de OpenID:

• Complejidad: no se implementa fácilmente.
• Seguridad: es un protocolo muy vulnerable al  phishing.
• Privacidad: los proveedores de OpenID tendrán mucha información del usuario.
• Confianza: ¿quién es realmente el usuario?.
• Usabilidad: puede ser incómodo  y/o complejo  para el usuario.
• Adopción: los proveedores de servicios tienen pocos motivos para aceptarlo como autenticación.
• Disponibilidad: se incrementa la dependencia de servidores.
• Patentes: no es un protocolo “tan” abierto.

OAuth

El protocolo abierto OAuth, a diferencia de OpenID, es un protocolo de autorización; más exactamente, de delegación de acceso; es decir, permite definir cómo un tercero va a acceder a los  recursos propios. Empezó a definirse en 2006 y en 2007 se publicó la primera versión oficial.  El propósito de este protocolo es, pues, que un usuario que tiene determinados recursos en un servidor (el “proveedor” de OAuth) pueda dar acceso a un tercero (el “consumidor”, usualmente un sitio web) a parte o todos esos recursos, sin necesidad de que ese tercero conozca su usuario y contraseña, ya que con esos datos tendría el control total de la cuenta.

Problemas de OAuth:

• Complejidad.
• Orientado a navegadores.
• Seguridad.

OAuth 2.0

OAuth 2.0  pretende ser una versión revisada y simplificada de OAuth. Aventaja a la versión anterior en una mayor simplicidad de implementación, y en una arquitectura más robusta y que da soporte a mayor número de plataformas.

Existe cierta confusión sobre si OAuth es o no un protocolo de autenticación de usuario. Estrictamente hablando  no lo es, ya que no define ningún mecanismo  explícito destinado a autenticar la identidad del usuario. Por tanto, cuando se habla del  “mecanismo de autenticación de OAuth”, en realidad  se están refiriendo al mecanismo de autenticación propio del sitio web proveedor de OAuth, que puede ser cualquiera: autenticación http básica, OpenID, etc.

Nuevos Protocolos y estándares

OpenID OAuth Hybrid Protocol

Como hemos visto, OpenID y OAuth son protocolos con objetivos distintos aunque complementarios: autenticación de usuario (federada) y autorización, respectivamente. El protocolo híbrido OpenID OAuth  combina ambos sistemas, integrándolos en una interfaz única.

Facebook Connect

Debido al enorme incremento de usuarios y, en consecuencia, de datos personales que ha experimentado Facebook en los últimos años, la compañía lanzó en 2008 su propio sistema conocido como Facebook Connect.  Con ese movimiento, Facebook pretendía posicionarse como repositorio central de identidad de los usuarios en Internet. En la actualidad Facebook parece haber  abandonado Facebook Connect para adoptar el protocolo 2.0 de OAuth.

OpenID Connect

El protocolo OpenID Connect es la última propuesta para reactivar OpenID. Su propósito es redefinir y simplificar el protocolo construyéndolo sobre el protocolo OAuth; de ese modo se aprovecha el trabajo desarrollado para OAuth, que parece  estar  extendiéndose rápidamente, dotándolo de una funcionalidad estándar de autenticación que, como hemos visto anteriormente, no posee.

Otros sistemas

Algunos de los grandes proveedores de servicios en Internet han definido, en algún momento, su sistema propio  de autenticación y/o autorización. Sin embargo, la mayoría de ellos están adoptando  estándares  como OpenID y, especialmente, OAuth; es el caso, por ejemplo, de MySpace, Twitter o Yahoo!.

Otro estándar abierto para el intercambio de recursos de identidad es Security Assertion Markup  Language (SAML). Está basado en XML, y su principal propósito es servir de marco para protocolos de autenticación federada. Este protocolo sirve de base para algunos sistemas propietarios de single-sign-on, pero no es utilizado por los grandes proveedores de servicios en Internet.

Resumiendo

Blog | Tienda

Servicios Web – II

Blog | Tienda

Feliz Navidad y próspero 2012

El motivo de empezar esta nueva serie de artículos tiene que ver con el futuro lanzamiento del motor de JavaScript de WebKit fuertemente integrado en Velneo V7 (http://twitter.com/#!/varquitecto). También tiene que ver con uno de nuestros productos en desarrollo, PaaSOS ESB.

No os perdáis esta serie de artículos ya que todos estos conocimientos serán necesarios para exprimir estas tecnologías en esta nueva etapa.

Empecemos por el principio:

Un servicio web (en inglés, Web service) es una pieza de software que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones.

Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.

Wikipedia:http://es.wikipedia.org/wiki/Servicio_web

Guía breve: http://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb

Los web services supusieron una revolución ya que permitieron integrar distintos lenguajes y plataformas (sobre todo a nivel de datos o servicios).

Para comprender el alcance, es importante conocer cada uno de los conceptos que giran en torno a los servicios web. Empecemos por el concepto Web Services Protocol Stack, que no es más que el conjunto de formatos, protocolos y servicios.  Continuemos desglosando los componentes que inicialmente formaron esta pila de protocolos y servicios.

A destacar:

Formato para los datos

• XML (eXtensible Markup Language): Es un formato, ampliamente utilizado, basado en etiquetas.

Protocolos

• SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call):
• Otros comúnmente aceptados (utilizados típicamente en combinación con sistemas de colas distribuidos y transaccionales): HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), o SMTP (Simple Mail Transfer Protocol).

Metadatos

• WSDL (Web Services Description Language): Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web.

Directorio

• UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información de los servicios Web. Es un protocolo para meta-directorios de servicios web.

Seguridad

• WS-Security (Web Service Security): Protocolo de seguridad aceptado como estándar. Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.

Optimización

• MTOM (Optimización de Transmisión de Mensajes para SOAP): Recomendación del W3C.

Y llegó el problema:

XML/WSDL/SOAP es complejo y pesado por lo que una nueva iniciativa REST (Representational State Transfer) fue ganando adeptos en toda la web como una alternativa más simple a SOAP y a los servicios web basados en ella. Varios grandes proveedores Web 2.0 migraron a esta tecnología, incluyendo a Yahoo, Google y Facebook, quienes marcaron como obsoletos sus servicios XML/WSDL/SOAP y pasaron a usar un modelo más fácil de usar, orientado a los recursos.

REST define un conjunto de principios poniendo el foco en los recursos del sistema, cómo se accede a dichos recursos y cómo se transfieren por HTTP.

Los 4 principios de REST

Una implementación concreta de un servicio web REST sigue cuatro principios de diseño fundamentales:

• Utiliza los métodos HTTP de manera explícita.
• No mantiene estado.
• Expone URI’s con forma de directorios.
• Entrega XML (eXtensible Markup Language), JSON (JavaScript Object Notation), HTML (HyperText Markup Language) u otros.

Los defensores de REST han creído que estas ideas son tan aplicables a los problemas
de integración de aplicaciones como lo son XML/WSDL/SOAP. Pero la verdad es que REST no es la cura para todo, algunas características de diseño de REST no son apropiadas para ciertas aplicaciones.

Conclusión:

REST surgió como una alternativa para diseñar servicios web con menos dependencias (más ligeros y sencillos), que su contraparte SOAP+WSDL. De algún modo, REST es la vuelta a los orígenes de la Web, ya que incide en los primeros estándares de Internet, URI y HTTP.

http://jelabra.blogspot.com/2007/03/clase-de-soap-vs-rest.html

XML sobre HTTP es una interfaz muy poderosa que permite que aplicaciones internas, como interfaces basadas en JavaScript Asincrónico + XML(AJAX) puedan conectarse, ubicar y consumir recursos. De hecho, es justamente esta gran combinación con AJAX lo que generó el interés por REST.

Blog | Tienda

Servicios Web – I

• Introducción a QML – I
• Introducción a QML – II
• Introducción a QML – III
• Introducción a QML – IV
• Introducción a QML – V
  • Introducción a QML – Primer ejemplo I
  • Introducción a QML – Primer ejemplo II
• Gestión dinámica de componentes QML – I
• Gestión dinámica de componentes QML – II
• Gestión dinámica de componentes QML – III
  • Introducción a QML – Primer ejemplo III

Si por algún motivo no os gustan o resultan insuficientes, os sugerimos empezar por la web de Qt con los ejemplos básicos e ir avanzando paulatinamente.

SDK:
• http://www.developer.nokia.com/info/sw.nokia.com/id/da8df288-e615-443d-be5c-00c8a72435f8/Qt_SDK.html

Tutoriales:

• http://saim.pub.ro/ITNQ/Qt_Quick_QML.pdf (Qt Quick for Mobile)
• http://doc.qt.nokia.com/4.7-snapshot/qml-tutorial.html (QML Tutorial)
• http://doc.qt.nokia.com/4.7-snapshot/qml-advtutorial.html (QML Advanced Tutorial)

Referencias:

• http://doc.qt.nokia.com/4.7/qtquick.html
• http://doc.qt.nokia.com/4.7/qdeclarativeintroduction.html
• http://doc.qt.nokia.com/4.7/qdeclarativestates.html
• http://doc.qt.nokia.com/4.7/qmlruntime.html

Wikis:

• http://developer.qt.nokia.com/wiki/Category:Developing_with_Qt::Qt_Quick

Foros de debate:

• http://developer.qt.nokia.com/forums/viewforum/12/

Blogs

• http://labs.qt.nokia.com/category/declarative-ui/
• http://quitcoding.com/
• http://www.lanpartyelx.com/7party/

Videos QML:

• http://developer.qt.nokia.com/videos#c-86
• http://qt.nokia.com/learning/topics/qml-qt-quick/ (QML / Qt Quick)

Training:

• http://qt.nokia.com/learning/online/training/materials/qt-quick-for-designers/
• http://qt.nokia.com/learning/online/training/materials/qt-essentials-qt-quick-edition
• http://qt.nokia.com/qtdevdays2011/training
• http://qt.nokia.com/qtdevdays2010/training

Ejemplos:

• http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeexamples.html
• http://www.developer.nokia.com/Develop/Qt/Code_examples/

Blog | Tienda

Recursos para iniciados en QML

El último día celebramos el evento empresarial sobre el que centraré este artículo, mis conclusiones:

• Hemos andado el camino correcto durante estos tres años (con algún traspiés menor)
• SaaS es el presente y futuro. Como vimos en las primeras CloudCamp.
• Queda aún camino para que en España, la nube, sea una realidad en la mediana o pequeña empresa.
• Los nuevos modelos de distribución requieren obligatoriamente de volumen.
• El nivel de conocimiento tecnológico de la comunidad V7 es medio-bajo con algunas excepciones.
• En cambio, el nivel de conocimientos sobre los sectoriales es de alto valor añadido.
• Es estrictamente necesario encontrar más alianzas con canales de distribución al mayor, para eso requeriremos de más inversión comercial y de nuevas alianzas empresariales (hay que cerrar la cadena de valor).

• Las redes sociales tomarán más peso, por lo que seguirá siendo necesario realizar bastante inversión en marketing online, SEO y SEM.
• El precio es un factor dependiente del modelo empresarial. Hoy, el precio, no es una prioridad (nosotros no pensamos en el hoy ya que el mañana en breve estará entre nosotros).
• Es necesario aunar esfuerzos para ganar en esta nueva etapa. DESPIERTA!!!, si vas solo lo pasarás muy mal.
• Somos pocos los que estamos realmente preparados para dar soluciones maduras basadas en V7 (los contamos con los dedos de las manos).
• Los esfuerzos de Velneo durante el próximo año se centrarán fundamentalmente en SaaS y PaaS.

• Pronto se empezará a hablar más de todos nosotros, y puede que no todo sea bueno.
• Quedan aún bastantes lagunas legales que superar (joder con la carga de leña). Quiero dar las gracias públicamente a mi buen amigo Enrique Ávila por anticiparme y guiarme respecto a esta cuestión.
• La multiplataforma es una prioridad para Velneo (QML y Android es la evidencia). Incluso priorizándolas sobre otras cuestiones mayores requeridas por la comunidad (informes, demonios, mejoras de estabilidad o similares).

Es pronto para decirlo, pero me voy a aventurar: Velneo V7 es actualmente la mejor PaaS del mercado para hacer aplicaciones empresariales multiplataforma.

Blog | Tienda

Sobre software empresarial

PaaSOS Core es la esencia de todas nuestras aplicaciones empresariales.

Consta de una decena de módulos tales como calendario, gestión de actividades, agenda, navegador web o sistema de ficheros. Además incorpora varias características empresariales que le serán de gran utilidad.

• En PaaSOS toda la información está organizada en módulos.
• Todos los módulos comparten un conjunto de características comunes tales como la seguridad, configuración, taxonomía, etc…
• Cada uno de los módulos almacena información de un cierto tipo.

Blog | Tienda

PaaSOS Core – Unifique sus datos empresariales

PaaSOS es un conjunto de aplicaciones empresariales que le permiten gestionar la información de su negocio o empresa. Está especialmente recomendado para PYMES y autónomos por su sencillez y bajo coste.

PaaSOS funciona en sistemas operativos Windows, Linux o Mac OSX. También existe la opción de ejecutarlo en tú tablet Android 3.0 o superior.

Blog | Tienda

PaaSOS – Gestiona tú información empresarial