[Aperocky]

> For example, my oldest files were made in Microsoft Word on an iMac G3 running Mac OS 9. I can open them in a modern word processor, and they look similar – but it’s not the same. Some of the fonts and graphics are missing, and I don’t know where I’d find replacements.

> It’s even harder for an undocumented side project I abandoned years ago. Having the code isn’t the same as a working application.

The author's solution to this is apparently screenshots, I have to respectfully disagree.

For software, side project or not, it should probably come with dependency configurations (granted, in early 2000s this isn't as mature as it is today) and some tests. My side projects basically all have tests, these tests are vital for picking up years later and for validation while developing.

For personal notes, I use this script which upon `$ diary` would create/open an entry for the current day in the appropriate folder with vim: https://github.com/Aperocky/diaryman/blob/master/diaryman.sh. Text files will last forever, it has some basic flavoring with markdown, but that's it. The folder where this is indexed is without a doubt the most valuable data on my computer, and it stretches back years.

I do occasionally take screenshots but never for reasons that author find screenshot to be useful for.

[whartung]

  > For software, side project or not, it should probably come with dependency configurations (granted, in early 2000s this isn't as mature as it is today) and some tests.

These may or may not help. Things have certainly changed in the past several years, but if we have learned anything, the "infinite memory of the internet" is anything but. Dependencies vanish and die all the time. So, while you may have a list of dependencies, if you don't have those actual dependencies locally with you, you may be out of luck. Even if the actual project still exists, the older versions you depend on may not.

I can't speak to others, but if you were to actively shelve a Java project, and were using Maven or relying on its infrastructure, I would clean out your local repository cache, rebuild and test the project, then snapshot the project directory and the repository cache. At least then you might have a solid chance of resuscitating the project later on if you needed too.

[spockz]

Or, point maven to a directory in your repo (`-DlocalRepository`) and include it in your git with lfs. Best of both worlds. Get to use dependency management and always have your dependencies around.

[KronisLV]

> These may or may not help. Things have certainly changed in the past several years, but if we have learned anything, the "infinite memory of the internet" is anything but. Dependencies vanish and die all the time. So, while you may have a list of dependencies, if you don't have those actual dependencies locally with you, you may be out of luck. Even if the actual project still exists, the older versions you depend on may not.

I say this problem impacts most of the development stacks out there, whenever you're dealing with a package manager:

  - Node and Javascript have npm
  - Python has pip
  - .NET has NuGet
  - Java has Maven/Gradle
  - PHP has Composer
  - Ruby has gem

And all of those have packages that could technically disappear, or you could have network issues and so on (when I build my container images, I sometimes even have apt fail, though very rarely). I think a safe bet is to run your own package proxy, like Sonatype Nexus: https://www.sonatype.com/products/nexus-repository (there's also JFrog Artifactory in this space, probably others too: https://jfrog.com/artifactory/)

This can improve build speeds because you refer to your own server for getting packages, the proxy will also pull packages that it doesn't have automatically, there are no rate limits to deal with (e.g. DockerHub pull limits vs the image being pulled once and stored in Nexus, unless changed) and you can also pretty easily see just how much stuff you're relying on.

The next step is to also use this server for publishing your own packages, which is suddenly easier - you can manage your own accounts, with nobody to tell you what you can/can't upload and how: you literally have all of the storage on the server at your disposal, redeploy as often as you want.

The only real downside to this is that you are indeed self-hosting it: you need updates, storage and all that. Well, maybe there's also the issue that using custom repositories downright sucks in some stacks - while npm supports something like --registry, I distinctly recall Ruby being a total pain in this regard in a container context (something about Bundler configuration, since it doesn't seem to support a command line parameter): https://help.sonatype.com/repomanager3/nexus-repository-admi...

[whartung]

In a related matter it behooves open projects to do a very clean build before they do a release.

By that I simply mean they should take a source distribution of their project and perform a build with their repository caches cleared to ensure the project actually still builds in the wild.

Dependencies can silently vanish behind the facade of a local proxy or cache.

[simonw]

Good luck compiling an iOS app you built and last touched in 2012 against a modern version of XCode.

You'd need to keep an entire old, un-upgraded Mac around just to have a chance of doing that without MAJOR engineering work!

[Wowfunhappy]

What about a Virtual Machine? I've found VMWare Fusion does a good job with Mac guests. Snow Leopard works quite well. You could even do it from a non-Mac host if you don't mind applying well-known patches to VMWare.

[wingerlang]

I think the best solution is to just keep both, I have all the source code for all my projects since maybe 2008. But I also keep a lot of screenshot, if I want to refer to an old project I go to those screenshots (or even better, videos) in 99.9% of the cases.

[torh]

> The author's solution to this is apparently screenshots, I have to respectfully disagree.

It's a good thing you're respectful about it. Your proposed solution seems to miss of of the main point of the author: creativity. Using a standard set of mature programming tools isn't creativity. The other aspect (that you touched) is time. Unless you set up a virtual machine, you will never get the same visual result of your toy project in Microsoft Visual Basic -- or maybe even get it to compile.

The author argues that screenshots is the fastes and most convenient way to reminiscence about the past, and for that she is right.

[humaniania]

Turn a copy of your old PC into a VHD for a VM before you retire it.