Me pregunto que clase de engendros programarán las aplicaciones web que ofrecen los bancos a sus clientes. Es realmente difícil hacerlo tan mal, en todos y cada uno de los aspectos, tanto el técnico como de usabilidad, diseño… funcionan realmente mal sea cual sea el navegador, funciones sin sentido, confusión absoluta para hacer una mísera transferencia… os animo a que entreis en la web de vuestro banco preferido y useis un poco firebug. Algo me dice que están programadas por grandes consultoras con grandes comerciales con grandes amigos y muchos expertos en tecnología.
Pero la cosa no queda ahí, lo peor es que no te dan un acceso a los datos de forma simple. Esto es, no puedes de forma simple tener los datos de, por ejemplo, los movimientos realizados. Tan difícil es tener un api web simple que los retorne?
Con la cantidad de pasta que todos los ciudadanos hemos regalado a los bancos bien podría el gobierno haberles obligado a hacer las cosas bien, porque digo yo, si para hacer negocio se necesita mover dinero y no tenemos una forma automática y homogenea de tener esos datos disponibles, como quieren que las empresas españolas automaticen, informaticen o se “adapten a la nueva realidad de las TIC”, como dicen los ignorantes tecnológicos que hablan por nosotros las sandeces que sabe dios que asesor de su partido les ha comentado que queda bien porque se lo ha oído a vaya usted a saber que gurú.
Este fin de semana ha sido la railsrumble, un concurso donde hay que crear una aplicación web en 48 horas usando el framework web Ruby on rails.
No deja de ser una compo más, pero llama la atención la calidad, tanto en los diseños, como en la funcionalidad. 48 horas es muy poco tiempo para cualquier cosa, lo justo para centrarse en algo y hacer una cosa sencilla.
A pesar de eso lo que más valoro no es la calidad técnica de los trabajos, si no la calidad de la comunidad alrededor de rails. Solo hay que ver algunos detalles, por ejemplo la costumbre de compartir del código (no hay más que ver la cantidad de plugins para rails que hay en github), estar siempre tratando de mejorar, organizan conferencias de muchísima calidad (en españa tenemos conferencia rails, recomiendo ver las charlas) y un largo etcétera… incluso solo con ver el diseño de algunas web podrías decir si está el backend está hecho por gente de la comunidad RoR.
Decir que hay varias entradas españolas recogidas por @happywebcoder, varias de ellas están en la final:
- http://letsdecide.us/ código
- http://diversion.r09.railsrumble.com/ un especie de wiki al estilo github.
- http://triphq.net
- parlio. Reseña especial, porque además de haber hecho la aplicación en 48h, han intentado que tenga un uso final apuntando bien algo: acercar lo que hacen a los que votas a la gente de a pie. Me una pregunta: cómo se les tiene que haber quedado la cara a la gente que hace la web del parlamento vasco . El código en el github de probono (la asociación a la que han donado el código).
Hasta ahora no había usado el folding de vim porque me parecía un verdadero peñazo el crear los folds para el código en C/C++, sin embargo existe un modo de hacerlo tan simple que no puedo dejar de usarlo:
:set foldmethod=syntax
de esta forma se colapsa todo. Para abrir y cerrar tan fácil como:
- zO con ‘O’ de “open”. Es mayúscula para que se abran los folds internos, si usas zo se abre el fold de primer nivel.
- zc con ‘c’ de close.
Hay miles de tutoriales de folding, pero creo que he puesto la forma más simple que se puede.
Hay dos o tres blogs que leo habitualmente de los cuales no me interesa para nada la tecnología, pero que están escritos por gente tan buena que merece la pena leerlos. Unos de ellos es el blog de github, y esta mañana me encuentro con que han liberado un libro sobre git.
El libro merece la pena para aprender git, aunque me da la impresión que es una amalgama de la estupenda guía git magic y el libro de la web oficial de git.
Dejando a un lado la parafernalia de la libertad, creative commons y otras hierbas, lo que hace el libro redondo es el último capítulo, git internals, donde explica, bien clarito, con 2 comandos básicos, como funcioan git por dentro. Asombra lo realmente simple que es.
Como me gusta saber como funcionan las cosas, he mirado el código fuente de git, pero no el actual, si no el primero publicado, git-0.01, donde se puede apreciar claramente todas las cosas que explica en el capítulo. Una pena que el capítulo no haga referencia a ese código.
Y ya que estaba metido en harina he buscado el primer código liberado de mercurial, mercurial-0.1, para ver si el sistema usado es el mismo. Me han llamado la atención dos cosas, la primera de ellas es que si ejecutas hg, el script principal, sin parámetros la aplicación te lanza la típica excepción… no comprueba los parámetros, la segunda es el propio “announce.txt”. El código dista de ser ordenado y documentado, pero 4 años después ahí lo tienes..
Otra curiosidad, la primera release de git fue el 7 de abril, la primera de mercurial el 27 de mayo del mismo año (2005), 39kb de C frente a 6.2kb de python :).
Seguro que os habeis encontrado en la situación: una persona sin conocimientos técnicos, o muy básicos, os hace una pregunta, pongamos “qué significa el número ese, 8080, que hay detrás de esta dirección de esta web”. Puedes ponerte a explicarle la pila de protocolos desde la capa física hasta http, tú lo sabes, sabes porque los desarrolladores usan a veces otros puertos, te sabes la teoría, cuando ves eso rápidamente viene a tu cabeza cosas como iptables, proxy_pass, accept, netcat, tomcat…
O la pregunta que nunca sabré responder: “hijo, qué haces en tu trabajo?”, esa pregunta bien intencionada de las madres, donde ves que están poniendo todo el interés, lo hacen porque te quieren y no las puedes fallar. Pero lo siento amigo, vas a fallar, o dicho de otra forma, en tu cabeza sonará un EPIC FAIL! (y a continuación lo twitearás y 4 ó 5 ciber-amigotes se descojonarán)
Y ahora vamos a algo más serio, porque que tu madre sepa o no que eres un fan de java es poco relevante, pero que trates de explicarle algo a alguien, incluso si es técnico, y no te entienda me parece cuanto menos grave. Yo lo reconozco, me explico mal, hablo demasiado rápido y encima meto términos muy técnicos que la persona que escucha no tiene porque saber. Lo peor es que me doy cuenta y que la mayoría de personas que he tenido a mi alrededor con mi perfil padecían del mismo problema.
De quién es el problema, de nuestros compañeros de trabajo que no se esfuerzan o nuestra por no saber esquivar los terminos técnicos o condensar la información de forma clara? Siempre he pensado que el peso de la primera era mayor, pero a medida que pasa el tiempo y veo diferentes perspectivas, sobretodo de personas técnicas de lo que podríamos decir avanzada edad, me doy cuenta que es posible que al final simplificar es lo mejor para explicarle las cosas a tu compañero y lo mejor, para ti mismo.