Clickr, or a young man's Flickr clonejure | Hacker News Reader

Clickr, or a young man's Flickr clonejure

jmglov.net

78 pointsadityaathalye25 comments

You can save yourself the POO -> POM translation by using `clojure.core/bean`, which turns Java objects into maps, e.g.

    (bean (java.util.Date.))
    => {:day 3,
        :date 24,
        :time 1706087564699,
        :month 0,
        :seconds 44,
        :year 124,
        :class java.util.Date,
        :timezoneOffset -120,
        :hours 11,
        :minutes 12}

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.

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?

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.

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

> 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?

if you use glacier it's like 1$/TB month + taxes.

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.

So it’s $60 for 5 years - about the same as a HDD.

That’s more than what I imagined when I heard “cents”!

yeah but photos on your HDD aren't likely to be accessible online for years and years even with self-hosting.

Odds are good that a young man has not heard of flickr.

Reply on news.ycombinator.com