ls napisał(a) :
> W dniu sobota, 20 października 2012 09:49:39 UTC+2 użytkownik Zbynek Ltd. napisał:
>> Elo
>> (...)
>> Przy okazji.
>> W moim Realu zmieniono PINpady i już nie ma możliwości wypłaty gotówki.
>
> Nie martw sie na zapas. Napisalem w tej sprawie do Reala i oto odpowiedz:
>
> "W odpowiedzi na Pana mail chciałbym uprzejmie poinformować , że Cash
> back będzie u nas dostępny w niedługim czasie .Obecnie brak dostępu do
> tej usługi spowodowany jest zmianą terminali oraz centrum rozliczeniowo
> autoryzacyjnego , które je obsługuje . Pracujemy nad przyspieszeniem
> przywrócenia tej funkcji, w trosce o jak najlepszą obsługę naszych
> klientów."
>
> Oby tak sie stalo ;)

Właśnie dzwoniłem do BOK Reala w moim mieście. Podobno jest awaria i
będzie działać dopiero za 3 tygodnie.

--
Pozdrawiam
Zbyszek
PGP key: 0x1E6680DF

[Człowiek zaczyna używać dopiero wtedy rozumu, gdy kończą mu się
wszystkie możliwości.]

do góry

Kamil Jońca pisze:

>> Przykład jest nieadekwatny, bo w tym konkretnym wątku rozmawiamy o
>> konkretnym błędzie w implementacji. Nie przekonasz mnie, że jakakolwiek
>> specyfikacja kazała informatykom celowo nie odróżniać wypłaty od zapłaty.
>
> A dlaczego? Może na początku nie odróżniali "sprzedaży" od
> "sprzedaży+cashback" bo nie było to do niczego potrzebne.

Są to dwie różne operacje i to wystarczy. Bank powinien dysponować pełną
wiedzą, choćby na wypadek, gdyby klient złożył reklamację.

A ja nie wyobrażam sobie, że kodując cokolwiek mógłbym nie odróżnić
różnych możliwych przypadków. Jasne wyodrębnienie wszystkich możliwych
sytuacji wejściowych jest podstawą przejrzystego i łatwo modyfikowalnego
algorytmu.
Z tym że ja programowałem w czasach, gdy się liczyło bajty, więc moje
podejście jest zapewne mocno niewspółczesne... Kto by się dziś
przejmował takimi bzdetami...

> (Bo jeśli się nie nalicza opłat za np. CB to po co rozróżniać?)

Choćby po to, żeby debuggowanie się udało. A testy, które nie
uwzględniają różnych możliwych sytuacji to po prostu złe testy są...

> I tak zostało, bo stwierdzono że dla paru świrów z pbb nie opłaca się
> modyfikować systemu.

To być może. System nie został zmodyfikowany i już nie zostanie. Ja
jednak twierdzę, że on od początku źle był zaprojektowany. Nawet jak
jeszcze nie było potrzeby rozróżniania, to system wewnętrznie
powinienbył rozróżniać.

W zasadzie jedynym rozsądnym powodem nierozróżniania może być fakt, że
kiedyś w ogóle nie było takiej usługi, więc nie było takiej możliwej
sytuacji. Jak usługę nową wymyślono, to programiści poszli na łatwiznę i
zamiast dodać pełną obsługę nowej sytuacji, po prostu dodali swego
rodzaju protezę - czyli sprowadzili nowy przypadek do przypadku już
rozwiązanego, tracąc po drodze pewne dane. W starych systemach takie
rakowe narośla często się pojawiają, a potem są przyczyną problemów - bo
"ktoś czegoś nie przewidział".

--
MiCHA

do góry

Przemyslaw Kwiatkowski <m...@m...waw.pl> writes:


[..]
> W zasadzie jedynym rozsądnym powodem nierozróżniania może być fakt, że
> kiedyś w ogóle nie było takiej usługi, więc nie było takiej możliwej
To jest inne wytłumaczenie, też możliwe.

> sytuacji. Jak usługę nową wymyślono, to programiści poszli na łatwiznę i
I znowu zakładasz, że _programiści_ podjęli jakąś decyzję. Ech. Ja sie
poddaję.

KJ

--
http://blogdebart.pl/2012/06/24/hiena/
"First things first -- but not necessarily in that order"
-- The Doctor, "Doctor Who"

do góry

W dniu poniedziałek, 22 października 2012 19:58:06 UTC+2 użytkownik Przemyslaw
Kwiatkowski napisał:
> jednak twierdzę, że on od początku źle był zaprojektowany. Nawet jak

Tu byłeś na właściwym tropie. A więc programiści, czy może ktoś inny?
Wiesz w ogóle jak obecnie wygląda proces produkcji oprogramowania? Jakie w nim
występują role i kto za co odpowiada?

do góry

Przemyslaw Kwiatkowski

> Kamil Jońca pisze:

>>> Przykład jest nieadekwatny, bo w tym konkretnym wątku rozmawiamy o
>>> konkretnym błędzie w implementacji. Nie przekonasz mnie, że jakakolwiek
>>> specyfikacja kazała informatykom celowo nie odróżniać wypłaty od zapłaty.
>> A dlaczego? Może na początku nie odróżniali "sprzedaży" od
>> "sprzedaży+cashback" bo nie było to do niczego potrzebne.

> A ja nie wyobrażam sobie, że kodując cokolwiek mógłbym nie odróżnić
> różnych możliwych przypadków.

Ale to nie należy do zadań kodera/programisty

> Jasne wyodrębnienie wszystkich możliwych
> sytuacji wejściowych jest podstawą przejrzystego i łatwo modyfikowalnego
> algorytmu.

To wykracza poza zakres obowiązków kodera/programisty

> Z tym że ja programowałem w czasach, gdy się liczyło bajty, więc moje
> podejście jest zapewne mocno niewspółczesne... Kto by się dziś
> przejmował takimi bzdetami...

Kto projektował to co programowałeś i dlaczego? A kto testował i dlaczego?

> testy, które nie
> uwzględniają różnych możliwych sytuacji to po prostu złe testy są...

Przygotowanie testów nie powinno być zadaniem kodera/programisty

>> I tak zostało, bo stwierdzono że dla paru świrów z pbb nie opłaca się
>> modyfikować systemu.

> Ja jednak twierdzę, że on od początku źle był zaprojektowany.

Ooooo. Projektowanie. No to patrz wyżej

> programiści poszli na łatwiznę i zamiast dodać pełną obsługę nowej sytuacji

Zapewne by dodali, ale modyfikacja algorytmu nie do nich należy. Poszli na
łatwiznę...

do góry

Kamil Jońca pisze:

>> sytuacji. Jak usługę nową wymyślono, to programiści poszli na łatwiznę i
> I znowu zakładasz, że _programiści_ podjęli jakąś decyzję. Ech. Ja sie
> poddaję.

Czepiasz się słów. Wszak napisałem, że "niektóre banki mają ch*ych
informatyków". Kategoria "informatyk" jest dość szeroka i mieści się w
niej i programista, i projektant, i pan "od komputerów" w szkole, i
administrator trzepakowej sieci ulicę dalej... Ja nie wnikam jak w danym
banku wygląda struktura zespołu obsługującego projekty informatyczne. I
choćby nawet całość była robiona przez jednego studenta na umowę
zlecenie, to nie obchodzi mnie to. Mnie obchodzi efekt końcowy i widzę,
że on jest zły. I już. I nie ważne jest dla mnie czy to koder źle
wcisnął Enter, czy projektant narysował o jedną strzałkę za mało.

--
MiCHA

do góry

Piotr Hołda pisze:

>> jednak twierdzę, że on od początku źle był zaprojektowany. Nawet jak
> Tu byłeś na właściwym tropie. A więc programiści, czy może ktoś inny?

A co to dla mnie za różnica? Choćby i winna była sprzątaczka, bo wpięła
odkurzacz do UPSa, to mnie - jako końcowego użytkownika - kompletnie to
nie obchodzi.

> Wiesz w ogóle jak obecnie wygląda proces produkcji oprogramowania? Jakie w nim
występują role i kto za co odpowiada?

Jak wyglądają w konkretnym banku - nie wiem.
A ogólnie:
Najpierw Bardzo Ważny Pan stwierdza co chce dostać. On zwykle nie jest
informatykiem i dlatego potem wspomóc go musi jakiś Pan Informatyk, a
właściwie całe stado Panów Informatyków. Np. Jakiś Pan Informatyk
opracowuje specyfikację funkcjonalną. Jakiś Pan informatyk opracowuje
specyfikację infrastuktury - zastanej i potrzebnej. Jakiś Pan Informatyk
prognozuje efekty wdrożenia. Jakiś Pan Informatyk opracowuje harmonogram
wdrożenia. Jakiś Pan Informatyk bierze ołówek i rysuje logiczny model
systemu. Jakiś Pan Informatyk projektuje konkretną realizację modelu.
Jakiś Pan Informatyk projektuje procedurę testową. Jakiś Pań Informatyk
bierze kredki i rysuje gui. No i wreszcie jakiś Pan Informatyk to
koduje... No i gdzieś jeszcze upycha się Panów Informatyków od sieci,
baz danych, grafiki, obliczeń itd...

W zależności od wielkości projektu - każdy z w/w Panów Informatyków może
zostać zaimplementowany za pomocą odpowiednio większej liczby
informatyków fizycznych. (Albo kilku Panów Informatyków z listy może
zmieścić się w jednym fizycznym studencie na pół etatu.) Ołówek i kredki
można zaimplementować za pomocą specjalistycznych narzędzi do rysowania
ładnie wyglądających diagramów i strzałek, co z pewnością wprowadzi w
zachwyt Bardzo Ważnego Pana.

W skrajnym przypadku wszyscy Panowie Informatycy mogą się zmieścić w
jednej osobie - i dlatego programy linuksowe mają z reguły ch*we gui.

--
MiCHA

do góry

Przemyslaw Kwiatkowski <m...@m...waw.pl> writes:

> że on jest zły. I już. I nie ważne jest dla mnie czy to koder źle
> wcisnął Enter, czy projektant narysował o jedną strzałkę za mało.

A przychodzi ci do głowy, że to prezes powiedział "tego nie robimy bo za
drogie. A tych 0.1% klientów ktorzy zauważą niezgodność z regulaminem
obsłużymy reklamacjami"?
KJ

--
http://blogdebart.pl/2009/12/22/mamy-chorych-dzieci/
When I left you, I was but the pupil. Now, I am the master.
-- Darth Vader

do góry

Kamil Jońca pisze:

>> że on jest zły. I już. I nie ważne jest dla mnie czy to koder źle
>> wcisnął Enter, czy projektant narysował o jedną strzałkę za mało.
>
> A przychodzi ci do głowy, że to prezes powiedział "tego nie robimy bo za
> drogie. A tych 0.1% klientów ktorzy zauważą niezgodność z regulaminem
> obsłużymy reklamacjami"?

Jestem przekonany, że prezes nie ma o takim duperelu zielonego pojęcia...

--
MiCHA

do góry

Przemyslaw Kwiatkowski <m...@m...waw.pl> writes:

> Kamil Jońca pisze:
>
>>> że on jest zły. I już. I nie ważne jest dla mnie czy to koder źle
>>> wcisnął Enter, czy projektant narysował o jedną strzałkę za mało.
>>
>> A przychodzi ci do głowy, że to prezes powiedział "tego nie robimy bo za
>> drogie. A tych 0.1% klientów ktorzy zauważą niezgodność z regulaminem
>> obsłużymy reklamacjami"?
>
> Jestem przekonany, że prezes nie ma o takim duperelu zielonego pojęcia...

Że zacytuję "czepiasz się szczegółów". "Prezes" był tu w znaczeniu osoby
podejmującje decyzję.
KJ

--
http://blogdebart.pl/2009/12/22/mamy-chorych-dzieci/
Who goeth a-borrowing goeth a-sorrowing.
-- Thomas Tusser

do góry