Buscar este blog

viernes, agosto 17, 2012

Libro: Bajo presión


Título: Bajo presión. Cómo educar a nuestros hijos en un mundo hiperexigente.

Autor: Carl Honoré

Editorial: RBA



El título es algo engañoso. Honoré no nos va a decir como educar a nuestros hijos, aunque si hacemos caso a lo que cuenta, esa era su intención al iniciar la escritura de este libro.  Lo que sí hace Honoré es buscar y descubrir formas de educar a los niños, analizar qué parece funcionar y qué no, o incluso qué puede ser dañino. Y ya es bastante.

Puede que para algunos padres o interesados en el tema, esta obra sea algo novedoso, pero me temo que a mi me pilla un poco tarde. Ya creo (porque hablar de “saber” me parece absurdo venga de quien venga cuando hablamos de educación) que la educación es algo tremendamente complejo, con muchos intereses cruzados y opuestos de las comunidades de padres, profesores, editores, políticos… Entiendo que extraer conclusiones es terriblemente difícil dado que la educación es algo que abarca décadas, y también entiendo que la estadística solo funciona con números grandes, nunca con individuos. Así que gran parte de lo interesante del libro, me pilla un tanto de vuelta. Aun así está bien para reafirmarse, para ver como cosas que crees, son respaldadas por alguien con datos y mejor defendidas de lo que podría hacer uno mismo. Y es agradable ver durante el periplo de Honoré, que hay muchas iniciativas en marcha en el mundo para mejorar la educación y reducir la locura en la que se han convertido muchas sociedades y sistemas educativos.

Lectura altamente indicada para padres, educadores y personas relacionadas o interesadas con la formación y la educación pública y privada.

A continuación, algunos extractos:

Marilee Jones, ex docente a cargo de las admisiones en el MIT, observó que el campus había perdido parte de su brillo creativo. Concluyó que el proceso de admisión estaba descartando a los inconformistas, a las personas del estilo de Bill Gates, los rebeldes que persiguen una idea por sí misma en vez de complacer a los padres o a los posibles jefes.

-o-

Tal vez lo más sorprendente sea que los exámenes no constituyen ninguna prioridad en Finlandia. Aparte de los exámenes finales al término del instituto, los niños finlandeses no se enfrentan a exámenes estándar. Los profesores los ponen pruebas en sus respectivas áreas, y las escuelas comprueban la evolución de los alumnos, pero la idea de empollar para las pruebas de acceso a la universidad es tan ajena a Finlandia como una ola de calor en invierno. Ello plantea una deliciosa ironía: el país que pone menos énfasis en la competencia y los exámenes, que  muestra un menor interés por las escuelas preparatorias y las clases particulares, es siempre el primero del mundo en los competitivos exámenes de PISA.

Según Domisch Rainer, experto en educación alemán que ha vivido casi treinta años en Finlandia, esta paradoja se debe a que el sistema finlandés antepone las necesidades de los niños a los ambiciosos deseos de padres y burócratas.

-o-

Logramos buenos resultados generales porque atendemos a todos los estudiantes – dice Kassinen. La clave es que los chicos de todas las capacidades estén juntos en la misma clase: al fin y al cabo, así es la sociedad.

Los informes de la OCDE lo confirman: en los países que evitan la división de alumnos según sus aptitudes, hay mejores estudiantes.

-o-

Los maestros de escuela fineses tienen una tendencia excesiva al método de instrucción tradicional de pizarra y lección. Es extraño, si tenemos en cuenta su afición a la tecnología, pero los finlandeses tampoco se han apresurado a informatizar sus aulas.

-o-

Tal vez la lección más amplia es que no hay una fórmula mágica para mantener a los niños controlados, ni hace falta que la haya. Sólo hay que pensarlo un momento: ¿hay algo más espeluznante que un niño que se comporte de modo impecable en todo momento? ¿O una familia que nunca se pelee? Rebelarse contra la autoridad forma parte del crecimiento –todos lo sabemos instintivamente- y el conflicto es un rasgo de la vida familiar. Tal vez no resulte agradable que los niños estén enfurruñados, den portazos o digan entre dientes “Te odio”, pero eso es parte del trato paterno filial.

-o-

Después de que los románticos entronizaran la idea de la inocencia infantil, el miedo a la corrupción no cesó de intensificarse. Los críticos advirtieron que leer cómics estimularía en exceso a los jóvenes y los llevaría a cometer crímenes y actos disolutos. Otros temían que el trabajo en las fábricas de la Revolución Industrial mancillaran moralmente a los niños, lo que motivó que algunos jefes contrataran a monjas o enfermeras para tranquilizarse la conciencia. Como todos los demás miedos sobre la infancia, el temor a la corrupción aumentó en el siglo XX, y se amplió hasta abarcarlo todo, desde la música rock a tiendas de regalos.

Esto nos muestra una de las paradojas más curiosas de la infancia moderna: hoy, al mismo tiempo que nos inquieta nuestra pérdida de inocencia, permitimos, incluso alentamos, que los niños se mojen cada vez más temprano los dedos en la piscina adulta. En parte se debe a nuestro deseo de acercarnos a los hijos, de fortalecer el estatus de “mejor amigo”. Al fin y al cabo, nada une más a dos personas que un pasatiempo compartido. Sólo hay que oír cómo deliran algunas madres sobre hacer limpiezas de cutis y pedicura a sus hijas de nueve años.

-o-

Claro está que el papel de los padres sólo es una parte de la ecuación. Más allá de la familia, debemos replantear las normas que gobiernan todo lo tocante a las vidas de los niños: escuela, publicidad, juguetes, deportes, tecnología, tráfico. Eso implica aceptar algunas verdades incómodas: que los coches deben ocupar menos espacio en nuestras calles, que gran parte del mejor aprendizaje no puede medirse, que los chismes electrónicos no pueden reemplazar algunas cosas, que la medicación debe ser el último recurso ante un comportamiento difícil, que nuestra adicción colectiva al consumo debe acabar.

martes, agosto 14, 2012

El abismo




Como desarrollador con unos cuantos proyectos a mis espaldas, he llegado a identificar como uno de los problemas más importantes a resolver lo que llamamos "gap" tecnológico del usuario. ¿Qué este gap tecnológico? Pues se trata de la falta de determinados conocimientos tecnológicos (del usuario o cliente), que imposibilitan la comprensión y uso de un sistema.

Esta tierra de nadie, esta zanja en el camino a la solución tecnológica, puede ser de distintos tamaños, yendo desde la simple ignorancia de un pequeño truco o utilidad como puede ser el usar el TeclaControl+F para buscar palabras en un documento, o el TeclaWindows+escribir para encontrar una aplicación en sistemas Windows 7/8, a algo mucho más profundo y peligroso como puede ser la total falta de conocimientos no ya en informática (que al fin y al cabo solo existe masivamente desde hace unos 50 años) sino la más completa ignorancia sobre qué es un automatismo, ordenador o máquina.

Con esto quiero decir que en casos leves es solución suficiente señalar al usuario dónde está un menú, o hacerle una demo de una funcionalidad nueva, pero en demasiadas ocasiones nos encontramos ante la ausencia del marco necesario para entender un carajo.

Este caso sería el del típico empleado que guarda toda su información en su ordenador local, y desconoce lo que es un fallo de hardware, una copia de seguridad, la naturaleza electromagnética de la información de su disco o RAM (volátil), las soluciones gratuitas de backup local y online, el valor de su información, etc…

Este tipo de usuarios puede ser un auténtico problema en entornos informatizados (cualquier oficina de más de 2 personas a día de hoy) por varias razones:

1.      Por un lado su falta de conocimientos hace que use mal las herramientas, en general infrautilizándolas y perdiendo un montón de tiempo al cabo de día por ello.

2.      Por otro lado, todo ese tiempo malgastando es tiempo que alguien tiene que pasar esperando o se transforma en trabajo extra para otros compañeros (por baja productividad o control de daños).

3.      La frustración que produce usar mal las herramientas lleva al usuario a estar descontento con las herramientas y eso genera una carga negativa a día a día que puede sumarse a otras cosas para generar un mal ambiente de trabajo.

4.      La lentitud y complejidad extra añadida al trabajo por un mal uso de la herramienta, suele  pasar factura a la concentración del trabajador, empeorando sus resultados.

5.      La imagen de la tecnología y los cambios, se ve empañada a ojos del usuario por todo lo anterior, generando una animadversión a la tecnología y el cambio. Algo que a la larga puede matar a una empresa o industria al completo.

Por si todo esto no fuera ya bastante malo, resulta que la llamada brecha digital solo se amplía con el tiempo y llega un punto en que se hace tan grande que tratar de superarla uno mismo cuesta mucho más de lo que podemos asumir, en particular en condiciones de estrés y negatividad como las que enumeraba antes. Y en cuanto a confiar en terceros…  reconozcámoslo: la mayoría de los cursos de formación tecnológica tienen mucho de estafa (ofertas de pocas horas concentradas, malos docentes, programas rígidos…) o un desastre por falta de tiempo (RRHH contratando basurilla y presionando para abaratar algo con que llenar el expediente).

Es por todo esto que el gap tecnológico, la brecha no tanto digital como tecnológica, es tan peligrosa: provoca problemas reales, reduce la productividad, aumenta con el tiempo, se contagia a su alrededor y no existe una solución definitiva para ella.

Así que ahora que sabemos qué es y cómo nos afecta, preguntareis “¿cómo arreglamos este gap, este abismo de conocimientos que está cargándose la viabilidad de mi empresa?” La respuesta es, en mi opinión, que no se puede resolver, solo podemos tratar de minimizar el problema. Y para minimizarlo, al margen de reconocerlo en nosotros (sí, todos lo tenemos, no se libra ni Dios) y en los demás, debemos tratar de atacarlo a la mínima oportunidad: si vemos que nuestros compañeros desconocen algo o realizan tareas que debería estar realizando una máquina, debemos acercarnos y ayudar con ello. Se requieren también paciencia, curiosidad y humildad para reconocer nuestra propia ignorancia y ocasional estupidez. Y se requiere una voluntad de equipo para tratarla entre todos en el día a día, a pesar del estrés, los roces y los humos de cada uno de nosotros. Pero sobre todo, creo que se requiere valor y asertividad para cuestionarlo todo (independientemente de la jerarquía) y disentir públicamente.

¿Difícil? Sí. ¿Incómodo y desagradable en muchos casos? Desde luego. Pero la alternativa dada la velocidad de los acontecimientos, es el fracaso a medio y largo plazo. Y si no, que se lo digan a la industria musical (barrida por iTunes y el P2P), la industria del cine (barrida por Megaupload y los torrents) o la industria editorial (barrida por Amazon y los ebooks) entre otras afectadas por no tener un marco de conocimientos adecuado sobre la tecnología y las herramientas.

Lecturas relacionadas MUY recomendables: Philip Zimbardo, Gerd Gigerenzer, Usuarios del siglo XXI, Robert J. Stenberg.

jueves, agosto 02, 2012

Ya.com y sus regalos

Durante unos cuantos años fui un cliente de Ya.com más o menos satisfecho. Pura suerte, ya ven. Pero con el paso del tiempo, las prácticas de telemarketing de dudosa ética y legalidad y los comportamientos irregulares de lo que pensaba era la línea, acabé pasándome a Jazztel.


El caso es que el teléfono fijo e inalámbrico que uso en casa, fue parte del kit de bienvenida que ofertaba Ya.com hace unos tres años, y el otro día le dio por cascar. La pantalla de cristal LCD dejó, de un día para otro, de mostrar información más allá de unas rayas que hacían poco usable el terminal. Como me gusta tratar de arreglar las cosas y me tomo tiempo y cuidado cuando puedo, me dio por destripar el aparato con la esperanza de poder repararlo, antes de tomar la decisión de comprar uno nuevo. Y en esa operación descubrí algo inquietante.


El terminal parece que sufrió algún fallo y fue reparado por algún herrero, a la luz del estado de los componentes. Una chapa levantada, posiblemente para soldar algo de circuitería, y vuelta a poner en su sitio con los dientes por lo menos. Tras la hazaña de herrero de taller clandestino, le debieron poner la pegatina de refurbished, y acabó en un lote de bienvenida de Ya.com. En mi casa. Y cascando.


Así que amigo lector, si tienes problemas en casa con tu ADSL de Ya.com, recuerda que es más que probable que el problema sea del material de mercadillo que te entregaron y que supusiste que sería barato, pero no barato además de defectuoso.


Ah, y comprueba los microfiltros. Me dicen que a veces esos cabrones fallan.


Por si alguien tiene curiosidad tecno-morbosa, adjunto las fotos del trabajo herreril del proveedor de Ya.com. Véase el machaque de la chapa de la pegatina verde:









PD: El teléfono se recuperó bien una vez desmontado el LCD, limpiado la zona, vuelto a colocar las conexiones en su sitio y aplicado presión a base de silicona.


PD2: Jazztel bien, gracias. Aunque parece que mi oscuro pasado con Vodafone (con quienes no volvería ni cobrando) les pone un poco nerviosos a la hora de dejarme contratar móviles. Peor para ellos. Yoigo va muy bien.





Educando con el ejemplo

A los niños hay que enseñarles a apreciar las cosas buenas de la vida. Cómo el Doctor Who.


miércoles, julio 18, 2012

Libro: Piano. La historia de un Steinway de gran cola


Titulo: Piano. La historia de un Steinway de gran cola.
Autor: James Barrow 
Editorial: Alba 




Qué pasada de libro.

Imagino que no todo el mundo lo verá así, pero para mi, leer esta obra está al nivel de catarsis tras años de clases de piano practicamente olvidadas (más por imposibilidad de practicar que por desgana). Ha supuesto volver a escuchar las obras de Beethoven, Bach, Tchaikovsky o Rachmaninov con un interés adicional y un conocimiento orgánico del instrumento en si y de su historia (sin ser más que aficionado, ojo). Y ha supuesto volver a avivar con mi interés de la niñez por dos fabricantes de instrumentos: Steinway y Stradivari.

Puede que a quien no haya estudiado piano, o a quien no le interesan la fabricación (diseño, avances técnicos…) de instrumentos (no solo los musicales) no le parezca una obra tan buena, pero desde luego, es una buena obra. De ello se encarga James Barrow (perfectamente traducido), que transpira calidad al narrar el relato, ejerciendo como dios manda el oficio de periodista.

Retrospectivamente, es posible que leer este tipo de obras (aun tengo pendiente la reseña del de violín) me hubiesen animado más y mejor en el aprendizaje de un instrumento, pero esa historia ya es agua pasada, y a día de hoy su lectura me anima a educar en lo musical y en lo científico/técnico a mi hija. Así que si eres un nuevo estudiante de música (no exclusivamente de piano), un viejo aficionado, un fan de la música clásica, un fabricante de herramientas (desarrolladores de software incluidos), o incluso un aspirante a empresario, deberías leer este libro.

El siglo de historia que narra, nos acerca, no solo a la fabricación de un instrumento de precisión moderno, sino a la historia de una empresa, la de los cambios tecnológicos y económicos acaecidos, y la relación del hombre, del especialista, con sus herramientas.

Como hay más y mejores críticas en lugares como Amazon http://www.amazon.com/Piano-Making-Steinway-Concert-Grand/dp/0805078789 , lo dejaré aquí, solo para recomendarlo encarecidamente y para poner las habituales citas interesantes.


La RCA comercializaba la marca de radios más vendida en la nación y Sarnoff comprendió lo que podían ofrecer: entretenimiento con solo girar un botón… No hacían falta ni clases ni talento y las radios eran más baratas que los pianos, que los Steinway en particular. [Tras haber sobrevivido al fonógrafo y al tocadiscos…] en 1933 dos terceras partes de los hogares estadounidenses tenían receptor de radio.
-o-
Incluso los clientes que querían comprar un piano de cola no querían modelos grandes. Las casa adosadas iban desapareciendo en Nueva York y, en su lugar, surgían edificios de apartamentos. Henry Z. Steinway nación en un piso del edificio que se erigió en el solar de la Cuarta Avenida que ocupaba la primera fábrica Steinway. Lo que mantuvo a Steinway & Sons cuando la gente tuvo que conformarse con viviendas más pequeñas que las casas adosadas de sus padres fue el modelo M, un piano de cola que empezó a fabricarse en 1912 y que medía un metro menos que los gran cola como el K0862 (el protagonista del libro, un modelo D).
-o-
El problema de los pianos es que son orgánicos y cambian constantemente. No tienen nada que ver con la fabricación de neveras y cosas así.
-o-
[Acerca del ajuste de cuerdas en el piano] Utiliza una herramienta que tiene una especie de gancho al final y tira con fuerza. “Algunos llevamos pinzas de médico, de las que usan para cortar hemorragias, que parecen unas tijeras largas”, dice. Se refiere a las pinzas de hemostasia; algunas tienen dientes en los filos y vienen muy bien para tirar de las cuerdas.

lunes, julio 02, 2012

Code as Design: Three Essays by Jack W. Reeves





Por alguna razón tengo en la recámara desde hace meses una versión alternativa del artículo sobre La programación como proceso de diseño. Y como creo que es bastante diferente del "original", además de que siempre es buena idea hablar sobre desarrollo de software, lo añado a continuación. 

:-)

Code as Design: Three Essays by Jack W. Reeves

Estos ensayos con casi veinte y diez años de antiguedad, siguen siendo una verdad como un templo y comenta cosas que la mayoría de las personas en el mundo del software, ignoran (y olvidamos) con consecuencias negativas a corto, medio y largo plazo.

El punto clave del ensayo es que desarrollar código, es un proceso de diseño, y es uno muy complicado.

Siempre se compara el desarrollo de software con otras ingenierías donde se diseña y construye algo físico. Pero es incorrecto. Si hacer aviones se pareciese a hacer software, entonces pulsando un botón, los planos y especificaciones de un Boeing 747 se convertirían en un avión real y en pleno vuelo en cuestión de segundos o minutos a coste cercano a cero. Si se tratase de hacer puentes, el F5 nos permitiría levantar un puente para comprobar cuanto peso aguanta con pilares de un material u otro en el mismo tiempo y al mismo coste.

La naturaleza de las ingenierías "normales" es construir algo en base a unas especificaciones. Algo caro de diseñar, pero muchisimo más caro de construir (tiempo, recursos, gente). En software la "build", es decir el producto final construido, es cuestión de un compilador y un par de minutos (o segundos). Lo realmente caro es el diseño, y el diseño (especificaciones, planos...) es el código. Construir en base al diseño es labor del compilador y al contrario que en todas las demás ingenierías, tiene un coste en tiempo y dinero cercano a cero.
Partiendo de esa premisa, es fácil de donde vienen ciertos problemas, como las especificaciones mutantes, el scope creep, etc.

A continuación dejo algunas citas interesantes.

Revelation number two: it is cheaper and simpler to just build the design and test it than to do anything else. We do not care how many builds we do—they cost next to nothing in terms of time, and the resources used can be completely reclaimed later if we discard the build. Note that testing is not just concerned with getting the current design correct, it is part of the process of refining the design. Hardware engineers of complex systems often build models (or at least they visually render their designs using computer graphics). This allows them to get a "feel" for the design that is not possible by just reviewing the design itself. Building such a model is both impossible and unnecessary with a software design. We just build the product itself. Even if formal software proofs were as automatic as a compiler, we would still do build/test cycles. Ergo, formal proofs have never been of much practical interest to the software industry.
-o-
The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design. Software may be cheap to build, but it is incredibly expensive to design. Software is so complex that there are plenty of different design aspects and their resulting design views. The problem is that all the different aspects interrelate (just like they do in hardware engineering).
-o-
[...] no other modern industry would tolerate a rework rate of over 100% in its manufacturing process. A construction worker who can not build it right the first time, most of the time, is soon out of a job. In software, even the smallest piece of code is likely to be revised or completely rewritten during testing and debugging. We accept this sort of refinement during a creative process like design, not as part of a manufacturing process. No one expects an engineer to create a perfect design the first time. Even if she does, it must still be put through the refinement process just to prove that it was perfect.
-o-
The software design is not complete until it has been coded and tested. Testing is a fundamental part of the design validation and refinement process. The high level structural design is not a complete software design; it is just a structural framework for the detailed design.
-o-
It would be nice if high level software design could be a more rigorous engineering process, but the real world of software systems is not rigorous. Software is too complex and it depends on too many other things. Maybe some hardware does not work quite the way the designers thought it did, or a library routine has an undocumented restriction. These are the kinds of problems that every software project encounters sooner or later. These are the kinds of problems discovered during testing (if we do a good job of testing), for the simple reason that there was no way to discover them earlier. When they are discovered, they force a change in the design. If we are lucky, the design changes are local. More often than not, the changes will ripple through some significant portion of the entire software design (Murphy's Law). When part of the effected design can not change for some reason, then the other parts of the design will have to be weakened to accommodate. This often results is what managers perceive as "hacking", but it is the reality of software development.
-o-
As just a small point, all programmers know that writing the software design documents after the code instead of before, produces much more accurate documents. The reason is now obvious. Only the final design, as reflected in code, is the only one refined during the build/test cycle. The probability of the initial design being unchanged during this cycle is inversely related to the number of modules and number of programmers on a project. It rapidly becomes indistinguishable from zero.
-o-
The generally accepted definition is that a “specification” states the what, which is followed by a design document that details the how. While there is a certain amount of flexibility allowed of the compiler in determining the how of object code, there is certainly no creativity involved. And that is where I draw the line. When the document is detailed enough, complete enough, and unambiguous enough that it can be interpreted mechanistically, whether by a computer or by an assembly line worker, then you have a design document. If it still requires creative human interpretation, then you don’t.
-o-
Back to software. We in the software industry also refine our designs, only we don't get to call it engineering. We call it "testing and debugging". This phase of the software lifecycle takes a long time. All too often it takes longer than planned. Unfortunately, it is often not enough and the final designs that we turn into deliverable software are still not as good as they should be. This seems like a fact of software life. Many people lament it and ask why we software developers do not "engineer" our designs better? Many explanations are offered, but never the one most obvious to me -- simple economics. Software is dirt cheap to build.
-o-
I suspect that most engineers in other disciplines haven't a clue about what percentage of their time is spent actually creating a design and what is spent on testing and debugging the result. Some industries are probably better than software. I am pretty sure that other industries are actually much worse. Consider what it must take to "design" a new airliner.
-o-
I get somewhat testy when people start making gratuitous comparisons between software design and other engineering disciplines. Major microprocessors have been shipped with bugs in their logic, bridges have collapsed, dams broken, airliners fallen out of the sky, and thousands of automobiles and other consumer products recalled - all within recentmemory and all the result of design errors.
-o-
The bottom line is that my design must be correct, or every piece of software built from it will be erroneous. Therefore I concentrate on doing it right, and it takes mental effort and skill, just like any other creative design activity.
-o-
Even the best of the traditional approaches continue to try to break software design into disjoint steps with separate notations and products, and then they continue to wonder why they have problems getting a final software product that is correct.
-o-
Same thing. Likewise, Warner-Orr diagrams, Booch diagrams, object diagrams, you name it. Each has its strengths, and a single fundamental weakness - it really isn't a software design. Ultimately, improvements in programming techniques are overwhelmingly more important to software development than anything else.

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.