On 18 Aug 2023 at 03:01:06 CEST, "Marcin Debowski" <a...@I...zoho.com>
wrote:

>> Hipotetycznie:
>> Ktoś zauważył potrzebę dokładniejszej weryfikacji numerów, ale nie zastanowił
>> się nad migracją istniejących danych, które nie spełniają nowych norm. Taki
>> scenariusz wydaje mi się bardzo prawdopodobny.
> A jest w ogóle możliwość takiej weryfikacji? Musiałaby być jakaś
> centralna, uaktualniana baza wzorców z tych xxx krajów. I jaki miałby
> byc tego sens w przypadku nr telefonu?


Aaaa bo ja wiem, co tam product managerom w głowach siedzi. Ktoś wymyślił
sobie jakiś powód, dla którego weryfikacja wydała się odpowiednim
rozwiązaniem.
Nie wiem dokładnie o których numerach mówisz -- użytkowników aka pacjentów?
Może np. chcieli upewnić się, że kanał powiadomień jest poprawny, żeby
mieć większy współczynnik zrealizowanych wizyt?

Jeśli zastanawiasz się jak Tobie, czy innym szarym użytkownikom to pomoże,
to raczej trud Twój marny. Nie spodziewałbym się, żeby w tej skali pojawiały
się zmiany, które faktycznie są praktycznie przydatne pacjentom. Tym raczej
rządzą jakieś górnolotne idee i przeważnie nastawione są na optymalizację
jakichś mierników, a nie faktycznych odczuć żywych ludzi ;)

W większości oczywiście, bo pewnie jest masa wyjątków. Ale ogólny model
tłumaczy ten dysonans, który masz -- po co robią, skoro to niepotrzebne.



Co do bazy, to akurat jest, w dodatku bardzo fajna:
https://github.com/google/libphonenumber

To akurat bliżej moje pole, bo robiłem teraz przez kilka lat projekt związany
z telco, więc tam numery były kluczowe. No ale oczywiście to tak jak z
walidacją
adresów mailowych: można budować skomplikowane regexpy, dostosowywać się do
RFC... Albo można po prostu maila potwierdzającego wysłać ;)


> Podobnej klasy petunie dotyczą serwisów odrzucających najzupełniej
> poprawne adresy e-mail. Zapewne ktoś sobie wymyślił, że wszyscy uzywają
> gmaila, outlooka czy innego hotmaila, tak jak kiedyś istniała cała
> "klasa" łebpartaczy którzy robili wszystko pod IE i ekran określonej
> rozdzielczości.

Yep, ludzie robią założenia, które pozwalają im zrozumieć świat lepiej,
albo zrealizować swoje cele, a potem zonk, bo świat jest bardziej
skomplikowany.

Nie przytoczę dokładnie anegdotki, ale znana była sytuacja, gdzie software
porusza się w ramach oczywistych dla większości aksjomatów. Jak np. jedna
aplikacja do budowania drzewa genealogicznego nie dawała możliwości
łączenia rodzeństwa więzami małżeńskimi. To brzmi jak rozsądna restrykcja.
Dopóki nie przyszło zgłoszenie z obsługi Klienta, że ktoś ma taką potrzebę.

Świat jest chaotyczny i mocno niepoukładany. Programiści, w odróżnieniu,
często są na drugim krańcu spektrum, chcąc wszystko poukładać według
prostych, zwięzłych zasad... No a potem ups ;)


>> Któregoś razu *wewnętrznie* zgłosiłem problem dotyczący bookowania, czyli
>> głównego produktu firmy. Przez kolejne tygodnie, a potem miesiące, ticket
>> był odbijany pomiędzy kolejnymi osobami, spośród których żadna nie miała
>> nawet bladego pojęcia kto może skutecznie zdiagnozować problem.
> Czy tez nie miała zwyczajnie chęci?

Może trochę, ale to nie był powód. Najzwyczajniej ludzie nie mieli tak dużej
ekspertyzy, żeby rozumieć tak szeroko system, żeby zdiagnozować skomplikowany
problem, a najwyraźniej nie był on wystarczająco ważny, żeby zainteresować
osoby z większym stażem.
W moim doświadczeniu, przy tej skali rządzi biurokracja, procesy, etc,
które wcale nie odpowiadają na potrzeby jednostek, tylko organizacji w
skali makro.

>> Innym razem, jako użytkownik, wyszukałem *na mapie* lekarza w mojej
>> okolicy. Kliknąłem pinezkę oddaloną kilkaset metrów od mojego domu,
>> następnie niebieski guzik umawiania wizyty, wybrałem termin, etc. Ku
>> mojemu zdziwieniu, okazało się, że to był tylko ,,chłyt marketingowy"
>> (albo błąd po prostu): lekarz faktycznie pracował w tym miejscu, ale
>> wizyty dostępne miał w innym mieście, oddalonym o 300km notabene, a
>> serwis chciał trochę ,,uprościć" proces ;)
> No to akurat nie wyglada na winę serwisu, tzn spodziewałbym się, że
> lekarz namotał.

Wina serwisu. Aplikacja została wprost poproszona o ,,znajdź wizytę blisko
mojego miejsca zamieszkania" i w odpowiedzi pokazała bąbelek lekarza na
mapie z guzikiem zabookuj.
Lekarz uzupełnił sobie wiele adresów, pod ktorymi przyjmuje, a w każdym
z nich wprowadził kalendarz z godzinami przyjęć.

Za to serwis zdecydował, że pod pinezką na mapie w Warszawie, pokaże niebieski
guzik bookowania kierujący do gabinetu w Poznaniu. Ale to powstało w wyniku
tego samego mechanizmu -- komuś taki model się zgadzał, pewnie po to,
żeby zaproponować więcej terminów użytkownikom. To, czy ktoś wchodzi na
listing
lekarzy skupiając się na lokalizacji, ocenach czy jakimkolwiek innym kryterium
było w tym procesie (dla projektujących) nieistotne; a fakt, że lekarz
przyjmował w gabinetach oddalonych o 300km był niewygodnym edge-casem,
o którym nikt nie pomyślał.

Ale to nie to, że narzekam. Staram się spekulować na temat tego jakie procesy
powodują takie efekty, chociaż wcale nie mam odpowiedzi na pytanie jak można
zrobić to lepiej.


> To jest problem systemowy. W ciągu ostanich 10-15 lat jakość tego typu
> usług informatycznych poleciała tak drastycznie w dół, że znakomita
> większość łyka takie kwiatki jako standard. Kłamstwo jest wszędzie i na
> każdym kroku. Będą ci wmawiać, że coś z Twoją
> siecią/komputerem/tesciową/chomikiem jest nie tak i dlatego nie działa,
> podczas gdy sami dają dupy na każdym kroku. Wobec tego faktycznie,
> kłamliwy komunikat przy blokowaniu IP jest w sumie pomijalnym
> szczegółem. Powstała cała "kultura" IT oparta na kłamstwie do czego walnie
> przyczynił się majkrosoft ze swoim wspaniałymi wynalazkami.

Zakładając, że tak jest faktycznie -- jak mniemam jesteśmy przyzwyczajeni
do czasów, kiedy rzeczy robiło się bardziej od podstaw, a jednocześnie z
większą dbałością o szczegóły. Dzisiaj wiele obszarów można outsource'ować
lub po prostu kupić w abonamencie za $30/mo. Zyskujemy szybkość, możemy
skupić się na problemach unikalnych dla naszej branży i prouszać się na
wyższym poziomie abstrakcji -- kosztem właśnie tej dokładności i
przekłamywania.


>> Poza tym, z tego co rozumiem taka blokada nie jest z powodów ,,biznesowych"
>> jak np. często spotykane geo-blocki na europe z powodów GDRP, ale raczej
>> techniczna -- wycięcie nieobsługiwanych rynków dla zwiększenia bezpieczeństwa
>> być może? Ciężko mi spekulować, nie mam wystarczającej wiedzy na ten temat.
> I nie można zwyczajnie napisac, co wyżej napisałeś (mozna to ująć w
> sposób zrozumiały nawet dla dziadka emeryta)? Czy też taki kłamliwy
> komunikat ma zwiększyć bezpieczeństwo (security through obscurity) bo
> ewentualny atakowacz to przecież idiota i nie będzie wiedział?
>
> To jest ponownie, brak pewnej kultury, etyki ludzi współcześnie
> nadzorujących takie prace. Zwyczajnie nie warto się wysilac dla 1%
> odrzuconych, czesto ze szkodą dla klienta.

Myślę, że zdecydowanie tak. Ja robiłem strony i aplikacje od podstaw,
samodzielnie od początku do końca. Byłem też często odbiorcą własnych
produkcji, dlatego zależało mi na tych szczegółach. Rozumiem więc dobrze
o czym do mnie mówisz.
Ale masa osób nigdy nie przeszła tej ścieżki. Nauczyła się jakichś metod
prowadzenia projektów, albo ich projektowania, albo implementacji i używa
tych metod w pracy, ale niekoniecznie w takim samym celu jaki nam byłby
bliski. Można sprawnie władać warsztatem projektowym, ale wcale nie umieć
robić produktów, które w kontekście tego wątku moglibyśmy określić jako
wartościowe.

Tak, tak, w skrócie chciałem napisać: ,,za moich czasów (...) a w ogóle to
spieprzajcie z mojego trawnika".

>> Robiłem za to blokowanie ,,back in the day", skierowanie przeciwko botom
>> scrapującym bazę. Nikt wtedy nie martwił się tym, co będzie widniało w
>> zablokowanych requestach. Nie miałbym zatem oczekiwań, że teraz, w tej
>> skali, ktoś będzie zastanawiał się takimi szczegółami.
> Bo obecne środowisko jest takie, że jest to norma. Co więcej, jestem
> przekonany, że jakby się ktoś wychylił i chciał to zrobić porządnie
> to szybko by z roboty wyleciał.

Nie wiem, czy koniecznie wyleciał, ale na pewno spotkałby się z serią
zdziwionych spojrzeń ;)

Anegdotka:
W jednym z moich pierwszych korporacyjnych projektów, po latach tworzenia
serwisów hobbystycznie, byłem odpowiedzialny za poprowadzenie jednego
projektu. Jednym z zadań, które wyznaczyłem było zaprojektowanie struktury
linków serwisu. Dla mnie to było istotne. Wzorowałem się takimi serwisami
jak Flickr, gdzie hierarchia adresów miała semantyczne znaczenie, była
świadomie projektowana i przynosiła wartość.
Dla osób realizujących było to zupełnie niezrozumiałe. Dla nich linki
były jakimś szczegółem technicznym, gdzie framework sam je generował
automatycznie, aby połączyć z wybranymi kontrolerami w kodzie.

Programiści nie kumali o co ich proszę, podczas gdy dla mnie było tak
ważne i oczywiste, że nie rozumiałem co muszę im wytłumaczyć (wpadłem
w popularną pułapkę, gdzie zakładałem, że mają podobną wiedzę i kontekst
co ja -- nic bardziej mylnego). :)


--
Maciej Łebkowski
https://lebkowski.name/nntp