Feedyes – obtenim feeds RSS de sites que no tenen feeds
Sempre m’he volgut sindicar a mini-itx però no disposa d’enllaç a un fitxer XML amb els feeds en format RSS ni ATOM. Així que el meu bloglines sempre ha estat esperant que això passes, de fet, la cosa no ha canviat. Però per fi he trobat un servei web que genera feeds automàticament d’altres sites que no ho tenen i a més gratuït, estic parlant de Feedyes en un 1s m’he donat d’alta i he generat els feeds de la web mini-itx. Així que si algú més s’hi vol sindicar ja ho sap. El sistema és força intuitiu tot i que us recomano que lliu el que diuen els passos per crear un feed sinó potser us passeu 1min com jo pensant on heu d’apretar per seguir, el que fa no llegir les coses.
nova versió del devilspie
A finals del 2004 vaig parlar del devilspie una eina que em permet llençar les aplicacions als workspaces. Doncs bé la qüestió és que la nova versió del Devil’s pie ha canviat totalment el format de configuració i totes les configuracions que tenia montades per la versió antiga no m’han servit per res.
L’antiga sintaxis es basava en XML l’actual s’assembla més a un algoritme. Abans tot estava en un fitxer de configuració i ara s’han de crear fitxers amb l’extenció .ds dins el directori ~/.devilspie i dins podem veure coses com aquestes:
(if (contains (window_name) "Firefox") (set_workspace 4))
La configuració anterior envia el firefox a l’area de treball 4, un altre idea perquè quedi clar el senzill que és d’usar, carreguem l’asmn perquè estigui present a totes les arees de treball:
(if (contains (window_name) "aMSN") (pin))
Ara uns links cap als manuals de veritat:
SOAP vs XML-RPC
Abans de començar un detall important sobre el món XML, compte a no acabar com el de la foto:
Bé doncs ens trobem davant de dos protocols del tipus RPC (Remote Procedure Control), o sigui, que serveixen per intercomunicar dos processos que estan corrent en sistemes dispersos. Si mai ús han donat Sistemes Operatius, segur que us han fet fer la típica pràctica d’RPC d’Unix programada en C. El que acostuma a ser el mal son de tots els alumnes d’informàtica i telemàtica. Doncs bé, tranquils des d’aquella teoria inicial sobre RPC s’ha avançat molt.
De fet, jo fa molt de temps que uso els XML-RPC per implementar web-services senzillets entre les meves aplicacions. Hi ha un protocol que s’usa molt en el món del blogging, es diu ping (no el de tota la vida per mirar si un sistema és viu). Bàsicament el ping el que fa és aprofitar l’XML-RPC per notificar a un altre servei web un event de la nostre web, concretament que hem actualitzat el blog. També s’usa XML-RPC per fer trackback entre articles a diferents blogs. Així podem informar a un altre blog de que hem parlat sobre aquell article que ell ha escrit. Fixeu-vos que tot això és independent del sisteam operatiu, el servidor web, l’aplicació, etc.
Com podeu veure l’XML-RPC esta molt estès i és realment molt útil i senzill d’usar en totes aquestes aplicacions que us comento. Per tant, podriem dir que l’XML-RPC esta orientat a la simplicitat i la senzillesa d’ús, permet passar dades entre processos codificant-les en XML i usant l’HTTP com a protocol de transport. El model de dades que usa l’XML per implementar XML-RPC és molt senzill i si mireu un HTTP-POST que transporti una transacció XML-RPC veureu que és molt senzill entendre les estructures de dades que es monten a partir de les típiques etiquetes.
Llavors ús preguntareu; si l’XML-RPC va tan bé perquè carai vull el SOAP o fins hi tot; què carai és el SOAP. Doncs bé, el Simple Object Access Protocol (SOAP) és un protocol RPC com ja he dit i també es codifica en XML i es transporta sobre HTTP, i encara us diré més també serveix per transportar informació estructurada en el seu interior. La diferència escencial és que és capaç de transportar estructures de dades força complexes i a més permet definir contra quin mètode de quina classe han de ser usades aquestes estructures. Així doncs, el SOAP ens permet oferir infinitat de serveis en un sol biding (publicació) de servei.
Com podeu veure l’escència és la mateixa però la potència és ben diferent. SOAP al suportar models de dades tan complexos fa que quan intentem mirar un XML dels que usa per fer les transaccions ens costi força entendre el que hi ha dintre. Ja que a la mínima que ens compliquem una mica el model de dades a passar pel webservice es fa ben difícil entendre el munt d’etiquetes i d’atributs de les etiquetes que es creen.
A més SOAP disposa de diferents extencions que el fan encara més potent. Bàsicament les més conegudes són SOAP 1.1, SOAP 1.2 i WSDL. Aquest últim és el més usat per implementar WebServices, el seu propi nom ja ens indica aquest fet WSDL: Web Services Description Language. Concretament Microsoft amb .NET, IBM i Sun amb Java fan diverses implementacions del WSDL per tal d’implementar WebServices en les seves arquitectures. Això ens va de perles a la gent que ens agrada el PHP, perquè permet que ens entenguem amb els ASP, JSP, servlets i altres similars des del nostre PHP5 que ja implementa suport de SOAP/WSDL de serie.
Si voleu començar a jugar amb el SOAP i el PHP5, a la pròpia web de Zend podeu trobar aquest document: PHP SOAP Extension. Per una informació més tècnica del WSDL, la gent d’xml.com tenen un munt de documents sobre el tema, concretament us recomano: WSDL first i encara un altre sobre el mateix Examining WSDL. Si ja controleu l’UML és una bona idea que comenceu a veure com es modelen els WSDL des d’UML, un bon document per començar UML for Web Services.
Abans d’acabar l’article si voleu un document seriós que resolgui els vostres dubtes sobre les diferències que hi ha entre XML-RPC i SOAP, sobretot no us perdeu: XML-RPC vs SOAP (local)d’en kate rhodes.
Aprenent UML
Ja he repetit mil vegades que no sóc informàtic, així doncs, mai havia après UML fins aquest cap de setmana que aprofitant que estava de Rodriguez m’he fotut una marató d’aquelles que feia temps que no feia.Doncs per tal de posar remei a la meva mancança en el tema UML m’he llegit/estudiat el llibre Aprenda UML en 24 Horas (editorial: Prentice Hall. 2001. Autor: J. Schmuller. ISBN: 968444463X. link amazon).
La veritat és que encara estic destrossat de l’esforç però us recomano el llibre. Realment no és res de l’altre món però si com jo teniu un problema i no pas la teoria per plantejar-lo, doncs jo diria que és la millor solució que he trobat per avui dilluns haver-lo pogut afrontar ja amb UML directament. M’ha agradat molt el fet que esta orientat a objectes tot el que explica això ja et permet pensar ràpidament en conceptes que coneixes i que et permeten avançar moltíssim.
Una altre cosa important del llibre és que no comença amb la pesada teoria de l’UML sinó que va directament a ensenyar-te a usar les eines, és a la segona part del llibre on tot això es posa en pràctica en un problema real i llavors et queda ben clar com s’han d’usar totes aquestes eines. Ara com sempre passa quan entres en una matèria que fins ara era nova és que tinc el gusanillo d’aprofundir més en alguns conceptes especialment en temes de Design Patterns.
Fer un business plan sense tenir-ne ni idea…
Com sabeu jo sóc telemàtic i això dels negocis ho estic aprenent a base de caure i aixecar-me. Doncs bé estic cansat d’escriure plans de negoci sense tenir un patró clar de quins són els punts que aquest ha de contenir. Així que la setmana passada vaig escriure el que sota la meva opinió és el millor que he escrit, encara no m’han donat feedback de que tal esta. Crec que defineix perfectament el que vull que sigui movilpoint i després de molt de temps i molts esforços jo diria que tots els socis hi estem d’acord.
Però bé, jo l’únic que us volia dir als que tingueu la necessitat de fer-ho i com jo només disposeu de l’ajuda del google que a mi em van anar bé quatre documents que a continuació us enllaço. Es tracte de 4 articles no massa llargs i que si els sumem al fet de tenir les idees molt clares sobre el nostre negoci ens ajudaran a tenir una guia de quins són els punts a tocar i explicar en el que s’ha de convertir en el llibre de navegació del nostre negoci.
- El plan de marketing en la empresa (local) amb aquest document ja teniu per on començar. Té una minidescripció de tots els punts a tocar al vostre business plan. En el meu cas alguns no calia i en faltaven alguns altres. Però en general m’ha estat molt útil.
- La matriz DAFO y su aplicación en el ajedrez (local) si com jo això de DAFO us ha sonat a japonés, doncs bé resulta que és un dels punts que s’han de posar en un pla de negoci. Així doncs amb aquest petit document podem resumir les vostres: debilitats, amenaces, fortaleses i oportunintats.
- Estrategias de Marketing – La Matriz RMG I aquest document ja parla de temes una mica més avançats però si en el vostre business plan voleu realment explicar d’on sortiran els diners en la vostre empresa és una bona idea incloure’l.
- Estrategias de Marketing – La matriz RMG II la segona part del document que comentava avanç. Com podeu veure aquest tema no és trivial, però tampoc és indispensable en molts casos. Així que no us desanimeu.
En el primer dels documents vaig trobar un quadre resum que m’ha ajudat molt a l’hora de no perdrem escribint. Així que per no perdre aquesta eina tan útil aquí teniu l’enllaç.
protocol de capa 4: SCTP (Stream Control Transmission Protocol)
Tot navegant per la xarxa fa uns dies que vaig trobar un breu document d’IBM que parlava d’un protocol que fa temps que coneixo però que mai m’havia parat a pensar com funcionava per dintre. Es tracta d’un protocol de la capa de transport que intenta ser una eina molt més precisa i efectiva en alguns problemes que presenten els protocols TCP i UDP al transportar aplicacions d’streaming per sobre seu. Tot i la seva orientació a aplicacions multimèdia es pot usar per moltes altres aplicacions.
Més que fer un resum de les aplicacions que són òptimes corre sobre aquest relativament nou protocol (l’RFC és de l’any 2000) el que jo he trobat molt interessant i que vull explicar una mica aquí són dues funcionalitats que desconeixia completament d’aquest protcol:
1) Multi-homing
En un enllaç podem adreçar el tràfic d’un host a un altre a través de més d’una interficie de xarxa i de més d’una IP. A diferència del protocol TCP les comunicacions no s’estableixen entre un socket que uneix dos hosts, sinó que SCTP ens permet establir connexions que permeten connectar dos hosts a través de més d’una interficie simultaneament. El sorprenent és que el propi protocol de transport, al igual que fa TCP, s’encarrega d’entregar els paquets de forma ordenada a la capa d’aplicació.
2) Multi-streaming
Cada paquet SCTP té una associació d’stremas, o sigui, multiples streams en el seu interior. L’importància d’això esta en que, per exemple, quan estem esperant una retransmissió després d’haver perdut un paquet; això no afecta als altres streams de l’associació d’streams. Aquest és el problema més greu que tenim en TCP, perquè si ens falta el paquet inicial aquest bloc d’informació que ens falta bloqueja la resta d’informació que ja hem rebut. Per això, no és gens òptim treballar en connexions TCP si estem usant aplicacions basades en stream de dades. A part dels problemes de sobrecarrega de tràfic que suposa haver de tenir una capçalera tan pesada com la TCP, en protcol que depenen tan de la latència del canal.
El document també ens parla d’altres característiques molt interessants d’aquest protocol de transport. Per exemple, que per negociar l’obertura d’un enllaç ja no es fa amb una three-way handshake sinó que s’usa un sistema millorat que evita de forma intrínseca els problemes de SYN flood. La resta de característiques no les he vist especialment interessants així que si les voleu coneixer us convido a llegir el document en que m’he inspirat per escriure això: Better networking with SCTP (local).