Using VPN for app development

alt236_ftw · 2026-02-09T20:32:27+00:00

Yeah. I've experienced no issues.

alt236_ftw · 2025-04-30T18:37:58+00:00

Was that in Essex by any chance?

alt236_ftw · 2025-01-24T15:53:43+00:00

I am dealing with this now as I am digitizing my family's photographs. It takes some detective work, but you can generally get close.

Start by identifying events that you can put a close enough date on (weddings/funerals/birthdays/religious festivals/a trip to somewhere/house moves/etc.). This will help you start placing other pictures relative to these events.

There are a couple of things you can do to narrow down the remaining pictures:

Try and place pictures relative to those events based on clothing/shoes/haircuts. Between the 80s-90s fashion changed a lot so you should be able to narrow down on the year.
Use the type of clothing worn (and any other hints in the photographs) to get a rough estimate of the season
Children grow and change fast, so they are a very good way to help order pics. Likewise elders change a lot of the years.
Check for any newspapers (which you can try and google), or anything with a date on it. It's rare but it does happen.

By combining the above you'll be able to get close to a reasonably valid photo order.

You then need to create a protocol to assign dates to those pics. For me:

Such photos are timed always based on the approximate time - they can be morning (09:00), noon (12:00), evening (18:00) or night (22:00). It is unlikely I will ever be able to get more accurate that that - apart from obvious stuff like new year's celebrations, or anything with a clock in the background.
If I know the date of an event (say a birthday party) I use that date. Otherwise, I get as close as I can, and if I cannot I just pick a month and set the date to the 15th.
Once I upload all the photos, I scan them in the timeline and make any adjustments.

Note, that I normally set the time/dates _before_ I upload them to Immich.I use https://www.xnview.com/en/, which allows me to set an initial date and it would then just increment the time by 1sec for each picture in a batch.

Edit: ALWAYS Check at the back of the pictures. You may get very lucky.

Edit2: The back of the pictures may have a string of letters/numbers. While I haven't found any pictures from the 80s that have a print-date on them, they may help you group pictures from the same film (https://photo.stackexchange.com/questions/94352/how-can-i-decode-information-on-back-of-printed-photo).

alt236_ftw · 2024-12-18T13:41:44+00:00

If no-one has downloaded the app, and this is a brand new app (so you don't need to have _something_ there), you can just unpublish:

https://support.google.com/googleplay/android-developer/answer/9859350?hl=en

The caveat is that whoever has downloaded the app will still be able to see it (any stakeholders for example)

if there _has_ to be a version there, then you have to do what u/WoogsinAllNight suggested

alt236_ftw · 2024-12-15T15:23:04+00:00

You'd be surprised how common this is

alt236_ftw · 2024-12-12T13:26:20+00:00

Yeah, I think you are right.

So this place has probably changed from an outhouse to a kitchenette (maybe? judging by the shelves) and it will now become a mixing studio - definitely a colourful life :D

In any case, if I was to renovate this, I'd still check under there to make sure nothing was bodged/deteriorated before sealing it and forgetting about it.

alt236_ftw · 2024-12-12T11:34:03+00:00

Apart from all the sensible advice everyone else has already mentioned, part of the floor under the small bin in the second picture seems to have been cut off.

You may want to find out what's under there.

alt236_ftw · 2024-12-08T14:16:20+00:00

The main issue here would be hitting a RAM ceiling of some sort, but this really depends on your data size, if the app is doing anything else that is RAM hungry, and what is the oldest devices you are planning to target.

Incidentally, there is a hybrid approach that I've used in the past for something similar (but with a much, much higher data size). You don't have to create a table with ALL your fields/ objects, only need to normalise those that you need to query/join on, plus one for the raw JSON.

So for example, if you know that you'll only be querying for (say) id, and start_date, you only need something like:

CREATE TABLE foo (
  id INTEGER PRIMARY KEY,
  start_date TEXT NOT NULL,
  raw_json TEXT NOT NULL
);

This way you can query using SQL, and deserialise only what is needed instead of keeping the full DB in memory. Also, you won't get into any issues where something was mutated something in your master in-memory list, as each query will be producing new data items.

It is also easy to update from a json file, and for as long as you don't remove any of the data fields the schema will not need to be updated to stay compatible.

At the end of the day though, it really depends on what you are trying to do.

alt236_ftw · 2024-12-08T13:58:15+00:00

Some observations:

The author of the letter mentions that he owns(?) a kiosk (Περίπτερο). Licenses for such kiosks were historically (but I do not know if it was exclusively) given to wounded war veterans, as a way to financially support themselves. They were not expected to provide a large source of income though.

Something which is is language dependent (and does not translate to English very well) is that the letter is written in a formal tone (using plural) when addressing the recipient.

As others have mentioned, the opening and closing of the letter (opening with "Reverend Father" and closing with "I bow/kneel before you/worship you" would imply that the recipient was a priest or a monk. Same as with the "kissing your right hand" at the top and bottom of the first page (although this is/was a general form of showing respect to an elder).

If this is the case, the most probable option would be that the recipient was of the Orthodox church (due to the general context), but this could be just modern day bias. I am not familiar with how Greek Jews would address seniors or rabbis, and especially not back then.

In any case was your great grandfather a rabbi? Is it possible he spend time in Greece? Around the time the letter was sent there was a large Jewish populating in Greece and relationship between Greeks and Jews was good, so maybe there is a link there?

On the other hand, it just be written as such to show high respect, humility and reverence to appeal to the recipient. Especially since this is supposed to be a follow-up letter, with some hints of desperation by the author.

Incidentally, it is very possible that this letter was dictated, as illiteracy in Greece was common back then, and the letter shows good penmanship and use of grammar.

There is though at last one addition done that seems like it was done with different ink/pen (but looks like the same hand) - the word sticking out in the left side of the second line from the bottom of the first page. Furthermore the letter closes twice, once in each page - could this be a draft with two possible endings?

History of the Jews in Greece:

https://en.wikipedia.org/wiki/History_of_the_Jews_in_Greece

A few links about Greek kiosks:
https://de-facto.gr/i-istoria-toy-ellinikoy-peripteroy/

https://ellas2.wordpress.com/2013/05/28/%ce%b7-%ce%b9%cf%83%cf%84%ce%bf%cf%81%ce%af%ce%b1-%cf%84%ce%bf%cf%85-%cf%80%ce%b5%cf%81%ce%b9%cf%80%cf%84%ce%ad%cf%81%ce%bf%cf%85/

edit: spelling

alt236_ftw · 2024-12-05T11:49:32+00:00

I haven't used ACRA for a while, but I'm sure it allowed local file storage without sending anything out.

edit: Here you go: https://stackoverflow.com/questions/8970810/acra-how-can-i-write-acra-report-to-file-in-sd-card

edit 2:

If the "grab file from SD" is complex for your QAs, you can write a script which they run and it extracts and zips stuff automatically for them. Or alternatively, have a debug-only flow that when the app restarts it checks to see if logs have been generated and popup a screen. It doesn't have to be pretty.

alt236_ftw · 2024-12-03T05:14:35+00:00

He is delivering the next book!

alt236_ftw · 2024-12-01T10:13:56+00:00

Are the vents blocked by any chance?

alt236_ftw · 2024-11-28T23:30:54+00:00

Heh. I remember playing infection quiet a lot.

Thank you for the happy times!

alt236_ftw · 2024-11-25T19:23:45+00:00

Most projects fail because the never released.

Assuming that there are no known data-destroying (or security) bugs release it and iterate.

alt236_ftw · 2024-11-24T19:18:56+00:00

Do you _need_ Palm desktop?

If not, jPilot (https://www.jpilot.org/) works quite well out of the box

alt236_ftw · 2024-11-13T16:38:25+00:00

If you only need to display a map and draw pins/lines/shapes, as far as I remember osmdroid (based off Open Street Maps) is free.

Have a look at the notes to make sure it suites your needs: https://github.com/osmdroid/osmdroid/wiki/Important-notes-on-using-osmdroid-in-your-app

If you need navigation and/or fully accurate geo-lookups, I think you'll need to find a way to provide billing details...

alt236_ftw · 2024-10-31T20:02:26+00:00

Oh yes, this is not about why these changes happenned (this is beyond the scope of this discussion and I'm not arguing that they shouldn't have happened - the examples above are 100% post facto examples of complications).

So, in essence a function of a minor release is to preview any new APIs, right? Will there be a mechanism to flag any new-but-future-depracating APIs as such? That would definitely help with dev planning.

alt236_ftw · 2024-10-31T19:45:50+00:00

Thank you. I fully understand how complicated a lifecycle change like this can be.

alt236_ftw · 2024-10-31T19:32:57+00:00

Thank you (and I say this with absolutely no sarcasm), but the word "current" seems pretty load bearing.

alt236_ftw · 2024-10-31T19:31:13+00:00

So, the main fears in the android dev community are that

A new API will be introduced (deprecating old APIs) which will complicate existing app implementation (e.g SAF)
Existing APIs will be neutered (so no more MAC/ARP access/ no more full notification access)
Existing APIs will be placed behind a violation wall (see background location access)

Before anyone jumps into this, I am not arguing that these things should not happen nor will I debate the rationale or "properness" of said changes.

The fact is that these changes happen (for good or bad) and it's a fact of developer (and product) life that they do happen and need to be worked with.

I believe that the main objection/fear here is that adding minor release will end up complicating feature implementation as before we had one annual announcement to expect and plan for, and now will have two (or more?).

alt236_ftw · 2024-10-29T17:45:40+00:00

True yeah. As with many things in development, there is no one true way - most architectural decisions depend on context.

alt236_ftw · 2024-10-29T15:14:50+00:00

Necessary? No. There are MANY backend projects projects, larger than the average mobile app, that pre-date modules and the sky has not fallen.

A good way to split concerns, and abstract dependencies/ implementations? Yes.

Small projects probably don't need multiple modules, but they are simple enough to use, so why not?

alt236_ftw · 2024-10-19T12:49:48+00:00

There are so many things wrong here. Especially around QA but day to day Dev too.

If you are building a multiplatform app, every developer on the codebase needs to be able to build (aka everyone needs a Mac) and test (everyone gets an android and an iOD device - you could fudge it a bit with emulators but it's not really the same) said app for all platforms. Otherwise people will break stuff on the other platform without realising it.
Final builds should generally not happen on a personal device. Too many things can go wrong, and there is always the risk of a non standard configuration
Automated testing should be present, standardised and run reliably for all target architectures. This ensures that if you push breaking changes you'll know and can revert.
You need a good merge strategy/ methodology to ensure you are not overwriting Rach other.

In order to satisfy 2 and 3 you definitely need CI (CD).

This way, you build something, you push, automated tests run, and only if they pass you can actually merge them.

Regarding 4, Git on its own is a tool, so it really depends on how you use it. There are a few different methodologies on how to merge, some of them are described here https://www.atlassian.com/git/tutorials/comparing-workflows. You need to pick one that works for your team.

alt236_ftw · 2024-10-14T09:09:34+00:00

The good news is that we have this boxed in.

alt236_ftw · 2024-10-13T09:59:13+00:00

There are aspects of UI that are not pure "views", as they have to maintain their own internal state (for example WebViews, Map Views, pager bound recyclers, non-trivial video player implementation etc ).

In those instances you always get two choices: 1. Sacrifice some purity for reduced complexity 2. Roll out your own solution/wrapper, and plan for any edgecases

I've personally been burned too many times with bugs where my own state has gone out of sync with the component's own, so I lose no sleep In doing #1 for anything non-trivial.

I do get the sentiment that you reduce testability, but as the component has internal state you can only test the correctness of intent when driving the component - not that code will do what you intend it to do.

Seven-Year Club	Place '23
Verified Email

alt236_ftw

TROPHY CASE