Link del día: URLs cortas de verdad
Para algunos servicios en donde se comparten links, como redes sociales, o como simple comodidad para compartirlos, es muy útil que las URLs sean acortadas. Es decir, que en lugar de tener un http://www.example.com/posts.php?postid=2313&searchterm=search&l=en, podemos tener algo como http://bit.ly/6bCxjl, que lleva al mismo lugar. No sólo eso, muchos servicios de acortamiento de URLs (como Bit.Ly, que acabo de mencionar), ofrecen URL-tracking, que nos permite saber cuánto o de dónde se han usado las URLs que hayamos compartido.
Más allá de eso, quería comentar de un servicio que vi funcionando la semana pasada (ya no, pero tengo esperanzas de que vuelva a funcionar) llamado http://to/. Sí, tal cual, no tiene nombre de dominio. Este acortamiento de URLs parece que lo introdujo el gobierno de Tonga (habrán sido ellos realmente?) y podría acortar nuestra URL de ejemplo a algo como http://to/EVFaj. (No la prueben, no funciona, incluso aunque redireccione, no va a ningún lado).
Pero hasta que ese funcione, podemos probar cualquier cantidad de otros servicios disponibles hoy por hoy, algunos ya muy conocidos:
- Bit.Ly
- ShortURL (uno que comenzó allá en el 99)
- Tiny.CC
- Zwap.to
- Goo.gl (en algún momento disponible al público en general)
- MetaMark
- y otros más…
- …Y otros tanto más que seguro habré dejado de lado.
Cabe destacar que algunos consideran que las URLs cortas “rompen” la internet, porque como usuario, uno no sabe a dónde va a parar, y como bot (como los de Google que surfean la internet), se encuentran con que en realidad los links llevan a un lugar que no es el destinado (ya que estos en realidad funcionan haciendo redirecciones). Para revertir estas situaciones existen servicios como Real-URL, LongURL, Untiny.me y PrevURL.
Soy un zorrinito acortado.
Link del día: Tecnologías Web
Para cerrar la semana vamos a ver un poquito de nuevas tecnologías web que están aflorando desde hace un tiempo. Comencemos por CSS 3, HTML 5, SVG o Canvas, que son cosas que últimamente están ganando mucho la atención de los desarrolladores multimedia. La pregunta es: cuándo sabremos que esto está disponible para usarse y en donde? Para responder de forma fácil esa pregunta es que tenemos a una aplicación web llamada When can I use…, en donde podemos filtrar según nuestros deseos de compatibilidad y ver qué tan cerca estamos de poder usar estas posibilidades sabiendo que será soportado por el público al que apuntamos.
Como extra (y compensando el link del día de ayer que faltó), les dejo una guía muy didáctica, detallada al extremo llamada Creating a Web App from Scratch. Eso es, cómo se construye una aplicación web, desde que se tiene la idea hasta que se termina y se publica. Muy interesante, y con muchas buenas ideas para aprender cómo organizar un proyecto de este tipo.
Soy un zorrinito web.
Link del día: TODOs pero con onda
Creo que ya éramos varios los que estábamos en busca de alguna aplicación al estilo agenda, pero sin horarios (es decir, no es una agenda). Algo al estilo de listado de cosas pendientes, que pudiéramos acceder y actualizar de distintos lados. Que fuera simple, que fuera fácil de entender, que no haya que rellenar muchas cosas.
Finalmente encontré algo que se acerca muchísimo a eso que buscábamos y, creo yo, que lo voy a estar usando para poder actualizar el listado de cosas pendientes. La idea es básicamente no olvidarse de las cosas que uno debe hacer, no importa exactamente (o no importa tanto) cuándo se tengan que hacer, sólo cuáles son y cuáles ya están hechas.
Les dejo que visiten entonces a Teux Deux, una aplicación web encargada de eso. (via NQB, via swissmiss). Será el nombre una forma rara de decir “To Do”?
Soy un zorrinito atareado.
Sistemas Jenga
Suelo decir muchas tonterías a modo de chiste, pero de tanto en tanto, alguna de ellas tiene un poco de verdad. Hoy, hablando de un sistema del que estoy encargado (entre otras personas) de mantener, pensé que estaba muy difícil su actualización, y lo llamé un Sistema Jenga. ¿Qué es un sistema Jenga? Es un sistema para el cual agregar una pieza hace que peligre toda la estructura de su programación.
Aquí participan varios conceptos que alguna vez he mencionado. Uno de ellos es, por supuesto, la arquitectura o la estructura con la cual se ha programado, diseñado y modelado el sistema en cuestión. Es obvio que una buena arquitectura, o una pensada en torno a futuros cambios, pueda ser lo suficientemente flexible como para aceptar futuros nuevos requerimientos sin necesidad de rediseños mayores o cambios drásticos en la programación anterior. Pero ese no es el concepto que más me interesa discutir hoy.
Otro de los conceptos es el hecho de cuál es el propósito de una pieza de software. Lo considero un punto incluso filosófico, porque está claro que no hay un sistema multipropósito, que realice todas las funciones que podamos llegar a necesitar, y creo que no debería haberlo tampoco, porque sería infactible que dicho sistema se adapte a todas las situaciones particulares que puedan surgir. Por tanto, el riesgo que tal hipotético sistema introduciría en nuestros procesos, sería catastrófico. No haría falta mencionar tampoco, que la programación/diseño/análisis de ese sistema se aproximaría a lo altamente infactible. Muchos sistemas operativos ya proveen de estas posibilidades gracias a la integración de muchas pequeñas herramientas, pero no es técnicamente parte del mismo sistema, a pesar de que pueden llegar a interactuar de forma muy íntima.
Entonces, a medida que pasa el tiempo, es muy factible que los requerimientos para un sistema se vayan modificando. Muchas veces los cambios son pequeños, pueden ser cuestiones de usabilidad o cuestiones de performance. Incluso puede que haya una modificación grande en el sistema, agregando nuevas funcionalidades y hasta quitando funcionalidades obsoletas, pero el objetivo o el propósito del sistema se mantiene, hace lo que siempre debió hacer.
** ¿Qué pasa, entonces, cuando cambia el enfoque de negocios y los requerimientos del sistema pasan a tener un propósito distinto del original?**
Yo creo (aunque es mi opinión personal) que en ese caso el sistema se vuelve obsoleto, y pierde su razón de ser. Es entonces en donde el mantenimiento de esos sistemas para acomodarse a los nuevos requerimientos puede ser algo dramático, porque se está intentando usar algo que ni siquiera estaba pensado de la forma que se necesita para algo que ni siquiera estaba pensado que se iba a necesitar. Casos tan drásticos son raros, pero son factibles de ocurrir. Y creánme, ocurren.
{ :align-right}
Esto no es nada nuevo tampoco. Se sabe, y es algo conocido como “la curva de la tina de baño” (o su nombre en inglés “Bathtub curve”) que el ciclo de vida de un sofware, o la utilidad que el mismo proporciona a sus propósitos es poco al principio, hasta que los usuarios logran sacar el máximo provecho de los sistemas, hasta que los demás sistemas lograron integrarse de forma correcta al mismo y hasta que los bugs iniciales hayan sido corregidos. En la etapa media es el ápice de la utilización de esos sistemas, pero pasado el tiempo, es cuando el sistema ya deja de satisfacer las necesidades del usuario.
Aquí surge la discusión de qué sucede con la curva en el final. Para productos comunes (por ejemplo, elementos mecánicos) el desgaste producido comienza a introducir nuevas fallas que de a poco vuelven al producto inusable. En el software, es fácil reacomodar la lógica del mismo y entonces, adaptándose a las nuevas necesidades, cabe la posibilidad de que se mantenga en su estado de mejor uso. Así, la curva finalizaría con una forma de sierra, en donde se observarían pequeños picos (dado que al usuario le deja de resultar útil el sistema) y tras dicho re-acomodamiento, una planicie.
Sin embargo, la manutención de un producto a través de la eternidad no es algo factible, y quizá no es deseable tampoco. Aquí es en donde la otra opinión se asoma al respecto, diciendo que la vida de un software también se desgasta proporcionalmente al tiempo que estuvo activo, y, personalmente, creo que tiene sentido. Las necesidades a través del tiempo suelen cambiar muy drásticamente y, aunque una suma siempre haya sido una suma, las cosas tienden a simplificarse para el usuario y cuando un click antes hacía una suma, ahora debe realizar una estimación a futuro.
Y finalmente, otra cosa que quería mencionar al respecto, es la terrible necesidad del backward compatibility. Esto significa que a medida que vamos mejorando y agregando funcionalidades a nuestro sistema, necesitamos algunas veces tener compatibilidad con las versiones viejas de nuestro sistema. A veces es fácil, porque nuestro sistema puede ser una web application que no requiera de muchas entradas, y por tanto podemos cambiarlo todo sin necesidad de tener esa precaución. ¿Qué pasa si en cambio Microsoft, al implementar su nuevo formato de archivos de Office 2007 hubiera hecho inútiles los archivos de Office 2003 hacia atrás? ¿Qué pasa si en cambio cuando decidieron implementar IPv6 no hubieran tenido en cuenta que somos millones los que estamos actualmente usando IPv4 y que no podemos (o queremos) comprar nuevas placas de red en este momento?
Por eso, siempre es una cuestión a considerar, no hay ni blancos ni negros, pero siempre que un sistema debe mantener compatibilidad con sus versiones anteriores, se agrega complejidad, y de alguna forma es un requerimiento extra que nos impide avanzar con las modificaciones que quisiéramos hacer para avanzar con las nuevas funcionalidades del sistema.
Es entonces, en conclusión, en donde el mantenimiento de un sistema se vuelve algo tan pesado que quizá sería mucho más provechoso realizarlo de cero con las nuevas necesidades, y en donde la modificación del mismo lo hace peligrar cada vez más en su integridad, algo que a mí me gusta llamar Sistemas Jenga.
Soy un zorrinito jenga.
Link del día: Cloud Computing Ecosystem
Hace no mucho hablamos un poco sobre la importancia y los beneficios del cloud computing, o la computación en la nube, como muchos quieren traducir el término. Volviendo sobre la idea, es el concepto de tener sistemas distribuidos para los cuales muchas computadoras físicas a lo largo y a lo ancho de internet están colaborando para un fin común. Puede que estas computadoras sean computadoras personales, o puede que sean servidores dispuestos a ese fin en algún lugar fuera de nuestro alcance.
Independientemente de eso, deberíamos saber que esto no es algo nuevo y que ya existen muchas plataformas y servicios disponibles gracias a esto, seguramente muchos de los cuales conocemos a través de grandes empresas como Google y Microsoft (no pensaron que Google Docs estaba en un solo servidor, o que las descargas de Microsoft estaban todas en el mismo lugar, verdad?). Pero en realidad existen muchos servicios variados de muchas empresas, algunos disponibles al público y otros no.
Para guiarnos en todo eso es que viene el link del día de hoy, llamado Cloud Computing Ecosystem, un “mapa” que nos muestra qué distintos servicios y para qué distintos fines están disponibles desde qué empresas y qué disponibilidad tienen al público. El mapa está dividido en tres partes verticales y tres horizontales. De las verticales, tenemos por un lado a los servicios disponibles públicamente, a los servicios pagos, y a servicios privados. De las horizontales, tenemos los tipos de servicios divididos según su uso: aplicaciones (ya pre-armadas), plataformas (para desarrollo de aplicaciones), o servicios de infraestructura.
Por último, cabe preguntarse por qué alguien armaría un mapa así (más allá de aparecer como nominado al link del día). La respuesta es que la empresa que lo mantiene, llamada Appirio, es una empresa que brinda soluciones informáticas e integración de sistemas utilizando una gran variedad de servicios en la nube de los cuales ellos dicen ser partners. De esta forma, podemos generar soluciones de negocios enteramente tercerizados en internet, en donde nuestra información estará disponible desde cualquier lado y (supuestamente) segura y accesible.
Soy un zorrinito nublado.
Link del día: WPA Cracker
Si mal no recuerdo creo que fue Nano quién me compartió por Google Reader este artículo de Kabytes, en donde hablan de una aplicación web llamada WPA Cracker, una aplicación que tomando un archivo pcap de capturas de un wifi WPA, puede compararlo contra una enorme cantidad de palabras y combinaciones (gracias al cloud computing) y devolvernos el password en un pequeño tiempo.
El uso de esta aplicación es paga, no realmente mucho si es que tiene algún beneficio para nosotros la utilización de esa red, pero independientemente de eso, es una buena aproximación a la obtención de claves: no tiene por qué hacer todo el trabajo una sola máquina durante semanas, cuando varias máquinas alrededor del mundo pueden hacerlo en cuestión de horas o minutos.
Fuera de eso, la aplicación es interesante, también permite el crackeo por diccionario de archivos ZIP (sólo porque el público lo pidió), nuevamente también contra un diccionario enorme de palabras en inglés y en alemán.
Según cuenta el autor, es un esfuerzo mucho más grande pero mejor para resultar de esta forma porque utilizar rainbow tables (como las que tienen para bajar en Curch of Wifi) es un poco ineficiente, dado que para eso se necesita crear una serie de rainbow tables para cada ESSID de la red, con lo cual se vuelve impracticable la idea original del rainbow table: tener una solución pre-armada, por pesada que fuera.
El precio que se le pone al servicio es de 17 dólares si es que queremos utilizar el diccionario básico (136 millones de palabras) en modo half-cluster (es decir, la mitad de las máquinas disponibles trabajan), o 35 si queremos utilizar el clúster completo. Además, también se puede hacer una corrida contra un diccionario extendido (que no contiene al diccionario básico) con 284 millones de palabras. Realmente bastante como para que se haga en unos 20 minutos, verdad?
Cabe decir por último que este es otro de los trabajos de Moxie Marlinspike, un hacker que siempre interesado en la seguridad (y en la navegación [marina, no por internet], pero eso es otra cosa). Puede verse mucho más al respecto en su website, más personal que website, y más elegante que completo.
Soy un zorrinito cracker.
Link del día: Máquinas Virtuales
Es bien conocido que la virtualización es una herramienta muy poderosa que amplía vastamente nuestras capacidades de prueba y simulación sobre sistemas para los cuales no disponemos el hardware real – o el dinero equivalente. Hoy por hoy las máquinas virtuales pueden llegar a ser tan poderosas como máquinas reales (con obvias limitaciones) y satisfacer muy bien ciertas necesidades (hosting con administración remota, ambiente de pruebas, testing de stress, investigación, etc.).
El proceso de creación de una máquina virtual es igual (o a veces un poquito más complicado) que la configuración de una máquina real: instalar el sistema operativo, configurarlo acordemente, configurar la red, instalar los programas necesarios, configurarlos, dejar todo en un estado lo más performante posible y finalmente, algún retoque final que querramos, y sabemos que solo el sistema operativo ya puede tomar un buen par de horas que no quisiéramos tener que sacrificar.
Para eso la gente de VMWare Images y VirtualBox Images (via LuAuF) nos deja imágenes prearmadas para bajar, y por mi parte también encontré estas imágenes para Virtual PC (aunque expiran muy prontito). Podemos descargarlas a nuestro disco y una vez ahí, ya tenemos el sistema operativo pre-instalado y a veces con algunas aplicaciones (como es el caso de las de Virtual PC).
Soy un zorrinito virtual.
Link del día: Google Closure
Hace ya algunos días que Google publicó sus Closure Tools, una serie de herramientas para trabajar con JavaScript eficiente y lograr mejorar la performance, velocidad y tamaño del código. Entre ellos se encuentran Closure Compiler, una suerte de compilador para JavaScript, removiendo código innecesario, mejorando el código existente y minimizando lo que queda. También está la Closure Library, una librería JavaScript pero versión Google, y por último, los Closure Templates, una serie de soluciones “pre-hechas” para elementos reutilizables de HTML y UI.
Ahora, todo esto llama mi atención desde un artículo que encontré llamado Google Closure: How not to write JavaScript, que al principio parecía ser una crítica vacía de estas herramientas, pero luego se llena de fundamentos y (aquí es lo interesante) muchos datos que la gente de Google saltó al momento de crear estas herramientas. Esos datos son los que nos permitirían a nosotros aprender de esos errores y mejorar nuestras propias prácticas. Hay en todos lados para aprender.
Soy un zorrinito JavaScript.
A Tester's Guide to .NET Programming
Terminé hace poco de leer el libro A Tester’s Guide to .NET Programming, de Randal Root y Mary Romero Sweeney, un interesante libro aproximativo a .NET de unas 630 páginas.
Mi prejuicio de este libro, basándome en su título, era que iba a encontrarme con un libro que mostrara características propias de Visual Studio y de la plataforma .NET para llevar a cabo tareas particulares de testing. Seguramente, pensaba yo, me encontraría con nuevos conceptos de testing y nuevas características o nuevos usos de características existentes que me permitirían mejorar las metodologías que conozco para testing.
Desafortunadamente, no ha sido el caso. El libro, debo decir aún así, es realmente bueno, muy detallado y explicativo en sus puntos. La suposición que el libro hace es: tomemos como tester a aquél que quiere realizar testeos (más que nada de aceptación de usuario) sobre un determinado software, y basado en eso, el programa enseña programación en VB.NET y C# orientado a la utilidad de ciertas cosas.
A pesar de no haber cumplido con lo que esperaba, este libro es una joyita. Al poner un concepto tan poco desarrollado sobre testing, nos permite utilizar este libro como un manual para aprender a programar en ambos lenguajes, planteando al testing como un ejercicio práctico que desarrollaremos a lo largo de toda la lectura. Y esto mismo es interesante, porque no solo tiene una aplicación práctica muy directa – cosa que muchos estudiantes de un lenguaje siempre quieren ver prontamente – sino que es fácil de entender y de sobrellevar.
El libro comienza con conceptos algo vagos de la programación, solo mostrando que con determinadas líneas en determinado lugar podremos lograr cierto resultado. Avanzando más, de a poco nos introducen a las clases, métodos, conceptos de orientación a objetos y reutilización de código. No llega a niveles más avanzados como la creación de frameworks para generar testware más complejo, pero se para a un paso de eso, y lo mantiene simple. Esto nos permite seguir el libro sin necesidad de demasiada atención, en donde sabemos que la información no está condensada sino explicada de formas que son fáciles de comprender, llenos de ejemplos, llenos de ejercicios prácticos y todo eso nos genera el impulso de seguir avanzando.
Como tal, resumo, este libro no tenía lo que yo esperaba encontrar, pero ha sido un muy buen hallazgo aún así.
Soy un zorrinito .NET.
Link del día: Freenet
Freenet es el nombre de un proyecto (no del todo nuevo) que es tan ambicioso como para querer lograr una nueva internet, libre de restricciones y con pura anonimidad. La idea es que internet, en lugar de funcionar de forma servidor-cliente, funcione de una forma descentralizada, en donde nuestros contenidos pueden estar en cualquier lado, y donde cualquiera puede accederlos sin saber a dónde accede o cómo se está llegando ahí.
El proyecto de Freenet quiere entonces una distribución de la información totalmente libre, independientemente de las barreras legales que las distintas políticas apliquen, creando el concepto de una “internet” con una legislación independiente de la legislación que tengan los países.
No sabemos qué habrá ahí adentro, seguro que muchos lo están utilizando para lo más ilegal que se les ocurra, pero fuera de eso, el proyecto no deja de ser ambicioso y una idea muy interesante. Como toda gran idea, es un arma de doble filo.
Soy un zorrinito libre.