iOS se estanca

A estas alturas, el año pasado iOS 7 ya estaba en casi el 70% de los dispositivos en los que podía instalarse. Sin embargo, ahora sólo está en el 47%:

A 5 de octubre de 2014.

Entre las posibles razones para que esto sea así se están destacando dos:

  • La pérdida de confianza de los usuarios provocada por los fallos en iOS.
  • El espacio necesario para poder instalar iOS 8 desde iOS 7 (5 GB).

Diría que la segunda razón es la que más peso está teniendo.

Pero existe una tercera razón, no es tan importante como estas dos aunque añade su granito de arena a los porcentajes: el iPhone 4 se ha quedado fuera de esta actualización. Se vendieron muchos más iPhone 4 que 3GS, motivo por la que la influencia de aquellos que se quedaron fuera de iOS 7 fue menor que la de aquellos que han quedado ahora fuera de iOS 8.

Como desarrollador para iOS se trata de algo que me preocupa, quisiera que todos estuviesen usando iOS 8 lo antes posible. Cuanto más repartida esté la población de usuarios de iOS entre las diferentes versiones, más me costará hacer un buen trabajo, tener a todo el mundo contento.

Así que me pregunto si esta tendencia se hará más pronunciada en la siguiente iteración hardware/software. Espero que no, o Apple recupera la confianza perdida y encuentra una manera de actualizar iOS que requiera menos espacio, o la brecha se hará cada vez más grande.

Porque estoy seguro de que no va a regalar un iPhone nuevo a quien no pueda instalar iOS 9.

Anuncios

La historia de Mel

I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.

“The Story of Mel”, de Ed Nather (utastro!nather).

Escuché hablar de Mel en el programa 000 de We.Developers.

MKVs y MediaCenter 4G

Algunos MKV no se reproducen correctamente en el MediaCenter 4G de InOutTV. El síntoma es, en concreto, que se oye pero no se ve; por lo visto está relacionado con la compresión de la cabecera.

Dados estos datos, los siguientes pasos pueden ayudarte a convertir los MKV para que se vean correctamente en dicho MediaCenter:

  1. Instala Xcode (si no lo has hecho ya). Es necesario para el siguiente paso.
  2. Instala homebrew. Basta con esta orden:
    ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
  3. Instala mkvtoolnix:
    brew install mkvtoolnix
  4. Es posible que tengas que crear la carpeta /usr/local/Cellar:
    mkdir /usr/local/Cellar
  5. Para reconvertir los MKV ejecuta esta orden:
    mkvmerge --compression 1:none -o nuevo.mkv viejo.mkv

De momento, lo he probado y funciona. Espero que os sea útil hasta que InOutTV solucione este problema.

Trasladar un certificado SSL de IIS a Apache

Cómo trasladar e instalar en Apache un certificado SSL emitido para IIS.

Empieza por exportar el certificado IIS a un archivo PFX (algo que, de todas formas, tendrás que hacer si quieres tener una copia de seguridad del certificado):

  • Ejecuta mmc.exe.
  • Selecciona la opción Agregar o quitar complemento del menú Consola.
  • Haz clic en el botón Agregar, selecciona el complemento Certificados y haz clic en Agregar.
  • Selecciona la opción Cuenta de equipo y haz clic en Siguiente.
  • Selecciona Equipo local y haz clic en Finalizar.
  • Haz clic en Cerrar y, a continuación, en Aceptar.
  • Expande el nodo Certificados y haz clic en la carpeta Personal.
  • Haz clic con el botón derecho sobre el certificado que quieras exportar y selecciona Todas las tareas>Exportar.
  • Se pondrá en marcha un asistente. Deja todas las opciones predeterminadas, pero asegúrate de que la opción Exportar la clave privada esté seleccionada. Sigue todos los pasos hasta que obtengas el archivo PFX.

A continuación, ejecuta openssl para extraer la clave privada y el certificado:

# Exportar la clave privada del archivo PFX.
openssl pkcs12 -in archivo.pfx -nocerts -out clave.pem

# Exportar el certificado del archivo PFX.
openssl pkcs12 -in archivo.pfx -clcerts -nokeys -out certificado.pem

# Eliminar la contraseña de la clave privada para que Apache no
# la pida al ponerse en marcha.
openssl rsa -in clave.pem -out servidor.key

Ahora, copia dentro de la carpeta donde guardes los certificados del dominio (por ejemplo, /etc/apache2/certificados/www.example.com/) el archivo certificado.pem con el nombre AAAA-www.example.com.pem ((Obviamente, AAAA son los cuatro dígitos del año actual.)) y el archivo servidor.key con el nombre AAAA-www.example.com.key.

Enlaces externos

Too Much Information

Cómo borrar el contenido de una carpeta cuando ésta contiene demasiados archivos en UNIX.

Si alguna vez has intentado eliminar el contenido de una carpeta en UNIX ((Quiero decir Linux, imagino que también pasa en BSD, OpenBSD, Mac OS X, etcétera.)), es posible que te hayas encontrado con este problema:

$ rm * -f
-bash: /bin/rm: Argument list too long

Es decir, en la carpeta hay demasiados archivos y rm no puede con todos ellos. Una posible solución:

$ for i in `ls` ; do rm -f "$i" ; done

Banda sonora: ‘Too Much Information’ de The Police.

Twitter Stats

Programa escrito en Perl para generar estadísticas de utilización de Twitter en Mac OS X con Numbers.

Eduo habla hoy sobre Twitter Stats ((Ahora, también en Google Code.)), un programa escrito en Perl que los usuarios de Mac OS X que tengan Numbers instalado pueden utilizar para ver unos bonitos gráficos que resumen cómo han utilizado Twitter mostrando, por ejemplo, a quién se responde con mayor frecuencia o la utilización de este servicio por horas o por días.

Por la razón que sea no he logrado que Twitter Stats funcione en mi máquina. Menos mal que alguien se ha tomado la molestia de convertirlo en una aplicación Web que utiliza Google Charts API para crear los gráficos resultantes. Aunque estéticamente, al menos por el momento, deja bastante que desear, el resultado es aceptable:

  1. Tweets por hora: soy un búho.
  2. Tweets por hora

  3. Tweets por día: empiezo con fuerza pero me desinflo.
  4. Tweets por dia

  5. Tweets por mes: interés creciente.
  6. Tweets por mes

  7. A quién respondo más: pobre eduo.
  8. A quién respondo más

Conclusión: mientras el propio Twitter no proporcione estas estadísticas, paso de ellas.

Revisa la ortografía con WordPress

Con muy pocos cambios en WordPress puedes revisar la ortografía de las entradas que escribas.

Si utilizas el editor visual de WordPress es posible que te hayas fijado en el icono de revisión ortográfica (cuya etiqueta es Toggle Spellchecker):

Revisión ortográfica

Al desplegar el menú asociado a dicho icono sólo verás la opción English. Para que aparezca, además, la opción Spanish en WordPress 2.3 (que es donde lo he probado) tienes que editar el archivo /wordpress/wp-includes/js/tinymce/plugins/spellchecker/editor_plugin.js y cambiar esta línea:

var i, ar = tinyMCE.getParam('spellchecker_languages', '+English=en').split(','), p;

por esta otra:

var i, ar = tinyMCE.getParam('spellchecker_languages', '+Spanish=es,English=en').split(','), p;

Visto en Viciao2k3.

¡Vente a Belice, César!

Las causas de la desaparición de los dominios BZ de los servidores DNS de Telefónica.

César, rezando para que Belice vuelva a existirComo algunos ya sabréis porque lo habréis sufrido en vuestras propias carnes, durante unos meses los servidores de nombres de Telefónica no resolvían los nombres de los dominios .bz. Es decir, no era posible obtener la dirección IP de un dominio terminado en .bz. Como consecuencia, ningún usuario ADSL de Telefónica que utilizase los servidores DNS predeterminados podía acceder a las páginas servidas desde estos dominios.

El problema se solucionó, pero hasta ahora no he podido explicar aquí cómo fue porque no disponía de todos los detalles. No fue gracias a todas las incidencias que abrimos con Telefónica, no. La promesa de llamarnos a la mayor brevedad posible que nos hicieron en cada una de ellas no se cumplió. Tampoco fue cuestión de tiempo: si nos hubiésemos quedado quietos, rezando como César, es posible aún siguiésemos en las mismas. Al final todo fue tan sencillo como llamar a un amigo que tenía un amigo que conocía a alguien que tenía un contacto en el mismo corazón de Telefónica. Esa persona tan bien relacionada no es otra que Alberto Lozano.

Alberto Lozano

Gracias a Alberto, los dominios .bz volvieron a estar disponibles para los servidores DNS de Telefónica entorno al 26 de febrero de 2007 (unos días antes). Aunque ya le di las gracias a él, a los dos amigos intermedios e, indirectamente, al “infiltrado” que había en Teléfonica, es mi responsabilidad darles también las gracias a todos los implicados desde aquí. A fin de cuentas, utilicé este púlpito para hacer público el problema y os debo a todos una explicación. Y esa explicación que os debo, os la voy a pagar.

Alberto me contó lo que puedes ver a continuación el pasado 27 de febrero de 2007 (las negritas son cosa mía):

Hola Juan. Encantado de haberos podido ser de ayuda. Ya sabes que lo importante no es saber sino tener el teléfono del que sabe… como diría Groucho. 🙂 Aunque en esto Jorge acudió a una persona que tiene amigos hasta en el infierno… o sólo en el infierno. Quién sabe. 🙂

Puedes citar mi nombre; no me importa, soy una persona bastante conocida y ya no viene de ahí. Eso sí, como es lógico, no te voy a dar los nombres ni cargos de quienes, desde “dentro de infierno”, atendieron mi ruego. Precisamente, en un par de semanas tendré ocasión de hablar en persona con quien inició la investigación interna y hasta donde me diga te lo comentaré en privado para que estés informado a título de curiosidad.

En principio y como supongo que te habrá dicho Jorge, se trataba de un bloqueo por “razones de seguridad”. La verdad es que se me escapan esas razones y lo cierto es que una vez mis amigos abrieron la incidencia interna, en pocos días estuvo resuelto. Pero si comunicar a terceros las “razones de seguridad” no me obliga a cumplir una ilegalidad, te las diré.

Como le comenté a Jorge, Telefónica, en cuanto a atención al cliente es como una cebolla y cuando lo problemas están en el corazón de esa cebolla, las incidencias que se abren en las capas exteriores carecen del oxígeno necesario para bucear hasta abajo.

Es un problema del que adolecen las grandes compañías. Cuando se trata de un problema de funcionamiento entre el usuario y su conexión con ese usuario, lo suelen resolver pero cuando el problema es de raíz, les fallan o, más correctamente, no existen los mecanismos para corregirlo.

La empresa subcontratada o la división de Telefónica que atiende el funcionamiento de los DNS no tiene conexión con la que atender a los usuarios finales. O, si la tiene, es a través de unos largos caminos burocráticos que acaban disolviendo la incidencia.

Se supone que los backbones de Telefónica funcionan bien…
Se supone que los puntos de conexión con otros backbones también funcionan bien…
Se supone que el sistema de enrutado de Telefónica funciona OK…
Se supone que los servidores de DNS funcionan como deben…

…ya que para todo eso funcione están los correspondientes responsables, directores de Calidad, técnicos, consolas de monitoreo, etc.

Y como todo lo anterior funciona correctamente, lo que no se supone es que un usuario de calle pueda detectar un mal funcionamiento de esos sistemas básicos y, por tanto, cualquier incidencia que abra un usuario de calle en ese sentido tiene muchas posibilidades de ser tragada por el agujero negro de la burocracia interna o ser guardada en el directorio /tmp/ hasta que se borre por si sola si nadie la recoge de ahí. Eso si no la meten directamente en /dev/null/ 😀

Un saludo y a mandar para lo que necesites.

No fue hasta el pasado 20 de abril de 2007 que supimos todos los detalles de este “bloqueo por razones de seguridad”:

[…]
Resulta la red neteka.net detectó envíos masivos de spam provinientes de Telefónica a direcciones de correo @xxxx.bz y los servidores dns de neteka.net, responsables del TLD .bz, discriminaron (notificándolo) a Telefónica como medida de seguridad (de ahí el comentario que me hizo mi amigo sobre que se había cortado por razones de seguridad) y… por lo visto nadie se miró la notificación de neteka.net acerca de la discriminación. Así hubiese quedado ad aeternam) Las incidencias desde el lado de cliente, las tuyas, no hubiesen prosperado. Como ya te comenté en su momento, no existe mecanismo previsto.

El caso es que mediante una incidencia interna el tema se resolvió muy rápido, el necesario para contactar con neteka.net confirmándoles que la fuente de spam estaba cancelada.
[…]

Esta claro que hay que tener amigos hasta en el infierno, como ha quedado rotundamente demostrado.