A number of events and coincidences have reminded me about functional programming and parallelism lately, especially an example I saw of Clojure’s pmap:
Usage: (pmap f coll)
(pmap f coll & colls)
Like map, except f is applied in parallel. Semi-lazy in that the parallel computation stays ahead of the consumption, but doesn’t realize the entire result unless required. Only useful for computationally intensive functions where the time of f dominates the coordination overhead.
I’ve heard, for a long time, the argument that functional programming offers a programming style better suited for parallelism. After all, MapReduce is perhaps the ultimate form of famous-brand massive parallelization. In a typical map operation, you don’t have to worry so much about all the nasty little parallelism problems since your code, by convention, is side-effect free.
parallelmap(proc, tasks, callback)
where proc is a function that takes one argument, tasks is an array of things, and callback is a function that will be called with the results when processing has completed. The computation will occur in parallel and show dramatic speedups on processing-intensive tasks.
Git-dude is a cool little thing. Given a directory of git repos, it continually fetches updates and displays a popup if you get any new commits. When I first saw it on Google Plus, somebody inexplicably commented, “This is a neat thing and I dont [sic] think there is a mercurial equivalent.”
Given that Git and Mercurial are isometric for most intents and purposes, this baffled me. Clearly, this could not be some special Git-exclusive functionality. I dug into the git-dude source code and found out it was little more than a single bash script that pipes some git commands through sed and awk.
A few minutes later, I made hg-dude, which offers similar functionality for Mercurial. There’s a couple things that aren’t supported. Git-dude offered special notifications for tags and branches, and I didn’t translate them to Mercurial because the concepts, even though they have similar names, don’t quite match up. Regardless, it is still as useful as git-dude for commit notifications, which I expect is the primary usage.
“To perform the requested action, connection information is required.”
My earlier post on WordPress with NearlyFreeSpeech.net was too hastily written. There are more issues than WP not wanting to use the direct upgrader, and editing WordPress code is not the right way to solve it either.
Problem 1: WordPress doesn’t want to use the direct upgrader. You can force it to use the direct upgrader by adding define('FS_METHOD', 'direct'); to /wp-config.php.
Problem 2: WordPress may not have write access to certain directories. The wp-content directory, for example, would need to be chgrp to web and chmod to 775 in order for WordPress to update the things within. Of course, there is the option of just doing that on all of your WordPress files.
Problem 3: WordPress will create files that you cannot edit. Files created by PHP will be owned by user ‘web’ and the permissions will be 644. That means you (“me”) cannot edit these files over SSH since you are not the owner. You can’t even delete, chown, or chmod the files. You’ll either have to get PHP to delete them or ask NFSN support to chown them for you. A workaround is to umask(002); to your wp-config.php, which makes files created by PHP group-writable. They will still be owned by web by default, but at least you can do something about it.
Problem 4: The default temp directory may not be accessible by PHP. NFSN’s FAQ for installing WordPress has instructions about this and a variant is given here. First, make a directory called ‘tmp’ in your WordPress root and give PHP permissions to write to it (chgrp to web and chmod to 775). Then, add define('WP_TEMP_DIR', dirname(__FILE__).'/tmp'); to your wp-config.php file.
If you’re reading this, then the DNS changes have successfully propagated and you’re loading this page from my new hosting provider, NearlyFreeSpeech.net. I’m dropping Site5 like a bad habit, and will soon be free of uncool mainstream shared hosting relatively soon. Although Site5’s control panel software went through a major revision recently, it was still clunky and awkward, especially for MySQL and hosting multiple sites on one plan.
I recently moved an old website to a new server. For performance reasons, the new server is running nginx instead of Apache, and didn’t have nginx set up to use PHP. (The optimal way, apparently, is to use PHP-FGM, which currently requires you to patch and build PHP yourself, at least until PHP 5.4).
That was fine, though, because this old site only really needed PHP for one little thing that we could do without. In fact, the primary reason for using PHP here was to essentially append the header and footer sections to each unique page. Basically, we had stuff like:
on every page. What I needed was an automated process to convert all of these PHP pages into static pages. GNU Make, of course, is the de facto standard for automating something like this. Let’s give it a go:
I was cleaning out some miscellaneous files from my computer today when I found a folder called “eyeos”. EyeOS. My friend and I thought we were uber-cool when we set up eyeOS on our shared hosting accounts and looking back, yeah, well, we were.
EyeOS was an ambitious open-source project to give you a desktop in your browser. You could have files, record appointments, and write documents from anywhere, as long as you had an Internet-connected computer. Nothing was stored on your local hard drive, it was all up on the … Internet.
This was November, 2005. This was back when clouds meant fewer UV rays.