Libro: Matar a un elefante

Titulo: Matar a un elefante

Author: George Orwell

Editorial: Turner

"Matar a un elefante" es una crónica de Orwell de cuando servía a Su Majestad en la India. Y es la crónica que muy acertadamente da nombre a este conjunto de artículos y crónicas del escritor aglutinadas en formato libro.

No se trata de un libro especialmente interesante, pero dada la variedad de textos y el intervalo temporal que abarcan, puede resultar suficientemente interesante para los admiradores de Orwell que quieran saber algo más de el como pensador de su época y no solo como escritor de ficción (si no has leído 1984 y Rebelión en la Granja, ya estás tardando).

A mi en particular me ha parecido bastante prescindible, a excepción del primer relato, el del elefante que tiene que sacrificar (o ejecutar, según se mire) bajo la opresiva mirada de los aldeanos y que da que pensar sobre la importancia del entorno y las circunstancias en los actos de cada uno, muy al estilo de Philip Zimbardo en El Efecto Lucifer. El resto de capítulos creo que me los podría haber ahorrado, aunque no está de más leer sus opiniones sobre la Segunda Guerra Mundial y la Guerra Civil Española (la del 34).

A continuación, algunos extractos de muestra:

[Sobre la Guerra Civil Española] Los fascistas ganaron la guerra porque eran más fuertes. Disponían de armamento moderno que el otro bando no poseía. No hay estrategia política que pueda paliar tal deficiencia.

-o-

Los llamados dominios de habla inglesa [...] son rehenes que están en manos de Norteamérica. Por lo tanto, siempre existe el poligro de que Estados Unidos rompa toda coalición europea, arrastrando a Gran Bretaña fuera de ella.

-o-

Los pueblos de Europa, y en especial los británicos, desde hace mucho deben su elevado nivel de vida a la explotación directa o indirecta de los pueblos de color, Esta es una relación que nunca se ha aclarado debidamente en la propaganda oficial del socialismo, y el trabajador británico, en vez de recibir el mensaje de que, según la media mundial, vive por encima de sus posibilidades, ha sido aleccionado para pensar que es un esclavo que trabana en exceso y que está pisoteado por el patrón. Para las masas, el "socialismo" significa o al menos se relaciona con salarios más altos, jornadas laborales más cortas, viviendas mejores, seguridad social para todos, etc. Ahora bien, de ninguna manera es seguro que sea posible financiar tales ventajas si se prescinde de los beneficios que acarrea la explotación colonial.

Lecciones aprendidas en 2011

Este es un recopilatorio de lecciones aprendidas por las malas en el 2011 que fui poniendo en Twitter desde Mayo con el hastag #LeccionesAprendidas

Las dejo aquí (la mayoría al menos) para poder localizarlas fácilmente, ya que Twitter no es la mejor manera de guardar información que quieras usar.

Ah y un aviso, deben ser leídas con la mente abierta. No se trata de quejas, chistes, o cabreos del momento, sino de ideas meditadas, experiencias que me han dado que pensar y que querría recordar en el futuro.

Si alguien quiere añadir alguna, estaré atento a los comentarios. :-)

#LeccionesAprendidas:

No se puede agradar a todo el mundo. Al final hay que toma elecciones y hacer lo que uno crea mejor.
Fri Jan 06 12:25:25 +0000 2012 

Si te envían un correo con más de una dirección en el "Para:", ignóralo. Es un intento de colocar un marrón.
Mon Oct 31 17:12:39 +0000 2011 

Nunca es fácil. Nunca.
11:31 AM Oct 18th from web 

Cuando necesites tener tiempo para ti, tómatelo, porque nadie más te lo va a dar.
9:26 PM Oct 9th from Twitter for Android 

Do less to achieve more and be happier. No excuses.
8:37 AM Oct 8th from web 

Si mezclas tónica Qtonic con ginebra Gin Mare, te cargas el #gintonic.
4:48 PM Aug 15th from web 

Cuando suficiente gente sigue instrucciones sin entender su sentido final o pervirtiéndolo, se crean problemas gordos.
4:01 PM Aug 8th from Twitter for Android 

El Excel puede ser tu mejor amigo a la hora de tratar datos de listas y bibliotecas.
11:30 AM Jul 12th from web 

Las personas están sobrevaloradas.
8:53 PM Jul 3rd from Twitter for Android 

Cuando trabajes con #Sharepoint, procura que todo lo que instales en una misma máquina, esté en el mismo idioma.
2:54 PM Jun 29th from web 

Cuando hay tiempo para pensar, y se usa para ello, todo va mucho mejor. #soluciones
5:22 AM Jun 16th from Twitter for Android 

Eat your own dog food. Pero realiza catas de la de los demás, de vez en cuando.
3:06 PM Jun 15th from web 

Sharepoint #onpremise#online es un sistema demasiado grande, complejo, y cambiante como para llevarla en solitario.
5:37 PM Jun 8th from Twitter for Android 

A nadie le gusta asumir la derrota. Pero la alternativa es el desastre total.
6:21 PM Jun 7th from Twitter for Android 

A veces, arrastrarse, culpar a un chivo expiatorio y decir que sí a todo, puede ser la única estrategia efectiva.
5:50 PM Jun 7th from Twitter for Android 

Nunca confíes en un comercial. Sin excepción.
5:43 PM Jun 6th from Twitter for Android 

Es mucho mejor conocer las preguntas correctas, que tener buenas respuestas.
6:06 AM Jun 6th from Twitter for Android 

No juzgues a personas u organizaciones por lo que dicen o consiguen. Observa atentamente lo que hacen.
1:32 PM Jun 3rd from Twitter for Android 

Normalmente la parte más complicada e importante de resolver un problema es entender cual es el problema.
9:00 AM Jun 3rd from web 

Si tienes que dejar tu máquina de trabajo funcionando tras la jornada, es evidente que ahí tienes un cuello de botella.
5:46 PM Jun 2nd from Twitter for Android 

En 1 proyecto informático, suele haber 2 problemas a resolver: el real y el percibido. Con soluciones incompatibles.
6:15 PM Jun 1th from Twitter for Android 

A menudo veo soluciones rechazadas por "malas", que acaban demostrando ser soluciones excelentes pero mal entendidas.
6:08 PM Jun 1th from Twitter for Android 

Hacer horas extra no compensa. Huir de ellas como de la peste o exigir enormes recompensas inmediatas si no queda otra.
12:22 PM Jun 1th from web 

Pasar por y recuperarte de, una experiencia horrible, cambia la manera en que se ven y juzgan las cosas.
5:47 PM May 31st from Twitter for Android 

Hay muy poca gente con vocación por su trabajo (algunos la pierden, otros nunca tuvieron). Y son los más valiosos.
5:26 AM May 31st from Twitter for Android 

La gente no cambia nunca, ni siquiera un poco. Solo cambian las circunstancias.
5:25 PM May 30th from web 

Las limitaciones pueden ser una ayuda... cuando el objetivo está perfectamente claro.
5:12 PM May 29th from web 

Los eufemismos siempre esconden problemas. Para resolver un problema (si ese es el objetivo) lo primero es eliminarlos.
6:40 PM May 28th from web 

Por muy bueno que sea, nadie se suma a un plan si no lo conoce o no le convence. Se necesita contar con evangelistas.
2:47 PM May 27th from Twitter for Android 

El trabajo en equipo requiere reglas y objetivos, claros y conocidos. Comunicacion y trasparencia al fin y al cabo.
2:36 PM May 27th from Twitter for Android 

El trabajo que Mr X no hace, lo acaba teniendo que hacer Mr Y. Donde Mr Y suele ser un servidor.
9:34 AM May 26th from web 

Escucha lo que la gente tenga que decir, pero dale mucha más importancia a lo que hacen.
5:49 AM May 25th from Twitter for Android 

Madurar supone no solo asumir responsabilidades, sino también decidir y actuar en base a ellas.
10:24 PM May 24th from Twitter for Android 

El desarrollo de Software es un proceso de diseño. Recalco "proceso".
5:29 AM May 24th from Twitter for Android 

Algunas personas no tienen alegría por vivir. Y lo único que puede hacerse al respecto es no ser arrastrados por ellos.
5:28 AM May 24th from Twitter for Android 

Decir no. Que no, coño.
5:54 PM May 23rd from Twitter for Android 

A menudo la gente solo tiene razones emocionales xa tomar decisiones. Mencionarles razones objetivas solo les cabreará.
6:21 AM May 20th from Twitter for Android 

La gente confunde "trabajo en equipo" con "asignar trabajo". Y confunde "equipo" con "individuos en una habitación".
6:15 AM May 20th from Twitter for Android 

Sin trabajo en equipo, el rango de problemas al que se puede uno enfrentar es tendente a 0.
6:14 AM May 20th from Twitter for Android 

No hay balas de plata. Nunca las hay. Y quien dice tenerla suele ser un tonto, o un iluminado camino del desastre.
8:56 PM May 15th from web 

Algunas personas prefieren los rumores y los prejuicios, a la información de 1a mano y los hechos comprobables.
6:32 PM May 11th from Twitter for Android 

Algunas personas piensan que el tiempo de los demás no vale nada.
6:28 PM May 11th from Twitter for Android 

La formación continua y mantenerse al día es importante y DEBE hacerse principalmente en horario laboral.
7:49 PM May 8th from web 

Multitud de pequeñas mejoras en las herramientas, entorno, técnicas y organización; producen grandes diferencias.
9:09 PM May 4th from Twitter for Android 

Olvidar lo aprendido es tan importante y necesario como haberlo aprendido en primer lugar.
7:12 PM May 4th from web 

Un trabajador feliz es MUCHO más productivo.
7:11 PM May 4th from web

La programación como proceso de diseño (Code as Design)

Hace unos meses que tengo pendiente comentar un poco los ensayos de Jack W. Reeves: Code as Design.

Se trata de unos textos realmente valiosos dada su relevancia a lo largo de dos décadas (el primero fue publicado inicialmente en 1992) y por la peculiaridad de que la idea fue revisada 13 años después. Pero además es decepcionante ver como aun hay muchos profesionales del sector que no tienen claro lo que comentaba Reeves ni nada remotamente parecido.

La idea central que plantea Reeves es simple en su formulación: el desarrollo de software es un proceso de diseño. Pero esa simpleza oculta multitud de ideas interesantes y de prejuicios dentro y fuera del sector que llevan a considerar al programador como un obrero más. Y así nos va.

Esa idea nos lleva a plantear la obligatoriedad de que los cambios de requisitos deberían ser caros. Y que los desarrolladores ni son albañiles, ni son intercambiables como les gusta pensar a las grandes consultoras. O que el presupuesto cerrado a la hora de entregar un software es una estupidez de base. Pero como es un ensayo corto y discutido a lo largo de 20 años, creo que será mejor que cada uno lo lea (es corto) y juzgue por sí mismo.

A continuación para tratar de animar a los mas perezosos a leerse los ensayos, pongo algunas citas interesantes:

The Unpredictability of Requirements
There's a refrain I've heard on every problem project I've run into. The developers come to me and say "the problem with this project is that the requirements are always changing". The thing I find surprising about this situation is that anyone is surprised by it. In building business software requirements changes are the norm, the question is what we do about it. 

One route is to treat changing requirements as the result of poor requirements engineering. The idea behind requirements engineering is to get a fully understood picture of the requirements before you begin building the software, get a customer sign-off to these requirements, and then set up procedures that limit requirements changes after the sign-off. 

One problem with this is that just trying to understand the options for requirements is tough. It's even tougher because the development organization usually doesn't provide cost information on the requirements. You end up being in the situation where you may have some desire for a sun roof on your car, but the salesman can't tell you if it adds $10 to the cost of the car, or $10,000. Without much idea of the cost, how can you figure out whether you want to pay for that sunroof? 

Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify. 

Software's intangible nature also cuts in. It's very difficult to see what value a software feature has until you use it for real. Only when you use an early version of some software do you really begin to understand what features are valuable and what parts are not. 

This leads to the ironic point that people expect that requirements should be changeable. After all software is supposed to be soft. So not just are requirements changeable, they ought to be changeable. It takes a lot of energy to get customers of software to fix requirements. It's even worse if they've ever dabbled in software development themselves, because then they "know" that software is easy to change. 

But even if you could settle all that and really could get an accurate and stable set of requirements you're probably still doomed. In today's economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading. 

Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.

En serio. Si no lo has leído, léelo ya.

Problemas desenfocados

Como desarrollador, en muchas ocasiones tengo la ocasión de observar lo que solo se me ocurre llamar "problema de enfoque". Cosas (a menudo soluciones propuestas al cliente) que vistas desde cierta perspectiva o distancia, parecen problemas, pero que en realidad no lo son, y que a menudo se deben a un fallo de comunicación (ya sea por parte del proveedor o del usuario, por falta de conocimientos, intereses ocultos, etc.).

En esas situaciones, cuando el usuario percibe algo como un error (que no lo es bajo ningún parámetro racional), corregir el error percibido puede ser inútil, costoso y/o contraproducente. Y en esos casos la acción encaminada a solucionar el error percibido debe aplicarse en primer lugar sobre la comunicación (lenguaje común, metáforas, demostraciones...) y sobre el usuario (formación, pruebas, laboratorios, extraerle mediante tortura los verdaderos motivos de la solución informática...).

En psicología, si no recuerdo mal, suele hablarse de este problema bajo los términos: "marco", "contexto", "error cognitivo", "conducta automática o irreflexiva" o "prejuicio". Y en el mundillo de las TIC hay un chiste relacionado con el tema: "no es un bug, es una feature". Sea como fuere, se trata de algo muy común, y que poco tiene que ver con la tecnología, aunque sí con la informática según la concepción de Dijkstra de "resolver los problemas de la gente [...] entender a la gente".

En el ámbito del software, suelo observar este problema en clientes que no entienden la tecnología, su área de negocio (más habitual en grandes empresas) o ambos (motivo de extinción para muchas empresas en el pasado). Y dependiendo de a quién le preguntes obtendrás apoyos diferentes en cuanto a si solucionar el problema real o solo dedicarse al percibido por el cliente (raro es que quieran una solución completa). La analogía médica sería que ante una enfermedad tuviésemos que elegir entre tratar de curar al paciente mediante un tratamiento incómodo que debemos explicarle y para el que necesitamos de su cooperación, o limitarnos darle un placebo que le haga sentir bien y mandarle a casa. Obviamente habrá casos graves y leves que podrán inclinar la balanza pero en general no me gusta en absoluto tirar de placebo.

Además puede pasar que el cliente sufra de pánico cuando observa el problema (el percibido) y se cierre en banda en cuanto a la solución, adoptando una mala solución técnica que aporte poco o nada a su negocio. Si a eso le sumamos un comercial centrado exclusivamente en vender (no en aportar una solución) que apoye al 110% la solución del cliente, ya tenemos un coctel explosivo ante el cual el consultor y/o desarrolladores pueden, o bien ceder para contentar temporalmente al cliente (que puede y suele acabar dándose cuenta de que necesita una solución mejor), o  bien tratar de hacerle notar el problema de enfoque a base de paciencia, mano izquierda, mucha formación y tiempo. Cada una de estas posturas tiene pros y contras, por lo que no hay balas de plata. Como en la analogía del médico y el placebo, en ocasiones lo mejor sería coger el dinero y hacer lo que el cliente pide (fácil pero en mi opinión bastante rastrero y cortoplacista), y en otras lo mejor es hacer lo que el cliente necesita y presentárselo (arriesgado según el tipo de cliente) para que lo pruebe antes de aceptar o denegar la solución (las veces que he tenido ocasión de hacerlo, ha funcionado y a permitido establecer una relación de confianza con el cliente).

Así que tenemos un problema que puede identificarse y abordarse, pero requiere habilidades no técnicas, o al menos no según una concepción conservadora del mundillo. Y como es un problema común y persistente, no es extraño que se hayan pensado y probado con éxito cosas como el desarrollo ágil, para abordarlo (al menos parcialmente, dado que ágil significa muchas cosas). Pero eso es otra historia.

Resumiendo: la informática es mucho más que programar o hacer productos excelentes, los desarrolladores no somos infalibles, los comerciales pueden ser un problema, y el cliente no siempre tiene razón, aunque a menudo haya que dársela. Nada nuevo bajo el sol, lo sé, pero espero que el recordatorio le sirva a alguien a parte de mi mismo.

Directivos psicópatas: Un problema ignorado. Una propuesta de solución.

Al hilo de las declaraciones del artículo del diario británico Independent (muy, muy recomendable), me gustaría retomar brevemente el tema de los psicópatas y los puestos de responsabilidad y decisión (AKA: directivos).

Que los psicópatas orgánicos (nacidos así) y funcionales (que se comportan como tal, que aprenden a serlo) están ahí es un hecho indiscutible, y con el tema de la crisis su presencia y acciones están quedando al descubierto en los casos más sangrantes. Es más, al parecer son sus acciones las que nos han traído hasta aquí, hasta los 5 millones de parados, los recortes y la bancarrota de cajas y comunidades autónomas.

No merece la pena entrar a enumerar los gravísimos problema que causa (no es una posibilidad sino un hecho muy real) tener a uno o varios psicópatas en un organigrama empresarial o social. Sin mirar la historia o los periódicos podemos imaginar una degradación de las relaciones, un maltrato del cliente, o incluso el amañado de cuentas y desfalcos con resultados catastróficos. Pero no pensemos que esto son ideas difusas, los psicópatas funcionales y orgánicos están ahí, están haciendo mucho daño y no deben ser tolerados.

Por eso, por tratar de controlarlos y mejorar nuestras empresas, sociedades y el mundo en general, me gustaría que el lector reflexionase sobre la necesidad de establecer controles de acceso a los puestos de responsabilidad para evitar que los psicópatas acaben en ellos.

Identificarlos es el primer paso tanto para curar a los psicópatas funcionales, como para vigilar estrechamente o marcar a los orgánicos que necesiten ser degradados, despedidos o medicados, dependiendo del caso. Y la identificación permitiría dos medidas clave: relevar a los existentes de sus puestos y evitar que nuevos psicópatas accedan a cualquier puesto de responsabilidad.

Las medidas a tomar serían mucho más baratas que la alternativa, y probablemente no son nada complejas de implementar tanto a nivel público como privado (tests, biométrica, EEG, anális de oxitocina...). Las entrevistas, las oposiciones y los mecanismos de promoción interna podrían implementar test para identificar a personas sin empatía ni conciencia y eso seguramente nos llevaría a conseguir empresas y sociedades sin Lehman Brothers, Emilios Botín, Esperanzas Aguirre* o Leires Pajín*. Es decir, que con un par de medidas sencillas (identificar y apartar) tendríamos una sociedad más justa, productiva y limpia. Y la tendríamos de golpe, sin tener que esperar décadas.

Además a día de hoy, con las notannuevas tecnologías, podríamos tener datos estadísticos de toda una vida para poder identificar de manera más fina a los futuros psicópatas o a las organizaciones que hacen psicópatas. Imaginemos que analizando datos históricos de los últimos 5 años, vemos que grupos de personas que son "normales" empiezan a hacerlo mal en sus test de empatía cuando empiezan a trabajar en una empresa en particular. Eso indicaría que la empresa debería ser inspeccionada, sancionada o marcada de alguna manera para que la gente pudiera evitarla. Y nos ahorraría unos cuantos psicópatas funcionales más en el mundo. Ah y como efecto colateral de reducir el impacto de los psicópatas quizá podríamos reducir crímenes de género, suicidios, depresiones y acosos laborales.

Por supuesto todo esto es ciencia ficción sin una legislación que le de forma y algunos organismos estatales de apoyo (Sanidad, Trabajo, Hacienda). Y dado que los legisladores (partídos políticos mayoritarios) parecen tener completamente comprometidas sus jerarquías con corruptos y psicópatas, mucho me temo que solo nos queda rezar para que alguna empresa privada no contaminada consiga una posición tipo Google/Microsoft que le permita instaurar estas medidas al margen de todo (como prueba de que funciona) y montar un lobby de presión al respecto.


*Nota: Si crees que Aguirre o Pajín no tienen signos de psicopatía o no deberían ser puestas a prueba, considera seriamente la posibilidad de estar bajo los efectos de un lavado de cerebro.

Imagen del post obtenida de la Wikimedia.

Libro: Rework

Titulo: Rework
Autor: Jason Fried y David Heinemeier Hansson
Editorial: 37Signals (supongo)

Hace un par de semanas terminé de leer uno de los libros de la gente de 37signals, Rework, que habla de su filosofía y experiencias en el desarrollo de software, la gestión de personas, el trato a los clientes, y en definitiva, todas las áreas no puramente técnicas sobre el negocio del software.

Se trata de un libro muy fácil de leer, con el que es difícil estar en desacuerdo (si no lo estás, me interesaría saber por qué, y si alguna vez has desarrollado un producto) y que a pesar de no ser exhaustivo, es una muy buena recopilación de consejos prácticos si quieres vivir con el software.

El estilo del libro recuerda al del Guy Kawasaki y es de los que van directo al grano, sin historietas ni adornos. Pura experiencia para el que la quiera o pueda aprovechar.

Como se trata de un libro muy variado, que está parcialmente online, e incluso traducido (aunque no parece muy buena traducción por lo poco que he visto de ella), y como ya hay medio millón de reviews en Internet, me abstendré de recopilar citas interesantes y me centraré en una que desgraciadamente sufro en mi puesto actual: considerar todo como urgente (ASAP:as soon as possible).

ASAP is poison Stop saying ASAP.
We get it. It's implied. Everyone wants things done as soon as they can be done. When you turn into one of these people who adds ASAP to the end of every request, you're saying everything is high priority. And when everything is high priority, nothing is. (Funny how everything is a top priority until you actually have to prioritize things.) ASAP is inflationary. It devalues any request that doesn't say ASAP. Before you know it, the only way to get anything done is by putting the ASAP sticker on it. Most things just don't warrant that kind of hysteria. If a task doesn't get done this very instant, nobody is going to die. Nobody's going to lose their job. It won't cost the company a ton of money. What it will do is create artificial stress, which leads to burnout and worse. So reserve your use of emergency language for true emergencies. The kind where there are direct, measurable consequences to inaction. For everything else, chill out.

Para terminar, solo comentar que es un libro indispensable si quieres hacer un buen trabajo con el mínimo de recursos, si trabajas en una PYME, en una startup, si planeas montar un producto o si te interesa conocer otras maneras de funcionar a parte de las que venden las megaconsultoras.

Funda Kensington para iPad 2

La verdad es que Kensington hace unas fundas estupendas. Esta en particular protege el aparato (el iPad 2 de la entrada anterior) completamente (pantalla, bordes y parte trasera) mediante estructuras rígidas y elegantes que no desmerecen en absoluto el diseño del aparato que protege. Pero lo hace dejando accesibles los botones, altavoz y conectores.

Es cierto que añade algo de peso extra, pero mejora el agarre del aparato y protegen el metal y plástico de arañazos, golpes y el sudor de las manos. Porque el sudor es algo que se tiende a olvidar pero he visto como este puede comerse el recubrimiento de metal de algunos objetos, así que ojo con usar solamente una tapa para este trasto que va a estar en nuestras manos durante periodos prolongados.

La tapa, aun siendo rígida, tiene un doblez que permite convertirla en soporte vertical u horizontal de modo que sea cómodo para ver vídeos y escribir en el teclado. Pero además tiene un imán que activa el apagado y encendido automático de la pantalla (configurable por software en el propio iOS) por lo que ya no necesitamos botones para usarlo en ruta y se asemeja más a un libro en cuanto a uso.

Por último solo comentar que me parece bastante barata en comparación con lo que hay por ahí, y la gente de Amazon España te la lleva a casa en un periquete.

afafLa verdad es que Kensington hace unas fundas estupendas. Esta en particular protege el aparato completamente (pantalla, bordes y parte trasera) mediante estructuras rígidas y elegantes que no desmerecen en absoluto el diseño del aparato que protegen. Pero lo hace dejando accesibles los botones, altavoz y conectores. 

Es cierto que añade algo de peso extra, pero mejora el agarre del aparato y protegen el metal y plastico de arañazos, golpes y el sudor de las manos. Porque el sudor es algo que se tiende a olvidar pero he visto como este puede comerse el recubrimiento de metal de algunos objetos, así que ojo con usar solamente una tapa para este trasto que va a estar en nuestras manos durante periodos prolongados. 

La tapa, aun siendo rígida, tiene un doblez que permite convertirla soporte vertical u horizontal de modo que sea cómodo para ver vídeos y escribir en el teclado. Pero además tiene un imán que activa el apagado y encendido automático de la pantalla por lo que ya no necesitamos botones para usarlo en ruta y se emeja más a un libro en cuanto a uso. 

Por último solo comentar que me parece bastante barata en comparación con lo que hay por ahí, y la gente de Amazon España te la lleva a casa en un periquete. 

Por último solo me queda recomendar las fundas de Kensington de este tipo para cualquier tablet. De hecho, hay una para el Samsung Galaxy Tab aun mejor que esta. 

 verdad es que Kensington hace unas fundas estupendas. Esta en particular protege el aparato completamente (pantalla, bordes y parte trasera) mediante estructuras rígidas y elegantes que no desmerecen en absoluto el diseño del aparato que protegen. Pero lo hace dejando accesibles los botones, altavoz y conectores. 

Es cierto que añade algo de peso extra, pero mejora el agarre del aparato y protegen el metal y plastico de arañazos, golpes y el sudor de las manos. Porque el sudor es algo que se tiende a olvidar pero he visto como este puede comerse el recubrimiento de metal de algunos objetos, así que ojo con usar solamente una tapa para este trasto que va a estar en nuestras manos durante periodos prolongados. 

La tapa, aun siendo rígida, tiene un doblez que permite convertirla soporte vertical u horizontal de modo que sea cómodo para ver vídeos y escribir en el teclado. Pero además tiene un imán que activa el apagado y encendido automático de la pantalla por lo que ya no necesitamos botones para usarlo en ruta y se emeja más a un libro en cuanto a uso. 

Por último solo comentar que me parece bastante barata en comparación con lo que hay por ahí, y la gente de Amazon España te la lleva a casa en un periquete. 

Por último solo me queda recomendar las fundas de Kensington de este tipo para cualquier tablet. De hecho, hay una para el Samsung Galaxy Tab aun mejor que esta.