Junio de 2015
Calendario de artículos de de 2015
| lu | ma | mi | ju | vi | sá | do |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
Emacs Lisp en casos prácticos (1): modificando un modo con ad-hook y advice-add
2015-06-30
GNU Emacs es un editor de textos potentísimo. Por debajo, es un intérprete de Emacs Lisp, un lenguaje de programación de la familia de Lisp. En esta serie de artículos vamos a mostrar algunas formas de adaptar Emacs a nuestras necesidades con algunos casos prácticos.
Hoy veremos dos formas de modificar una funcionalidad existente de Emacs sin cambiar su código fuente: add-hook y advice-function. La primera forma es la recomendable siempre que es posible: los programadores añaden puntos donde hacer modificaciones (hooking) y esperan que los usuarios los usen. La segunda forma es un último recurso que apenas está un paso antes de llegar a modificar el código fuente directamente: consiste en crear funciones nuevas para preprocesar o postprocesar el trabajo de cualquier función existente aunque el programador original no hubiera considerado tal opción, lo que puede tener impactos no anticipados y difíciles de trazar en otro código.
El ejemplo de hoy funciona en GNU Emacs 24. Hay versiones anteriores que proporcionan una característica similar a la discutida y modificada en el presente artículo, pero implementada de una forma diferente.
El problema
Emacs tiene una funcionalidad muy útil que consiste en ejecutar otras aplicaciones e interactuar con ellas a través de un búfer como los que se usan normalmente para editar texto y con todas las posibilidades avanzadas de edición que ofrece Emacs. Hay una función interactiva, list-processes, que sirve para mostrar una tabla con los subprocesos que están ejecutándose y que es útil para buscar un proceso concreto y saltar al búfer que tiene asociado. Lo que quizá puede echarse en falta es la opción de gestionar los procesos (pausarlos, reanudarlos, terminarlos, cambiarles la prioridad…). Hoy, para ilustrar dos formas distintas de modificar el comportamiento de una función de Emacs sin cambiar su código fuente, vamos a ofrecer una acción muy concreta: matar un proceso y eliminar el búfer que tiene asociado. Nuestro objetivo es emular el comportamiento de list-buffers (que sirve para mostrar los búferes abiertos):
- Si pulsamos C-k, k, C-d o d, marcamos el proceso seleccionado para su eliminación. A la izquierda del todo, en la entrada del proceso marcado, aparece la marca D.
- Si pulsamos u, desmarcamos el proceso seleccionado. A la izquierda del todo, en la entrada del proceso desmarcado, desaparece la marca D.
- Si pulsamos x, eliminamos los procesos (con sus búferes) que están marcados.
Plan de acción
Tenemos que hacer lo siguiente:
- Crear las combinaciones de teclas para realizar las operaciones de marcado, desmarcado y ejecución.
- Modificar las funciones que sirven para crear y mostrar la tabla de búferes con subprocesos para que aparezca la marca de eliminación.
- Crear una función para eliminar los procesos (con sus búferes) marcados.
Al invocar list-processes, se crea un búfer con el modo mayor process-menu-mode, que está derivado a su vez del modo mayor tabulated-list-mode. Si miramos el código fuente de process-menu-mode y sus funciones auxiliares (una gran característica de GNU Emacs es que permite mirar rápidamente el código fuente de cualquier función), vemos hay dos puntos donde podemos atacar. Uno de estos puntos es la activación del modo process-menu-mode (donde es conveniente crear las combinaciones de teclas y modificar el formato de la tabla de búferes) y el otro es la función que se encarga de actualizar el contenido de la tabla de búferes: list-processes--refresh (donde es conveniente añadir las marcas de borrado).
Funciones básicas
Vamos a crear las funciones que necesitamos para marcar, desmarcar y eliminar. La primera, la de marcar, lo único que tiene que hacer es cambiar el contenido de la primera columna de la tabla (que es la que reservamos para la marca) y poner la marca D. Esto lo hacemos con la función tabulated-list-set-col. Por comodidad, terminamos avanzando a la siguiente entrada con forward-line. La función queda como sigue:
(defun process-menu-mark-for-deletion ()
"Mark the process on this Process List buffer line for deletion."
(interactive)
(tabulated-list-set-col 0 "D" t)
(forward-line))
El desmarcado es igual, pero en vez de poner la marca D, dejamos la casilla vacía:
(defun process-menu-unmark (&optional backup)
"Unmark the process on this Process List buffer line."
(interactive "P")
(tabulated-list-set-col 0 "" t)
(forward-line))
Finalmente, hemos de crear la función que borra los procesos (y sus búferes) marcados para ser borrados. Para ello, tenemos que recorrer el contenido de la lista de procesos (la variable tabulated-list-entries). Cada elemento de esta lista es a su vez otra lista con el siguiente contenido:
- el proceso;
- un vector con los campos mostrados en pantalla (de los que el primero es la marca de borrado).
De cada entrada, nos interesan el proceso y la marca de borrado. Si la marca de borrado está activa (es una D), eliminamos tanto el proceso (con delete-process) como el búfer (con kill-buffer sobre el búfer obtenido mediante process-buffer). La función es así:
(defun process-menu-execute ()
"Delete the processes marked for deletion."
(interactive)
(dolist (entry tabulated-list-entries)
(let ((process (elt entry 0))
(mark (elt (elt entry 1) 0)))
(if (string-equal "D" mark)
(delete-process process)
(kill-buffer (process-buffer process)))))
(revert-buffer))
Modificando process-menu-mode con una función hook
Los modos mayores ofrecen la opción de añadir funciones hook que se ejecutan al entrar en ellos. Se trata de una forma muy sencilla de adaptar la funcionalidad de un modo a nuestras necesidades. Nuestra función hook crea combinaciones de teclas (con local-set-key) y añade una columna (reservada para la marca de borrado) al principio del formato de la tabla (la variable tabulated-list-format):
(defun process-menu-mode--enable-process-management ()
(local-set-key (kbd "\C-k") 'process-menu-mark-for-deletion)
(local-set-key (kbd "k") 'process-menu-mark-for-deletion)
(local-set-key (kbd "\C-d") 'process-menu-mark-for-deletion)
(local-set-key (kbd "d") 'process-menu-mark-for-deletion)
(local-set-key (kbd "u") 'process-menu-unmark)
(local-set-key (kbd "x") 'process-menu-execute)
(setq tabulated-list-format
(vconcat [("" 1 nil)] tabulated-list-format)))
Colgamos la función hook con add-hook sobre process-menu-mode-hook:
(add-hook 'process-menu-mode-hook
#'process-menu-mode--enable-process-management)
Modificando list-processes--refresh con una función advice
Otra forma de modificar la funcionalidad de una función existente es con funciones advice. No es el mecanismo más limpio y puede tener consecuencias indeseadas, ya que el código sobre el que se trabaja no tiene por qué haber sido pensado para que el usuario modificara su semántica al vuelo. A pesar de ello, puede ser una opción razonable a veces. Para ilustrar cómo funciona, elegimos esta vía de acción para retocar list-processes--refresh y mostrar las marcas de borrado.
En primer lugar, definimos una función para modificar la tabla de procesos (que está en la variable tabulated-list-entries). Igual que nuestra función process-menu-execute, esta nueva función recorre los elementos de la lista, pero en vez de hacer comprobaciones, añade una celda en blanco (en la que podría haber marca de borrado) al principio de cada vector de celdas a mostrar:
(defun list-processes--add-mark-column ()
(dolist (entry tabulated-list-entries)
(setf (cadr entry) (vconcat [""] (cadr entry)))))
Con la función ya preparada, envolvemos list-processes--refresh con ayuda de advice-add. Podemos elegir cómo ejecutar nuestra función modificadora; esta vez queremos que se ejecute tras la función modificada, así que indicamos la opción :after. La documentación explica qué otras opciones hay. El código es así:
(advice-add 'list-processes--refresh
:after
#'list-processes--add-mark-column)
Todo el código junto
El código está disponible a través del siguiente enlace: process-menu-modifications.el
Categorías: Informática
Tuerca de recambio para el eje X del mini torno paralelo FD 150/E
2015-06-29
Debido a un accidente, la entrada de la rosca de la tuerca del eje X de mi mini torno paralelo (un Proxxon modelo FD 150/E) se deterioró de forma que era muy difícil enroscar el husillo tras retirarlo para hacer limpieza. Ante la posibilidad de que el problema fuera a peor hasta el punto de inutilizar el eje, fabriqué una sencilla tuerca de recambio en latón.
Dimensiones (en milímetros) de la tuerca.
La pieza era muy sencilla, pero las herramientas disponibles no eran las más prácticas. Al llegar el momento de taladrar el agujero que iría roscado, a falta de un taladro de columna en buenas condiciones, usé la herramienta disponible más apta para la labor: una mini fresadora vertical. Esta mini fresadora es tan pequeña que no agarra herramientas de más de 3,2 mm, pero el taladro para una rosca M6 es de 5 mm. Punteé la pieza, hice un taladro piloto pasante de 3 mm y, finalmente, usé un juego de brocas de tamaños crecientes con mango estrecho especial para mini taladros. Como la broca era para madera (con una punta a todas luces inadecuada) y la fresadora no estaba hecha para este trabajo, la operación de taladrado fue lenta, ruidosa y pringosa (por la gran cantidad de aceite que tuve que aplicar).
Broca para madera de mango estrecho. La fuerza de la necesidad
hizo que valiera para taladrar 12 mm de
latón.
La mini fresadora tras taladrar.
Una alternativa inteligente habría sido realizar un taladro piloto para después sujetar la pieza al plato de cuatro garras del torno y taladrar allí, ya que el portabrocas tiene capacidad suficiente para usar una broca de 5 mm más adecuada.
Alternativa: taladrado en el torno.
Tras terminar la pieza y limpiar bien, reemplacé la tuerca del eje X del torno. La nueva tuerca está funcionando a las mil maravillas.
La tuerca nueva (a la izquierda) junto a la tuerca vieja (a la
derecha).
La tuerca instalada.
Categorías: DIY
El último lanzador Falcon 9 ha explotado, pero no hay motivos para alarmarse por ahora
2015-06-28
El último lanzador SpaceX Falcon 9 1.1 (CRS-7, con carga para la Estación Espacial Internacional) explotó hoy, 28 de junio de 2015, unos 2 minutos tras el despegue. Llevaba el IDA-1 (International Docking Adapter o Adaptador Internacional de Acoplamiento), un dispositivo que iba a permitir utilizar el sistema de acoplamiento («docking» en inglés) de las futuras misiones estadounidenses, que tras la retirada del transbordador espacial hace 4 años, habían estado recurriendo a la técnica del berthing. Además de esto, la misión CRS-7 llevaba suministros y ciencia.
Evidentemente, la explosión supone una pérdida importante de tiempo y recursos, pero esto no es el fin del mundo. En primer lugar, hay seguros para cubrir las pérdidas económicas. Por su parte, las operaciones en la Estación Espacial Internacional, pasan del plan nominal a uno de contingencia (el slip plan), pero seguirá haciéndose ciencia y no hay falta de suministros.
¿Hay motivos para preocuparse por la seguridad del Falcon 9 1.1? Sí los hay, pues ha habido un fallo catastrófico, pero no habríamos de preocuparnos más que por otros lanzadores. El historial de fallos es comparable al de otros vehículos lanzadores de tamaños y capacidades diversas como el Ariane 5 y Soyuz-2.
Categorías: Actualidad, Aeroespacio
Herramienta para alinear piezas en el mini torno para madera
2015-06-24
Mi torno miniatura para madera es una fuente de alegría. De alegría y de ruido, pero sobre todo de lo primero.
Hace unas semanas presenté una herramienta para alinear piezas en un torno paralelo muy pequeño. Esta herramienta consiste en una rueda que hay que presionar contra una pieza desalineada hasta lograr que gire con su eje bien colocado. Un compañero de trabajo sugirió fabricar esa herramienta tras ver una similar en un vídeo. Hoy aproveché un disco de teflón descartado para hacer un artefacto del mismo tipo, pero para el torno miniatura para madera:
Herramienta de alineamiento.
El disco de teflón (la pieza de color blanco) está sujeto a un mango corto mediante un perno de acero cincado. El teflón gira alrededor del tornillo con muy poca fricción y permite empujar la pieza de trabajo sin calentarla ni arañarla. La herramienta es muy útil cuando hay que reposicionar una pieza en voladizo.
La herramienta en acción. Hay que presionar suavemente hasta que
la pieza gira con su eje correctamente alineado con el del torno.
Categorías: DIY
Permalink: https://sgcg.es/articulos/2015/06/24/herramienta-para-alinear-piezas-en-el-mini-torno-para-madera/
Sistema elemental de pruebas unitarias para el lenguaje de programación C (3)
2015-06-23
Presenté recientemente un sistema elemental de pruebas unitarias para el lenguaje de programación C. Este sistema cubre el caso más simple y común: define una macro que sirve para llamar a una función de prueba unitaria y seguidamente imprimir el resultado con un formato uniforme. Puede echarse en falta la capacidad de mostrar estadísticas, así que cubrimos dicha carencia ayer con un filtro externo en awk. La alternativa, por supuesto, consiste en añadir un poco de complejidad al propio sistema hecho en C. El sistema modificado de pruebas unitarias hace el siguiente trabajo:
- Manda a ejecutar cada prueba unitaria e imprime su resultado: si ha sido exitosa o si ha fallado.
- Imprime unas estadísticas: cuántas pruebas ha habido, cuántas han sido exitosas y cuántas han fallado.
- Define una variable que indica si el ensayo se considera exitoso (si no ha habido pruebas fallidas) o no (si ha habido pruebas fallidas).
Para hacer esto, hace falta declarar y poner a cero unas pocas variables; el sistema de pruebas unitarias tiene definida una macro (init_testsuite) que sirve para este fin. Habría que llamar a esta macro desde la misma función (probablemente main) que seguidamente irá invocando las diferentes pruebas unitarias (mediante la macro run_test), imprimirá el resumen final (mediante la macro print_testsuite_summary) y finalizará el programa devolviendo el código de estado del conjunto de pruebas (la variable testsuite_status). El código reside en el fichero de cabecera test.h y es como sigue:
#ifndef TEST_H
#define TEST_H
/*
* Simple unit testing system for the C programming language.
*
* Usage:
*
* 1) Call init_testsuite(). This creates the following automatic
* variables:
* - unsigned int pass_count: number of tests that passed;
* - unsigned int fail_count: number of tests that failed;
* - unsigned int test_count: number of tests run;
* - int testsuite_status: EXIT_SUCCESS if all tests passed,
* EXIT_FAILURE if any test failed.
*
* 2) For each test, call run_test with a void -> int test function
* that returns 1 if the test passes and 0 if the test fails; run_test
* will print "PASS: " or "FAIL: " and the name of the test function
* to the standard output.
*
* 3) Call print_testsuite_summary(project_name) (where project_name
* is a string) to print some statistics.
*/
#include <stdio.h>
#include <stdlib.h>
#define init_testsuite() unsigned int pass_count = 0; \
unsigned int fail_count = 0; \
unsigned int test_count = 0; \
int testsuite_status = EXIT_SUCCESS;
#define run_test(test) do \
{ \
if ((test)()) \
{ \
puts ("PASS: " #test); \
pass_count = pass_count + 1; \
} \
else \
{ \
puts ("FAIL: " #test); \
fail_count = fail_count + 1; \
testsuite_status = EXIT_FAILURE; \
} \
test_count = test_count + 1; \
} while (0)
#define print_testsuite_summary(project_name) \
printf ("============================================================================\n" \
"Testsuite summary for %s\n" \
"============================================================================\n" \
"# TOTAL: %u\n" \
"# PASS: %u\n" \
"# FAIL: %u\n" \
"============================================================================\n", \
(project_name), test_count, pass_count, fail_count);
#endif /* TEST_H */
Podemos poner a funcionar el código con el siguiente programa que define una prueba que sale bien y una prueba que sale mal:
#include <stdlib.h>
#include "test.h"
int
test_1_equals_1 (void)
{
return 1 == 1;
}
int
test_1_equals_2 (void)
{
return 1 == 2;
}
int
main (int argc, char* argv[])
{
init_testsuite ();
run_test (test_1_equals_1);
run_test (test_1_equals_2);
print_testsuite_summary ("example project");
return testsuite_status;
}
Tras compilarlo y ejecutarlo, obtenemos la siguiente salida:
PASS: test_1_equals_1 FAIL: test_1_equals_2 ============================================================================ Testsuite summary for example project ============================================================================ # TOTAL: 2 # PASS: 1 # FAIL: 1 ============================================================================
El código de error es 1 porque una de las pruebas ha fallado.
Categorías: Informática
Sistema elemental de pruebas unitarias para el lenguaje de programación C (2)
2015-06-21
En el último artículo vimos uno de los sistemas de pruebas unitarias más sencillos que puede haber para el lenguaje de programación C. Es una cosa minimalista que preparé para algunos proyectos pequeños. El sistema consiste simplemente en una macro que llama a una prueba unitaria (un procedimiento que devuelve si la prueba ha salido bien o mal) e imprime el resultado. Esto es suficiente a veces, pero en otras ocasiones se echa en falta alguna pequeña estadística. Podemos hacerlo bien con macros un poco más complicadas o procesando con una herramienta externa. Hoy vamos a ver la segunda opción.
El sistema de pruebas unitarias imprime una línea por prueba ejecutada. Las pruebas exitosas aparecen como PASS:, un espacio y el nombre de la prueba. Las pruebas fallidas aparecen como FAIL:, un espacio y el nombre de la prueba. Como el formato es tan sencillo, es trivial hacer un programa de filtrado que lleve la cuenta de qué pruebas han salido bien y qué pruebas han salido mal. El siguiente script de awk, que funciona en sistemas tipo *nix, hace este trabajo e imprime cuántas pruebas han salido bien y cuántas pruebas han salido mal:
BEGIN { count["PASS:"] = 0
count["FAIL:"] = 0 }
{ count[$1] += 1
print }
END { print "============================================================================"
print "Testsuite summary"
print "============================================================================"
print "# TOTAL: ", count["PASS:"] + count["FAIL:"]
print "# PASS: ", count["PASS:"]
print "# FAIL: ", count["FAIL:"]
print "============================================================================"
if (count["FAIL:"] == 0) exit 0
else exit 1 }
Este script está pensado para procesar la salida del programa de pruebas unitarias. Cada línea de dicha salida empieza bien por PASS:, bien por FAIL:. El script usa una matriz asociativa para llevar la cuenta de cuántas líneas empiezan por cada palabra. Cuando la salida del programa de pruebas unitarias se termina, el script imprime un resumen con el número total de pruebas, el número de pruebas exitosas y el número de pruebas fallidas. Además de esto, termina con un código de estado: 0 si no ha habido pruebas fallidas exitosas y 1 si ha habido alguna prueba fallida. Este código de estado es útil cuando el sistema de pruebas unitarias se usa con otras herramientas (por ejemplo, make).
Digamos que tenemos unas pruebas que generan la siguiente salida:
PASS: first_test PASS: second_test FAIL: third_test
Si filtramos esto con el script de awk, obtenemos el siguiente resultado:
PASS: first_test PASS: second_test FAIL: third_test ============================================================================ Testsuite summary ============================================================================ # TOTAL: 3 # PASS: 2 # FAIL: 1 ============================================================================
Categorías: Informática
Sistema elemental de pruebas unitarias para el lenguaje de programación C (1)
2015-06-18
Hace tiempo, preparé un sistema de pruebas unitarias para el lenguaje de programación C. Es una cosa sencillísima para proyectos también sencillísimos: consiste en una macro (run_test en el siguiente listado) que acepta como argumento el nombre de un procedimiento que define una prueba unitaria; la macro ejecuta dicha prueba llamando al procedimiento e imprime un mensaje en función del resultado (si la prueba ha sido exitosa o ha fallado). La macro va definida en un fichero (test.h) cuyo contenido es el siguiente:
#ifndef TEST_H
#define TEST_H
/*
* Simple unit testing system for the C programming language.
* Just call run_test with a void -> int test function that returns 1
* if the test passes and 0 if the test fails; run_test will print
* "PASS: " or "FAIL: " and the name of the test function to the
* standard output.
*/
#include <stdio.h>
#define run_test(test) do { \
if ((test)()) puts ("PASS: " #test); \
else puts ("FAIL: " #test); } while (0)
#endif /* TEST_H */
Quizá lo más llamativo es el
do { … } while (0),
que es un viejo truco para que una macro que expande a una
secuencia de instrucciones pueda invocarse con un punto y coma al
final, de manera que quede indistinguible de una llamada a función y
sea posible encadenar varias invocaciones en la misma línea sin más
que separarlas mediante el punto y coma.
Un programa en C que ejecutara pruebas unitarias con esta macro podría ser así:
#include <stdlib.h>
#include "test.h"
int
test_1_plus_1_equals_2 (void)
{
return 1 + 1 == 2;
}
int
test_1_plus_1_equals_3 (void)
{
return 1 + 1 == 3;
}
int
main (int argc, char* argv[])
{
run_test(test_1_plus_1_equals_2);
run_test(test_1_plus_1_equals_3);
return EXIT_SUCCESS;
}
Si compiláramos y ejecutáramos este programa, obtendríamos la siguiente salida:
PASS: test_1_plus_1_equals_2 FAIL: test_1_plus_1_equals_3
Categorías: Informática
La Comisión de Empleo de California dicta que una conductora de Uber era empleada de Uber
2015-06-17
Los resultados del test del pato (si parece un pato, nada como
un pato y grazna como un pato, entonces probablemente es un pato
)
aplicado por la Comisión de Empleo de California a una antigua
conductora de Uber son
inequívocos: esta
conductora habría de ser clasificada como empleada, no como
contratista autónoma. Uber, por supuesto, ha apelado.
Parece un pato
Por estos motivos se considera que la trabajadora era una falsa autónoma, realmente una empleada no reconocida de Uber:
- El trabajo de los conductores es la base del negocio de Uber.
- Uber consigue a los clientes y proporciona los conductores a estos clientes.
- Uber investiga a los aspirantes a conductor para decidir quién está autorizado a realizar ese trabajo igual que haría cualquier otro empleador al uso;
- Uber controla las herramientas de trabajo al establecer requisitos sobre los vehículos que pueden usar los conductores.
- Uber también controla las herramientas del trabajo al prestar a los conductores terminales de comunicaciones con su «propiedad intelectual», que es intransferible y obligatoria para realizar el trabajo.
- Uber prohibe efectivamente a sus supuestos proveedores trabajadores autónomos contratar a otras personas (esto lo hace no de forma directa, sino impidiendo la cesión de su «propiedad intelectual» necesaria para hacer el trabajo).
- Uber se reserva el derecho de denegar unilateralmente la condición de conductor (efectivamente, realiza despidos).
- Los conductores no realizan labores de gestión, sino que se limitan a conducir, mientras que Uber dirige las actividades.
Categorías: Actualidad, Derechos
Cuando la Estación Espacial Internacional tiene riesgo de colisión
2015-06-14
La Estación Espacial Internacional es un artefacto costoso que carga con varios tripulantes humanos y que se encuentra en un entorno hostil en el que una colisión con otro objeto puede ser fatal. La Estación está blindada y muchos impactos pueden ser insignificantes, pero otros pueden causar daños a sistemas o incluso provocar una depresurización. Hay varias medidas establecidas para garantizar la supervivencia de la tripulación en primer lugar y preservar la Estación en segundo lugar.
Medidas preventivas
Los medios técnicos actuales permiten localizar muchos objetos y propagar sus órbitas para evaluar el riesgo de colisión. Como hay incertidumbre en las medidas y en los modelos de las fuerzas que perturban el movimiento de estos objetos, no se sabe con certeza si un objeto va a colisionar, pero sí se conoce la probabilidad de impacto. Conforme se toman nuevas medidas y el tiempo hasta la conjunción se reduce, la incertidumbre se hace más pequeña y la probabilidad de impacto tiende bien a 1 (colisión segura), bien a 0 (colisión imposible). La prudencia impera y se plantea la opción de maniobrar cuando la probabilidad de impacto es inaceptable y hay tiempo suficiente para actuar. Una maniobra evasiva implica un cambio de órbita que puede dificultar las misiones de reabastecimiento próximas, así que es algo que se estudia detenidamente.
Por otra parte, hay muchos objetos que son técnicamente imposibles de seguir en la actualidad. Contra estos objetos, solamente queda confiar en que la estructura aguante. Por el momento, no ha habido más problemas que algunas marcas.
Cuando se aprecia un objeto peligroso y es demasiado tarde para emprender una maniobra evasiva, la tripulación se refugia en el vehículo Soyuz que siempre está acoplado a la Estación.
En caso de depresurización
Si se produce un impacto que provoca la depresurización de la cabina, hay varias alarmas que sirven para avisar si la presión desciende rápidamente y si la presión queda por debajo de cierto valor (que podría suceder con una fuga lenta que escapara a la primera alarma). La tripulación se refugia en el vehículo Soyuz que está acoplado a la Estación igual que sucedía en la situación descrita en el anterior párrafo. Si la Soyuz no tiene fugas y la depresurización es tan rápida que no hay alternativa a evacuar de inmediato, toca descender (es más fácil decirlo que hacerlo) y dejar atrás la Estación. En cambio, si la depresurización es lo bastante lenta, quizá es posible reparar la fuga o, al menos, aislar el módulo dañado; la actuación se decide tras discutir el asunto con Mission Control (Control de Misión).
Categorías: Aeroespacio
Útil para alinear rápidamente piezas en el torno paralelo
2015-06-08
La herramienta.
Estoy haciendo muchas piezas en torno paralelo en el trabajo. Uso un plato de tres garras y a menudo tardo un rato en dejar las piezas con el eje bien alineado. Un compañero me sugirió un método muy rápido y eficaz para alinear el eje de la pieza al eje del torno: con la pieza sujeta y el motor girando, basta con presionar un elemento deslizante (un rodamiento es una opción excelente) al contorno de la pieza que da vueltas. La pieza desalineada describe un cono al girar, pero al presionar el elemento deslizante, este cono puede abrirse cada vez menos, con lo que se logra alinear el eje de forma automática.
Preparé un útil para poner en práctica el concepto. El útil, que ha de ir sujeto a la torreta portaherramientas, consiste en una barrita con un rodamiento en su extremo. Mecanicé la barrita a partir de un sobrante de aluminio 6061. El rodamiento es uno minúsculo del tipo 682ZZ (un rodamiento de bolas cerrado que tiene un diámetro exterior de 5 mm, un agujero interior de 2 mm y un espesor de 2,3 mm). Para unir el rodamiento a la barra, usé un tornillo de tamaño M2 por 12 mm y un par de tuercas.
Dos vistas de la barra de aluminio. Las dimensiones están dadas
en milímetros.
El útil funciona de maravilla. Las piezas quedan con el eje prácticamente concéntrico con el del torno en cuestión de segundos. Tras retirar la presión, las piezas permanecen bien alineadas.
La herramienta en acción. El rodamiento impide que la pieza baile
hacia los lados, pero permite la rotación según el eje del torno.
Categorías: DIY
Permalink: https://sgcg.es/articulos/2015/06/08/util-para-alinear-rapidamente-piezas-en-el-torno-paralelo/
Historia de un botón
2015-06-06
El 1 de abril de 2015, con motivo del April's Fools Day (una festividad para bromistas), el popular agregador de noticias y foro Reddit anunció un curioso experimento: una cuenta atrás de 60 s y un botón (el Botón) que cualquier usuario registrado antes del día del experimento podría pulsar una vez y una sola vez (o una vez por cada cuenta de la que dispusiera) para reiniciar la cuenta atrás. La cuenta atrás comenzó 10 minutos después del anuncio.
El Botón venía acompañado de un foro en el que abundaban los chistes, la especulación sobre la auténtica naturaleza del experimento, el arte gráfico, las intrigas y los intentos de engañar a los novatos. También había intentos de adivinar el día en el que acabaría el experimento y que fallaban sistemáticamente.
Un tema de conversación chistoso habitual trataba sobre el Pressiah (el «Presías» o «Mesías Presionador»): la última persona en pulsar el Botón. De hecho, un chiste común consistía en tratar todo lo relacionado con el Botón como un asunto religioso.
En los mensajes dejados en el foro, cada cuenta figuraba con una marca coloreada (flair) que idenfiticaba su naturaleza:
- las cuentas que no podían pulsar el Botón por ser demasiado nuevas (can't pressers) aparecían con una marca blanca;
- las cuentas que podían pulsar el Botón pero no lo habían pulsado (non-pressers o greys) aparecían con una marca gris;
- las cuenta que habían pulsado el Botón (pressers) aparecían
con un color específico en función del tiempo restante en el contador
en el momento de la pulsación:
- morado (los purples) entre 60 s hasta justo por encima de 51 s,
- azul (los blues) entre 51 s hasta justo por encima de 41 s,
- verde (los greens) entre 41 s hasta justo por encima de 31 s,
- amarillo (los yellows) entre 31 s hasta justo por encima de 21 s,
- naranja (los oranges) entre 21 s hasta justo por encima de 11 s,
- rojo (los reds) de 11 s para abajo.
Algunos usuarios tenían varias cuentas que usaban para coleccionar marcas diferentes.
La comunidad se dividió en facciones según los colores de la marca o flair. Algunas facciones se basaban en referencias literarias (los autoestopistas azules que ostentaban marcas de 42 s) y a videojuegos (los amarillos: praise the Sun!). A menudo, había una falsa y humorística hostilidad entre personas de diferentes grupos. Una muy marcada estaba entre los no pulsadores y los pulsadores (greys versus filthy pressers): ¡si esos sucios pulsadores hubieran tenido autocontrol suficiente para aguantar un cortísimo minuto sin pulsar un botón compulsivamente, esto habría acabado muy pronto!
Al principio, con el experimento recién anunciado, hubo una
avalancha de pulsadores. Con muchas pulsaciones cada segundo, la
cuenta atrás se mantenía en lo más alto. Muchos pulsadores no leían
las instrucciones (solamente puedes pulsar una vez
) hasta que
era demasiado tarde. Con el paso de los días, la cosa se relajó y,
poco a poco, la marca más baja alcanzada (el color al que aspiraban
muchos «falsos grises» en ese momento) fue haciéndose más y más
próximo a 0 s. Los primeros rojos
llegaron con polémica, puesto que fueron obtenidos gracias a unos
problemas con los servidores. Estos problemas, de hecho, fueron algo
frecuentes: el contador llegó a 0 s y
fue reiniciado manualmente en varias ocasiones. No hubo más que
esperar algunos días, no obstante, para poder ver la primera oleada
de true reds
: rojos obtenidos de verdad, sin aprovechar
problemas de acceso a los servidores.
Con muchos usuarios simultáneos, era relativamente difícil alcanzar la marca deseada. Muchos «perecieron» (obtuvieron una vergonzosa marca morada) víctimas de la ambición al adelantáreseles alguien en el último momento a la hora de pulsar. Un gris diría les estaba bien empleado por ser sucios pulsadores.
Algunos usuarios crearon programas informáticos relacionados con el
Botón, bien para pintar representaciones gráficas y calcular
indicadores estadísticos, bien para automatizar el proceso de
pulsación del Botón. Uno de estos programas, muy popular, coordinaba
la pulsación para aumentar enormemente tanto la probabilidad de
obtener la marca deseada como el tiempo de vida del experimento. Esto
último lo lograba mediante la coordinación de muchas cuentas donadas
(zombies
) para pulsar el Botón automáticamente cuando la
cuenta se aproximara peligrosamente a su fin. Estas cuentas «zombi»
llegaron a ser suficientes para, en principio, prolongar el
funcionamiento del Botón durante muchas horas incluso si no hubiera
más participantes.
La cuenta atrás llegó a 0 y se detuvo el 5 de junio de 2015 a las 21:50:55 UTC. ¡El Botón había durado más de 2 meses y había acumulado más de un millón de (sucias, sucias) pulsaciones! El programa de pulsación automática mencionado antes activó una cuenta «zombi» que resultó ser can't-presser. El Pressiah fue un triste morado de 60 s.
Categorías: Actualidad, Informática
Permalink: https://sgcg.es/articulos/2015/06/06/historia-de-un-boton/
