Clickr, or a young man's Flickr clonejure(jmglov.net)
jmglov.net
Clickr, or a young man's Flickr clonejure
https://jmglov.net/blog/2024-01-17-clickr.html
32 comments
You can save yourself the POO -> POM translation by using `clojure.core/bean`, which turns Java objects into maps, e.g.
Clojure is just fantastic for this kind of thing. You can really tell Rich Hickey and the wider community has spent a lot of time thinking about developer problems and actually fixing them with sensible tooling.
I've done something similar. It started with creating a frontend for more easily viewing my albums on flickr (https://ash.code27.co.za).
Then when flickr was acquired by smugmug I migrated all my photos to DropBox, only to later find out that a small number of photos have been randomly truncated.
In the end I just started to fork out for Flickr, although I have similar feelings each year when I need to renew.
Then when flickr was acquired by smugmug I migrated all my photos to DropBox, only to later find out that a small number of photos have been randomly truncated.
In the end I just started to fork out for Flickr, although I have similar feelings each year when I need to renew.
There's a follow-up post which is pretty good too: https://jmglov.net/blog/2024-01-22-clickr-goes-fe.html
good stuff you've written there, mate. it shows the tight feedback loop of REPL driven development. but, the second part of this series reminds me how hard frontend development is.
Was the goal to download the photos or to fiddle with Clojure and Babashka.
Anyway I wonder what would happened had he written his old code in Node.JS instead of Clojure. Update? Rewrite?
Anyway I wonder what would happened had he written his old code in Node.JS instead of Clojure. Update? Rewrite?
It's the standard developer story. 50 hours into development, you're like, wait, how long would it have taken to go to each album and click Select All->Download?
This guy sure can write. Verbose, but good writing.
Wonderfully entertaining style of writing!
Fun, I've gone the same route (exporting everything through API), but then pushed it to an Immich instance
How's Immich these days? I see it still has a big don't-use-this-in-prod warning, so, should I?
No, that's just a disclaimer to prevent people from randomly installing it without thinking about consequences.
If you actively manage your Immich instane, and regularly read the Changelog before updating it, then you'll be fine.
Just use it alongside a backup.
If you actively manage your Immich instane, and regularly read the Changelog before updating it, then you'll be fine.
Just use it alongside a backup.
The hardest I had to do was to change the docker compose file and update my postgres instance. As long as you don't blindly update its fine. There's the occasional bug, but so far never had issues with the data
[deleted]
> pay AWS a few more cents a year to store them for me
Curious, what would be the estimated yearly cost on aws, would it really be cents?
Curious, what would be the estimated yearly cost on aws, would it really be cents?
if you use glacier it's like 1$/TB month + taxes.
great for backups
great for backups
I'd also recommend S3 intelligent tiering for backups. Storage price goes down to near-glacier levels if you don't access the files, but is available instantly if you do need them. Perfect for important backups.
Couple things to note depending on the traffic and what you're storing:
- Intelligent tiering won't auto-tier <128KB files, will bill them as if they were 128KB in size and at Frequent Access prices
- Glacier and Infrequent Access tiers will bill you a good amount for reading objects, so if they're accessed more than a handful times a year, it might be better to keep them in a higher tier
- Standard Infrequent Access, Glacier Flexible Retrieval and Glacier Deep Archive bill a minimum of 30, 90 and 180 days per object, so better not using it for short lived objects.ramon156(2)
adolph(1)