Nuevos datos sobre la repercusión del proyecto

En sólo 3 días desde mi anterior post el repositorio ha aumentado su popularidad de una manera increíble, a continuación hago un recuento de los datos de tráfico actuales y pongo las pruebas  de ello😛

  • Estrellas: 51
  • Visitas únicas: 798
  • Visitas totales: 4538
  • Clones únicos: 55
  • Clones totales: 117

Increíble, ¿verdad?

newtraffic0

newtraffic1

A continuar creciendo, ¡y a por los 1000! 😀

Increíble impacto social del proyecto

Resulta que esta mañana me he levantado y he mirado las estadísticas del repositorio donde se está desarrollando SyncMe, y cual es mi sorpresa de que en pocas semanas se ha vuelto un repositorio conocido, habiendo conseguido más de 2800 visitas, más de 300 visitantes únicos33 estrellas, 3 forks y 47 clones únicos además de algunas colaboraciones que se han realizado en el repositorio (que nombraré luego cuáles).

Se pueden apreciar las estadísticas en la siguiente imagen:

SyncMe-Traffic-05042016

La verdad es que ha sido una gran sorpresa para mí que el proyecto haya tenido tanto impacto, ya que esto quiere decir que la gente considera a SyncMe una herramienta útil y viable.

 

Colaboraciones del mes de abril:

  • El usuario @EleDiaz reportó que el logo de la aplicación le parecía poco estético y sugería hacer uno nuevo (issue), tras esto @Dariasteam contestó al Issue diciendo que él podía encargarse de eso, ¡y vaya si lo hizo!, ha hecho un pedazo de logo que me ha encantado (commit), el resultado ha sido este:

 

SyncMe

¿No es precioso?😛

 

  • Además, @alu0100845235 ha propuesto ofrecer una traducción de la interfaz de SyncMe al inglés, para así aumentar todavía más el rango de personas a las que alcance el proyecto (ya que resulta que el 70% de los interesados en el proyecto son de EEUU ó UK)… no le falta razón, lo que he hecho es crear la rama “translate” donde he puesto el fichero ‘spanish.lang’ que contiene los textos en castellano actuales de la interfaz, de forma que se pueda seguir esa plantilla para colaborar ofreciendo traducciones (commit).
  • Por otro lado @Cicko se ha ofrecido a traducir la interfaz al idioma Checo (issue).

Apostando por la accesibilidad universal

He decidido hacer (o al menos intentar) que SyncMe sea lo más accesible posible, es decir, orientar el desarrollo hacia la accesibilidad universal, de forma que cualquiera pueda utilizar la aplicación, independientemente de sus capacidades concretas, ya que sería una lástima que alguien no pudiera utilizarla por algún tipo de diversidad funcional.

A continuación expongo las opciones de accesibilidad con las que cuenta SyncMe, empezando por el menú “Accesibilidad” de la interfaz (Recomiendo darle click para abrirlo en tamaño completo y apreciarlo mejor):

SyncMe-Accesibilidad

 

Como se puede observar, actualmente la interfaz cuenta con 4 elementos de accesibilidad:

  • El primer elemento, es el menú de “Accesibilidad”, en el cual se desplegarán todas las facilidades actuales y futuras relativas a la accesibilidad de SyncMe.
  • El segundo elemento es la opción de “Cambiar tamaño de letra a grande”, la cual como es fácil deducir, te permite aumentar el tamaño de todos los textos de la interfaz a uno más grande, de forma que se aprecie con mucha mayor claridad para personas con dificultad visual.
  • El tercer elemento te permite decirle a SyncMe que todos los colores que utilice en la interfaz sean de alto contraste, de forma que apreciar las diferencias entre ellos es mucho más fácil, a continuación se muestra la gama de colores de alto contraste que se utiliza:

contraste-colores_GIF

  • El cuarto elemento te permite reinicializar todos los colores y tamaños de letra al que viene por defecto.

 

Otras consideraciones que se han tenido en cuenta:

  • Como se puede ver en la interfaz, se han utilizado colores claritos que cansan poco la vista, lo que hace que el usuario se sienta cómodo utilizando la aplicación (lo que a su vez aumenta el tiempo de uso), evitando por supuesto utilizar colores que causen problemas a personas daltónicas:

1

 

  • Por otro lado, se han utilizado iconos en la barra de herramientas lo más intuitivos posibles, de forma que es fácil deducir para qué sirve, y por si acaso se ha incluido un tooltip text cuando pones el ratón encima indicando la funcionalidad del botón:

SyncMe-ToolBar

 

  • Por último es importante remarcar el uso de botones grandes para las distintas operaciones que se pueden hacer sobre los ficheros, junto con el uso de una tipografía que maximiza la legibilidad:

SyncMe-Botones-Operaciones

 

Diseño de Software: Motor de Google Drive

Unas semanas después de haber terminado de desarrollador la versión funcional del motor de Dropbox para SyncMe he decidido ponerme manos a la obra y empezar a diseñar lo que será el motor de Google Drive, de forma que una vez termine con este motor ya tendríamos las dos piezas más grandes del puzzle casi colocaditas.

El diseño de software con el que pretendo enfocar el motor de Google Drive es ‘bastante’ más complejo que el diseño que utilice para el motor de Dropbox, a continuación el resultado, he utilizado StarUML para desarrollarlo (Recomiendo darle click para abrirlo en otra ventana y así sea más fácil navegar por el mismo):

SyncMe_GDrive_Engine

 

Ideas generales:

  • He dividido el diseño en 5 subsistemas que en su conjunto forman el sistema principal o núcleo, estos son:

    • El primer subsistema es “GUI”, el cuál tendrá toda la implementación necesaría para mostrar la interfaz gráfica de SyncMe que trabaje con Google Drive, este a su vez estará dividido en 3 partes: Controls, Forms y Tools.
      • Controls (Controles) tendrá utilidades gráficas tales como Combo Box, espaciadores y barras de herramientas, de forma que sea más sencilla su instanciación.
      • Forms tendrá todas las interfaces gráficas (utilizando el IDE Qt Creator), es decir, los archivos .ui y las implementaciones de las señales que utiliza cada elemento gráfico.
      • Tools tendrá herramientas que ayudarán al dibujado cross-platform, de forma que dibujar un elemento sea tan sencillo como invocar al método ‘draw‘ de la clase Painter Helper, el cuál se encargará de hacerlo de forma correcta dependiendo del sistema operativo en el que esté corriendo SyncMe.
    • El segundo subsistema es el de Settings (Preferencias), el cuál tendrá una clase SM_Settings_Manager que se encargará de gestionar las preferencias del usuario: guardar la ruta donde descargar los ficheros, guardar las cuentas utilizadas/sincronizadas por el usuario, guardar tokens…etc.
    • El tercer subsistema es el ‘Parsers’, el cuál se encargará de parsear la información que nos venga del servidor de Google Drive, así como de transformar nuestros objetos al formato correcto cuando queramos enviarlos al mismo. Estará formada por otros 2 subsistemas: El parser de JSON y el parser de XML.
    • El cuarto subsistema es el de Network (red), el cuál realizará todas las tareas relacionadas con el envío y/o recibimiento de información y/o peticiones de red al/desde servidor de Google Drive, estará formado a su vez por tres clases principales:
      • La primera clase es SM_Operation, y define una operación abstracta de la cual heredan los demás tipos de operaciones: Children (obtener hijos de un directorio), Copy (copiar un fichero), Create (crear fichero o directorio), Delete (borrar un fichero o directorio), Download (descargar un fichero del servidor de Google Drive), Move (mover un fichero), Rename (renombrar un fichero), Share (compartir un fichero… esto va a ser chungo de implementar), Upload (subir un fichero al servidor de Google Drive).
      • La segunda clase es SM_OperationsManager la cuál es compuesta de 1 ó más SM_Operation (operaciones abstractas), está clase se encarga de gestionar las distintas operaciones y forma parte del gestor de red (SM_NetworkManager).
      • La tercera clase es el gestor de red que he nombrado en la línea anterior (SM_NetworkManager) que se encargará de gestionar todas las peticiones de red, está formado por:
        • SM_Auth: Se encargará de las peticiones de red de autentificación de usuarios.
        • SM_ContentManager: Se encargará de las peticiones de red de obtención de directorios.
        • SM_DownloadFileManager: Se encargará de las peticiones de red de descarga de ficheros, de la cuál hereda la clase SM_ResourceManager.
        • SM_UploadFileManager: Se encargará de las peticiones de red de subida de ficheros.
        • SM_AccountInfo: Se encargará de las peticiones de red para obtener información de la cuenta del usuario.
  • Todos los sistemas anteriores, combinados, forman el SM_DriveEngine, que es el núcleo/core del motor de Google Drive para SyncMe.

¿Algún otro detalle?:

He estado mirando en las referencias del Google Drive API v2 y para hacer las peticiones Google te pide sí o sí que utilices el protocolo HTTPS o en otro caso te rechaza la petición, por lo que optaré por utilizar OpenSSL cuando vaya a implementarlo.

¡Uno menos!: Funcionamiento del motor de Dropbox asegurado

Después de haber terminado la primera versión del motor de Dropbox para SyncMe he decidido asegurar que su funcionamiento es correcto utilizando pruebas unitarias, por si alguien quiere utilizar dicho motor o mejorarlo (de forma que sus implementaciones no deberían hacer que las pruebas fallen), en general las pruebas que he definido son las siguientes (17 en total):

  • Pruebas con JSON:
  1. Se prueba que se leen String en JSON correctamente. OK
  2. Se prueba que se leen enteros en JSON correctamente.OK
  3. Se prueba que la comprobación de la validez de un JSON funciona correctamente.OK
  4. Se prueba que se leen booleanos en JSON correctamente.OK
  5. Se prueba que se leen flotantes en JSON correctamente.OK
  6. Se prueba que se leen subJSON correctamente.OK
  7. Se prueba que se leen enteros sin signo correctamente.OK
  8. Se prueba que se limpian JSON correctamente.OK
  9. Se prueba que la interpretación como array de un JSON y su acceso es correcta.OK
  10. Comprueba que el método de comparación funciona correctamente.OK
  11. Comprueba que utilizando strContent() se crean dos JSON iguales.OK
  12. Se prueba que los setters y los getters funcionan correctamente.OK
  13. Se prueba que el parseo de [ ] en JSON funciona correctamente.OK
  14. Se prueba que el parseo de { } en JSON funciona correctamente.OK

 

  • Pruebas de casos de uso con Dropbox:
  1. Comprobación de que se conecta correctamente a Dropbox y se envía un esqueleto de petición para comprobar la conexión en modo texto plano (obviamente la petición no se procesa).OK
  2. Comprobación de la conexión a Dropbox + uso de llamadas delta.OK

 

Uso de métodos de ayuda (helpers):

Para hacer uso de estas pruebas se han definido dos métodos helpers:

  1. connectDropbox: Este método intenta conectar a una cuenta de Dropbox con un método de autentificación que se le pasa por parámetro (será texto plano ya que HMAC-SHA1 no lo tengo implementado todavía), y hará uso del método auxiliar authorizeApplication().
  2. authorizeApplication: Este método muestra un enlace en el navegador para que autorices a SyncMe, esperará en un bucle hastsa que el token de acceso haya sido recibido.

 

Enlace a las pruebas: https://github.com/AdrianBZG/SyncMe/tree/master/src/SyncMe/API/Tests

Implementación: Motor de Dropbox

Después de unas semanitas de curro y sacando tiempo entre el trabajo y la Universidad para avanzar con el proyecto, he conseguido terminar la primera versión del motor de Dropbox para SyncMe, me he basado explicítamente en el diseño que realicé hace 2 semanas y la verdad es que ha funcionado de maravilla.

Por otra parte, he ido creando ya el proyecto con Qt y haciendo una jerarquía de directorios bien separadita, de forma que sea cómodo y fácil encontrar las diferentes clases, básicamente dentro de la carpeta de códigos hay dos subdirectorios: Headers y Sources.

  • Dentro de Headers estan las cabeceras de las clases o ficheros de definiciones, variables globales y estructuras auxiliares.
  • Dentro de Sources está la implementación de cada clase.

La única ligera diferencia entre el diagrama UML que hice hace 2 semanas y el código implementado es la adición de una nueva clase, llamada SM_Dropox_DeltaResponse, cuyo objetivo es el de gestionar las llamadas delta a la API de Dropbox, tienes las siguientes funcionalidades (así de forma muy resumida):

  • Un método getEntries() que sirve para mapear las rutas del fichero a las entradas de metadatos (es decir los de la clase SM_Dropbox_FileInfo), un dato interesante es que si el mapeo que se realiza puede tener un objeto QSharedPointer que sea ‘null’, lo que indica al Core del motor que las entradas que deberían ser borradas del seguimiento local.
  • Un método shouldReset() que devolverá un booleano: true si el mecanismo local de seguimiento debería borrar su estado actual.
  • getNextCursor() que devuelve un QString con el cursor que deberías err enviado a la siguiente llamada a la API.
  • hasMore() devuelve un booleano: true si hace una llamada delta a la API con el mismo cursor y lo trata como parte de la misma respuesta, y false si espera un tiempo (5 minutos por ejemplo) antes de hacer otra llamada delta.

Además he definido los códigos de errores para la señal errorOcurred, quedando de la siguiente forma:

  • SM_DROPBOX_ERROR_BAD_INPUT con código 40o, se generará cuando se introduzca una entrada errónea o con formato inválido (mal parseo del JSON).
  • SM_DROPBOX_ERROR_EXPIRED_TOKEN con código 401, se generará cuando el token haya expirado.
  • SM_DROPBOX_ERROR_BAD_OAUTH_REQUEST con código 403, se generará cuando se haga una petición inválida (normalmente desconocida) a la API de autenticación de Dropbox (OAuth).
  • SM_DROPBOX_ERROR_FILE_NOT_FOUND con código 404, quiere decir que el fichero solicitado no existe en el server.
  • SM_DROPBOX_ERROR_WRONG_METHOD con código 405, quiere decir que el método por el que se va a realizar la llamada es inválido (desconocido normalmente).
  • SM_DROPBOX_ERROR_REQUEST_CAP con código 503, se produce cuando se ha llegado al límite de peticiones simultáneas sin procesar.
  • SM_DROPBOX_ERROR_USER_OVER_QUOTA con código 507, se produce cuando el usuario intenta subir un fichero al servidor de Dropbox pero su límite de espacio ya ha sido sobrepasado.

 

Por otro lado, como ya sabíamos por el diagrama UML, la clase SM_QDropbox (la cuál es la clase madre o clase principal que realiza el grueso del trabajo) utiliza diferentes tipos de peticiones, a los cuales les he asignado un código en hexadecimal para poder diferenciarlos a la hora de codificarlo en JSON, tal y como se puede apreciar en la siguiente imagen:

2de0f13393ae35a279563bfdc6add8c7

 

Voy a explicar un poquito las funcionalidades que cumple la clase principal SM_QDropbox:

Este clase es el punto de entrada principal de la API Dropbox de SyncMe, provee varias facilidades de conexión e información general. Lo que intenta es dar todas las utilidades requeridas para conectarte a cualquier cuenta de Dropbox, por propósitos de conexión esta clase provee una interfaz asíncrona basada en señales y slots.

  • Conectando a una nueva cuenta:

Si quieres iniciar una nueva conexión a una cuenta que no ha autorizado a SyncMe a acceder debes usar el método requestToken() y entonces llamar a requestAccessToken() tan pronto como la señal requestTokenFinished() es emitida.

Si el token que estás usando no está autorizado o ha expirado se emitirá la señal tokenExpired(), en este caso se pedirá al usuario que reautorice a SyncMe. Un enlace a la interfaz de autorización de Dropbox se le proveerá al usuario utilizando el método authorizeLink(), por ahora no he implementado el proceso de autorización automático, ya que la API de Dropbox 1.0 no ofrece dicha facilidad/característica… por lo tanto se mostrará el enlace en una ventana del navegador.

Para reconectarte a una cuenta para un uso posterior de SyncMe se guardará el token y el token secreto obtenido después de requestAccessToken(), dichos valores son distribuidos por los métodos token() y tokenSecret().

  • Conexión a una cuenta autorizada:

Si la cuenta a la que quieres conectar ya ha autorizado a SyncMe y ya has obtenido un token autorizado y un token secret entonces se usará un atajo para conectarse: se establecerá el token y el token secret que se obtuvo en un uso previo de SyncMe con las funciones setToken() y setTokenSecret(), por lo que no se invocará ni al método requestToken() ni al método requestAccessToken(), las cuales sólo son llamadas cuando se utiliza SyncMe por primera vez y no hay token ni token secret disponibles.

En caso de que el token o el token secret que estés usando ya haya expirado se emitirá la señal tokenExpired(), en este caso se le pedirá reautorización al usuario.

  • Usando peticiones bloqueantes:

Todas las funciones que piden información al servidor de Dropbox tienen una versión bloqueante y una no bloqueante.

Una petición bloqueante esperará hasta que el servidor responda a tu consulta antes de retornar directamente un resultado y las no bloqueantes simplemente emitirán una señal acorde a dicha petición cuando ésta haya finalizado.

 

El código está disponible en la rama dropbox-engine del repositorio: enlace (https://github.com/AdrianBZG/SyncMe/tree/dropbox-engine)

Diseño de Software: Motor de Dropbox

Después de pelearme un poco para ver como podría crear una buena jerarquía de clases he terminado de hacer el diagrama UML que especifica las interconexiones y propiedades de las distintas clases que debería tener el motor de Dropbox de SyncMe, el resultado es este (Recomiendo darle click para abrirlo en otra ventana y así sea más facil navegar por el mismo):

SM_Dropbox_Engine_Design

Ideas generales:

  • Básicamente lo que he hecho es dividir el diseño en 4 grandes clases principales, las cuáles son:
    • SM_Dropbox_Account: Es la clase que gestionará la información de la cuenta del usuario (id, quota, referral link, email… entre otros)
    • SM_Dropbox_JSON: Esta clase se encargará de gestionar los paquetes JSON que recibiremos/enviaremos en la aplicación; explicaré esta clase un poco más en detalle:
      • Un objeto JSON estará formado por un Mapa que tendrá como clave un QString y su valor será un Struct del tipo SM_Dropbox_JSON_entry que guardará ‘tipo y valor’.
      • ‘tipo’ a su vez será un tipo de dato ‘char’ definido como SM_Dropbox_JSON_entry_type
      • ‘valor’ será Struct del tipo SM_Dropbox_JSON_value que está compuesto por los atributos ‘JSON‘ (objeto de la clase SM_Dropbox_JSON) y valor (QString).
    • SM_Dropbox_File: Esta clase se encargará de gestionar los ficheros que recibiremos o enviaremos mediante este motor de Dropbox en SyncMe, que heredará directamente de QIODevice, es decir, nos permitirá tratar nuestros ficheros como objetos de forma que trabajar con ellos será muy sencillo.
    • SM_Dropbox: Esta será la clase principal que hará todo el grueso del trabajo, basando todo el proceso de gestion de ficheros de SyncMe en llamadas asíncronas que seguirán un proceso similar (o se intentará) al siguiente:
      • Se realiza una petición de fichero a Dropbox.
      • Las peticiones se procesarán primero mediante el Struct SM_Dropbox_Request, el cuál guarda un tipo (formado a su vez por un Struct SM_Dropbox_Request_Type), además guardará el método con el que hará la petición (POST/GET), el host (a quién la hago; que obviamente será ‘api.dropbox.com’ y la opción linked (que por el momento no utilizaremos en fases tempranas del desarrollo).
      • Esta petición se codificará en JSON utilizando la clase SM_Dropbox_JSON
      • Se enviará dicha petición a Dropbox mediante la clase SM_Dropbox
      • Dropbox procesará la petición y devolverá el fichero solicitado en binario (bytes; QByteArray)
      • Se procesará dicho binario mediante la clase SM_Dropbox_File para pasarlo a objeto, luego se guardará en nuestro objeto SM_Dropbox (que utiliza el patrón de diseño Singleton, por lo que sólo existirá uno); es decir, que estará formado por varios objetos SM_Dropbox_File, entre otros…

Vale, más o menos es sencillo, ¿y con qué señales asíncronas debería trabajar?:

Las señales con las que va a trabajar el motor de Dropbox serán:

  • errorOcurred: Será emitida cuando ocurra cualquiera tipo de error, conteniendo el código del error.
  • tokenExpired: Será emitida cuando el token de acceso proporcionado por Dropbox haya caducado.
  • accessTokenFinished: Será emitida cuando se haya recibido satisfactoriamente un token de acceso firmado por Dropbox, contendrá el token y el secret, ambos como QString.
  • fileNotFound: Será emitida cuando intentemos descargar un fichero que no existe en el servidor de Dropbox.
  • operationFinished: Será emitida cuando una operación termine, tendrá como valor el número de la petición que hizo generar dicha operación.
  • accountInfo: Será emitida cuando se obtenga satisfactoriamente la información de la cuenta que hemos solicitado, contedrá guardado en un QString los datos de la cuenta codificados en JSON.
  • tokenChanged: Será emitida cuando el token de acceso haya cambiado.
  • finished: Esta señal será recibida por el objeto SM_Dropbox cuando se emita una señal del tipo QNetworkAccessManager (Hereda de QtNetwork), esto se hará cuando se reciba una respuesta de red (que quiere decir que se ha terminado una petición), y la señal tendrá guardada dicha respuesta como una QNetworkReply*.

Por ahora esto es todo lo que puedo decir respecto al diseño, voy a ver si puedo ir implementándolo y ver cómo funciona en el repositorio del proyecto (https://github.com/AdrianBZG/SyncMe/).

Primeros pasos

Después de estar pensándolo un poco, he decidido ponerme manos a la obra y he creado el repositorio en GitHub donde se irá desarrollando SyncMe poco a poco, el enlace es este (https://github.com/AdrianBZG/SyncMe/).

Además, como prometí (lo prometido es deuda :P) he estado estudiando acerca del funcionamiento de Google Drive y Dropbox, sobretodo las facilidades que ofrecen a los desarrolladores, dando como resultado el haber encontrado dos maravillosas herramientas:

Vale, ¿y qué pasa con eso?:

Pues básicamente, gracias a esas dos herramientas puedo conseguir un “punto de comunicación” entre la aplicación “SyncMe” y las respectivas plataformas con la que te va a permitir sincronizarte (Google Drive y Dropbox), es decir, que ya tenemos el punto de entrada necesaria para obtener los datos de los servidores de datos.

¿Incovenientes?:

Por supuesto, nada es perfecto, bien… pasaré a explicar cuáles son los incovenientes:

  • Yo con el lenguaje de programación que ‘mejor’ me manejo es con C/C++, y lamentablemente tanto la API de Google Drive como la API de Dropbox NO ofrecen soporte para C ó C++; esto es algo que hay que tener en cuenta.

Entonces, ¿qué se puede hacer?:

  • La opción más rápida sería la de utilizar otro lenguaje de programación, como Java, pero creo que es mejor utilizar uno en el que me maneje de la mejor forma posible, de forma que la codificación no sea un problema.
  • Por suerte, tanto la API de Google Drive como la de Dropbox ofrecen soporte para llamadas HTTP (¡bravo!), por lo que podemos sin problemas decir por ejemplo: “oye realiza la siguiente petición a la API de Dropbox”, utilizando para ello paquetes codificados en JSON.
  • En el caso de Dropbox podremos hacerlo directamente desde el código en C++ pero en el caso de Google Drive la aproximación debe ser de esta manera:
    • Primero hay que tener en cuenta que tendremos que utilizar un punto de comunicación intermedio, en JavaScript, que reciba las peticiones que queremos hacer (desde la aplicación en C++) y las envíe al servidor de Google Drive.
    • Lo siguiente será que el servidor de Google Drive procesará dicha petición y generará un resultado, que mandará al punto de comunicación intermedio en JavaScript.
    • Finalmente, la aplicación en C++ será notificada cuando esta petición haya finalizado y el resultado esté efectivamente almacenado en el punto de comunicación intermedio, para esto haremos uso de señales asíncronas, o en determinados casos (operaciones críticas) haremos uso de funciones bloqueantes que se quedarán a la espera de recibir una respuesta.

Tengo las ideas bastante fresquitas así que ahora mismo después de darle click a “publicar” en este post me pondré a ir haciendo el “diseño del software” en lo referente al motor de Dropbox que utilizará SyncMe, para ir obteniendo una visión más consistente de las ideas.

Nacimiento de la idea

Recién he creado este blog para ir hablando poco a poco de “SyncMe”, que es el nombre que tendrá la aplicación que tengo pensado desarrollar para el X Concurso Universitario de Software Libre a nivel nacional y en el VI Concurso de Software Libre a nivel local en la Universidad donde me encuentro estudiando Ingeniería Informática (Universidad de La Laguna), a continuación hablaré un poco de cuál es la idea:

Los propósitos generales con los que quiero que se enfoque SyncMe son los siguientes:

  • Un punto de gestión centralizado para la sincronización de nubes, en concreto la idea es empezar por Google Drive y Dropbox ya que son las más utilizadas y las más útiles según mi experiencia personal.

¿Por qué?

  • Básicamente esta idea se me ha ocurrido porque yo soy, por decirlo un poco a lo bruto, una persona “adicta” a las ‘nubes de datos’ y tengo varias cuentas en distintas plataformas (Google Drive, Dropbox…etc.), y naturalmente muchas veces se me hace engorroso el tener que utilizar varias aplicaciones distintas para gestionar mis cuentas, además de que algunas de ellas no son cross-platform y sólo están disponibles, por ejemplo, para Windows.

Sí, pero, ¿es viable el proyecto?

  • En mi opinión, la respuesta es un sí rotundo, sobretodo si se enfoca el proyecto desde el punto de vista Open Source o Software Libre, es decir, tiene que ser un trabajo colaborativo de muchas personas, de forma que desarrollarlo sólo sea cuestión de que cada persona vaya aportando su granito de arena: ideas, código, detección de bugs…etc., todo ayuda.

Investigaré un poco acerca de qué aproximación o qué enfoque puedo darle al desarrollo inicial y hablaré sobre esto en un próximo post.