symfony: cridant funcions i18n des de les actions
Una eina molt potent de symfony és la d’internacionalització (i18n), concretament la funció __() es converteix en una de les més usades i indispensables en la capa de vista de les nostres aplicacions. Ja que permet després de forma molt senzilla traduir la nostre aplicació a l’idioma que sigui. El problema és quan des de la part del model em de carregar informació a objectes que després seràn directament mostrats per la vista. Si volem que aquesta informació sigui fàcilment traudible malgrat trobar-se en el model i no pas en la capa de vista la cosa es complica una miqueta. De fet, fins avui no sabia com es feia i ho he descobert gràcies a un snippet publicat a la web de symfony.
Concretament symfony tracta la funció __() com el que ell anomena un helper que ens permeten dinamitzar i donar moltíssima potència als nostres templates. Si no sabeu el que són els helpers us recomano que repasseu la documentació de symfony concretmanet View chapter. De fet, symfony té molts tipus de helpers: url, javascript, form, i18n, etc. fins hi tot podem programar els nostres propis helpers.
Així doncs el que comentaré serà com usar els helpers de tipus i18n des del model, però la resta de helpers també es poden invocar de la mateixa manera.
Primer cal pensar en incloure des del model el codi on es declaren les funcions del helper:
include_once('symfony/helper/I18NHelper.php');
Per invocar la funció __(), hem de fer:
sfConfig::get('sf_i18n_instance')->__($text, $args, 'messages');
El que no sé és si les eines de traducció que es dediquen a extreure els missatges de les funcions __() són capaces de recorre també els fitxers d’accions definits al model o només passen pels templates. Tot i que no deu ser molt difícil dir-los que també mirin els fitxers del model.
Aprofitant que parlo del tema de la internacionlització us recomano una eina per traduir els fitxers d’idioma (XLIFF) és una eina multiplataforma programada en java: open language tools XLIFF editor. Com podeu veure l’aspecte i la simplicitat és inmillorable. Ideal per persones no tècniques que ens poden fer les traduccions de les aplicacions.
Per generar els fitxers XLIFF des de symfony us recomano: HowToGenerateI18NFiles. És un petit manual que he trobat al wiki de symfony.
symfony: Problemes de javascript
Symfony usa prototype com a framework de JavaScript. Malgrat la potència del projecte té un petit problema de disseny que ens dona problemes quan intentem integrar el nostre codi fet en prototype/symfony amb codi JavaScript de tercers. De fet, el problema de disseny és molt senzill prototype exten dues classes bàsiques de JavaScript: Object i Array ambdues són classes molt bàsiques i sovint usades en qualsevol script així doncs quan aquest codi intenta usar aquestes classes bàsiques al estar exteses no tenen el comportament habitual, així doncs el codi d’aquestes persones s’ha d’adaptar per suportar les modificacions de prototype. Així doncs, si això no és possible tindrem un problema d’incompatibilitat entre codis.
Si voleu més detalls tèncis sobre el problema l’Oriol m’ha passat un parell d’enllaços es raona el problema:
PoE – Power over Ethernet
Jugant amb els amics més d’una vegada hem injectat l’alimentació d’un dispositiu a través del cable ethernet l’invent és una mica d’anar per casa. Però serveix per estalviar-se una bona quantitat de calers i poder tirar només un cable entre el switch i el dispositu a alimentar. Per exemple, en algunes instal·lacions wifi del poble s’ha fet: Unim eBosc i ePineda (quasi 1km).
Doncs bé fins que no m’he llegit l’article que us vull recomanar pensava que l’estàndard PoE de la IEEE no era gaire més del que ja feiem nosaltres. Però després de llegir Power over Ethernet: the reality of designing a powered device (local) realment he vist que per començar els elements que fan falta per crear un dispositiu que compleixi l’estàndard PoE són força més complexes i professionals que com ho feiem nosaltres. Un bon exemple és mirar l’esquema dels components que componen un dispositiu PoE.
Així doncs us recomano perdre 5min en llegir l’article i tenir el tema PoE més que clar. Que sempre va bé saber perquè paguem tants calers per certes coses.
Tipus d’VPNs
Quan parlem d’VPNs gairebé tothom té clar perquè serveixen i què fan. El fotut és quan comencem a parlar de quin tipus d’implementació s’ha d’usar o s’ha usat per montar-la. Això fa que un munt de sigles comencin a saltar sobre la taula i al final si no tenim una molt bona base tècnica som incapaços d’entendre a què es refereixen. Aprofitant un article que ha aparegut a Network Systems DesignLine, de fet, és la primera part d’una serie encara incompleta anomenada Compare, design, and deploy VPNs–A tutorial–Part I he decidit fer un petit resum dels tipus d’VPN més comuns.
Dispositius d’una VPN
Per tal de poder parlar en propietat quan parlem dels elements de la VPN a continuació s’intenta definir una mica els dispositius que intervenen (o poden intervenir) en una VPN i on estan situats.
En el costat del client:
- Customer (C) devices els dispositius C són simples, per exemple routers i switchos dins de la xarxa del client. Aquests dispositius no estan connectats a la xarxa del proveedor de servei. Aquests dispositius no saben distingir si estan o no dintre d’una VPN.
- Customer Edge (CE) devices són els dispotius del client que donen conectivitat a la xarxa del proveedor de serveis.(via Provider Edge [PE]).
- CE-r routers
- CE-s switches
En les VPNs basades en CE, els dispositius CE si que estan disponibles per ser usades amb la VPN. Si les VPNs estan basades en els PE, els dispositius CE no estan disponibles per la VPN.
En les VPNs site-to-site, els dispositius del proveidor de serveis es poden classificar en:
- Service Provider (P) devices els dispositius P com ara routers i switches dins de la xarxa del proveedor que no es connecten directament a la xarxa del client.
- Service Provider Edge (PE) devices connectats directament a la xarxa del client a través dels dispositius CE. En les VPNs basades en PE aquests dispositius són visibles des de l’VPN, en les basades en CE no són visibles.
- PE-r Provider Edge routers
- PE-s Provider Edge switches
- PE-rs Provider Edge devices that are capable of both routing and switching
VPNs de capa 2, com ara VPLS, afegeixen un nivell a la gerarquia per ser més escalable (VPLS llavors passa a ser Hierarchical VPLS [H-VPLS]). En aquest cas, les funcionalitats dels dispositius PE, es divideixen en dos parts U-PE i N-PE.
Cal que no oblidem que els U-PE i els N-PE són equivalents al PE-CLE i al PE-POP, respectivament. Quan tenim un dispositiu PE-U de capa 2, podem referir-nos a ell com un MTU-s.
Altres dispositius d’una VPN poden ser els NAS i els concentradors o gateways d’VPN. Un NAS és un dispositiu que fa d’interficie entre la xarxa d’accés (com ara PSTN) i les xarxes de conmutació de paquets (com ara un backbone IP). En un accés remot VPN el NAS pot treballar com a finalitzador de tunel.
Depenent del protocol usat per establir un accés remot el NAS es pot anomenar de diferents formes Layer Two Forwarding (L2F) Protocol NAS, Layer Two Tunneling Protocol (L2TP) Access Concentrator (LAC),o Point-to-Point Tunneling Protocol (PPTP) Access Concentrator (PAC).
Un gateway o concentrador d’VPNs actua com a punt final d’un túnel (VPN endpoint), especialment quan parlem d’accessos remots o VPNs basades en CEs (site-to-site).
Segons el protocol usat per aquests accessos remots el gateway o concentrador d’VPNs es pot anomenar, per exemple, L2F Home Gateway, L2TP Network Server (LNS), o PPTP Network Server (PNS).
Tecnologies i protocols usats en VPN del tipus Site-to-Site (o LAN-to-LAN)
En les VPNs site-to-site (o LAN-to-LAN) la informació del client viatja entre dispositius CE o entre dispositius PE.
- IPsec són un conjunt de protocols dissenyats per protegir el tràfic IP entre gateways o hosts. Normalment s’usa aquest protocol per establir VPNs entre CEs.
- GRE usat per fer túnels i transport de multiprotocols entre CEs. La seguretat de GRE és baixa o no inherent al protocol, però si volem podem aprofitar IPSsec per securitzar els túnels montats en GRE.
- Draft Martini (Any Transport over MPLS–AToM) permet transportar protocols punt a punt com ara Frame Relay, ATM, Ethernet, Ethernet VLAN (802.1Q), High-Level Data Link Control (HDLC), i tràfic PPP sobre MPLS.
- L2TPv3 permet transportar protocols com ara Frame Relay, ATM, Ethernet, Ethernet VLAN, HDLC, i tràfic PPP sobre IP o altres protocols de backbone.
- IEEE 802.1Q tunneling (Q-in-Q) permet als proveedors de servei transportar tagged Ethernet (802.1Q) entre xarxes dels clients a través d’un backbone compartit. Per tal de fer això l’únic que es fa és tornar a afegir una altre etiqueta, a la afegida pel 802.1Q de la xarxa del client, aquesta vegada l’etiqueta 802.1Q és de la xarxa del proveedor.
- MPLS LSPs (Label Switch Routers) els paquets es conmuten segons l’etiqueta afegida al paquet. LSPs poden rebre senyals de TDP, el LDP, o el RSVP.
Tecnologies i protocols usats en accessos remots
- The Layer Two Forwarding (L2F) Protocol és propietari de Cisco. Bàsicament es va dissenyar per fer túnels PPP (o SLIP) per enllaços entre NAS i VPN gateways en oficines centrals. Els usuaris remots connecten al NAS, i les trames PPP de l’usuari remot són enviades pel túnel cap al VPN gateway.
- The Point-to-Point Tunneling Protocol (PPTP) el van desenvolupar Microsoft, 3com i Ascend Communications. Com el L2F, el PPTP permet crear túnels per accessos remots a través de trames PPP entre un NAS i un VPN gateway. PPTP també permet crear túnels entre l’usari remot i el VPN gateway. PPP encapsula els paquets enviats a través dels túnels PPTP i sovint com a mètode de protecció s’usa MPPE.
- The Layer 2 Tunneling Protocol versions 2 i 3 (L2TPv2/L2TPv3) és un estàndard de la IETF i combina les millors funcionalitats del L2F i el PPPTP. En un entorn d’accés remot, L2TP permet enviar trames PPP del client a través del NAS contra el VPN gateway o concentrador de túnels. L2TP té la seguretat com a element intrinsec, sovint s’usa IPSec per protegir-los.
- IPSec permet establir túnels tipus site-to-site (LAN-to-LAN>), accessos remots o usuaris mòbils.
- The Secure Sockets Layer (SSL) és un protocol de seguretat que va ser desenvolupat per Netscape Communications (SSL v1,v2 i v3). Ens permet crear enllaços remots segurs als usuaris mòbils. Funcionalment esta molt limitat, perquè no ens cal un client d’VPN. Cal no oblidar que TLS és un estàndard IETF molt similar la SSLv3.
Per tal de disfrutar d’un conjunt de funcionalitats més potent cal instal·lar un client d’VPN SSL específic.
Modelant i Caracteritzant una VPNs
Un bon mapa perno perdres en el món de les VPNs:
VPNs creades pel proveedor o pel client
Exemples d’VPNs creades pels proveedors:
- Virtual Private Wire Service (VPWS) VPNs
- Virtual Private LAN Service (VPLS) VPNs
- IP-Only Private LAN Service (IPLS) VPNs
- BGP/MPLS (RFC4364/2547bis) VPNs (BGP/MPLS VPNs are also known as MPLS Layer 3 VPNs.)
- Virtual Router (VR)-based VPNs
- IPsec VPNs
Exemples d’VPN creades en el client:
- GRE VPNs
- IPsec VPNs
- SSL VPNs
Site-to-Site i VPNs d’accés remot
Les VPNs les crei el proveidor o el client, només poden oferir dos tipus d’accés:
- Site-to-site ofereixen connectivitat entre xarxes distants geograficament connectant-les com si es tractes d’una xarxa local. Bàsicament es ditingeixen dos tipus les intranet i les extranet segons si connecten xarxes de la mateixa organització o de diferents organitzacions, respectivament.
- Accés remot també anomenades VPNs d’accés permeten a un usuari mòbil o domèstic accedir a la xarxa de l’organització i accedir als seus recursos de xarxa com si estiguessis físicament a la xarxa.
La calor mata…
Definitivament he d’afirmar que la calor ja ha pogut en mi. Així no es pot ni viure ni treballar ni res. L’estiu decididament no esta fet per passar calor davant d’una pantalla, es fa difícil pensar. El cervell es posa calent, calent, calent!!! cada cop costa més pensar en res que no sigui fresc o mullat 😉
Tinc tropocientos articles per publicar, mails per contestar i temes de feina per tancar. Però quan no pot ser no pot ser. Si la CPU puja de 70ºC no se li pot demanar el rendiment que té a l’hivern en 25ºC. Així que em declaro persona inútil per treballar amb més de 27ºC de temperatura ambient. Estic plantejant-me seriament fer reunions durant el dia i prou i treballar a les nits. Perquè posar-se a pensar amb la calorassa esta clar que no esta fet per mi.
Ala! ja teniu la meva reflexió de l’estiu… a veure si aconseguixo donar-li el tomb al ritme de vida.
Curs: Oficina OpenSource
La setamana passada vaig estar a l’ESI de Murcia donant un curs sobre com substituir el software propietari per software amb codi lliure. El curs va ser d’una durada total de 25h repartides en 5h diaries. Podeu consultar el material separat en 5 capítols segons cada un dels dies. El target del curs eren empreses del sector de les TIC però que no tenien un grans coneixement del SL. Així doncs tot esta enfocat a fer un gran overview dels continguts del curs.
Si voleu descarregar el material en format OpenOffice Impress, PDF i alguns documents complementaris en PDF podeu descarregar-ho tot plegat al wiki. El material només el vaig usar com a guia per explicar tots els temes així doncs tampoc espereu trobar un llibre ni res semblants, sinó una guia per poder explicar en 25h el que hauria de durar-ne 2.500h 🙂
Petit resum de continguts del curs: (castellano)
Introducción al curso
Se introducen las principales diferencias entre el software privativo y el OpenSource, con el fin de definir un marco tecnológico.
Linux en el ordenador sobremesa
Se repasarán las distintas tecnologías de sobremesa que hay en el mundo Linux, así como comparaciones con las tecnologías del mercado de software actual.
Servicios internet e intranet
Tecnologías libres para ofrecer nuestros servicios en internet y en la intranet: correo, web, FTP, servidores de ficheros, backups, etc.
Empresas que dan soporte al OpenSource en España
Las empresas necesitan confiar en otras empresas que les ofrezcan los servicios que requieren. Así pues conocer cual es el marco real de empresas en España que se dedican a dar soporte al software con esta filosofía es muy importante.
ERP, CRM y Groupware basados en OpenSource
Hay herramientas vitales para una empresa como los: ERP, CRM y Groupwares. Conocer cuales son las alternativas en este tipo de software fuera de las típicas ofertas privativas es vital si queremos migrar a un entorno OpenSource.
Telefonía IP y VoIP
En nuestros días las tecnologías de VoIP (Voice over IP) estan constantemente en las portadas de los periódicos. El OpenSource ofrece un abanico de tecnologías que abren un mundo de posibilidades infinitas en esta área.
Desarrollando software OpenSource
Por muy avanzado que este un campo de la informática no siempre las herramientas se comportan como deseamos y no siempre existen aplicaciones que se adapten exactamente a las necesidades requeridas. Por este motivo hay que conocer las plataformas de desarrollo más importantes.