Continuan los problemas de A3 Media: cortes en la emisión y programación

Cada año A3 Media se felicita del número de espectadores de su web Atresplayer.com, donde se puede ver la programación de varias emisoras en directo y programas ya emitidos, como por ejemplo de Antena 3 y La Sexta.

El problema de ver la televisión en directo en AtresPlayer es que los horarios de los programas no coinciden con el real.

Por ejemplo, los telediarios comienzan la emisión antes de que aparezca en la web para verlos: solo aparecen como "próxima emisión". Así que siempre te pierdes los primeros 5 o 10 minutos de los programas.

También la programación termina antes que la emisión real, por lo que la emisión en directo se corta antes de que termine la emisión real del programa, como suele suceder con El Intermedio.

Otro problema recurrente son los cortes durante la emisión en directo, con cortes de comunicación que hace que se repitan unos segundos para luego perderte otros.

Si realmente En grupo A3 Media quiere tener espectadores en Internet, tiene aún que mejorar, al menos, estos dos problemas que desaniman a ver su programación.

Android y el volumen loco (Actualizado)

Estamos en una época en la que la informática es de pitorreo. Los errores campan a sus anchas y los programadores parecen idiotas.

El último ejemplo es el control del volumen del sonido en Android: si estás escuchando música y recibes una notificación, el volumen de la música baja para que puedas oír la notificación y luego debería volver al volumen inicial, pero en lugar de eso se queda más bajo. Glorioso.

Un fuerte aplauso para Google y Android.

Actualización: el problema resulta ser de Dolby y la marca BQ. Cuando suena una notificación se desactiva el Dolby, bajándose el volumen del sonido.

Así que el fuerte aplauso es para Dolby y BQ.
A cada uno lo que es suyo.

El curioso caso muchas empresas informáticas

Cuando contratas un trabajo, un programa, a una empresa informática, su objetivo es ganar dinero con ello, pero se sobreentiende que la empresa tiene la capacidad adecuada y es competente. Con frecuencia no es así y hacen autenticas chapuzas que luego se pagan resolviendo las incidencias (eufemismo de "problema") que causa aquella chapuza. Y los empresarios que las contratan no lo ven o no lo quieren ver.

Solo conozco una gran empresa, por tamaño, en la que si una " incidencia" ocurría más de tres veces en un mes pasaban a catalogarla como problema a resolver de forma definitiva, no sólo el problema en sí sino la causa.
El resto de empresas se dedican a pagar por contratos de "mantenimiento" que solo resuelven las "incidencias". Un negocio redondo: le cobras por la chapuza y luego por los problemas que ocasiona la chapuza.

Pero no acaba aquí el cuento. Cuando el cliente pide una modificación del programa se hace otra chapuza sobre la chapuza original. Y tras cada chapuza es más complicado hacer una mínima modificación, o nueva chapuza.

Esto, unido a la total ausencia de documentación y a la "rotación de personal" (eufemismo de "los programadores se marchan quemados de trabajar a contrarreloj para hacer y mantener las chapuzas y se llevan con ellos el conocimiento de las chapuzas y cómo funcionan"), termina en un programa monstruo que no hay forma de modificar una línea de código y saber a qué afectará.

Algunas empresas, como la que me refería antes, reaccionan tarde y le piden a la empresa de las chapuzas, que documenten los programas. No hace falta ser muy listo para saber cómo va a ser esa documentación: otra chapuza que no servirá para mucho. Y el cliente será incapaz de darse cuenta.

Todo esto muy a menudo con el agravante de que el cliente ni sabe lo que necesita ni cómo es su forma de trabajo o ésta esta lejos de ser óptima, a veces incluso es incoherente.

Esto apenas ocurre en las empresas bien gestionadas que se hacen sus propios programas o tienen un control adecuado del que encargan. Otro caso a parte es el de las empresas con departamentos de programación pero a los que otros departamentos actúan como el tipo de clientes irresponsables que mencionaba antes.

Oracle: ejemplos poco ejemplares

En esta página (http://docs.oracle.com/javadb/10.6.1.0/adminguide/tadminconfigverifyingstartup.html) Oracle muestra cómo saber si un servidor Derby, una pura copia de la base de datos de Apache a la que únicamente le han cambiado el nombre. Pero veamos qué ejemplo utilizan.

Dos barbaridades de GIMP

El programa de edición fotográfica Open Source, libre y gratis por popularidad, que no excelencia, es sin duda GIMP.

Pero GIMP tiene dos errores de concepto que son una muestra de la falta a veces de la necesaria visión global de lo que se está haciendo.

El primero de los errores es en qué tipo de ventanas se muestran, por ejemplo, la barra de herramientas. Por defecto se muestran cono una ventana más. El problema es que al mover la imagen que se está editando ésta puede quedar encima de las herramientas, lo que es una molestia. Así que GIMP permite indicar que las herramientas se muestren en un tipo de ventana que siempre está por encima de todas las demás. Así la ventana de edición de la imagen nunca estará encima de las herramientas. Hasta aquí bien.

¡Splash Screen!

Muchos, pero que muchos programas, muestran un “splash screen” al iniciarse, pero no siempre ha sido así. Antes los programas se inciaban sin más, en un abrir y cerrar de ojos, o si no se sabía quese esraba iniciando porque oíamos el traqueteo de la disquetera, pero a partir de cierto momento, tardaban un tiempo considerable antes de mostrar nada en la pantalla así que lo que un programador listo pensó que hasta que se pudiera mostrar la ventana principal del programa era calmante para el usuario mostrarle algo conforme el programa se estaba iniciando. Mientras se mostraba esta ventana con apenas el logotipo del programa éste iba realizando los trabajos necesarios de inicialización.

Conceptos básicos de programación: "¿Está seguro?"

Las preguntas de confirmación son algo normal en cualquier programa. Existen porque la persona que los usa puede equivocarse y elegir una opción equivocada por error.

Pero la pregunta para confirmar la opción elegida debe utilizarse donde tenga utilidad y hay muchos programas que la usan a diestro y siniestro consiguiendo que exasperar al usuario.

Que quede claro: la única situación donde es útil es cuando realizar la acción elegida por error no puede deshacerse o volver al estado anterior requiere un esfuerzo o tiempo considerable.

Por ejemplo, en un programa de calculadora, ¿tiene sentido que al pulsar el = se pida confirmación? No. No es tan costoso volver a introducir la operación.

En un programa que formatea el disco duro, ¿tiene sentido pedir confirmación? Sí, volver al estado anterior puede ser imposible si no se tiene una copia de seguridad o considerablemente costoso aunque se tiene dicha copia.

En un programa pequeño, ¿tiene sentido que pida confirmación al salir? No si el programa se carga rápido. Otra cosa es que pregunte si se desea antes de salir guardar los documentos no guardados. En cambio, en un programa grande que tarda en cargarse sí tiene sentido.

Programadores, por favor, usen las preguntas de confirmación sólo cuando tengan sentido.

Confusiones épicas: cadenas de texto

La informática es maravillosa. Permite coger un proceso tedioso y automatizarlo, dejando las tareas creativas a las personas.
Pero tiene un lado oscuro: cuando esas mismas personas pretenden reinventar la realidad o entienden mal un problema. Vamos, lo que se conoce como "pajas mentales".

Advierto que este "artículo" no es para todos los públicos y puede ser soporífero para quienes no han programado.

Cadenas de texto

La informática lleva dando tumbos desde sus inicios a cómo representar lo que en cualquier idioma es un sencillo texto.

Comprendo que inicialmente los caracteres se representasen en 7 bits (ASCII) y que luego lo ampliasen a 8 bits, que luego se quedase corto e inventasen UFT-8 y que luego se internacionalizase con UNICODE.

Lo que no puedo entender es cómo puede llegarse a complicar tanto la representación de un texto. Me refiero a un trozo de texto, una frase, no a un texto completo.

Andengine, Box2D y SVG: cómo guardar el contorno en el propio SVG.

Hoy un regalito para aquellos programadores que utilizan Andengine, ese gran motor para gráficos bidimensionales y gratuito gracias a Nicolas Gramlich. Nunca le daré las gracias lo suficiente.


Andengine tiene una extensión Box2D que permite hacer que los elementos tengan propiedades como gravedad, fricción o elasticidad, como si de objetos reales se tratara. 

A un objeto se les llama sprite y para que tenga propiedades físicas debe asociarse a un body que es en realidad el que tiene las propiedades y mueve el sprite consigo.

Esclavos de las actualizaciones y los intereses ocultos

¿Quien no querría actualizar su software? Yo, en las condiciones en las que los fabricantes las realizan actualmente.

Muchas veces lo correcto no es lo más cómodo, pero no por eso, y aunque finalmente no lo hagamos, deberíamos dejar de admitir qué es lo correcto.

Si un software se difundió con un error, el fabricante está en la obligación ética de corregirlo.

Los actuales contratos de licencia de uso del software son un abuso inadmisible. En la mayoría de los casos se resumen en: "El software se le sirve tal cual se le entrega, sin garantía de ningún tipo." Esto incluye los errores en el diseño y en la programación.

Pero los fabricantes no se limitan en el mejor de los casos a corregir los errores de su software, de ahí que lo llamen "actualizaciones". Las actualizaciones incluyen la corrección de errores en lo que es en realidad un cambio en el funcionamiento del software. De hecho están entregando una nueva versión, que incluye y elimina características de que las que el fabricante no informa, dejando al usuario y consumidor a merced de decisiones no explicitamente consentidas.

Ni siquiera se le deja elegir al usuario entre si quiere las correcciones de los errores o las actualizaciones: ambas se sirven en el mismo plato.

Esto llevaba, por ejemplo, a que un ordenador con Windows XP, funcionase perfectamente con la versión original y fastidiosamente mal con el último Service Pack.

Y uno se pregunta, ¿por qué querría el fabricante cambiar el funcionamiento de su software sin el consentimiento del usuario? Se me ocurren varias razones:
1.- Falta de objetivo claro para el software: el fabricante cambia para qué sirve el software conforme a factores ajenos a las necesidades del usuario y en favor de sus propios intereses.
2.- Incluir nuevas funcionalidades: con ello, más adelante, pueden dar soporte para funcionalidades que aún no usan otros softwares. Un día, mágicamente, nuestro ordenador es compatible con esa nueva funcionalidad que no hemos pedido ni autorizado a cambio de que el software utilice más recursos de nuestro ordenador.
3.- Intereses ocultos: hay gente que aún tiene en mente cuando Microsoft Windows, misteriosamente, dejó de funcionar con el sistema operativo D.O.S. de Digital Research, un sistema que le daba dos bofetadas al D.O.S de Microsoft.

Hace unos días leía la noticia de la reprimenda que le dedicó el creador del núcleo de Linux a otro programador, refiriéndose a que un cambio que proponía éste último haría que programas existentes dejasen de funcionar.
Espero que no se me malinterprete: estoy a favor de la evolución del software, siempre y cuando eso no suponga tirar a la basura el trabajo de todos lo que han estado desarrolando software. Cualquier software desarrollada debería poder ser ejecutado ahora en un entorno adecuado.
Si un cambio necesario en un entorno de ejecución fuera a dejar inoperativo el software existente, se debería considerar un nuevo entorno y no considerarse como el mismo entorno pero "mejorado".

Y es que con los cambios de funcionalidades ocultos tras las actualizaciones no sólo se molesta al usuario. También se suele molestar a los programadores que ven como deben volver a modificar su software para que funcione en el nuevo entorno, algo que raras veces debería ocurrir.

Y en el momento de terminar este texto, la infamia continúa.

Premio al error del día: www.helloandroid.com

Hoy damos el premio al error del día a estos profesionales de www.helloandroid.com.

Siguiendo uno de sus ejemplos, que indica cómo se puede hacer un widget:esos iconos que se ponen en la pantalla, como relojes, tiempo meteorológico y demás.

Concretamente explican cómo hacer uno con los días que faltan hasta navidad, que es lo de menos. Lo importante es saber cómo han hecho para que el widget se actualice cada cierto tiempo, porque Android, en prinicipio sólo permite hacerlo una vez cada 30 minutos como mucho.
Y aquí es donde yo sigo su ejemplo y le cambio los 60 segundos que ellos utilizan por 1 segundo, para ver si la cosa va bien.

Y sí, parece que va bien. El iconito muestra los segundos de la hora actual con alegría.

Dejamos el móvil un ratín a su aire, digamos, una hora.

Pero mi alegría inicial se va tornando más oscura cuando la desbloquear el móvil veo que el numerín  está parado. Y no sólo eso: además, cambiar de una pantalla a otra se ha convertido en algo pegajoso.

En el log del teléfono que puede verse desde Eclipse, a parte del log que he hecho que deje el widget cada vez que actualiza el número, empezamos a ver con frecuencia cosas somo estas:

02-17 03:37:23.195: D/dalvikvm(9546): GC_CONCURRENT freed 1620K, 38% free 9020K/14535K, external 5496K/6863K, paused 2ms+5ms

02-17 03:37:23.500: D/dalvikvm(9760): GC_CONCURRENT freed 1988K, 53% free 4530K/9479K, external 10379K/12380K, paused 2ms+2ms

Un poco más adelante...

02-17 03:41:08.420: D/dalvikvm(9997): GC_EXPLICIT freed 11K, 50% free 2737K/5447K, external 0K/0K, paused 16ms

02-17 03:41:08.615: D/dalvikvm(9760): GC_CONCURRENT freed 1978K, 53% free 4649K/9735K, external 10379K/12380K, paused 2ms+2ms

Luego empiezan a aparecer de tres en tres.

02-17 03:43:10.345: D/dalvikvm(9546): GC_CONCURRENT freed 2019K, 39% free 8971K/14535K, external 5502K/6863K, paused 4ms+7ms
02-17 03:43:10.355: D/dalvikvm(9760): GC_CONCURRENT freed 2139K, 54% free 4578K/9799K, external 10379K/12380K, paused 2ms+6ms
02-17 03:43:10.825: D/dalvikvm(9760): GC_CONCURRENT freed 1925K, 53% free 4666K/9799K, external 10379K/12380K, paused 1ms+2ms

Luego, de cuatro en cuatro:

02-17 03:49:15.160: D/dalvikvm(10607): GC_EXPLICIT freed 35K, 50% free 2721K/5379K, external 0K/0K, paused 27ms

02-17 03:49:15.220: D/dalvikvm(11003): GC_EXTERNAL_ALLOC freed 483K, 57% free 4107K/9543K, external 4184K/4184K, paused 31ms

02-17 03:49:15.325: D/dalvikvm(9546): GC_CONCURRENT freed 2542K, 37% free 9189K/14535K, external 1608K/2056K, paused 3ms+5ms

02-17 03:49:15.475: D/dalvikvm(9760): GC_CONCURRENT freed 1280K, 39% free 7373K/11975K, external 10442K/12380K, paused 2ms+3ms

Comienzan a aparecer logs de error:
02-17 03:52:49.215: E/JavaBinder(9546): !!! FAILED BINDER TRANSACTION !!!
02-17 03:52:49.215: E/JavaBinder(9546): !!! FAILED BINDER TRANSACTION !!!
02-17 03:52:49.215: E/JavaBinder(9546): !!! FAILED BINDER TRANSACTION !!!

Y finalmente la perla:

Pulsamos el botón de inicio. Aparece el escritorio SIN el widget. Luego aparece el widget, pero no se actualiza cada segundo ni de lejos. El escritorio se ha convertido en algo súmamente pegajoso, nada ágil.

Aparece la segunda perla:

Y una tercera:

Vuelve a aparecer el error de que TwLanuncher no responde varias veces.

La hecatombe sucede: el móvil se reinicia. Prefiero pensar es el wiget no es la causa.

Tampoco quiero pensar que el siguiente log tiene algo que ver:

02-17 03:04:54.785: I/ActivityManager(9546): No longer want ####.####.####.calendario (pid 10554): hidden #26

Donde hemos sustituido las partes sensibles con #, claro.

Buscando en Google encuentro esta página en la que aparece el código fuente de la clase ActivityManager de Android. 

12272 Slog.i(TAG, "No longer want " + app.processName
12273           + " (pid " + app.pid + "): hidden #" + numHidden);
12274 EventLog.writeEvent(EventLogTags.AM_KILL, app.pid,
12275           app.processName, app.setAdj, "too many background");
12276 app.killedBackground = true;
12277 Process.killProcessQuiet(app.pid);
 
Me tienta interpretarlo como "Estás haciendo demasiadas cosas. A tomar viento."

La cuestión es que el widget ha funcionado correctamente apenas una hora: una mierda de widget.

Y concluyo dándole mis felicitaciones a www.helloandroid.com por este estupendo tutorial que hará las delicias de los novatos y que, con seguridad, les animará a seguir adelante y sobretodo acudiendo a su web en busca de su valiosa información y experiencia profesional.

P.D.: Quien quiera tutoriales que funcionan e informacion veraz puede ir a la página web de este señor que no conozco pero felicito:  http://www.vogella.de

Curso de programación - Capítulo 1: Programando en alemán

La programación en "alemán" está muy extendida entre el gremio de artistas programadores.

Aquí tenemos un ejemplo:

WHILE SacCong(Bol) DO
  NumCong++
END

¿No se adivina qué hace el bucle? La mayoría de programadores son muy dados a este estilo de código, en lugar de este otro estilo para el mismo código:


WHILE SacarConguito(Bolsa) DO
  NumeroConguitos++
END

Gracias al lenguaje orientado a objetos y a los espacios de nombres gran parte del código es más inteligible por obligación, aunque para las variables hay quienes siguen utilizando NumPelTirFuer en lugar de NumeroPelotasTiradasFuera.

La excusa para utilizar ese "alemán" (con mis más serios respetos hacia este idioma) es que "si no se escribe mucho": vagos. Lástima que existe el copy/paste y los asistentes de programación.

La razón para utilizar el código claro es precisamente ésa: hacer código claro para que quien luego tenga que modificarlo no tenga que estar una semana meditando "¿¡Qué demonios hace esto!?"

En el próximo capítulo veremos cómo "optimizar" el código hasta hacer imposible una posterior modificación.