npm – The Woodwork

For some reason, moving to the new MacBook Air hasn’t been very successful. My Alfred spotlight is broken, Apple Mail slows to a crawl for no good reason even though everything is in the cloud, and I have a \<50% success rate of backing up my Time Machine during my workday. Basically if it doesn’t complete before lunch, it isn’t going to finish at all.

That last one seems to be well within the realm of what’s feasible. I mean why is it backing up 15GB of new files each day and why is it when I really get working the last 2GB never seems to complete? Not to mention that this 5TB drive I purchased four years ago to back up what is only a 500GB SSD (was smaller in years back) is now starting to appear full.

Well I think I figured it out. I’ve been using Vagrant for the last 5 years to build out virtual machines for development and each of them is a single (very large) virtualbox file that needs to be re-imaged every time and is constantly changing if the machine is up during the backup process.

After some research here are some suggestions on what to exclude from your time machine backups…

Working scratch folders:

Things like ~/.Trash and ~/Library/Caches should automatically be excluded by Time Machine in general, but for me, I use ~/Downloads as scratch space for stuff that I don’t care if I lose. If it’s important, I usually drag that to desktop, so I added that. You can add something similar

Cloud files

I added ~/Dropbox because that stuff will be built from Dropbox, and Time Machine or migration restores will just confuse the backup system. If I used Google Drive, I’d probably add that too.

Virtual machines and other dev related environments

For me that’s ~/.vagrant.d and ~/VirtualBox VMs where vagrant downloads the boxes and where, by default, it puts the VirtualBox VMs. The actual boxes that I might image to do Windows/IE development are manually created and imaged in ~/Documents so there is no need to exclude those. If you want to keep your plugins then save ~/.vagrant.d/boxes only.

I also added ~/Library/Containers/com.docker.docker because sometimes I did Docker development and that’s where those instances are.

Also if you have a standard place where you put Python virtual environments with virtualenv you should probably add that too. I don’t develop on localhost anymore so that isn’t the case for me.

Local software caches

I added ~/.gem for Ruby and ~/.npm for NodeJS. I’d probably look into what I can torch from rbenv and rvm but I no longer do local Ruby development, but if you do, add those to your checklist.

Games

I don’t have this on my work computer, but on my home one, I added ~/Library/Application Support Steam/steamapps because those are big files that are downloaded from the internet anyway. When I get home, I’ll have to make sure that sort of thing wasn’t moved into /Users/Shared.

Unknown unknowns

I probably should figure out where Ulysses puts its files because every time I do Migration Assistant I have unresolved conflicts which take forever to clean up. It’s not a big deal though since almost all copies are actually the same file.

Know of any other things I need to add?

Answered in Quora

Q: Which has better packages, Python or PHP?

It depends on the target utility. In the Python world, the most common package installer is pip; the PHP world didn’t settle on a dominant format/installation for packages until composer, and that was relatively recently (last 4 years).

…

The reason for this is because PHP is a language almost exclusively designed for websites, and the economy of the open-source world has found that a dedicated application, instead of a framework or library could serve the bulk of most commercial needs. For instance, a single application, WordPress, four years ago (2014) accounted for nearly 20% of all websites and 50% of all blogs. There is little need package management when a single download and install (or a single click during ISP/hosting account creation or visit to site like Bitnami) can set up everything a typical website might need, fully under your control, with its own package infrastructure (plugin and theme ecosystem) where the underlying language (PHP) is pretty much irrelevant to the user.

Other languages like Ruby (with gems) or Go (import) or Javascript (with npm) which matured later and are more general purpose had a more robust package management and installation system. PHP Composer, in fact, is most modeled on npm.

Python, like Perl, predates these languages, but its general purpose demanded package management early in its development. However, because of this, pip takes less advantage of web conventions that npm does. Python has the added headache of version compatibility with its core runtime. Still pip is perfectly workable and relatively seamless and easy to use.

…

So which has better packages? The answer is it depends on the domain. In nearly any language you can find an adequate package for any of your needs, but overall you will find the packages are higher quality, more up-to-date, and sometimes just better overall in the domain the language seems to target well.

In my opinion, packages for data science/AI/ML applications, Python packages are second to none. As a PHP expert, I wouldn’t even bother looking in Composer for them and would instead find a PHP extension that binded to a dedicated engine optimized for the problem area or write a dedicated solution/web service in Python/flask and call it from PHP. If, for some crazy reason, I needed to do this entirely within PHP, I would search for the best solution in Python and see if someone has a port for that in PHP.

I would expect the same in DevOps for Python, but right now that space, like blogging (WordPress), seems to have dedicated solutions where a domain-specific language has abstracted one from the language-specific package management solution. For instance, in the configuration management space the top four applications are: Puppet, Chef, Ansible, and SaltStack. Of those four, I believe only one (Chef) exposes the underlying language (Ruby), and it does this to the DevOps engineer no more than WordPress exposes PHP to a blogger.

For server-side web-based packages, I feel PHP and Composer are going to have a solution for any problem PHP itself is capable of solving. That is a restricted set, however, as more and more work for web applications is being done on the client-side in Javascript and there is already an adequate toolchain for that (as well as a package management system in npm). Other web-based languages will probably have adequate solutions in this space with decreasing order/quality: Ruby (on Rails), Javascript (NodeJS), Python, Go, Perl, Java… The web problem is now pretty discovered at this point so there is less a need to adopt the bleeding edge in the web problem.

The Woodwork

You tell that other boy, not to touch the woodwork