Aquí pongo las cosas que no dan para un post pero quiero conservar y compartir.

Este verano he estado trabajando dos semanas desde una furgoneta. La furgoneta no tenía batería auxiliar así que compré por alrededor de 400 euros esta batería con la intención de tener “independencia eléctrica”. Por ese precio puedes encontrar batería de más capacidad, inversor, componentes eléctricos, etc pero el tener que hacer el montaje y tener que dejarlo instalado lo hacían inviable en mi caso.

La batería que compré es de 500 Wh (45 Ah). La llevé cargada al 100% y solo la conecté a la toma de mechero de 12 V.

El internet no fue ningún problema ya que la cobertura era buena, 4G. Mi tarifa de datos es ilimitada. Usé el móvil compartiendo datos con el ordenador. Gasté alrededor de 59 gigas, casi seis por día.

La usé para cargar lo que necesitaba para trabajar, un MacBook Pro 2020 13’, unos Bose QC35 II y un iPhone 12. No hice ningún cálculo previo, no sabía si la batería duraría un día o diez. Tampoco sabía cuanto consumían mis dispositivos pero los empecé a usar con la batería de los mismos al 100%. Mientras la usaba hice los cálculos, tenían sentido con lo observado.

Cambié un poco mis hábitos de uso del portátil, cosas simples como evitar usar el motor de Chrome (Brave) o aplicaciones Electron (Slack). Desconectar el bluetooth cuando no lo usaba. Usar el mínimo brillo posible. Optimizar el video y el audio en las videollamadas. Apagar Docker y/o otras aplicaciones que consuman mientras no las esté usando. Nada especialmente molesto o que afecte a la productividad pero sí estar con un ojo puesto en el consumo. Evité también utilizar el ordenador mientras lo cargaba ya que gastaba muchísimo. Normalmente lo usaba toda la mañana, lo cargaba a la hora de comer y lo volvía a cargar por la noche. Si paraba durante el día también lo cargaba durante ese tiempo.

Siempre dejaba por la noche todos los dispositivos cargados para el día siguiente. De media para un día de trabajo necesitaba:

  • 2 cargas de batería del portátil. 58 Wh por carga, 2 * 58 = 116 Wh
  • 2 cargas de batería de móvil. 10.78 Wh por carga, 2 * 10.78 = 21.56 Wh
  • 0.33 cargas de batería de auriculares. 2.04 Wh por carga, 0.33 * 2.04 = 0.67 Wh

Total por día: 116 + 21.56 + 0.67 = 138.23 Wh

En teoría la batería debería de durar 500 / 138.21 = 3.61 días de trabajo. Mi experiencia es que sí, tres días de trabajo enteros dura, al cuarto ya empiezas a tener problemas. El consumo es algo superior porque los días de no-trabajo también cargaba el móvil.

Lo suyo sería tener una placa solar para tener la batería siempre a tope pero yo no tenía ni quería comprarla así que solo me quedaba cargar la batería con el motor del coche.

La batería tarda en cargar unas seis horas a 12 voltios. Necesitaríamos un poco más de una hora y media en conseguir los 138.23 Wh necesarios para trabajar un día entero. Si suponemos consumo de un litro por hora al ralentí es factible tener la batería siempre con suficiente batería para trabajar. Eso suponiendo que no muevas el vehículo, el tiempo en movimiento ya lo vas a gastar igual.

Mi experiencia fue que hice 8 trayectos de 20 minutos y 2 trayectos de 50 minutos en esas dos semanas. En total 170 minutos, unas 3 horas. Yo me moví anormalmente poco ya que estuve las dos semanas en el mismo sitio lo que me llevó a dejar el coche al ralentí durante 6 o 7 horas más en total. Lo que hacía era aprovechar y antes de tener que hacer un trayecto dejar el coche encendido un tiempo.

La experiencia con la batería fue positiva ya que sin demasiado esfuerzo pude estar 10 días trabajando sin necesitar enchufe. Pensé que quizá iba a necesitar hacer noche en algún hotel para poder cargar la batería pero no hizo falta. Fui totalmente independiente de la red eléctrica. Si lo vuelvo a hacer tanto tiempo, para ir despreocupado, usaría un panel solar (rígido o plegable). Para una semana solo, no hay problema.

Hace unos meses la empresa para la que trabajo presentó el S1. Este documento se rellena cuando quieres pasar de ser una empresa privada a una cotizada. Me surgió la duda de cuanto tiempo tardaba de media una empresa desde publicar el documento hasta que las acciones cotizasen en un mercado público (IPO). Después de una búsqueda en Google no me quedó claro ya que decían “de 3 a 6 meses” y haciendo una búsqueda de alguna IPO reciente no era tanto tiempo.

Me descargué de varias fuentes los datos necesarios para saber los tiempos de las 450 IPOs de 2021 para responder a la pregunta.

La media de días entre el S1 y la IPO es de 29.1 días.

El máximo de días entre el S1 y la IPO es de 178 días.

El mínimo de días entre el S1 y la IPO es de 16 días.

Finalmente la empresa tardó 23 días así que el orden de magnitud era correcto ya que casi todas las empresas salieron entre 15 días y 30 días.

Lectura:

El otro día quería saber cuantas palabras tenía un texto que estaba escribiendo. Usé wc -w pero luego pensé que estaría bien tenerlo en la barra de vim así que añadí esto al .vimrc:

au BufReadPost,BufNewFile *.md,*.txt set statusline=%f\ \|\ %{wordcount().words}\ words " overwrites the status line for custom text
au BufReadPost,BufNewFile *.md,*.txt set laststatus=2    " enables the statusline.

La primera línea sobrescribe la barra de estado por defecto poniéndole el nombre del archivo seguido del número de palabras. La segunda línea activa la barra de estado. au BufReadPost,BufNewFile *.md,*.txt hace que esto solo esté activo para archivos markdown o text.

Ejemplo: _posts/2021-06-01-vim-words.md | 124 words

Lectura:

Videos:

Misc:

Hace una semana di un “workshop” en la empresa donde trabajo sobre Redis. Fue poco más de una hora. Es muy básico, con un poco de conocimiento en bases de datos relacionales debería ser bastante sencillo tener una idea básica de Redis.

Lo subí para compartirlo con los asistentes. Si sabes un poco de Redis puede serte útil para dar tú el “workshop”.

Redis Training

Últimamente estoy haciendo escribiendo más Makefiles. Hay dos necesidades que cubre la implementación de GNU Make que me han resultado muy útiles.

La primera es escribir @ antes del comando, sirve para que el comando no salga en la salida. Me resultó útil para no mostrar datos sensibles. Sin @:

test:
    echo 1
$ make test
echo 1
1

Con @:

test:
    @echo 1
$ make test
1

La segunda es escribir - antes del comando, sirve para ejecutar diferentes comandos con independencia del resultado del anterior. Los comandos se ejecutan aunque falle alguno. Me resultó útil para poder hacer la limpieza de los containers de Docker que podían existir o no. Sin -:

test:
    not_existing_command
    echo 1
$ make test
not_existing_command
make: not_existing_command: No such file or directory
make: *** [test] Error 1

Con -:

test:
    -not_existing_command
    -echo 1
$ make test
not_existing_command
make: not_existing_command: No such file or directory
make: [test] Error 1 (ignored)
echo 1
1

Se pueden combinar:

test:
    @-not_existing_command
    @-echo 1
$ make test
make: not_existing_command: No such file or directory
make: [test] Error 1 (ignored)
1

Lectura:

Misc:

Lectura:

Videos:

Lectura:

Videos:

Misc:

Lectura:

Videos:

En desarrollo de software se utiliza el término “buenas prácticas” para denominar al conjunto de técnicas necesarias para llevar a cabo con éxito un proyecto de software.

He estado pensando en la naturaleza de las “buenas prácticas”. En una discusión técnica es un término que no aporta nada. Al igual que ocurre con los términos “importante”, “urgente” el añadir “buenas” delante de “prácticas” es altamente subjetivo. Por sí mismo no tiene ninguna validez, asignar a una “práctica” el atributo de “buena” no cambia la práctica.

Depende de la experiencia y el foco de cada desarrollador podrá pensar en una serie de “buenas prácticas” imprescindibles para el proyecto. ¿Pero el proyecto de software tendrá más éxito cuantas más “buenas prácticas” adoptemos? No. Adoptar “buenas prácticas” por adoptarlas no tiene sentido, muchas quizá no apliquen al contexto, otras no aportaran mejoras y otras tendrán aporte negativo.

Las prácticas tendrán -adaptadas para un proyecto particular- un aporte positivo o negativo. El aporte podrá ser compuesto o exponencial (asimétrico).

Lectura:

Videos:

Misc:

Mientras leía (bueno, leo) el SICP echaba un poco en falta programar algo en Scheme más allá de los ejercicios del libro. Me topé con este jardín digital donde el autor usa un formato de fechas diferente al gregoriano, se llama Arvelie. La idea de representar el tiempo en un formato alternativo me llamó la atención.

Hay un librería en C. Se me ocurrió hacer mi propia librería en Scheme. La empecé en verano, ayer la publiqué. Algunas reflexiones…

Tuve que meter tests. Me cuesta muchísimo trabajar en algo que lleve más de una hora o dos sin tests. Por ejemplo, para el blog tengo scripts:

$ tree | grep '\.rb'
│   ├── add_book.rb
│   ├── amazon_book.rb
│   └── generate_bookshelf.rb
│   ├── add_domains.rb
│   └── add_entry.rb

que no están testeados, pero son scripts cortos que no (me) merece la pena testear. En cambio al meter el segundo método del conversor empecé a echar en falta los tests. Si hubiese sido un lenguaje compilado quizá podría haber confiado en el compilador para evitar los errores de sintaxis. Al ser interpretado, en lugar de lanzar el REPL para ejecutar los mismos casos de usos, más fácil, cómodo y menos frustrante automatizarlo desde el principio.

Los errores de sintaxis Scheme son crípticos. Un error de sintaxis y a buscar donde falta el paréntesis. Mi entorno de desarrollo no está optimizado para Lisp supongo que si inviertes ahí, no te lo tiene que decir el intérprete.

Lisp es estético. No comparto (ahora) la idea de que tantos paréntesis lo hace feo. Visualmente me resulta muy homogéneo.

La notación polaca, bien.

Demasiadas conversiones de tipos. Tengo la sensación de que mi solución tiene demasiadas conversiones de tipos. Creo que se podría refactorizar para trabajar con listas desde el principio siendo así más sencillo.

La solución podría ser más sencilla. Hubo un momento en el que dejé de hacer la solución más sencilla y empecé a darme prisa por acabarlo. Creo que se podría hacer más sencillo, en especial las validaciones.

Encontrar información no es tan fácil. Comparado con otros lenguajes que buscas en google how to get first n elements of a list in XXXX y el primer resultado es consistente en Scheme no es tan sencillo. Desde soluciones que ya existen en la librería estándar hasta soluciones de otros sabores de Lisp (Chicken Scheme, Racket) o soluciones que ya existen en la librería estándar pero que reimplementan en la solución. Supongo que por la historia/naturaleza del lenguaje no puedes esperar el mismo nivel de información que en los populares.

Me ha gustado trabajar con listas pero al ser un problema general aplicando un lenguaje generalista no he podido ver mejoras de “productividad” en comparación con otros lenguajes que he usado.

Lectura:

Videos:

Misc:

Lectura:

Videos:

Misc:

El monkey patching trae problemas pero estaba mirando por curiosidad como hacerlo en Lisp. Un ejemplo, que el símbolo de sumar reste:

1 ]=> (define (+ . args-list)
  (apply - args-list))

;Value: +

1 ]=> (+ 1 1)

;Value: 0

Lectura:

Misc:

Structure and Interpretation of Computer Program es un libro “clásico” de la informática. La primera edición es de 1985. Se usaba para enseñar a programar en el MIT. Aunque algunos lo consideran obsoleto y favorecen otros libros como How to Design Programs.

Son 5 capítulos, he acabado el primero.

  • Me parece un libro terrible para aprender a programar si lo que se quiere es programar.
  • Las matemáticas necesarias no son de un gran alto nivel aunque sí se necesita una base mínima.
  • Si ya sabes programar (como es mi caso) pero no tienes una gran “madurez matemática” el reto de los ejercicios es la parte matemática y no la parte de programación.
  • Introduce conceptos generales de los lenguajes de programación que ya conocía pero verlos de forma aislada, con tiempo, y sin aplicación práctica es un ejercicio fabuloso.
  • Las dudas (y los ejercicios) están resueltas en Internet.
  • Lips y derivados (Scheme en este caso) son interesantes e intuitivos.
  • Está orientado a estudiantes de ingeniería tradicionales cuando quizá no había ni facultades de informática. Conocimientos fuertes en cálculo.

Hay una frase de Taleb que dice:

When you use a ruler to measure the table, you are also using the table to measure the ruler.

Me venía mucho a la cabeza por esa dualidad programación-matemáticas.

Mi motivación para empezar con este libro era aproximarme a la computación desde un punto de vista más cercano a la academia.

Lectura:

Videos:

Misc:

Lectura:

Videos:

Misc:

Últimamente me he estado interesando por los sistemas operativos ya que supone una oportunidad para usar lenguajes de “bajo nivel” (si aceptamos C como lenguaje de bajo nivel). Empecé un curso de Linux y me di cuenta que había muchas cosas que no sabía sobre el funcionamiento de los sistemas operativos. Descubrí Xv6. Es un sistema operativo mínimo que se puede virtualizar con QEMU. Es más sencillo que MINIX y de kernel monolítico. Tiene un manual donde explica en 100 páginas el funcionamiento del sistema. El código es C y es sencillo.

Aproveché también para pasar re-escribir algunas de las GNU core utils para xv6. Hay varios forks y proyectos con modificaciones/extensiones (GUI, en otras arquitecturas…) que resultan más sencillas de explorar que proyectos reales.

No estoy 100% seguro pero uno de los profesores detrás de Xv6 es Robert Morris que es el “precursor” de los virus con El gusano morris.

Con estas funciones:

    " Writer mode
    function! SpanishWriterMode()
      set spelllang=es
      set spell
    endfunction

    function! DisableSpanishWriterMode()
      set nospell
    endfunction

    noremap <leader>swm :call SpanishWriterMode()<CR>
    noremap <leader>dswm :call DisableSpanishWriterMode()<CR>

se hace más cómodo usar la ayuda para ver las faltas ortográficas al usar vim.

Con ,swm para activar o ,dswm para desactivar el corrector ortográfico.

Lista de enlaces sobre el contenido que me ha gustado/recomiendo/provoca-interés durante el mes. Hay partes que he consumido superficialmente, otras al completo y otras no pueden ser consumidas (Misc). He cogido la idea de la newsletter de Gwern.

Lectura:

Videos:

Misc: