This looks ominous. (But it wasn’t actually.)
This looks ominous. (But it wasn’t actually.)
My family was sick all last week, and I fell behind on a tight deadline at work. So in the last two days, I’ve been working like crazy to catch up. Almost done.
I got a debit card for my oldest child so I could move to direct deposit allowance. Dealing with cash gets old fast.
I’ve often wished there were counterparts to the “for Dummies” series labeled “for mathematicians.” Replace 500 pages of babble and sidebars with five pages of formulas and analysis.
I’m trying to figure out a few U.S. tax laws that apply to me for the first time this year.
My thermostat just showed me an advertisement. I’m not happy about this.
Here is a great article on OmniFocus, its current state, and useful tips by Gabe Weatherhead. Like Gabe, I recently started using OmniFocus 2 after some years away.
One of the main lessons that I have learned in the last three years in my job as a programmer is that if you only have to do a job once or twice, use brute force.
Today, I was setting up a Synology NAS. The instructions for getting started are extremely sparse, consisting mainly of “type in the IP address in a web browser and follow the instructions there.”
In the old days, I would have started typing IP addresses until I found one that worked. Today, I made a new directory called “ips” and ran
for i in $(seq 50); do
echo "curl 10.0.1.$i > $i"
done | parallel -j 25
Then, since I am (obviously) impatient, I ran wc -l * every few seconds to see
which files were not empty. I found it at 10.0.1.5.
Later I discovered find.synology.com, which is the official way to find your Synology.
I got an Apple Watch for my birthday. So far, the best part is easy access to my calendar while I’m at work.
I would like to write more regularly, so I’m experimenting with a shorter post format, what Manton Reece calls a microblog post. I spent some time today tweaking my Jekyll configuration to enable them on this site.
Workflow is an iOS app that lets you build a simple program by dragging blocks around, similar to Apple’s Automator app that ships with macOS. A recent update makes it possible to send a wider variety of HTTP requests, which allows you to interact with web APIs that aren’t otherwise supported.
Or, if you have a web server, write your own API.
Here is a workflow to take images from my phone and upload them to my server.
It makes one request per image.
It sets the custom header Grigg-Authentication to make sure that random people
aren’t uploading images.
It puts a file into the POST request with field name image.
The responses will be HTML image tags, which are collected and then
copied to the clipboard.
Flask is a Python web framework. It makes it very easy to map URLs to Python functions.
The first thing I wrote was a private decorator, that would check the
HTTP headers for my authentication key. It doesn’t have to be a decorator, but
that makes it easier to reuse in the future.
|
|
If you are not using a secure (HTTPS) connection, somebody could read your authentication key and pretend to be you. You can set this up directly with Flask, but since I’m already running nginx, I used that. (I will share the details in a future post.)
Next, there is some basic Flask setup. I changed the response MIME type to plain text and registered an error handler that will report any exceptions in the response, rather than logging an error where I won’t see it.
|
|
Then, there is the routing code. This function is called
every time someone visits /blog/upload-image,
as specified in the route decorator.
|
|
Finally, the actual work is done by the upload_image function.
I save the image into a dated directory with a random filename, then
run a bunch of git commands.
|
|
If you like time zones—who doesn’t?—you should check out Time Zone News. Once a month or so, I get gems like this in my news feed:
Haiti cancels daylight saving time with two days notice
The planned change to daylight saving time in Haiti at 2 am local time on 13 March 2016 has been cancelled.
Or this one:
Chile reintroduces DST
Chile’s Ministry of Energy announced today that Chile will be observing daylight saving time again. Chile Standard Time will be changed back to UTC -4 at 00:00 on 15 May, and DST will be observed from 00:00 on 14 August 2016, changing time in Chile to UTC -3.
Chile used to observe DST every year until a permanent UTC offset of -3 was introduced in 2015.
It is unclear whether the time change also applies to Easter Island.
I was looking to make more room on my phone’s home screen, and I realized that my use of App.net had dwindled more than enough to remove it. I never post any more, but there are a couple of people I would still like to follow that don’t cross post to Twitter.
App.net has RSS feeds for every user, but they include both posts and replies. I only want to see posts. So I brushed off my primitive XSLT skills.
I wrote an XSLT program to delete RSS items that begin with @. While I was at
it, I replaced each title with the user’s name, since the text of the post is
also available in the description tag.
Here is the transformation that would filter my posts, if I had any:
|
|
Now I can use xsltproc to filter the RSS. In order to fill in the username automatically, I wrapped the XSLT program in a shell script that also invokes curl.
|
|
While adding multithreading support to a Python script, I found myself thinking again about the difference between multithreading and multiprocessing in the context of Python.
For the uninitiated, Python multithreading uses threads to do parallel processing. This is the most common way to do parallel work in many programming languages. But CPython has the Global Interpreter Lock (GIL), which means that no two Python statements (bytecodes, strictly speaking) can execute at the same time. So this form of parallelization is only helpful if most of your threads are either not actively doing anything (for example, waiting for input), or doing something that happens outside the GIL (for example launching a subprocess or doing a numpy calculation). Using threads is very lightweight, for example, the threads share memory space.
Python multiprocessing, on the other hand, uses multiple system level processes, that is, it starts up multiple instances of the Python interpreter. This gets around the GIL limitation, but obviously has more overhead. In addition, communicating between processes is not as easy as reading and writing shared memory.
To illustrate the difference, I wrote two functions. The first is called idle
and simply sleeps for two seconds. The second is called busy and
computes a large sum. I ran each 15 times using 5 workers, once using threads
and once using processes. Then I used matplotlib to visualize the
results.
Here are the two idle graphs, which look essentially identical.
(Although if you look closely, you can see that the multiprocess version is
slightly slower.)
And here are the two busy graphs. The threads are clearly not helping
anything.
As is my custom these days, I did the computations in an iPython notebook.
I have a Python script that downloads OFX files from each of my banks and credit cards. For a long time, I have been intending to make the HTTP requests multithreaded, since it is terribly inefficient to wait for one response to arrive before sending the next request.
Here is the single-threaded code block I was working with.
|
|
Using the Python 2.7 standard library, I would probably use either the
threading module or multiprocessing.pool.ThreadPool.
In both cases, you can call a function in a separate thread but you cannot
access the return value. In my code, I would need to alter Download
to take a second parameter and store the output there. If the second parameter
is shared across multiple threads, I have to worry about thread safety.
Doable, but ugly.
In Python 3.2 an higher, the concurrent.futures module
makes this much easier. (It is also backported to Python 2.)
Each time you submit a function to be run on a separate thread, you get a Future
object. When you ask for the result, the main thread blocks until your thread is
complete. But the main benefit is that I don’t have to make any changes to
Download.
|
|
In a typical run, my 6 accounts take 3, 4, 5, 6, 8, and 10 seconds to download. Using a single thread, this is more than 30 seconds. Using multiple threads, we just have to wait 10 seconds for all responses to arrive.
I have been using IPython for interactive Python shells for several years. For most of that time, I have resisted the web-browser-based notebook interface and mainly used the console version. Despite my love of all things texty, I finally gave in, and began using the web version almost exclusively. So much that I got annoyed at constantly needing to start and stop the IPython server and having a terminal dedicated to running it.
My first step was to always keep the IPython server running. I did this with a KeepAlive launchd job. Here is the plist:
<plist version="1.0">
<dict>
<key>KeepAlive</key>
<true/>
<key>Label</key>
<string>net.nathangrigg.ipython</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/python3/bin/ipython</string>
<string>notebook</string>
<string>--no-browser</string>
<string>--quiet</string>
<string>--port=10223</string>
<string>--notebook-dir=/Users/grigg/Dropbox/Notebooks</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/Users/grigg/Library/Logs/LaunchAgents/ipython-notebook.stderr</string>
<key>StandardOutPath</key>
<string>/Users/grigg/Library/Logs/LaunchAgents/ipython-notebook.stdout</string>
</dict>
</plist>
This job runs ipython notebook with the --port flag, so that the port
stays the same each time.
I used LaunchControl to create and load this launch agent,
but you can also just save it in ~/Library/LaunchAgents and run launchctl load.
If you want, you can be done now. The notebook browser is running at http://localhost:10223.
But I was not done, because I already had too many processes on my machine that were serving content at some localhost port. This required me to memorize port numbers, made Safari’s autocorrect not very useful, and felt barbaric. What I needed was a domain name that resolved to http://localhost:10223. To do this, I needed a virtual host and a proxy.
Before reading further, you should know that I am not an Apache expert. In fact, I have never managed an Apache webserver except as a hobby. The best I can promise you is that this works for me, on my OS X computer, for now.
In /etc/hosts, I created a new host called py.
127.0.0.1 py
This resolves py to 127.0.0.1, i.e., localhost.
Now in /etc/apache2/httpd.conf I created a virtual host and a proxy.
<VirtualHost 127.0.0.1:80>
ServerName py
ProxyPass /api/kernels/ ws://localhost:10223/api/kernels/
ProxyPassReverse /api/kernels/ ws://localhost:10223/api/kernels/
ProxyPass / http://localhost:10223/
ProxyPassReverse / http://localhost:10223/
RequestHeader set Origin "http://localhost:10223/"
</VirtualHost>
This forwards all traffic to py on port 80 to
localhost on port 10223.
Note that the order of the ProxyPass directives is
apparently important.
Also, if you use * instead of the address in the
VirtualHost directive, you might also be forwarding requests originating
outside of your machine, which sounds dangerous.
Then I ran sudo apachectl restart, and everything seemed to work.
Note that Safari interprets py as a Google search, so I have to type py/.
Chrome does the same thing, except for that after I load py/ once,
the trailing slash is optional.