Microsoft ha adquirido Mojang por 2500 millones de dólares. El estudio ha confirmado la compra y la cifra y el propio Notch ha ofrecido su explicación al respecto, en mi opinión, totalmente comprensible.
Lo que no termina de parecer comprensible es por qué Microsoft se ha gastado esa millonada en comprar la compañía. Por poner las cosas en perspectiva, los ingresos del Real Madrid de todo el año anterior suman algo menos de 674 millones de dólares. ¿Qué tiene Mojang para merecer tal desembolso?
Pues básicamente dos cosas (y de ahí el título): Minecraft y su comunidad. Pese a lo que pudiera parecer a primera vista, Minecraft es el tercer videojuego más vendido de la historia. Sólo por detrás de Tetris y Wii Sports, que venía incluido con Wii. Más de 54 millones de personas han comprado un juego que, en su versión para PC, ni siquiera está en plataformas de descargas populares como Steam u Origin.
Lo primero que se le viene a uno a la cabeza es que lo convertirán en un futuro exclusivo para sus sistemas, especialmente Xbox One, a la que un bombazo de este calibre le vendría de perlas para ponerse a la par de PS4. Sin embargo, el propio Phil Spencer ha confirmado que seguirá siendo multiplataforma.
Entonces, ¿se han vuelto locos?
Ni mucho menos.
Mi teoría es que esta gente quiere convertir Minecraft (o Minecraft 2) en un MMO (Multijugador Masivo Online).
Por una parte, Microsoft tiene experiencia de sobra montando tanto infraestructuras para juego online (Xbox Live) como computación en la nube (Azure). Por otra, Minecraft es un juego que puede adaptarse como un guante a ese concepto: un mundo virtualmente infinito, posibilidad de juego colaborativo y competitivo, el actual modo aventura que introduce ciertos aspectos de RPG en el juego... ¡incluso tiene multijugador mediante servidores locales! Ahora imaginemos eso a gran escala y potenciado, con más elementos de rol y con ciudades enteras creadas por los propios jugadores, todos dando forma a un mundo creado por ellos mismos. Le añadimos zonas donde no se pueda destruir el trabajo de los demás y ya tenemos el bombazo.
Es bueno incluso para monetizarlo; pueden usar cuotas mensuales, al estilo de World of Warcraft. Pueden usar cuota única, pueden optar por un modelo de micropagos por algunas ventajas (mejores materiales, herramientas, zonas para poder construir sin que otro te destroce tus creaciones); pueden incluso hacer como Valve con juegos como Team Fortress 2 o Counter Strike Go: un mercado controlado por ellos donde los jugadores puedan comprar y vender sus propios objetos, construcciones, materiales, etc. y Microsoft se lleve una pequeña comisión por cada transacción. Lanzar eventos competitivos o cooperativos para optar a ítems exclusivos... las posibilidades son casi infinitas, y varias de ellas garantizan un flujo continuo de ingresos.
Por otra parte, tienen a más de 50 millones de personas que ya han pagado por el juego expectantes por ver qué sacan, y eso sin contar las que aún no lo tienen o juegan una versión pirata. Esto es una ventaja con lo que pocos MMO han podido contar. Si saben gestionar bien el juego y el modelo de ingresos la jugada puede ser maestra.
Y, visto así, ¿tiene ahora sentido que hayan dicho que Minecraft seguirá siendo multiplataforma? Más incluso del que parece. Un MMO vive de sus jugadores. Si los jugadores no llegan o se van, por bueno que pueda ser el juego, está condenado. Pero el hecho de mantener Minecraft multiplataforma no sólo asegura más clientes y, por tanto, más beneficios; asegura tener un juego clave en las plataformas de la competencia. No es casualidad que Microsoft posea un buen pellizco de acciones de Apple, o una buena parte de las patentes de Android. Como en un casino, la banca siempre gana.
"Sólo" necesitaban una IP potente y el público, y eso precisamente es lo que creo que puede costar los 2500 millones de dólares que han pagado.
martes, 16 de septiembre de 2014
viernes, 17 de enero de 2014
Sobre la privacidad en Google
WordPress, Blogger y, desde hace algún tiempo, Tumblr son las elecciones obvias para cualquiera que se quiera iniciar en el mundo del blogging. Yo hasta ahora he venido utilizando Blogger, donde Google se encarga de facilitarte muchas cosas: Temas por defecto, facilidad para configurarlo, temas por defecto, adaptación a móviles, editores online para escribir tus entradas directamente y un largo etc.
Además de todo esto es "gratis", en el sentido de que no tienes que pagar dinero por usarlo. Si hablamos de privacidad ya es otro tema. Como dijo algún sabio: "Si algo es gratis, el producto eres tú". Aunque con matices, esta frase ha demostrado ser cierta en muchas ocasiones, y en el mundo del software como servicio ni te cuento.
Sin embargo, el caso de Google ya lleva tiempo que pasó de castaño oscuro. El cierre de Google Reader puso en evidencia por un lado una de las debilidades de los servicios online: si al desarrollador no le sale a cuenta seguir con el servicio, te quedas sin nada. Por otra parte, fue una muestra más de que Google es una empresa de publicidad y que lo que quiere es lucrarse con ello. El buscador es una excusa para ello, GMail es otra, YouTube más de lo mismo y así podríamos seguir. Reader obviamente no era tan interesante: no sólo es una aplicación dirigida a un target de corte más técnico, sino que no es tan fácil de monetizar como las aplicaciones que he nombrado antes.
Con esto no quiero decir que estas aplicaciones (y casi todas las de Google) sean malas ni nada por el estilo. De hecho, tienen que ser no sólo buenas, sino muy buenas para conseguir que todo el mundo las use. Al fin y al cabo el gran poder de Google es que sabe muchas cosas sobre nosotros, con lo que puede dirigirnos una publicidad mucho más específica.
Alguno quizá esté pensando que exagero, veamos un ejemplo: mediante Google Calendar, que resulta muy conveniente para sincronizar toda nuestra agenda, se puede tener acceso a, por ejemplo, si vamos al médico, con quién hemos quedado, reuniones, etc (por no hablar de que también se sabe desde dónde se ha enviado el mensaje o cuándo), mediante GMail se pueden ver nuestros contactos, cuándo solemos conectarnos, si solemos escribir o no, cuándo solemos escribir, cuánto tardamos, desde dónde escribimos y así podríamos seguir.
Recuerdo hace tiempo, en el segundo año de carrera, cuando un profesor mencionó de pasada el historial de Google o, dicho de otra manera, el registro que tenía Google de todas las búsquedas que había hecho desde 2008. De hecho, acabo de acceder y puedo saber que el 30 de Julio de ese año, a las 11:32 de la mañana accedí a una página sobre teoría de autómatas, seguramente para preparme el correspondiente examen. Curiosamente, no todo el mundo sabe que este historial existe, ya que no es algo publicitado o accesible desde la página de Google. Desde entonces ha llovido mucho, y Google ya tiene su propio navegador, sus propios portátiles, y sus dos grandes apuestas de presente y de futuro: Android y Google+.
El crecimiento de Android ha sido algo espectacular y su filosofía "libre" (nótense las comillas) es algo digno de admiración en comparación a Apple y Microsoft. Android ha permitido que los Smartphones pasasen de ser algo elitista a algo completamente común.
Pongo comillas a libre, porque aunque el núcleo de Android (que viene siendo Linux con una máquina virtual de Java y librerías en C/C++ por encima) sea libre, no pasa lo mismo con las Google Apps (GMail, Chrome, Maps y Play principalmente, aunque hay bastantes más), que vienen por defecto en la mayoría de Smartphones. Además, y por muy libre que sea, se ha demostrado que lo importante no es el sistema, sino las aplicaciones (véase Windows Phone, Meego, FirefoxOS, Tizen...). Al final, el que sea libre o no, no tiene tanta relevancia como pudiera parecer: o te ciñes a unas directrices, o adios tienda de aplicaciones y Google Apps, o lo que es lo mismo, adios a intentar conseguir ventas con ese terminal. Dicho esto, prefiero mil veces que el sistema sea libre a que no lo sea, pero continuemos...
Con Android, Google ha conseguido básicamente una plataforma tanto para recoger datos como para mostrar publicidad que llevamos siempre encima y siempre encendida y conectada. Si aún había alguna duda sobre esto, Google Now debería despejarla. Como ejemplo, un compañero de trabajo tenía conectado el GPS en el Nexus 5 e iba a introducir una ruta. El propio Maps se encargó de sugerirle la ruta que él pensaba tomar (hacia su casa) pero también una ruta alternativa que curiosamente llevaba hasta casa de su novia y que, a diferencia de la anterior, era a pie, que era como solía ir mi compañero. ¿Cómo se supone que sabía Google todo esto? Pensando mal, cualquiera diría que el móvil registraba cuándo y dónde se movía y la velocidad a la que iba, y apostaría a que si éste seguimiento fuera desactivable, no vendría desactivado por defecto y tendrías que acceder a algún menú recóndito para desactivarlo.
Ésta anécdota es sólo un ejemplo pero conviene recordar, aunque muchos no lo tengan todavía asumido, que en el bolsillo llevamos un ordenador con GPS, conexión a Internet permanente, micrófono, cámara y multitud de sensores. Resulta curioso como el modelo sandbox de seguridad de Android nos pide permisos para acceder a estos sensores o a diversas características del teléfono a la hora de instalar una aplicacion (una idea genial por otra parte, que ya podían implementar los sistemas operativos de sobremesa), pero podemos comprar una aplicación desde nuestro PC e inmediatamente y de forma transparente se descarga e instala en nuestro móvil. Básicamente, cualquier persona que conozca o descifre nuestra contraseña de Google puede instalarnos cualquier aplicación de Google Play sin que nos enteremos y sin necesidad de acceder a nuestro dispositivo (y luego nos escandalizaremos con el espionaje de la NSA).
La otra gran apuesta de Google es su red social Google+, lo cual tiene su lógica. No se me ocurre mejor manera de recopilar información de los usuarios que controlar una red social dominante (bueno, sí, Android, pero eso YA lo han hecho). Google+ puede ser una fuente de información (y de ingresos) brutal para Google, pero para ello necesitan que crezca y que se use, algo bastante complicado cuando tienes a Facebook como rey indiscutible.
¿Y cómo conseguir que los usuarios se cambien a otra red? Al principio pudieron pensar que añadir características únicas, como los círculos o los hangouts podrían inclinar la balanza a su favor. No sé si tuvieron éxito (aunque no se puede negar que fuesen buenas ideas) pero si lo tuvieron sin duda no fue suficiente, porque pronto pasaron a técnicas bastante más coercitivas.
Comenzaron promocionando Google+ en la página principal del buscador, siguieron activándolo por defecto en las nuevas cuentas de Google, activándolo por defecto en Android, instalando por defecto la aplicación oficial en Android (que además no se puede desinstalar como las aplicaciones normales, hay que hacerse root) y preguntándote en cualquiera de los servicios de Google si querías entrar. La red social sufrió un empujón importante, aunque las noticias decían que el tiempo de uso de la red era bastante reducido, algo normal por otra parte si "obligas" a registrarse a gente que no está interesada.
Google+ ya tenía usuarios, pero necesitaba contenido, ¿cómo conseguirlo? Pues qué mejor manera que forzar a los usuarios de la tienda de aplicaciones de Android a que usen su perfil de Google+ (con su nombre y apellidos reales) para evaluar cualquier aplicación u opinar sobre la misma. Da igual que sea una técnica rastrera: por una parte tenemos más contenido en la red social y por otro, Google puede usar esas opiniones para ponerles a tus amigos un bonito recuadro de publicidad donde puedan ver que tú recomiendas tal o cual aplicación, consiguiendo una publicidad mucho más directa y efectiva que mostrar un simple anuncio, por muy relacionado que esté con tus intereses. De paso, vamos a obligar también la necesidad de una cuenta de Google+ para comentar en Youtube, porque aunque llevamos años intentando que la gente vincule la cuenta de Youtube con nuestra red social y use su nombre completo, todavía hay algunos usuarios cabezones que no pasan por el aro...
La última fue hace unos días, cuando Google introdujo la posibilidad de que los usuarios de Google+ puedan enviar correos electrónicos sin saber tu dirección, directamente usando tu nombre de usuario de Google+ y, para variar, activado por defecto y sin notificarlo al usuario, que para eso estamos en la nube.
No sé si todos estos cambios han servido para conseguir los objetivos de Google, del mismo modo sé que a la mayoría de la gente todo esto le da exactamente igual o, si no le da, prefiere la practicidad a la privacidad. Yo mismo uso Google, GMail, Android, Youtube o, mismamente, Blogger (aunque ésto último seguramente cambie más pronto que tarde). Lo que sí se es que hace años que el "don't be evil" es papel mojado y que, aunque sigamos usando sus servicios, no está de más saber qué está pasando con nuestros datos, porqué está pasando y qué podemos esperar en un futuro.
No creo que ellos vayan a molestarse en explicarlo.
Además de todo esto es "gratis", en el sentido de que no tienes que pagar dinero por usarlo. Si hablamos de privacidad ya es otro tema. Como dijo algún sabio: "Si algo es gratis, el producto eres tú". Aunque con matices, esta frase ha demostrado ser cierta en muchas ocasiones, y en el mundo del software como servicio ni te cuento.
Sin embargo, el caso de Google ya lleva tiempo que pasó de castaño oscuro. El cierre de Google Reader puso en evidencia por un lado una de las debilidades de los servicios online: si al desarrollador no le sale a cuenta seguir con el servicio, te quedas sin nada. Por otra parte, fue una muestra más de que Google es una empresa de publicidad y que lo que quiere es lucrarse con ello. El buscador es una excusa para ello, GMail es otra, YouTube más de lo mismo y así podríamos seguir. Reader obviamente no era tan interesante: no sólo es una aplicación dirigida a un target de corte más técnico, sino que no es tan fácil de monetizar como las aplicaciones que he nombrado antes.
Con esto no quiero decir que estas aplicaciones (y casi todas las de Google) sean malas ni nada por el estilo. De hecho, tienen que ser no sólo buenas, sino muy buenas para conseguir que todo el mundo las use. Al fin y al cabo el gran poder de Google es que sabe muchas cosas sobre nosotros, con lo que puede dirigirnos una publicidad mucho más específica.
Alguno quizá esté pensando que exagero, veamos un ejemplo: mediante Google Calendar, que resulta muy conveniente para sincronizar toda nuestra agenda, se puede tener acceso a, por ejemplo, si vamos al médico, con quién hemos quedado, reuniones, etc (por no hablar de que también se sabe desde dónde se ha enviado el mensaje o cuándo), mediante GMail se pueden ver nuestros contactos, cuándo solemos conectarnos, si solemos escribir o no, cuándo solemos escribir, cuánto tardamos, desde dónde escribimos y así podríamos seguir.
Recuerdo hace tiempo, en el segundo año de carrera, cuando un profesor mencionó de pasada el historial de Google o, dicho de otra manera, el registro que tenía Google de todas las búsquedas que había hecho desde 2008. De hecho, acabo de acceder y puedo saber que el 30 de Julio de ese año, a las 11:32 de la mañana accedí a una página sobre teoría de autómatas, seguramente para preparme el correspondiente examen. Curiosamente, no todo el mundo sabe que este historial existe, ya que no es algo publicitado o accesible desde la página de Google. Desde entonces ha llovido mucho, y Google ya tiene su propio navegador, sus propios portátiles, y sus dos grandes apuestas de presente y de futuro: Android y Google+.
El crecimiento de Android ha sido algo espectacular y su filosofía "libre" (nótense las comillas) es algo digno de admiración en comparación a Apple y Microsoft. Android ha permitido que los Smartphones pasasen de ser algo elitista a algo completamente común.
Pongo comillas a libre, porque aunque el núcleo de Android (que viene siendo Linux con una máquina virtual de Java y librerías en C/C++ por encima) sea libre, no pasa lo mismo con las Google Apps (GMail, Chrome, Maps y Play principalmente, aunque hay bastantes más), que vienen por defecto en la mayoría de Smartphones. Además, y por muy libre que sea, se ha demostrado que lo importante no es el sistema, sino las aplicaciones (véase Windows Phone, Meego, FirefoxOS, Tizen...). Al final, el que sea libre o no, no tiene tanta relevancia como pudiera parecer: o te ciñes a unas directrices, o adios tienda de aplicaciones y Google Apps, o lo que es lo mismo, adios a intentar conseguir ventas con ese terminal. Dicho esto, prefiero mil veces que el sistema sea libre a que no lo sea, pero continuemos...
Con Android, Google ha conseguido básicamente una plataforma tanto para recoger datos como para mostrar publicidad que llevamos siempre encima y siempre encendida y conectada. Si aún había alguna duda sobre esto, Google Now debería despejarla. Como ejemplo, un compañero de trabajo tenía conectado el GPS en el Nexus 5 e iba a introducir una ruta. El propio Maps se encargó de sugerirle la ruta que él pensaba tomar (hacia su casa) pero también una ruta alternativa que curiosamente llevaba hasta casa de su novia y que, a diferencia de la anterior, era a pie, que era como solía ir mi compañero. ¿Cómo se supone que sabía Google todo esto? Pensando mal, cualquiera diría que el móvil registraba cuándo y dónde se movía y la velocidad a la que iba, y apostaría a que si éste seguimiento fuera desactivable, no vendría desactivado por defecto y tendrías que acceder a algún menú recóndito para desactivarlo.
Ésta anécdota es sólo un ejemplo pero conviene recordar, aunque muchos no lo tengan todavía asumido, que en el bolsillo llevamos un ordenador con GPS, conexión a Internet permanente, micrófono, cámara y multitud de sensores. Resulta curioso como el modelo sandbox de seguridad de Android nos pide permisos para acceder a estos sensores o a diversas características del teléfono a la hora de instalar una aplicacion (una idea genial por otra parte, que ya podían implementar los sistemas operativos de sobremesa), pero podemos comprar una aplicación desde nuestro PC e inmediatamente y de forma transparente se descarga e instala en nuestro móvil. Básicamente, cualquier persona que conozca o descifre nuestra contraseña de Google puede instalarnos cualquier aplicación de Google Play sin que nos enteremos y sin necesidad de acceder a nuestro dispositivo (y luego nos escandalizaremos con el espionaje de la NSA).
La otra gran apuesta de Google es su red social Google+, lo cual tiene su lógica. No se me ocurre mejor manera de recopilar información de los usuarios que controlar una red social dominante (bueno, sí, Android, pero eso YA lo han hecho). Google+ puede ser una fuente de información (y de ingresos) brutal para Google, pero para ello necesitan que crezca y que se use, algo bastante complicado cuando tienes a Facebook como rey indiscutible.
¿Y cómo conseguir que los usuarios se cambien a otra red? Al principio pudieron pensar que añadir características únicas, como los círculos o los hangouts podrían inclinar la balanza a su favor. No sé si tuvieron éxito (aunque no se puede negar que fuesen buenas ideas) pero si lo tuvieron sin duda no fue suficiente, porque pronto pasaron a técnicas bastante más coercitivas.
Comenzaron promocionando Google+ en la página principal del buscador, siguieron activándolo por defecto en las nuevas cuentas de Google, activándolo por defecto en Android, instalando por defecto la aplicación oficial en Android (que además no se puede desinstalar como las aplicaciones normales, hay que hacerse root) y preguntándote en cualquiera de los servicios de Google si querías entrar. La red social sufrió un empujón importante, aunque las noticias decían que el tiempo de uso de la red era bastante reducido, algo normal por otra parte si "obligas" a registrarse a gente que no está interesada.
Google+ ya tenía usuarios, pero necesitaba contenido, ¿cómo conseguirlo? Pues qué mejor manera que forzar a los usuarios de la tienda de aplicaciones de Android a que usen su perfil de Google+ (con su nombre y apellidos reales) para evaluar cualquier aplicación u opinar sobre la misma. Da igual que sea una técnica rastrera: por una parte tenemos más contenido en la red social y por otro, Google puede usar esas opiniones para ponerles a tus amigos un bonito recuadro de publicidad donde puedan ver que tú recomiendas tal o cual aplicación, consiguiendo una publicidad mucho más directa y efectiva que mostrar un simple anuncio, por muy relacionado que esté con tus intereses. De paso, vamos a obligar también la necesidad de una cuenta de Google+ para comentar en Youtube, porque aunque llevamos años intentando que la gente vincule la cuenta de Youtube con nuestra red social y use su nombre completo, todavía hay algunos usuarios cabezones que no pasan por el aro...
La última fue hace unos días, cuando Google introdujo la posibilidad de que los usuarios de Google+ puedan enviar correos electrónicos sin saber tu dirección, directamente usando tu nombre de usuario de Google+ y, para variar, activado por defecto y sin notificarlo al usuario, que para eso estamos en la nube.
No sé si todos estos cambios han servido para conseguir los objetivos de Google, del mismo modo sé que a la mayoría de la gente todo esto le da exactamente igual o, si no le da, prefiere la practicidad a la privacidad. Yo mismo uso Google, GMail, Android, Youtube o, mismamente, Blogger (aunque ésto último seguramente cambie más pronto que tarde). Lo que sí se es que hace años que el "don't be evil" es papel mojado y que, aunque sigamos usando sus servicios, no está de más saber qué está pasando con nuestros datos, porqué está pasando y qué podemos esperar en un futuro.
No creo que ellos vayan a molestarse en explicarlo.
viernes, 11 de octubre de 2013
Conectar pantalla LCD 16x2 a Raspberry Pi
Aunque el proyecto de la radio está muy olvidado, ahora que tengo algo de tiempo he investigado si en lugar de utilizar un Arduino de intermediario (como hacía hasta ahora) era posible conectar una pantalla LCD directamente al Raspberry Pi utilizando los puertos GPIO (General Purpose Input Output) que incluye. La respuesta es que sí que se puede, y que no es demasiado complicado. Así que, cuando continúe con el proyecto de la radio, posiblemente me decida a descartar el uso del Arduino y conectar todo al Raspberry. Para muestra, un botón:
En mi caso, he usado una pantalla simple 16x2 compatible con el controlador HDD44780. Básicamente, cualquier pantalla económica de 16x2 que encuentres en eBay o similares será compatible con este controlador. Algunas, más caras, tienen una interfaz I2C o SPI que nos permiten entre otras cosas utilizar menos cables. La interfaz de dicha pantalla es paralela, con 4 cables para datos y, además, tiene algunos conectores adicionales para la luz, el contraste, el modo de funcionamiento, etc.
Para mostrar el texto en la pantalla utilizaremos un pequeño programa en Python (una vez hayamos instalado las librerías necesarias para poder controlar desde Python los puertos GPIO del Raspberry). Pero empecemos por el principio:
1. Realizando las conexiones
Además de los puertos que solemos usar en el Raspberry (USBs, Ethernet, HDMI, Audio…), tenemos disponibles otros puertos para conexiones de más bajo nivel. Entre otros tenemos un puerto serie, UART, I2C, SPI y 13 puertos GPIO que se pueden programar para adaptarse a nuestras necesidades. Para más información se puede consultar este enlace. Todos estos puertos están situados en los pines de la esquina del Raspberry:
Y el diagrama de dichos puertos es el siguiente:
En cuanto a las pantallas 16x2 (aunque también hay disponibles otros tamaños como 20x4), todas tienen 16 pines cuyo diagrama es el siguiente:
Los pines de datos son los DBX, aunque en la práctica se suelen utilizar sólo DB4-DB7. Para más información sobre estas pantallas se puede consultar este enlace, donde además se puede descargar el datasheet completo de las mismas.
Siendo el Pin 1 de la pantalla situado más a la izquierda (GND), las conexiones que hay que realizar entre el Raspberry y la pantalla son las siguientes (es conveniente ayudarse de una protoboard):
- Pin 1 de la pantalla (GND) a tierra.
- Pin 2 de la pantalla (VCC) a +5V.
- Pin 3 de la pantalla (VEE) a tierra.
- Pin 4 de la pantalla (RS) a GPIO 25.
- Pin 5 de la pantalla (RW) a tierra.
- Pin 6 de la pantalla (EN) a GPIO 24
- Pin 7, 8, 9 y 10 de la pantalla desconectados.
- Pin 11 de la pantalla (D4) a GPIO 23
- Pin 12 de la pantalla (D5) a GPIO 17
- Pin 13 de la pantalla (D6) a GPIO 21
- Pin 14 de la pantalla (D7) a GPIO 22
- Pin 15 de la pantalla (LED+) a 5V.
- Pin 16 de la pantalla (LED-) a tierra.
Aunque con estas conexiones tenemos suficiente, podemos conectar un potenciómetro al pin 3 para poder regular el contraste de la pantalla (si lo conectamos a tierra, estará al máximo). Del mismo modo, podemos conectar un potenciómetro a LED+ para reducir el brillo de la misma (o incluso conectarlo a 3V3 Power, de proporciona 3.3V en lugar de los 5V).
El diagrama de las conexiones sería el siguiente:
2. Instalando los paquetes necesarios
El segundo paso es instalar en nuestra distribución (yo estoy usando Raspbian) los paquetes necesarios para poder ejecutar nuestro script. En este paso será necesaria una conexión a Internet en el Raspberry.
Comenzaremos instalando los paquetes de desarrollo de Python, Python PIP (una especie de Synaptic pero para las librerías de Python), las Setup Tools para poder instalar easy_install y git para descargar más adelante los códigos de ejemplo de la página de Adafruit:
sudo apt-get install python-dev python-setuptools python-pip git
A continuación actualizaremos la herramienta distribute (parte de setuptools), que nos ayudará a descargar la librería GPIO:
sudo easy_install -U distribute
Una vez hecho esto, por fin podremos descargar la librería GPIO para Python:
sudo pip install rpi.gpio
3. Descargando códigos de ejemplo
Adafruit mantiene un repositorio Git con diversos códigos de ejemplo para el Raspberry. La forma más sencilla de descargarlos a nuestro sistema es clonar el repositorio. Como ya instalamos git en el paso anterior, basta con introducir:
git clone git://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code.gitTras unos instantes, se habrá creado en el directorio actual una carpeta llamada Adafruit-Raspberry-Pi-Python-Code con multitud de subcarpetas. A nosotros nos interesa en concreto la subcarpeta Adafruit_CharLCD:
cd Adafruit-Raspberry-Pi-Python-Codecd Adafruit_CharLCD
4. Modificando el código de ejemplo (sólo Raspberry Pi Rev. 2)
El código de ejemplo que vamos a utilizar es Adafruit_LCD.py. Si tenemos un Raspberry Rev. 1 (las primeras Raspberry, que no tenían agujeros para tornillos en la placa y sólo tenían 256MB de RAM en el modelo B) el código funcionará perfectamente. Si por el contrario tenemos un Raspberry Rev. 2 (con agujeros para tornillos y 512MB de RAM en el modelo B), hay que realizar una pequeña modificación en el código. Para ello, podemos abrirlo con nano:
nano Adafruit_CharLCD.py
Y en la línea donde pone:
def __init__(self, pin_rs=25, pin_e=24, pins_db=[23, 17, 21, 22], GPIO = NoneReemplazar el 21 por un 27 (esto es debido a un cambio en los puertos del modelo 2 del Raspberry. Para guardar el archivo modificado pulsamos Ctrl+O y salimos con Ctrl+X.
5. Probando todo
Sólo nos queda dar permisos de ejecución al programa y ejecutarlo con:
chmod +x Adafruit_CharLCD.pysudo ./Adafruit_CharLCD.py
Si todo ha ido bien, deberíamos ver algo parecido a lo siguiente:
En caso de no obtener el texto, lo más probable es que no hayamos hecho correctamente las conexiones entre el Raspberry y la pantalla, por lo que lo mejor es repasarlas para buscar posibles errores. También puede que nos hayamos saltado el paso 4 teniendo un Raspberry Rev. 2. Para asegurarte de tu versión de Raspberry, mira la siguiente imagen:
El Raspberry de la izquierda es la revisión 1 y el de la derecha es la revisión 2. Se distinguen fácilmente por los agujeros para tornillos marcados con las flechas rojas.
6. Mostrando fecha, hora y dirección IP interna
Si queremos mostrar algo parecido a lo que se puede ver en la primera imagen de esta entrada, basta con ejecutar el otro ejemplo del directorio:
chmod +x ./Adafruit_CharLCD_IPclock_example.pysudo ./Adafruit_CharLCD_IPclock_example.py
jueves, 10 de octubre de 2013
Unir dos ficheros PDF en Linux
Podemos unir fácilmente dos archivos PDF usando pdftk. No suele estar instalado por defecto, por lo que los pasos serán:
1. Instalamos pdftk. En Ubuntu lo haríamos con:
sudo apt-get install pdftk
2. Concatenamos los dos (o más archivos) con:
pdftk <archivo1.pdf> <archivo2.pdf> cat output <archivofinal.pdf>
1. Instalamos pdftk. En Ubuntu lo haríamos con:
sudo apt-get install pdftk
2. Concatenamos los dos (o más archivos) con:
pdftk <archivo1.pdf> <archivo2.pdf> cat output <archivofinal.pdf>
lunes, 7 de octubre de 2013
Mejorar renderizado de fuentes en Netbeans
Al hilo de la anterior entrada sobre el renderizado de fuentes en Linux, seguramente nos haya pasado que en algunos programas como Netbeans o JDownloader los textos se vean peor que en el resto de aplicaciones del sistema operativo. La razón parece ser que dichas aplicaciones están programadas usando Swing (la biblioteca gráfica JFC de Java), la cual utiliza su propio motor de renderizado, y que en muchas ocasiones se traduce en que en Linux las fuentes se ven bastante mal.
Afortunadamente, los mismos programadores de Infinality, que vimos en la entrada anterior, se han encargado de parchear OpenJDK para conseguir un renderizado de fuentes decente con aplicaciones que usen Swing. Según dicen en su repositorio en Launchpad, sólo mantienen paquetes para la distribución de Ubuntu más reciente (a fecha de hoy es la 13.04) y la LTS que haya actualmente activa (a fecha de hoy es la 12.04). Por suerte estoy usando Ubuntu 13.04, por lo que instalar OpenJDK parcheado es tan sencillo como:
1. Añadir el ppa:
Afortunadamente, los mismos programadores de Infinality, que vimos en la entrada anterior, se han encargado de parchear OpenJDK para conseguir un renderizado de fuentes decente con aplicaciones que usen Swing. Según dicen en su repositorio en Launchpad, sólo mantienen paquetes para la distribución de Ubuntu más reciente (a fecha de hoy es la 13.04) y la LTS que haya actualmente activa (a fecha de hoy es la 12.04). Por suerte estoy usando Ubuntu 13.04, por lo que instalar OpenJDK parcheado es tan sencillo como:
1. Añadir el ppa:
$ sudo add-apt-repository ppa:no1wantdthi
2. Actualizar paquetes:
$ sudo apt-get update
3. Instalar OpenJDK:
$ sudo apt-get install openjdk-7-jdk
El resultado es prácticamente el de una aplicación que use el renderizador nativo:
miércoles, 25 de septiembre de 2013
Mejorar renderizado de fuentes en Linux
Una de las cosas que noté en su día al empezar a usar Linux es que los textos "se veían mejor" en Windows. La solución que se podía encontrar por Internet era instalar las fuentes de Windows (msttcorefonts), pero ese no era el problema: las fuentes seguían viéndose menos nítidas que en Windows, al menos para mi gusto.
Años más tarde, y por un tema completamente diferente, me he enterado que el problema es el renderizador que utiliza Linux para el suavizado de las fuentes (el equivalente al ClearType de Microsoft). El renderizador se encarga entre otras cosas del suavizado de las fuentes para evitar que se vean los bordes de los caracteres. En esta imagen, sacada de este blog, se puede ver más claramente:
La imagen de la izquierda es una fuente normal, dibujada en la pantalla sin ningún tipo de suavizado. Es desde luego la forma más nítida de ver el texto, pero tiene el inconveniente de que se notan claramente los bordes dentados. Hay fuentes que se diseñan teniendo en cuenta esto, especialmente para programación, pero cada vez son menos usadas.
En la imagen central puede verse la misma fuente con un antialias estándar. También se denomina "suavizado con escala de grises". En este caso, en lugar de utilizar sólo el color base (en este caso el negro) tenemos disponibles 256 tonos de gris que, como vemos, se utilizan para suavizar el contorno de la fuente. El resultado, aunque algo menos nítido que el anterior, es mucho más agradable a la vista.
Por último, en la imagen de la derecha, tenemos el "suavizado de subpíxel" que mejora el suavizado de escala de grises anterior. Nuestro problema es que, debido al tamaño de los píxeles, los tonos de gris intermedios hacen que la fuente pierda nitidez al usar el método anterior. El suavizado de subpíxel intenta conseguir los resultados del suavizado con escala de grises pero perdiendo la mínima nitidez posible. Para ello se basa en una idea muy ingeniosa: cada píxel de un monitor está compuesto de tres subpíxeles con los colores primarios (RGB) cuya intensidad se regula para obtener el color final de ese píxel en concreto. Un píxel ampliado es muy similar al cuadrado de tres colores que puede verse en la esquina superior derecha de la imagen anterior.
La idea básica es que si queremos aumentar un poco el grosor de la fuente por la derecha, lo que haremos es usar un tono de rojo de modo que el subpíxel verde y el azul estén "apagados" y el rojo esté más o menos "encendido". Del mismo modo, si queremos aumentar un poco el grosor por la derecha, regularemos el subpíxel azul y apagaremos el verde y el rojo. Si queremos aumentar un poco más el grosor buscaremos un tono que encienda los subpíxeles verde y rojo o verde y azul según el caso, y de este modo tenemos tres veces más resolución horizontal con la misma pantalla.
En este concepto se basa Cleartype para Windows y el renderizador de fuentes de Linux en su opción por defecto. Adicionalmente, algunas distribuciones como Ubuntu han mejorado el renderizador para obtener textos más nítidos.
El problema es que hay distribuciones, como Debian, en las que las fuentes no se ven tan nítidas. Afortunadamente existe un proyecto llamado Infinality que introduce unos parches que mejoran el renderizado de los textos. De hecho, permiten incluso adoptar renderizados similares a los que se usan en MacOS, Ubuntu o Windows entre otros.
Las diferencias son notorias, como se puede ver en la imagen siguiente sacada de Webupd8:
Aunque en la imagen ya se nota suficiente, es cuando lo tienes instalado cuando te das cuenta de que todos los textos se ven mejor. Si queremos instalarlo, en el enlace anterior nos explican cómo, pero a grosso modo, en Ubuntu:
1. Añadimos el PPA correspondiente:
sudo add-apt-repository ppa:no1wantdthisname/ppa
2. Actualizamos los repositorios:
sudo apt-get update
sudo apt-get upgrade
3. Instalamos Infinality
sudo apt-get install fontconfig-infinality
4. Lo configuramos
sudo bash /etc/fonts/infinality/infctl.sh setstyle
Al ejecutar esta orden podremos elegir el estilo que queremos utilizar para el renderizado. Yo suelo escoger el de Ubuntu o el de Linux.
5. Reiniciamos o cerramos sesión para ver los cambios
Para instalar Infinality en el resto de distribuciones o para configuraciones más avanzadas, lo mejor es leerse el post original de Webupd8 (en inglés).
Años más tarde, y por un tema completamente diferente, me he enterado que el problema es el renderizador que utiliza Linux para el suavizado de las fuentes (el equivalente al ClearType de Microsoft). El renderizador se encarga entre otras cosas del suavizado de las fuentes para evitar que se vean los bordes de los caracteres. En esta imagen, sacada de este blog, se puede ver más claramente:
La imagen de la izquierda es una fuente normal, dibujada en la pantalla sin ningún tipo de suavizado. Es desde luego la forma más nítida de ver el texto, pero tiene el inconveniente de que se notan claramente los bordes dentados. Hay fuentes que se diseñan teniendo en cuenta esto, especialmente para programación, pero cada vez son menos usadas.
En la imagen central puede verse la misma fuente con un antialias estándar. También se denomina "suavizado con escala de grises". En este caso, en lugar de utilizar sólo el color base (en este caso el negro) tenemos disponibles 256 tonos de gris que, como vemos, se utilizan para suavizar el contorno de la fuente. El resultado, aunque algo menos nítido que el anterior, es mucho más agradable a la vista.
Por último, en la imagen de la derecha, tenemos el "suavizado de subpíxel" que mejora el suavizado de escala de grises anterior. Nuestro problema es que, debido al tamaño de los píxeles, los tonos de gris intermedios hacen que la fuente pierda nitidez al usar el método anterior. El suavizado de subpíxel intenta conseguir los resultados del suavizado con escala de grises pero perdiendo la mínima nitidez posible. Para ello se basa en una idea muy ingeniosa: cada píxel de un monitor está compuesto de tres subpíxeles con los colores primarios (RGB) cuya intensidad se regula para obtener el color final de ese píxel en concreto. Un píxel ampliado es muy similar al cuadrado de tres colores que puede verse en la esquina superior derecha de la imagen anterior.
La idea básica es que si queremos aumentar un poco el grosor de la fuente por la derecha, lo que haremos es usar un tono de rojo de modo que el subpíxel verde y el azul estén "apagados" y el rojo esté más o menos "encendido". Del mismo modo, si queremos aumentar un poco el grosor por la derecha, regularemos el subpíxel azul y apagaremos el verde y el rojo. Si queremos aumentar un poco más el grosor buscaremos un tono que encienda los subpíxeles verde y rojo o verde y azul según el caso, y de este modo tenemos tres veces más resolución horizontal con la misma pantalla.
En este concepto se basa Cleartype para Windows y el renderizador de fuentes de Linux en su opción por defecto. Adicionalmente, algunas distribuciones como Ubuntu han mejorado el renderizador para obtener textos más nítidos.
El problema es que hay distribuciones, como Debian, en las que las fuentes no se ven tan nítidas. Afortunadamente existe un proyecto llamado Infinality que introduce unos parches que mejoran el renderizado de los textos. De hecho, permiten incluso adoptar renderizados similares a los que se usan en MacOS, Ubuntu o Windows entre otros.
Las diferencias son notorias, como se puede ver en la imagen siguiente sacada de Webupd8:
Aunque en la imagen ya se nota suficiente, es cuando lo tienes instalado cuando te das cuenta de que todos los textos se ven mejor. Si queremos instalarlo, en el enlace anterior nos explican cómo, pero a grosso modo, en Ubuntu:
1. Añadimos el PPA correspondiente:
sudo add-apt-repository ppa:no1wantdthisname/ppa
2. Actualizamos los repositorios:
sudo apt-get update
sudo apt-get upgrade
3. Instalamos Infinality
sudo apt-get install fontconfig-infinality
4. Lo configuramos
sudo bash /etc/fonts/infinality/infctl.sh setstyle
Al ejecutar esta orden podremos elegir el estilo que queremos utilizar para el renderizado. Yo suelo escoger el de Ubuntu o el de Linux.
5. Reiniciamos o cerramos sesión para ver los cambios
Para instalar Infinality en el resto de distribuciones o para configuraciones más avanzadas, lo mejor es leerse el post original de Webupd8 (en inglés).
domingo, 16 de junio de 2013
Creando túneles SSH con Putty
Para transferir archivos con un servidor del trabajo, me resulta muy cómodo usar WinSCP. El problema surge cuando me conecto desde mi piso, y he de entrar primero al servidor general de SSH y, una vez ahí, acceder al servidor en cuestión mediante su IP interna. En este caso no podía usar WinSCP y tenía que transferir los ficheros manualmente con scp… hasta ahora.
¿La solución? Accedemos al servidor en cuestión con un cliente SSH como Putty y establecemos un túnel SSH entre el servidor y nuestro PC. A continuación conectamos WinSCP al “lado” del túnel que se encuentra en nuestro PC, y de forma transparente la información llegará al otro “lado”, es decir, al servidor.
Para que se entienda mejor, he hecho un pequeño esquema:
Tenemos por un lado el PC de mi casa. Desde él, puedo hacer un SSH al servidor SSH a través de Internet, pero no al servidor destino, ya que éste no tiene su IP ni su puerto SSH conectado a Internet, sino a la red interna. Lo que queremos conseguir es algo parecido a la flecha verde de arriba: conectarnos al servidor destino de manera que el resto de aplicaciones crean que se trata de una conexión directa.
Hacer esto con Putty es muy sencillo. Comenzamos abriéndo Putty y estableciendo los datos generales de la conexión:
En “Host Name” he puesto la dirección del servidor SSH, desde el cual tengo que acceder a servidor destino. Podemos cambiar también la codificación de caracteres (en Window>Translation) y poner el nombre de usuario por defecto en Connection>Data. Pero vayamos a la parte interesante:
En Connection>SSH>Tunnels podemos establecer nuestro túnel. Para ello, en Source Port pondremos nuestro “lado” del túnel, es decir, el puerto de nuestro PC que vamos a conectar con el servidor destino. En Destination pondremos el otro “lado” del túnel, es decir, la dirección y el puerto del servidor destino una vez que hemos entrado en el servidor SSH. Por último pulsamos en Add y podemos ver que se ha añadido una línea como la que he tachado parcialmente en azul. Básicamente esto dice: “Cuando nos conectemos al puerto 2222 de nuestro PC, en realidad accederemos al servidor destino Y:22, que se encuentra dentro de la conexión SSH que hemos establecido previamente con el servidor SSH X:22. Si abrimos ahora la conexión, podemos comprobar cómo funciona perfectamente:
Como vemos, cuando accedemos al puerto 2222 de nuestra máquina, vemos el SSH del servidor destino. Ahora que vemos que el túnel funciona, sólo queda conectarnos con WinSCP directamente a localhost:2222, y podremos acceder directamente al servidor destino gracias al túnel SSH.
Suscribirse a:
Entradas (Atom)