Archivo para la categoría "Varios"
Opiniones firmes
Me encuentro ocasionalmente con ideas reveladoras. Las leo y noto como si un grupo de neuronas aletargadas se activasen de repente, haciéndome pensar en algo en lo que no había pensado antes.
La última la he leído en el artículo de Jeff Atwood “Strong Opinions, Weakly Held“, algo así como “Opiniones firmes, mantenidas débilmente”. El artículo es una defensa frente a otro artículo, “Blogging Horror“, que acusa a Jeff Atwood de haber perdido credibilidad emitiendo opiniones desinformadas sobre diversos temas relacionados con la programación. Esta discusión tiene una ramificación española, a través de una entrada en VELOCIDAD DE ESCAPE, que apareció en la portada de menéame y fue contestada por Ricardo Galli, entre otros.
El título del artículo de Atwood se refiere a una idea expresada en otro artículo del mismo nombre, cuya idea central se resume en este párrafo:
A couple years ago, I was talking the Institute’s Bob Johansen about wisdom, and he explained that — to deal with an uncertain future and still move forward – they advise people to have “strong opinions, which are weakly held.” They’ve been giving this advice for years, and I understand that it was first developed by Institute Director Paul Saffo. Bob explained that weak opinions are problematic because people aren’t inspired to develop the best arguments possible for them, or to put forth the energy required to test them. Bob explained that it was just as important, however, to not be too attached to what you believe because, otherwise, it undermines your ability to “see” and “hear” evidence that clashes with your opinions. This is what psychologists sometimes call the problem of “confirmation bias.”
que traducido por mí dice:
Hace un par de años, le estaba hablando a Bob Johansen [del Instituto de para el Futuro de Palo Alto] sobre la sabiduría, y él me explicó que – para tratar con la incertidumbre del futuro y aún así seguir avanzando – recomendaban a la gente que tuviese “opiniones firmes, que se mantuviesen de forma débil.” Llevaban dando este consejo durante años, y por lo que entiendo había sido inicialmente desarrollado por el director del Instituto Paul Saffo. Bob me explicó que las opiniones débiles eran problemáticas porque no inspiran a la gente a desarrollar las mejores ideas posibles para ellas. Bob me explicó que era igualmente importante, sin embargo, no sentirse demasiado ligado a tus ideas porque, de otra forma, socava tu habilidad para “ver” y “oír” las evidencias que choquen con tus opiniones. Es lo que los psicólogos llaman a veces el problema del “sesgo de confirmación.”
Cuando expreso una opinión en un ambiente formal (en el trabajo, en una discusión seria…), siempre intento hacerlo dejando claro que esa opinión se aplica a un ámbito concreto, que es posible que sea errónea en casos que no he contemplado y que por lo tanto admite matices y condicionantes, y que se basa en el conocimiento necesariamente limitado que tengo sobre el asunto en cuestión. Nunca se me había ocurrido que esa forma de actuar puede estar, a veces, equivocada.
No sé si cambiaré mi forma de opinar, pero me lo pensaré dos veces antes de llamar dogmático a quien exprese sus ideas con demasiada firmeza.
Estadísticas curiosas: fisgando móviles con BlueTooth
Aún no me he mirado el documento (que es un zip de 58 megas), pero por lo que veo en Mi N70 y yo contiene datos de dispositivos móviles recogidos por BlueTooth. Por ejemplo, esta gráfica que colgó el propio fernand0 en su cuenta de Picassa (y que me ha servido para darme cuenta de que el autor de Mi N70 y yo es el mismo de Reflexiones e irreflexiones, otro blog al que estoy subscrito), mostrando el número de dispositivos Nokia detectados por modelo:
Lógicamente, como toda muestra estadística, esta gráfica está condicionada por la forma en la que se recogieron los datos, así que la principal conclusión que podemos sacar (sin haber leído el documento) es que los usuarios del 6021 se dejan con mucha frecuencia el BlueTooth activado.
Tendencias en el tamaño de pantalla de los dispositivos móviles
Tras un par de semanas sin conexión por culpa de una mudanza, dos entradas de Morten Hjerde me dan la excusa para un pequeño apunte con el que volver al blog.
En Mobile screen size trends y More on mobile screen size trends hace un resumen de los tamaños de pantalla estándar en los dispositivos actuales y los tamaños propuestos por los fabricantes en sus dispositivos de última generación.
Resultan muy ilustrativos los gráficos que muestran el tamaños en píxeles y la proporción entre dimensiones por un lado, y el tamaño en pulgadas por el otro:
Conclusiones: se impone un modelo de pantalla adaptado a la visualización de vídeo, que resulta también adecuado para navegar por páginas no optimizadas para móviles. Así, el problema del diseño se desplaza al dispositivo de entrada: teclados virtuales frente a teclados físicos incrustados de alguna forma en el dispositivo; pantallas táctiles con interfaces de usuario adaptadas a las necesidades de la navegación móvil.
Veremos que soluciones proponen los dispositivos de gama alta que aparezcan en los próximos meses, como los primeros Android o las BlackBerry de la serie 9000.
¿Cuándo es antiguo un móvil?
Un lector del blog me ha escrito un correo a una de las cuentas de Ipoki y me ha hecho pensar en un par de cosas.
Primero, en que no tenía formulario de contacto. El plugin cformsII para WordPress se ha encargado de arreglarlo.
Segundo, en lo difícil que resulta decidir cuándo un móvil es “antiguo”. El correo hablaba de la dificultad de trabajar con números en punto flotante(1) en móviles con CLDC 1.0, ya que no hay soporte nativo. Estos móviles no tienen hardware dedicado a trabajar con punto flotante y las emulaciones por software son excesivamente lentas. El caso es que, pese a ser móviles antiguos (creo el último de Nokia con CLDC 1.0 es el 3230 y es del 2004), todavía existe un número importante de ellos en uso.
Así que la pregunta es: ¿cuándo compensa tener en cuenta estos móviles en el desarrollo? Mi respuesta: nunca. No debemos ser tímidos a la hora de descartar dispositivos por su antigüedad, ya que el número de potenciales usuarios perdidos disminuye con el tiempo, y a mucha velocidad. Preocuparnos de cómo hacer que algo funcione en un dispositivo de hace tres años consumirá recursos que estarán mejor empleados en una versión para el iPhone, o para S60 3rd Ed. FP2, o para Android. Si es posible que funcione en mi viejo N70 con algunos cambios menores, estupendo. Pero los dispositivos más recientes proporcionan formas cada vez más cómodas y eficaces de hacer las cosas, y generalmente no vale la pena tomarse el trabajo de pensar cómo hacer las mismas cosas para teléfonos de una generación anterior. Hablo por supuesto de desarrolladores amateurs, o de autónomos o pequeñas empresas. Las empresas grandes (o veteranas) tienen herramientas, recursos y metodologías para sacar el último juego Java para un montón de modelos distintos y rentabilizar el desarrollo. Pero no es mi caso, e imagino que tampoco el da la mayoría de lectores de este blog.
(1) Realmente en español lo correcto es “coma flotante”, pero no puedo evitar que me suene raro. Históricamente el punto es utilizado sobre todo en el mundo anglosajón, con la coma siendo la norma en Europa y Sudamérica, entre otros sitios. Imagino que la influencia de Internet acabará decantando la balanza a favor del punto.
Cómo mostrar imágenes de mapas en el móvil
En realidad esta entrada no se centra en cómo mostrar las imágenes, sino en cómo obtenerlas. Imaginemos que queremos programar una aplicación para móviles que se encargue de mostrar información geolocalizada. Existen abundantes APIs web que nos permiten mostrar todo tipo de información sobre un mapa, como las de Google, Yahoo o Microsoft, por citar sólo las tres más conocidas. El problema es que a estos servicios se accede usando JavaScript o Flash, ya que están pensados para visualizar la información en un navegador. Si no podemos renderizar esta información en nuestra aplicación, por ejemplo por falta de soporte javascript en el dispositivo, necesitamos buscar una alternativa que nos permita mostrar una imagen estática con la misma información.
Ingeniería inversa
Una práctica que se utiliza desde hace ya tiempo consiste en acudir a las mismas fuentes que el código Ajax o Flash, ya que al fin y al cabo los mapas que nos muestran los mash-ups habituales están compuestos por imágenes estáticas que se encuentran en algún sitio. Si por ejemplo abrimos la dirección http://code.google.com/apis/maps/documentation/examples/map-simple.html, que es el mapa de ejemplo de la documentación de Google, con Firefox y el plugin Firebug instalado o una herramienta similar, comprobamos que el mapa está compuesto de imágenes adyacentes, como si fuese un enlosado, cuyas direcciones tiene esta forma: http://mt2.google.com/mt?n=404&v=ap.69&hl=es&x=1315&y=3175&zoom=4&s=.
Los parámetros x e y nos muestran la posición de cada imagen en el enlosado, el zoom es autodescriptivo,… Con un poco de ingenio y paciencia es posible establecer una relación entre latitud y longitud y esos parámetros, o bien buscar en Internet a quien ya lo haya hecho.
Existen dos pegas a este procedimiento: la primera, que probablemente va contra los términos de uso de la API, así que si lo usamos en nuestras aplicaciones es posible que recibamos un aviso de Google, Yahoo! o Microsoft invitándonos a abandonar esta práctica. La segunda pega es la habitual al utilizar un procedimiento no documentado: en cualquier momento la especificación puede cambiar sin mantener ningún tipo de compatibilidad, inutilizando nuestro código.
Google Static Maps API
Una alternativa más segura es la nueva API de Google: la Static Maps API. Esta API es básicamente una URL que acepta varios parámetros, de la forma http://maps.google.com/staticmap?center=40.714728,-73.998672&zoom=14&size=512×512&maptype=mobile\ &markers=40.702147,-74.015794,blues%7C40.711614,-74.012318,greeng%7C40.718217,-73.998284,redc\ &key=MAPS_API_KEY.
Estos parámetros están bien documentados y permiten mostrar mapas indicando la posición, el zoom, la presencia de marcadores,…con la seguridad de que nadie nos va a cambiar los parámetros el mes que viene. La pega: las limitaciones en el número de peticiones a realizar. Cada usuario, y por lo que entiendo en la documentación el usuario es el dueño de la API key, puede hacer 1000 peticiones al día. Como nuestra API key irá en nuestra aplicación, todos nuestros usuarios contarán como el mismo para Google, con lo que esta API no es una solución práctica.
Yahoo! Map Image API
Yahoo! también tiene desde hace algún tiempo una API similar a la de Google: la Map Image API. Al igual que la anterior funciona componiendo una URL con parámetros: http://local.yahooapis.com/MapsService/V1/mapImage?appid=YahooDemo&street=701+First+Avenue&city=Sunnyvale&state=CA (en este caso lleva parámetros de búsqueda, pero también acepta latitud y longitud). Esta llamada no devuelve directamente una imagen, sino un xml que contiene, esta vez sí, la URL de la imagen solicitada:
<?xml version="1.0" encoding="UTF-8"?>
<Result xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
http://img.maps.yahoo.com/mapimage?MAPDATA=eJz6K.d6wXVM6myr2yRPfx6.kl.uMGgD3Tu4JtDQzr_33pFEsTT
SaosZ9OCtsiDrsLv9t65fzjz0CJm6JO2v_ZIHLflY9gto.xWMK9ovlRJVmrBLO4FoSsh3Ipsr
</Result>
La ventaja de la API de Yahoo! es que permite realizar 50000 peticiones por día y por IP, lo que la convierte en la alternativa más interesante de todas.
Predicciones de Deloitte sobre el mercado de las telecomunicaciones en el 2008
Un breve apunte para señalar este estudio que, aunque no es más que otra serie de previsiones, proviene de una de las consultoras más importantes del mercado.
Se puede descargar aquí: Telecommunications Predictions 2008
Redes de telefonía móvil: WiMAX
WiMAX (Worldwide Interoperability for Microwave Access) es una tecnología basada en el estándar IEEE 802.16 que está diseñada para proporcionar acceso inalámbrico de banda ancha a redes de área metropolitana. Dicho de manera más clara, WiMAX puede porporcionar el tipo de acceso que proporciona una red Wi-Fi, pero con la cobertura de una red telefónica celular.
Las redes Wi-Fi están habitualmente limitadas a un radio de acción de unos 100m, y la calidad de la señal disminuye notablemente con cualquier tabique que se interponga; en comparación, la especifiación WiMAX permite celdas de varios kilómetros de radio. Esta característica convierte a WiMAX en una tecnología idónea para, por ejemplo, unir entre sí nodos Wi-Fi o dar acceso inalámbrico de “última milla” (el tramo de conexión entre los hogares y las redes de cable o de telefonía) a los operadores de cable o ADSL.
Además de ser una tecnología de acceso inalábrico a redes, la última especificación (IEEE 802.16e-2005) ha añadido soporte para mobilidad: la posibilidad de transferir la conexión de un dispositivo WiMAX entre dos estaciones base. De hecho, como vimos en una entrada anterior, recientemente la Asamblea de Telecomunicaciones de la Unión Internacional de Telecomunicaciones incluyó la tecnología WiMAX en el marco de los estándares IMT-2000, con la denominación ‘MT-2000 OFDMA TDD WMAN’.
La única iniciativa comercial de acceso móvil a través de WiMAX que conozco es Xohm. Xohm es una iniciativa de Sprint Nextel (una de las operadoras móviles más imoprtantes de Estados Unidos) que entrará en funcionamiento en el 2008. Sin embargo es más que probable que haya más iniciativas similares en preparación. El futuro apagón analógico dejará libre una banda de frecuencia en el rango del UHF que puede ser aprovechada por WiMAX para ofrecer redes de muy largo alcance aunque menor ancho de banda. En USA ya se prepara la subasta de licencias en la banda de los 700MHz (en la que se rumorea que Google podría participar).
Entradas relacionadas:
Redes de telefonía móvil: 2G
Redes de telefonía móvil: 2.5G
Redes de telefonía móvil: 3G
Redes de telefonía móvil: 3G
3G: un número y una letra tras los que se oculta una maraña de acrónimos, términos técnicos, especificaciones, tecnologías, estándares… Es casi irónico pensar que todo partió de un intento inicial de establecer un sistema 3G global en la banda de los 2GHz. Este sistema único no prosperó debido a que las principales regiones del mundo ya habían asignado parte de ese espectro a otros usos, por lo que se decidió desarrollar varios estándares distintos diseñados bajo una pauta común. La Unión Internacional de Telecomunicaciones estableció el estándar global IMT-2000, que define seis interfaces de radio.
Una interfaz de radio es una especificación técnica del acceso a la red, que indica por ejemplo el ancho de banda de cada canal o la codificación de los datos. Así, aunque puede haber más de una tecnología que utilice una interfaz dada, se asegura un mínimo de interoperabilidad. A su vez, cada tecnología puede utilizar diferentes protocolos de transmisión de datos. Para desarrollar las tecnologías que usen estas interfaces se constituyó por parte de diversas asociaciones de telecomunicaciones la 3GPP, que basa sus especificaciones en evoluciones de GSM.
Interfaces
Veamos cuales son las interfaces definidas por IMT-2000:
- IMT-SC, Single Carrier
También conocido como EDGE, de la que ya hablamos en un artículo anterior.
- IMT-MC, Multi-Carrier
Otro nombre para esta interfaz es CDMA2000. También hablamos de esta tecnología en el anterior artículo, pero sólo para su variante más básica. Las variantes más avanzadas, EV-DO y EV-DV, son plenamente 3G y alcanzan los 3.1 Mbps (Megabits por segundo).
- IMT-DS, Direct-Sequence
Otros nombres para esta interfaz son W-CDMA o UTRA-FDD. Destacan dos tecnologías que utilizan esta interfaz: UMTS y FOMA. En un momento hablamos de la primera.
- IMT-TD, Time-Division
En realidad hay dos interfaces aquí: TD-CDMA y TD-SCDMA. TD-SCDMA es el estándar de referencia elegido en China. Hay que destacar que existe una versión de UMTS, llamada UMTS-TDD, que utiliza IMT-TD orientada a la conexión a Internet; esto es debido a que IMT-DS utiliza multiplexación por división de tiempo, mientras que IMT-TD utiliza multiplexación por división de frecuencia, más adecuada para la naturaleza asimétrica de las conexiones a Internet.
- IMT-FT, Frequency Time
Esta es la interfaz de DECT, el estándar europeo para teléfonos inalámbricos.
- IMT-OFDMA, TDD WMAN
WiMAX, la última incorporación a IMT-2000. De WiMAX hablaremos en otro artículo.
UMTS
El Universal Mobile Telecommunications System (Sistema Universal de Telecomunicaciones Móviles) es la tecnología 3G que ofrecen casi todos los operadores de telefonía en Europa (podemos ver una lista, no sé cómo de actualizada, en este artículo de la Wikipedia: List of UMTS networks). Utiliza la infraestructura de GSM y la interfaz W-CDMA, y soporta tasas de transferencia de hasta 14 Mbps. En la práctica, las redes comerciales disponibles no superan los 3.6 Mbps, y eso con terminales que soporten el protocolo HSDPA. Para terminales con 3G “clásica” (R99) la tasa desciende a 386 kbps. Debido a su mayor ancho de banda, a UMTS con HSDPA en ocasiones se le llama 3.5G.
En la actualidad los operadores de telefonía móvil cubren una buena parte del territorio europeo con tecnología HSDPA. Sin embargo, antes de contratar el servicio conviene cerciorarse de que el operador elegido da servicio 3G/HDSPA en la zona que nos interese, y hay que tener en cuenta que necesitaremos un terminal con soporte HDSPA para poder aprovechar este servicio.
Entradas relacionadas:
Redes de telefonía móvil: 2G
Redes de telefonía móvil: 2.5G
Redes de telefonía móvil: WiMAX
Redes de telefonía móvil: 2.5G
El término 2.5G se utiliza para referirse al conjunto de tecnologías que se encuentran a medio camino entre la 2G y la 3G. Lógicamente no es un término definido oficialmente en ningún sitio (ni siquiera creo que se le pueda dar mucho sentido al concepto de ‘media generación’ que implica), pero es útil para etiquetar algunos protocolos que se quedan un poco cortos para ser 3G.
En realidad, en la mayoría de las ocasiones 2.5G quiere decir GPRS. El General Packet Radio Service (algo así como Servicio General de Paquetes por Radio) es un servicio de las redes GSM que nos permite conectarnos a Internet con paquetes de datos (y no estableciendo un circuito, como veíamos en el artículo anterior), de forma que se nos pueda aplicar una tarifa por datos transferidos, y no según el tiempo de conexión. Las operadoras añaden a sus estaciones base dos nodos que se encargan de enrutar los paquetes de datos y conectarlos a Internet (ver por ejemplo el artículo IRM GPRS & 3G Security Overview, en inglés). La modificación es sencilla y poco costosa, por lo que todas las operadoras dan cobertura GPRS, pero este sistema obliga a que el tráfico de datos circule sobre la red GSM, y habitualmente con menor prioridad que la información de voz. De las distintas configuraciones GPRS que existen, la mejor de ellas nos proporciona 80 kbps (kilobits por segundo) de bajada y 60 kbps de subida. Además, debido a la baja prioridad de los paquetes de datos, puede existir un retardo (lag) muy considerable.
Otra tecnología que en ocasiones se denomina 2.5G es HSCSD (High-Speed Circuit-Switched Data). Es el sistema original con el que GSM transmitía datos, y utiliza la técnica de conmutación de circuitos. La máxima tasa de trasferencia que alcanza es de 57.6 kbps.
EDGE (Enhanced Data Rates for GSM Evolution) es una mejora sobre GPRS que se utiliza sobre todo en Estados Unidos. Aunque técnicamente es una tecnología 3G (como veremos en el siguiente artículo las tecnologías 3G se definen en los estándares de IMT-2000, y EDGE está entre ellos), su baja velocidad de trasferencia hace que se le catalogue como 2.5G (y como dice la Wikipedia, en ocasiones hasta como 2.75G). Su ancho de banda depende del tipo de implementación, pudiendo alcanzar los 236.8 kbps.
La última tecnología 2.5G que mecionaremos es CDMA2000. Al igual que EDGE, CDMA2000 es considerada una tecnología 3G. Sin embargo, su estándar principal, 1xRTT, que suele estar limitado a 144 kbps, y cuyo ancho de banda más frecuente es de unos 80 kbps, no se considera verdaderamente 3G. Esto permite que en algunos países se implante fuera de las frecuencias asignadas a la 3G.
Como vemos, estas tecnologías nos proporcionan anchos de banda típicos de las conexiones a Internet en la época del módem y el teléfono. Pero si se quiere ofrecer un terminal móvil como plataforma real de acceso a Internet debemos ofrecer anchos de banda que permitan navegación instantánea, streaming de vídeo y todos los servicios a los que estamos acostumbrados en nuestro ordenador de sobremesa.
Para eso se creó 3G. Y de eso hablaremos en el próximo artículo.
Artículos relacionados:
Redes de telefonía móvil: 2G
Redes de telefonía móvil: 3G
Redes de telefonía móvil: WiMAX
Interfaces de usuario en móviles: ¿nativas o personalizadas?
Una reflexión rápida provocada por el post Native or Custom UI? (¿Interfaz de usuario nativa o personalizada?) en el blog Mobile Phone Development. En él se comparan las interfaces de usuario de ProfiMail y de las versiones nativa y Java del cliente de GMail para móviles. Nokia tiene una extensa especificación sobre cómo las aplicaciones deben respetar la interfaz de usuario propia de S60, y Simon Judge, el autor del artículo, proporciona varios motivos por los que los autores de software pueden querer utilizar su propia interfaz de usuario.
Aunque las razones que da me parecen válidas, esta situación me recuerda hasta cierto punto lo que ocurría con la programación en Windows durante la segunda mitad de los 90. La API de Windows proporcionaba una interfaz de usuario que, aunque no especialmente bonita ni visualmente configurable, proporcionaba toda la funcionalidad que un programador podía razonablemente esperar. Muchas aplicaciones incorporaban su propia interfaz de usuario, generalmente por motivos estéticos (ya que habitualmente no presentaban mejoras de usabilidad), lo cual incrementaba el coste del desarrollo e introducía nuevas posibilidades incorporar bugs y problemas de seguridad en el producto. Hay un artículo de Joel Spolsky de hace unos años que habla de este asunto.
Aunque no creo que la situación con las interfaces de los móviles sea la misma, sí hay que tener en cuenta que mantener una interfaz de usuario consistente no es la única ventaja de seguir las recomendaciones de UI de cada plataforma. Según aumenta la potencia de los móviles también lo hace la complejidad de su software, por lo que hay que evaluar con mucho cuidado si lo que nos aporte la nueva UI nos va a compensar el esfuerzo.
