Idees de projectes

De WikiProves

Aquí aniré posant idees de possibles projectes a realitzar.

Si un projecte va agafant cos li faré una subpàgina i si es comença a materialitzar crearia un repositori i projecte al Trac (podeu veure a la meva web els projectes oberts).


Contents

Editors concurrents

La idea surt al conèixer la seva existència a través de l'artícle a Bulma sobre el Gobby.

Algunes idees que tenim (Adrià Gascón i jo) sobre aquest tema són:

KNetManager: Gestor de les connexions a xarxes per a GNU/Linux-KDE

Els gestors actuals no acaben de tenir totes les funcionalitats que a mi m'agradarien; moltes d'aquestes funcionalitats les trobem en un o altre gestor, però no n'hi ha un que les tingui totes.

Aquesta és la meva proposta.

Servidor de concurrències

Problema

La idea surt del problema que apareix quan estàs treballant en un projecte en grup, utilitzes un sistema de control de versions (per exemple, el Subversion), però dos programadors es posen a treballar sobre el mateix fitxer, i te n'adones quan vas a fer el commit.

Solució

La solució que veiem és utitilitzar un editor concurrent, però necessitem que, sense la necessitat d'un e-mail, trucada, etc. saber si hi ha algú treballant sobre aquell fitxer.

El projecte

El projecte consistiria en un servidor + protocol i un conjunt de plugins per als editors concurrents amb els que definissis una connexió al servidor per a cada projecte en el que estiguéssis treballant, i quan vas a editar un fitxer d'algun d'aquests projectes, primer es comunicaria amb el servidor per saber si algú més està treballant-hi, i si és així et connecta a la sessió del primer.

El resultat final ideal seria un editor concurrent amb el plugin pel nostre servidor de concurrències i, també, un plugin per poder treballar amb el Subversion (commits, updates, etc...).

Editor concurrent per a Wikis

Problema

TODO

Solució

Que quan entréssis a editar una entrada del wiki entréssis en un editor concurrent integrat, i si una segona (o tercera, o...) persona entra, es connecta a la sessió existent.

El projecte

???

Plugin per a eMule

Problema

En el hipotètic cas que marxes a l'estranger durant un temps i no saps de quina conexió a internet disposaràs. Disposes d'un servidor al teu pais d'origen. Durant l'estada pots necessitar software, i sobretot música, que no estàs disposat a comprar. I si la conexió, o les lleis del pais no et permeten fer servir el preuat emule?

Solució

Una aplicació que et permeti fer servir l'emule i gestionar les descàrregues remotament.

El projecte

Ja existeix una eina per gestionar e-mule via web (això diu l'Èric). Em quedo més tranquil.


Kontact on-line

Problema

Estem acostumats a utilitzar el Kontact (o qualsevol altre PIM) on tenim:

  • e-mail: filtres antispam, antivirus i filtres per organitzar el correu (llistes de distribució, etc) i el correu organitzat per carpetes, importància, etiquetes, etc...
  • contactes: informació completa dels nostres contactes (e-mails, IM, adreça...)
  • calendari
  • tasques pendents
  • diari
  • notes-basket
  • lector de feeds RSS

i volem seguir utilitzant, quan estem amb el nostre ordinador, aquesta aplicació (perquè ens agrada, perquè és àgil, perquè està ben integrada, perquè ens permet sincronitzar amb la Palm...) però quan estem fora de casa no podem accedir a tots aquests recursos i si accedim a algun d'ells per altres canals (webmail de l'ISP, llegim manualment els feeds...) el que hem fet no queda persistent (els e-mails no queden com a llegits, ni els feeds, ni els podem classificar...).

En Javier Linares ens ho explica molt bé en aquest artícle.

Solució

Tenir tots aquests recursos on-line (amb un sistema tipus offline-imap per si perdem la connexió que no ens quedem sense res) i poder-hi accedir tant des del Kontact com des d'un client web.

Funcionalitats:

  • e-mail
    • veure un sistema de filtres que s'executin a nivell de servidor (per separar el correu per llistes de correu... etc) i, a poder ser, configurable desde KMail. Solucions: amb filtres procmail, amb maildrop com expliquen en aquest artícle, amb filtres Sieve...
  • calendari
  • lector de feeds

En principi aquesta funcionalitat (o en part) ens la dona el servidor groupware Kolab, però tant a nivell de servidor com de client ens ofereix tot el que volem? podriem tenir el mateix sense necessitat d'un servidor propi (utilitzant un servei de hosting com DreamHost)?

Implementació

Sense servidor propi

Aprofitant un webhosting com els de DreamHost.

  • e-mail i contactes
    • buscar la manera de tenir els contactes compartits (a l'IMAP?)
    • buscar un webmail que mostri els fils i pugui accedir als contactes compartits
  • calendari
    • veure si es pot tenir el calendari a l'IMAP i buscar/implementar un client web (mirar l'api del calendar de Google, o
    • veure si el calendari de Google es pot editar en línia, si s'hi pot emular el funcionament de offline-imap
  • tasques pendents
    • veure si es pot tenir el recurs de pendents a l'IMAP i buscar (o implementar) un client web
    • buscar un alternativa
  • diari, notes, basket
    • idem, però per ara sense una gran necessitat
  • lector de feeds
  • Dubtes
    • L'accés IMAP pot ser offline-imap?
    • Accepta filtres Sieve
    • Es poden posar altres arxius/directoris a l'IMAP?
    • El calendari de Google és codi lliure? la comunicació es basa en protocols estandards?

Servidor propi

Basant-nos en el Kolab: configurant-lo, fent afegits o reimplementant-lo per donar-li les característiques que es comenten a dalt.

  • e-mail i contactes
    • buscar un webmail que mostri els fils i pugui accedir als contactes compartits
  • calendari
  • tasques pendents
    • buscar (o implementar) un client web
  • diari, notes, basket
    • idem, però per ara sense una gran necessitat
  • lector de feeds
    • veure si existeix al Kolab aquest recurs, o
    • buscar o implementar una solució de l'estil FeedLounge o que implementi les seves característiques però a poder ser que se sincronitzi amb l'aKregator


Protocol per fer calendaris col·laboratius

Idea

Buscar (veure api del calendar de Google), investigar, implementar un protocol a l'estil RSS (o aprofitar aquest) per tal de compartir events de calendari en format estàndard (iCal?) de manera que hi pugui haver calendaris col·laboratius.

La manera de publicar events en aquests calendaris col·laboratius seria sindicant un calendari (o una categoria d'events o events aïllats) o enviant-los a través d'altres interfícies (formulari web, SMS, accés wap...)

Implementació

Basant-nos en un servidor de calendari (Google o Kolab):

  • Implementar el protocol i el feed de publicació del protocol. Fixar-se en l'OPML.
  • Implementar la sindicació d'un feed d'aquest protocol.
  • Implementar els altres mecanismes de publicació.

Consulta i notificador de correu basat en filtres

Motivació

No disposes d'un terminal mòbil amb capacitat de rebre e-mails (o no hi vols tenir configurat el teu compte) però sí MMS i estaràs fora tot el dia (o matí, o setmana, o mes...) i estas pendent de rebre un mail important que el vols llegir el meś aviat possible.

Solució...

Idea

Tenir un servidor/servei que via interfície web/wap/SMS formatejat pot configurar-lo perquè estigui atent als e-mails rebuts i quan es complís una certa regla (l'e-mail prové de cert destinatari, té tal títol...) tel reenvia en format de missatge MMS (o t'envia només el remitent i títol com un SMS i un link a on pots consultar l'e-mail complet?).

També es podria fer que es servís per consultar correus que ja estan a les carpetes (del client? del servidor? veure implementació): especifiques les condicions (entre elles, per exemple, la carpeta on buscar) i t'envia els e-mails que coïncideixen.

Fer el mateix però per consultar/rebre notificacions d'events de calendari. A nivell tècnic fixar-se en l'OPML.

Implementació

  • Opcions de tipus de servei/servidor:
    • Seria un afegit sobre el servidor de correu? (es pot fer en un servidor del que no ne'ts l'administrador? o en un webmail)
    • Seria una aplicació (python?) que actuaria sobre filtres Sieve
    • Seria un dimoni (instal·lat en el client) que estaria entre el servidor i el client (es descarregaria el correu i després li passa al client) o amb un funcionament de l'estil bogofilter o spamassassin?
    • Seria algun tipus de plugin pel client de correu?
    • Per als webmails: seria un parsejador de la web del webmail?
    • Seria un client "només lectura"? es baixa el correu via POP (però no l'elimina) o via IMAP (però només el llegeix, no el modifica, elimina) i l'analitza. Si s'implementa l'opció de consultar e-mails antics, en el cas del POP hauria d'emmagatzemar-los.
  • Implementar la interfície web/wap/SMS per rebre i processar les peticions
  • Implementar el sistema d'enviament de l'e-mail (com un MMS o com un SMS o posant l'e-mail en una web i enviant el link).

ReMSS: Resource Management&Share System

Idea

És un recopilador de recursos (veure apartat Tipus de recursos) per organitzar-los segons la informació que ens donen (veure Tipus d'informació) per poder-hi accedir, treure-li profit i compartir més i millor.

Cada un d'aquest tipus d'informació tindrà un "contenidor" amb una informació comuna en tots (titol, resum...) i una informació específica que inclou la informació en qüestió en un format estàndard (un e-mail en format ¿?, un contacte en format vcard, una nota en text pla...) i estarà guardat en una o més cistelles (veure l'aplicació basKet) que podrà contenir un element (no es distingirà que és una cistella) o varis.

Aquestes cistelles s'organitzaran en categories jerarquitzades (arbre amb múltiples pares com el Drupal?), tags... (s'ha de veure si cada tag, categoria és en si una cistella)

Tipus de recursos

  • publicacions pròpies
    • notes
    • artícles
  • URLs
    • websites
    • weblogs i webs amb feed rss
    • artícles o pàgines concretes
    • artícle d'un feed
  • e-mails (un o un fil/conversa)
    • e-mails d'una llista de distribució (té accés web)
  • contactes
  • arxius (PDFs, documents Oasi, fotos, videos, audio...)

Tipus d'informació

  • documentació: manuals, HowTo, referències, experiències...
  • contingut artític: fotos, videos, podcasts
  • tasca pendent
  • event (calendari)
  • recomanació
    • llibre
    • música
    • pel·lícula
    • documental
    • serie

Compartició

  • publicació d'artícles: feed rss
  • links: del.icio.us
  • arxius: mlDonkey, aMule
    • albums de fotos: gallery2, flickr, picassaweb
    • videos: youtube, alternativa lliure?
  • recomanació musical: last.fm
  • recomanació pel·lícula: IMDb
  • event: calendari de Google o servidor propi (veure projecte Kontact on-line o Calendaris col·laboratius).
  • tasques a fer: servidor propi (veure projecte Kontact on-line)
  • publicació de les novetats (log): feed rss

Implementació

Com un sistema 100% web

Basant-nos en Drupal, per exemple, conjuntament amb altres solucions (gallery2, etc...)

  • Crear tipus de node per cada tipus de recurs amb una interfície (gràfica i lògica) adaptada a cada tipus, guardant tots els fitxers com adjunts.
  • Implementar visors per cada tipus de node.
  • Implementar la comunicació entre aplicacions (Drupal <-> Gallery).
  • Implementar la comunicació entre ReMSS i xarxes socials (del.icio.us, last.fm...)

Com un servidor complet

Afegint aquestes funcionalitats al Kontact on-line+Calendaris col·laboratius+

  • Implementar sistema d'emmagatzament pels recursos que no estan al Kontact on-line: links, documents...
  • Implementar interfície web/d'escriptori pels links, documents...
  • Implementar el sistema d'etiquetatge i metainformació
  • Implementar l'interfície web del sistema

Idees per al PFC (Eric)

Motor de render RAY-TRACING en temps real sobre Cell (Playstation 3)

Idea

Es tracta d'aprofitar la potència del processador Cell (218 Gigaflops de CPU + 1.8 Teraflops de GPU = 2 Putos Teraflops) i el fet que disposa de 8 processadors treballant en paral·lel per programar un motor de renderitzat 3D basat en la tècnica del traçat de raig (super realista), la qual simula les interaccions de la llum amb la matèria (reflexions/refraccions...), i que és molt fàcil de paral·lelitzar, ja que cada raig és independent dels altres. Aspectes a tenir en compte en el cost de l'algorisme:

  • Si volem que sigui en temps real ha de ser capaç de generar 25 imatges per segon
  • Les imatges han de tenir una mida mínima exigible d'uns 400x300 píxels.
  • Si volem que les imatges tinguin un nivell de realisme acceptable, el nivell de profunditat de la recursió ha de ser major que 2.
  • Si volem aplicar antialiasing per a generar imatges de més qualitat hem de tenir en compte el nombre de rajos traçats per píxel (si és 1 no tenim antialias)
  • Cal tenir en compte la complexitat de l'escena (nombre d'objectes reflectants...)

Cal equilibrar totes aquestes variables i veure si és possible crear un motor de raytracing en temps real amb els mínims que he mencionat.

Llenguatge d'alt nivell per a programació quàntica

Introducció

La computació quàntica és un camp d'investigació molt recent i molt prometedor. Aprofita les propietats màgiques de la mecànica quàntica per a fer càlculs exponencialment més ràpids que els algorismes clàssics. Aquests algorismes quàntics no s'han pogut provar encara ja que no existeix cap computador quàntic degut a la gran dificultat tècnica que té construir un aparell així (en realitat sí que s'han provat en computadors quàntics experimentals formats per pocs àtoms... i funcionen!).

Idea

Els algorismes quàntics sempre es presenten en forma de circuits de portes lògiques (en realitat, de portes quàntiques... com no), és a dir, que es pensen a un nivell molt proper al hardware. Molaria poder fer una abstracció i raonar la programació quàntica des d'un nivell més elevat, ja que ens aportaria un punt de vista diferent i ens ajudaria a entendre millor els intringulis d'aquest món. Un altre tema és que hi ha molt pocs algorismes quàntics, cosa rara amb la de cocos que hi ha ficats en el tema; jo crec que una de les causes de que s'avanci tant lentament és que no s'ha treballat prou el llenguatge.

La putada (o no)

Evidentment no soc el primer en pensar algo així, he buscat per internet i resulta que ja s'ha inventat una mena de llenguatge quàntic d'alt nivell anomenat QML, però no és l'únic, hi ha uns quants projectes dedicats a aquest propòsit i amb ments bastant brillants; per tant, difícil que pugui aportar alguna cosa nova. Però també pot ser un avantatge, ja que em puc basar en el que està fent aquesta gent, o intentar fer algo nou i comparar-ho. El que està clar és que la cosa encara està en dodotis i es poden fer moltes coses.

Personal tools