User-site-installed python packages, and path modification

PEP 370 allows you to have user-local installs of packages. You're supposed to run pip --user install whatever.

If you want to do that by default, so any future "pip install" does install to the user-site, you can add a pip configuration file telling pip to do so. In MacOS, the file must be located at ~/Library/Application Support/pip/pip.conf, and contains
user = true
(BEWARE! If you use virtual environments, note that thanks to another instance of Python brain damage/unfinished business, as of Python 3.5.3 and pip 9 the --user argument causes problems with installs in virtual environments of both venv and virtualenv varieties... and looks like the problem comes rather from the argument, not from the functionality! A Quick&Dirty fix is to do something like export PIP_CONFIG_FILE=/dev/null inside the virtual environment. This could be automated with hooks in virtualenvwrapper, but it starts to feel like a pile-up of hacks...)

OK, so now you have user-local installs by default. But their commands are not in your PATH, so you need to set that too.

You could go the naïve way and just add something like
to your .profile. But, note: here we're hardwiring python 3.5 (or any other version). Is that what you want? Is the rest of your system so hardwired? Unless you specifically did so, the answer probably is: no, it isn't. So you might end up mixing Python installs/environments.


Installing Ubuntu 16.04's friends into an iBook G4 with a USB pendrive

I had an old iBook G4 that could be useful for an elderly person, to be able to do her banking and basic internet browsing without having to use an XP-vintage, molasses-slow, honeypot-aspiring PC.

There's a reasonably complete and up-to-date guide in https://ricanlinux.blogspot.com/2015/03/ubuntu-mate-on-my-ibook-g4.html. I had to change a couple of details; and there are a couple of practical considerations to be had.

(Note to self: "lightness" in Linux rather correlates to "barebones" [3], which correlates with "hardcore" (text configs, mailing list scouring, lots of googling). Next time I'll be trying a heavy-weight distro for this kind of thing; better slow-but-useable than less-slow-but-WTF.)


Grand Central Dispatch for Android?

(Sometimes after a couple of hours of research, the result is a dead-end or needs further digesting.
Still, such a result might itself still be worth remembering.
This is a Quick&Dirty report of one of those cases.)

GCD is an implementation of thread pools / queueing (+ event management (sockets, files), etc) by Apple for Mac OS X / iOS. It was open-sourced, and FreeBSD got an implementation. They are practically an abstraction and simplification over pthreads (+ events, etc), and the GCD implementation includes some kernel and compiler changes (workqueues and blocks, respectively). Implementation details at http://newosxbook.com/articles/GCD.html. It's well performing and seemingly can help simplifying a lot.

What if one wanted to use GCD in Android? Is there anything compatible enough and that could be used at the C level?

Cocinando con citrato sódico casero

Parece ser que un ingrediente típico para la "cocina molecular" de Ferrán Adriá y compañía es el citrato sódico, que se usa por ejemplo para esferificaciones, caviar de frutas y cosas así.

Pero también se usa para algo mucho más simple y usable en casa en el día a día: ¡queso fundido!, que queda genial para salsas, dips, incluso fondues.

¿Pero cuál es el problema? Fundir queso es fácil, ¿no? En realidad, no. Prueba a fundir un taco de 100 gramos de queso normal y verás que el resultado es casi para tirar a la basura: un charco de aceite por un lado, una especie de trapo gomoso por otro. Esto lo podemos salvar con citrato sódico.


GitFlow (and friends) with remotes: avoid the busywork

There are lots of places online where one can learn about GitFlow, but it's seemingly always discussed in a local way; the details, subtle or not, about using GitFlow when you are pushing and pulling your changes through the network are never mentioned.

Now, GitFlow is a bit long on the teeth, and some of the younger and simpler alternatives do take into consideration things as Pull (or Merge) Requests; lately some even want the original GitFlow to be considered harmful. But still, there's a common basic concept in GitFlow and the alternatives, which is local feature branches. How and when exactly to merge them back into a development branch is one of the big differences, but is rarely detailed.

The goal of this post is to gather some tips on how to keep developing in the local feature branch while staying involved on a lively repository; and how to make easier the final feature merging.