Google sigue desarrollando nuevas tecnologías y Native Client se perfila como punta de lanza para llevar el software de escritorio a la web. Se trata de una tecnología que permite ejecutar código x86 (cualquier código de aplicación de escritorio) en un browser. De esta forma, no importa si está programado para Windows, este será servido a través de aplicaciones web, evitando así toda incompatibilidad de plataforma.

La lista de ejemplos y tests es prometedora. Imagínense poder jugar al Quake desde el browser.

La tecnología es Open Source (BSD) y ya puede encontrar todo lo necesario para correrlo en diferentes plataformas (Windows, Linux, Mac).

Fabuloso.

Para qué gastar tantos dólares en comprar música digital en iTunes si se puede comprar música digital usada. Si, como lo escuchan, Bopaboo ofrece una plataforma con música libre de DRM donde los usuarios puedan vender y comprar su música usada por menos dinero que si fuera “nueva”.

El concepto esta muy bueno, pero la práctica me resulta ridícula. El sitio sugiere que “obligaría” al usuario a borrar el archivo una vez vendido. Sino el usuario podría vender el archivo una y otra vez.

No se, me resulta un tanto difícil de imaginar que esto pueda tener éxito en un mundo donde se persigue la piratería con una política agresiva.

La fuente: Money.co.uk

Llegó el día en que Google y Yahoo nos censuran. Si bien es culpa nuestra (modelos, cabareteros y gente estúpida) es, en definitiva, una noticia muy fea.

Sin entrar en el neutralismo de “todo depende del proyecto” creo que este planteo tiene una base sólida: más de 4 años en el desarrollo web, tres de ellos en una empresa de desarrollo de software.

Los administradores de proyectos web, debieran exigir más documentación tanto al cliente como al desarrollador.

Muchos desarrolladores amigos quizá no estén de acuerdo y seguramente cada cual tendrá una opinión válida que me gustaría leer en los comentarios. La necesidad de expresar esto me surge luego de leer este artículo bastante bien fundamentado pero del cual no estoy de acuerdo. Uno de los pasajes dice:

They also showed me two big books (sorry, specification docs) with around 300 pages in total. And the project was quite simple – it was basic CRU (Create, Read, Update) with one type of objects to be stored and queried. Believe me – the system was simple.

Wow! That’s a lot of, for a simple system, to read – imagine how much time you need to read this. And it’s nothing comparing to how much time and effort it cost to produce it – and you still have no single line of code working.

Sinceramente, nunca me tocó un proyecto que esté sobre documentado pero en caso de que me toque, bienvenido sea. Prefiero gastar esfuerzo y tiempo en leer documentación que en pelear con el cliente sobre sus vagos requerimientos.

Más de una vez, por no decir siempre, el proyecto se subestima. El cliente dice que necesita ciertos requerimientos, esos requerimientos se estudian y se propone una solución en un determinado período de tiempo con una cierta cantidad de esfuerzo.

Sin embargo, en la mayoría de los casos, esos requerimientos terminan duplicándose debido a que los requerimientos originales ocultaban suposiciones que el cliente omitió.

El administrador de proyecto, en este caso, debiera exigirle al cliente, toda la documentación necesaria sobre los requerimientos. Y cuando digo necesaria me refiero a que el PM tiene que detectar estas suposiciones ocultas y aclararlas antes de que se comience el proyecto.

Por otro lado, en el afán de vender el servicio, se omiten los tiempos de documentación y de las especificaciones técnicas del desarrollo. Y este, es un punto en donde la mayoría de los PM y desarrolladores hacen agua.

El PM necesita y debe asignar esfuerzo y tiempo a la documentación técnica del proyecto, incluso si el cliente no lo desea. Esto debe ser integrado a la propuesta y el estimado.

Si no, lo que va a ocurrir tarde o temprano, es que la modificación o mantenimiento de ese sistema se vuelve más caro que el desarrollo de uno nuevo.

¿Te interesa el tema? Comentá lo tuyo.

Hace un par de años que internet está sufriendo un fenómeno de burbuja creciente, en donde los proyectos exitosos alimentan a otros, formando así una cadena de éxitos que genera un gran movimiento a nivel de negocios y de servicios.

Ahora bien, como en toda cadena, cada eslabón se sostiene de otro y si, por alguna razón, alguno de de los eslabones se rompe (peligro muy latente en nuestros días de crisis económica), toda la cadena corre riesgo de quedar inutilizada.

Esto es lo que comenta un interesante artículo sobre el peligro de colapso de esta burbuja 2.0 de la que todos formamos parte. El artículo nombra varios ejemplos. Pero creo que no hacen falta nombrar demasiados ejemplos ya que, la mayoría de nosotros, conocemos como se sostiene esta frágil estructura.

Cientos servicios muy populares se basan en YouTube, en Twitter, En FaceBook, En S3 de Amazon, en Vimeo, en Justin.tv, en OpenID, en flickr y sobre todo en el amo y señor de este tipo de servicios: Google.

El artículo propone una solución, la cual no comparto en absoluto. Este propone comenzar a construir herramientas que comiencen a guardar la información de manera local. Pero justamente ese es el principal motivo por el cual la mayoría de los servicios se basan en otros. Porque su infraestructura tecnológica no soporta tanto trajín. ¿Entonces?

Se me ocurren 2 o 3 cosas

En primer lugar diversificar. No basar todo el negocio en un solo servicio. Si usas youtube, usa también vimeo, y cualquier otro servicio de similares características.

En segundo lugar construir una plataforma flexible, la cual nos permita ser lo suficiente rápidos como para comenzar a hacer lo mismo por nuestra cuenta, en caso que el servicio deje de estar disponible, aunque sea en menor escala.

Y por último, Asesorense bien para crear una infraestructura sólida. Hay mucha gente que se especializa en el tema y si bien este conocimiento puede costar un poco más, al final no habrá que lamentar.

¿Se te ocurren otras cosas? Comentalas

Tengo esta noticia bookmarkeada desde el viernes y no podía hacerme un lugar para publicarla pero el tiempo no le quita méritos. Google informó que comenzó a aplicar OCR (optical character recognition) en los PDF que tienen páginas escaneadas para así poder indexarlos.

Si bien Google indexó desde siempre los PDF basados en texto, tenía serios problemas con la indexación del contenido de los PDF escaneados y principalmente con los que no usaban fuentes sans-serif.

Gracias a dos años de trabajo, Google está en condiciones de decir que su software está afinado lo suficiente para reconocer diferentes formatos de textos gracias a su software open-source OCRopus, que está basado en el Tesseract de HP.

Como ejemplo, google presenta la búsqueda “reparing aluminium wiring” en donde el primer resultado es un PDF escaneado extremadamente complejo de reconocer mediante un OCR estándar.

Esto me supone dos cosas, por un lado un mejor acceso al contenido disponible en los odiosos formatos PDF y en segundo lugar una nueva guerra contra el contenido propietario con derechos de autor ya que los PDF escaneados eran unos de los pocos bastiones que todavía tenía el contenido propietario.

Vía Arstechnica

PHP.js es un ambicioso proyecto colaborativo que trata de programar tantas funciones de php en java script como sea posible para lograr una mayor compatibilidad entre ambos lenguajes. Por el momento ya tienen una lista de 190 funciones escritas y pueden encontrarlas en esta librería JS.

Muchas funciones son simples manejos de array, otra más complejas tiene el algoritmo de encriptación MD5 e incluso está disponible la clásica base64_decode(). Hay otras otras más simples pero muy útiles como la función date().

Me parece un proyecto fantástico e invito a todos los profesores de programación para que inciten a sus alumnos a participar en este proyecto como alternativa a los clásicos ejercicios que suelen dar a sus alumnos.

El proyecto está muy bien organizado y tiene la documentación necesaria tanto para participar como para utilizar la librería.

Gracias Javier

Lo más difícil de la programación no es programar.

Las redes Wi-Fi se vuelven cada vez más populares gracias a la cantidad de dispositivos que utilizan esta tecnología. Instalar una red Wi-Fi, es bastante simple; pero, para hacerlo bien, se requieren tener en cuenta algunas variables. Este blog menciona 4 formas de mejorar tu conexión Wi-Fi que traduzco interpreto a continuación.

1) Mueve el router o conector Wi-Fi a una mejor ubicación

Esta es una de las causas más comunes de desperdicio de conectividad. Muchas veces por motivos de comodidad, espacio o buen gusto, colocamos nuestro router o conector en un rincón, en una repisa o en el lugar menos visible. Sin embargo, esto produce desperdicio de conectividad ya que mientras más oculto este nuestro router para nuestros ojos, más oculto estará también de los dispositivos que se conectan a el.

La mejor ubicación para un router wi-fi es el centro de nuestro radio de movimiento, además que no tenga ningún elemento que lo cubra. Si bien esto es algo utópico de lograr puede, al menos, ayudar a encontrar una mejor ubicación a nuestro router.

2) Mantén el firmware de tu router actualizado

Muchas veces los problemas de conectividad pueden deberse a incompatibilidades entre normas, entre dispositivos y entre firmwares. Manteniendo el firmware del router siempre actualizado, minimizarás el riesgo de incompatibilidades.

3) Cambia el canal de transmisión del Router

Es común, principalmente en los grandes centros urbanos, que existan varios router transmitiendo en los mismos canales (principalmente en los canales por defecto). Esto hace que se genere ruido que perjudica la conectividad. Prueba cambiar los canales hasta encontrar el más óptimo para tu conexión

4) Manten actualizados los drivers de tu dispositivo

Al igual que los router, los dispositivos pueden tener cierta incompatibilidades a la hora de conectarse con otros fabricantes de hardware. Principalmente cuando es un software el que administra esta conexión.

Mantener los drivers actualizados disminuye el riesgo de incompatibilidades de señal que puedan existir entre los dispositivos.

Además de estos útiles tips, no se olviden de revisar la seguridad de su red Wi-Fi, puede que tengan una gran optimización de conexión, pero problemas en la seguridad de su red.

Los discos rígidos SATA tienen una probabilidad muy alta de no leer todos los sectores. El bit error rate de estos discos hacen que recuperar un Raid a su estado normal después de una falla sea practicamente nula.