Traducción del Inglés al Español de un artículo escrito por Justin Searls, programador interesado en la productividad, que reflexiona aquí acerca de cómo sacarle el máximo partido al hardware y software de Apple y en concreto a su iPad Pro de 10,5″. Descubre todas las funciones y configuraciones que usa para ser súper eficiente en su trabajo y mejorar su productividad.
Traducción realizada por Jose, experto en traducción de páginas web.
Texto original de Justin Searls, publicado en Medium
* * *
Los programadores suelen describir sus herramientas ideales con adjetivos como «potente», «con muchas funciones» y «súper configurable». No se considera que los usuarios quieran algo más de sus ordenadores que los propios programadores.
Esta noción popular coincide con la creencia que una mayor capacidad produce intrínsecamente una mayor productividad. Sin embargo, mi experiencia sugiere que, aunque la capacidad es un requisito previo para la productividad, ambas no comparten una correlación lineal. Una docena de formas de hacer lo mismo sólo da lugar a una parálisis por análisis que hace perder el tiempo. Las aplicaciones repletas de funciones para cubrir todas las necesidades imaginables irán desplazando poco a poco el uso principal de la herramienta. Cada opción de configuración adicional que ajusto es otra rama if-else en el sistema, que requiere que sus desarrolladores prueben más y cambien menos, ralentizando el ritmo de la innovación.
Como resultado, he llegado a una visión más acertada de la productividad: la de un tenue equilibrio entre la fricción y la concentración. La «fricción» es la vuelta de tuerca necesaria de mis herramientas para poder trabajar. La «concentración» es la inacción en las herramientas para fomentar el pensamiento claro. Cualquier trabajador del conocimiento debe equilibrar su propia acción creativa con una atención reflexiva, y cada interfaz de software cristaliza un intento de lograr ese equilibrio.
He tenido todos los modelos de iPhone menos uno, pero no estoy haciendo mucho para celebrar nuestro décimo aniversario. El iPhone cambió mi vida de innumerables maneras, pero su mayor efecto a largo plazo ha sido el embotamiento de mis facultades introspectivas y creativas. El aburrimiento me incomoda, así que soy un consumidor ávido de noticias. Me he organizado una colección de cajas de Skinner que me permiten refrescarme, lo que ha afectado seriamente a la forma en que mi cerebro regula la dopamina. En las raras ocasiones en las que consigo concentrarme, una notificación me roba inevitablemente minutos de atención con un simple cambio de contexto de diez segundos. Es difícil hablar de productividad de forma seria sin reconocer lo mucho que han cambiado nuestras herramientas y nuestros cerebros desde 2007.
Durante un tiempo, supuse que trabajar en un ordenador de sobremesa seguiría siendo un refugio para esta era de distracciones, pero entonces Apple fue y devolvió toda la diversión al Mac. Y aunque es posible prescindir de muchas de las cosas que hacen que el Mac sea menos productivo, no puedo negar que el problema de fondo es que mi experiencia de llevar un iPhone a todas partes me ha cambiado de forma profunda.
He aquí un ejemplo deprimente. Las características de las ventanas de los sistemas operativos de escritorio solían representar un aumento neto de la productividad: podía ver dos cosas a la vez, arrastrar entre ellas y hacer más cosas en menos tiempo. Pero esto dejó de ser así en algún momento de la era post-iPhone. He aquí por qué: la mera ausencia de cualquier ventana en la esquina de mi pantalla hará que mi cerebro piense que si escribo ⌘-Space «tw», podría tener Tweetbot llenar ese vacío en el lado izquierdo de mi escritorio / alma. Y cada vez, como si hubiera entrado en algún tipo de estado de fuga, habrán transcurrido 30 minutos sin que haya conseguido hacer absolutamente nada, dejando un lío de pestañas del navegador abiertas, y con el ritmo cardíaco elevado a causa de sentirme enemistado con un rando poco amable en Twitter.
Como mucha gente, he comprado aspiracionalmente varios iPads a lo largo de los años pensando que «quizá esta vez sea diferente». Y cada vez, se ha quedado corto para permitirme hacer un trabajo real. Este último intento, me complace informar que finalmente ha tenido éxito.
Llevo 4 semanas usando un iPad exclusivamente para trabajar (cambiando al iPad Pro de 10,5″ una vez que salió), y he conseguido hacer mucho más trabajo significativo -programación incluida- del que normalmente hago. Mi mayor preocupación es que mis Macs más caros están empezando a acumular polvo.
Este es un post largo, pero es porque no sólo estoy usando el iPad para resolver tareas profesionales, sino que también lo estoy usando para resolver tareas mentales. He descubierto que no hay forma de distinguir de forma útil nuestras herramientas de software de nuestros procesos de pensamiento: cada uno informa e influye en el otro. Así que, sí, es fácil para mí enumerar las herramientas que estoy utilizando y por qué son tan buenas (y prescindiremos de ellas en un momento). Pero también espero que, al reflexionar sobre mis motivaciones más generales, puedas cuestionar también algunas de tus propias ideas preconcebidas.
INDICE
Si estás leyendo esto, probablemente estés buscando un resumen de qué aplicaciones estoy usando para hacer qué y si está funcionando. He aquí un resumen rápido de cómo he estado trabajando en un iPad todo el día:
No, el iPad sigue sin ofrecer a los usuarios ninguna forma de interactuar con las partes de UNIX bajo el capó, y cualquier aplicación que intentara crear un shell de este tipo sería rechazada por Apple. El iPad Pro es más que capaz de ejecutar máquinas virtuales basadas en ARM, pero todavía no hay ningún software de virtualización disponible. Quizá sus 4 GB de RAM representen un techo demasiado bajo.
Así que, desde esa perspectiva, no, no se puede programar en un iPad.
Lo que puedes hacer es lo que la gente ha estado intentando durante varios años, que es conectarse a un dispositivo remoto utilizando una aplicación de terminal. Si bien podría ir a la nube completa y hacer girar un Linode o Droplet, tengo la suerte de tener un iMac siempre encendido en casa al que puedo conectarme de forma remota, tanto en mi LAN como (después de configurar el reenvío de puertos en mi router doméstico) a través de Internet. Y con los datos móviles ilimitados en todo el mundo, incluso en los aviones, esta limitación es cada vez menor.
En el pasado había tratado de lograr este flujo de trabajo con el Prompt de Panic, pero lo encontré inadecuado para el trabajo «real». En primer lugar, sólo soporta SSH, que no proporciona conexiones muy duraderas – tan pronto como iOS suspende la instancia de Prompt al fondo, su socket se cierra y SSH necesita ser reconectado. Además, Prompt no ofrece una manera de volver a vincular una tecla de escape de cualquiera de las diversas cajas de teclado de hardware MFi sin tecla de escape o clamshells; esto hizo que los editores de terminal como Vim imposible de usar.
Y entonces llegó Mosh. Mosh ha surgido como una alternativa competente a SSH para este tipo de cosas, y sus conexiones son mucho más duraderas. Se comunica a través de UDP y en la práctica demuestra una latencia increíblemente baja, también. Me estoy conectando a mi iMac con la terminal Blink, y funciona mejor que Prompt. Blink permite a los usuarios volver a enlazar el bloqueo de mayúsculas con el escape y ya no es un problema cuando iOS mata la aplicación en segundo plano.
Ejecutar un conjunto de pruebas unitarias de testdouble.js en una sesión tmux de larga duración a través de Blink sobre mosh
Blink no es perfecto, pero como Mosh se distribuye bajo la GPL, es de código abierto. A fin de cuentas, lo único que me importa es que pueda mantener una conexión, enviar las pulsaciones correctas, y luego salir de mi camino, y la combinación de Blink y mosh hacen precisamente eso.
Y eso es realmente todo lo que hay que saber sobre cómo estoy usando el iPad para trabajar todo el día. Es un matrimonio sorprendentemente complementario de la simplicidad enfocada de iOS combinada con la poderosa complejidad de la línea de comandos de Unix.
Bien, y ahora las partes más introspectivas, como se prometió anteriormente.
Reflexionando sobre esta experiencia, me di cuenta de que no me molesto en automatizar mucho en mi Mac, porque sé que puedo forzar la mayoría de las actividades sin encontrar demasiado dolor. Si puedo realizar una tarea en 5 segundos pulsando ⌘-C ⌘-Tab ⌘-L ⌘-V para copiar una URL y abrirla en mi navegador, la repetiré (aparentemente) con gusto docenas de veces al día durante 14 años sin pensar en parar y encontrar una forma de reducir aún más esa fricción.
Mi experiencia al intentar trabajar en el iPad ha sido muy diferente. Si estoy tratando de hacer algo ordinario (como abrir una URL), iOS tiende a ser incluso menos fricción que macOS out-of-the-box, que agradezco. Pero donde el trabajo en el iPad realmente brilla, irónicamente, es en lo terriblemente doloroso que es realizar acciones fuera de lo común.
Por ejemplo, digamos que necesito algo un poco inusual, como guardar sitios web como PDF en una carpeta específica y anotarlos en un archivo Markdown. Las docenas de toques que exige esta tarea introducen tanta fricción que me veo obligado a automatizarla. Rara vez se me ocurre automatizar algo en macOS, tanto porque AppleScript/Automator palidecen en comparación con Workflow, pero también porque la interfaz de macOS es lo suficientemente buena como para que ninguna instancia de esa acción justifique invertir el tiempo en automatizar todo el proceso.
He pasado mucho tiempo reflexionando sobre el porqué de esto. Independientemente de si este fenómeno es por diseño, ciertamente se ajusta a la ética de marketing de Apple de que la respuesta a todos los problemas es «más aplicaciones». Si estás tratando de hacer algo y las únicas opciones disponibles son de alta fricción, es como si iOS te gritara: «¡ve a buscar o crear una app que haga lo que quieres!»
El problema es que la naturaleza bloqueada y en caja de arena de los primeros siete años de lanzamientos de iOS dejó un mal sabor de boca a la mayoría de los desarrolladores. A pesar de todo el bombo que se le dio a las aplicaciones entre 2008 y 2013, mucho de lo que los usuarios avanzados necesitaban para ser productivos no era posible dentro de las limitaciones impuestas por el sistema operativo. En iOS, cuando alguna actividad no puede realizarse de forma elegante, Apple ha demostrado su preferencia por ignorarla por completo antes que arriesgarse a dejarla a medias. Esto ha servido a la mayoría de los usuarios mucho mejor de lo que lo hicieron los ordenadores de sobremesa tradicionales, pero excluyeron a las personas cuyas necesidades aún no podían satisfacerse con dichas limitaciones.
La voluntad de Apple de decir «no», incluso cuando aleja a los usuarios avanzados, no podría ser más diferente de la estrategia de Microsoft para Windows después de la era del iPhone, que -al menos desde que eliminaron el igualmente inútil, pero no por ello menos valiente, Windows RT- ha sido decir a los usuarios que pueden tener su pastel y comerlo también. Pero mi experiencia de pasar un mes tratando de amar la Surface Pro 4 me mostró que Windows ha terminado con innumerables puntos de fricción, ocupando una especie de valle misterioso entre los escritorios tradicionales y las interfaces de usuario modernas.
A día de hoy, la mayoría de los desarrolladores siguen creyendo que el iPad es un ordenador de juguete. Sigue prevaleciendo la idea de que el único tipo de gente que «trabaja» en un iPad es la gente de negocios que pasa sus días en el correo electrónico y las hojas de cálculo. Apple se pasó ocho años iterando sobre iOS antes de lanzar los puntos de extensión necesarios para realizar el tipo de acciones que demandan sus usuarios avanzados. Por cierto, se necesitaron nueve versiones principales para que se materializara la compatibilidad real con el teclado de hardware. Puede que el iPad sea una noticia antigua, pero su utilidad como ordenador sigue siendo un desarrollo reciente.
A partir de iOS 8, el número de puntos de extensión entre aplicaciones bien pensados y seguros en iOS ha creado una oportunidad en gran medida aún no aprovechada para la integración y la automatización personalizadas y que reducen la fricción. En caso de que no hayas llevado la cuenta, hay pocas cosas que no puedan lograrse con una combinación de Acciones, esquemas de URL personalizados, proveedores de documentos y (a partir de iOS 11) arrastrar y soltar.
Pensamos en estas funciones como ejemplos mundanos de cómo Apple se está poniendo al día en iOS, ya que «los ordenadores de verdad siempre las han tenido», pero las comparaciones son sólo superficiales. Por ejemplo, consideremos las extensiones de los navegadores de escritorio: el navegador ofrece a los desarrolladores algunos métodos de utilidad privilegiados, pero por lo demás, el trato es: «escribe el JavaScript que quieras y fastidia el DOM como quieras y, por favor, no raspes las contraseñas de la gente». Compara esto con el pensamiento que Apple debe haber puesto en especificar rigurosamente los contratos de datos y comportamiento entre las aplicaciones que se encuentran en las extensiones de acción.
Este esfuerzo fue fundamental, porque cuando las extensiones y las aplicaciones se ven obligadas a producir metadatos como las entradas y salidas que admiten, el sistema operativo puede influir posteriormente en la forma en que los usuarios interactúan con ellas de forma más inteligente. La razón por la que encuentro esto emocionante es porque las restricciones impuestas por cosas como los contratos de tipos de datos -que algunos razonablemente ven como onerosos- pueden facilitar la automatización creativa en otros lugares. Es análoga a una dicotomía familiar para las aplicaciones de macOS, en la que un desarrollador puede utilizar controles de interfaz de usuario nativos (que se benefician de una mayor integración en el sistema operativo, como VoiceOver y los atajos de teclado) o puede optar por construir con herramientas basadas en la web, como Electron, que son cajas negras relativamente sin restricciones pero -al menos desde la perspectiva del sistema operativo- impenetrables.
iOS 11 representa la culminación de años de trabajo preliminar esencial y un enfoque gradual para alcanzar la paridad funcional con el escritorio de una manera formal y completamente razonada. Y aunque a mí personalmente no me importa mucho el nuevo «dock» del iPad, espero sin duda que el entusiasmo que ha generado aumente las ventas y haga que los desarrolladores den una segunda mirada a la plataforma. Después de todo, sería una lástima que todos esos puntos de ampliación tan bien pensados se quedaran sin utilizar.
Aparte de la disminución de la productividad y el aumento de las distracciones, otra cosa ha cambiado en mí desde el lanzamiento del iPhone en 2007. Soy menos amable y paciente con los demás de lo que solía ser. En general, también soy más negativo y cínico. Tiendo a estar tan agotado al final de cada jornada laboral que me lleva un par de horas sólo para desentumecerme. No esperaba que el cambio de un Mac a un iPad fuera a suponer una notable mejora en esos frentes.
Pero parece que ha ayudado.
Este mes he sido más amable, más feliz y con menos estrés de lo que recuerdo en los últimos tiempos. Por supuesto, necesitaré más datos antes de poder premiar a un tonto ordenador con ese tipo de testamento. También resulta que el Test Double va muy bien últimamente, y todavía siento alivio por haber hecho la mejor presentación de mi vida profesional, así que quizá me esté subiendo a esa ola.
Sin embargo, no puedo evitar pensar que aquí hay algo más profundo. Está claro que Apple ha pasado años sentando las bases para que el iPad sea finalmente un sustituto competente de un sistema operativo de escritorio, incluso para un desarrollador como yo. Lo que no estaba claro hasta ahora era que el iPad podría saltar de repente más allá de lo «suficientemente bueno» y empezar a mejorar radicalmente la experiencia vital del trabajo en sí.
No está mal para un iPod Touch grande.
Esta es una traducción Inglés – Español de un artículo escrito originalmente en Inglés.
If you need it, please check our Spanish translation services.
Articulos relacionados
Traducción de un articulo sobre páginas web, código Html y accesibilidad. Cómo programar una web sin perder de vista la accesibilidad, cómo mejorar el uso de etiquetas web para ofrecer a los usuarios mayor facilidad para navegar e interactuar.
Traducción de un artículo e Risa Fujii sobre traduccion e internacionalizacion de sitios web y apps basadas en Rails: "The Basics of Rails I18n - Translate errors, models, and attributes". Cómo traducir mensajes de error, modelos, atributos, etc. Un articulo de Risa Fujii publicado en...
Traducción a Español de un artículo en Inglés de Ushmi Dave explicando cómo localizar / internacionalizar / traducir aplicaciones en Angular, usando RxWeb