🚀 go-pugleaf

On 27/07/2023 13:46, PiteR wrote:
> www.znanylekarz.pl
> to projektował pierdolony kretyn aż wydaje się niemożliwe
> żeby byc takim głupim od urodzenia.

A możesz podkręcić jasność wypowiedzi?

On 27 Jul 2023 at 13:46:58 CEST, "PiteR" <email@fauszywy.pl> wrote:

> to projektował pierdolony kretyn aż wydaje się niemożliwe
> żeby byc takim głupim od urodzenia.
> 

Obecny.
But seriously, to było 10 lat temu. Dużo się od „mojego czasu” pozmieniało.

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

On 2023-08-03, Maciej Łebkowski <maciej@lebkowski.name> wrote:
> On 27 Jul 2023 at 13:46:58 CEST, "PiteR" <email@fauszywy.pl> wrote:
>
>> to projektował pierdolony kretyn aż wydaje się niemożliwe
>> żeby byc takim głupim od urodzenia.
>> 
>
> Obecny.
> But seriously, to było 10 lat temu. Dużo się od „mojego czasu” pozmieniało.

Pomysł, aby w danych kontaktowych akceptować zagraniczne numery a potem 
twierdzić, że są nieprawdziwe co de facto wymusza polskie to Twój, czy 
następców? :)

Plus kwiatki w stylu:

403 ERROR The request could not be satisfied. Request blocked. We can't 
connect to the server for this app or website at this time. There might 
be too much traffic or a configuration error. Try again later, or 
contact the app or website owner. If you provide content to customers 
through CloudFront, you can find steps to troubleshoot and help prevent 
this error by reviewing the CloudFront documentation.

To jest oczywiście filtrowanie po IP z kłamliwym komunikatem.

-- 
Marcin

On 12 Aug 2023 at 01:18:20 CEST, "Marcin Debowski" <agatek@INVALID.zoho.com>
wrote:

> On 2023-08-03, Maciej Łebkowski <maciej@lebkowski.name> wrote:
> Pomysł, aby w danych kontaktowych akceptować zagraniczne numery a potem
> twierdzić, że są nieprawdziwe co de facto wymusza polskie to Twój, czy
> następców? :)

Oczywiście, że następców ;)

A tak bardziej serio: wydaje mi się, że istnieje duży chaos komunikacyjny
(potocznie zwany: „Agile”) w organizacjach tej wielkości. Zespół IT
obsługujący obecnie te serwisy to pewnie jakieś 300-400 osób, rozsianych
po tuzinie większych i mniejszych zespołów.

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.

Ale pomyłka to jedno. Brak obserwacji tego, co się dzieje potem na serwisie,
żeby tę pomyłkę zidentyfikować to drugie. A trzecie, czy gdyby komuś takiego
buga faktycznie zgłosić, to czy byłaby szansa na poprawę. Bo to też może
wymagać komitetu, współpracy pomiędzy zespołami o różnych priorytetach.

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.

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 ;)

Widziałem też sytuację, w której dodanie umówionej wizyty do kalendarza
(eg. import pliku .ical) miesza strefy czasowe i pokazuje ją o złej godzinie.
Myślę, że to dość kluczowa funkcja, żeby przypomnienie o wizycie nie kłamało.

Krótko: myślę, że większe grzechy mają na sumieniu ;)


> Plus kwiatki w stylu:
> 
> [...snip...]
> 
> To jest oczywiście filtrowanie po IP z kłamliwym komunikatem.


Prawdopodobnie, ale jak sam widzisz, to akurat komunikat CloudFronta,
ciężko byłoby oczekiwać sensownych i spójnych komunikatów od 3rd party.
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.

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.

Ludzie na górze ogarniają big picture (jakieś górnolotne mierniki typu
współczynniki konwersji, ilości bookingów, etc), a osoby na dole realizują
zlecone zadania, bez brania większej odpowiedzialności za efekt końcowy,
w tym tego typu szczegóły.

Such is life, I guess.

-- 
Winning popularity contests since ’85

On 2023-08-14, Puck <puck@dx.one.pl> wrote:
> On 12 Aug 2023 at 01:18:20 CEST, "Marcin Debowski" <agatek@INVALID.zoho.com>
> A tak bardziej serio: wydaje mi się, że istnieje duży chaos komunikacyjny
> (potocznie zwany: „Agile”) w organizacjach tej wielkości. Zespół IT
> obsługujący obecnie te serwisy to pewnie jakieś 300-400 osób, rozsianych
> po tuzinie większych i mniejszych zespołów.
>
> 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?

> Ale pomyłka to jedno. Brak obserwacji tego, co się dzieje potem na serwisie,
> żeby tę pomyłkę zidentyfikować to drugie. A trzecie, czy gdyby komuś takiego
> buga faktycznie zgłosić, to czy byłaby szansa na poprawę. Bo to też może
> wymagać komitetu, współpracy pomiędzy zespołami o różnych priorytetach.

Trochę watpię. Jak widzę w serwisie takie kwiatki to MZ nie jest to 
poprawialne, bo nie wynika z technologii/danych a właśnie z czynnika 
ludzkiego.

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.

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

> 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ł.

>> To jest oczywiście filtrowanie po IP z kłamliwym komunikatem.
> Prawdopodobnie, ale jak sam widzisz, to akurat komunikat CloudFronta,
> ciężko byłoby oczekiwać sensownych i spójnych komunikatów od 3rd party.

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.

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

> 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ł.

> Ludzie na górze ogarniają big picture (jakieś górnolotne mierniki typu
> współczynniki konwersji, ilości bookingów, etc), a osoby na dole realizują
> zlecone zadania, bez brania większej odpowiedzialności za efekt końcowy,
> w tym tego typu szczegóły.
>
> Such is life, I guess.

Nie mam cienia watpliwości, że tak właśnie jest, co nie zmienia faktu, 
że efekt końcowy to pardąmła, często śmierdząca, uciążliwa kupa.

-- 
Marcin

On 18 Aug 2023 at 03:01:06 CEST, "Marcin Debowski" <agatek@INVALID.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