On 2010-02-17 20:16, Kamil Jońca wrote:
> "witrak()" <w...@h...com> writes:
>
> [..]
>> Tak się składa, że ja wiem jak się pisze systemy - bankowe również. I
>> wiem - choć może dla większości jest oczywistością, o której nie warto
>> wspominać - że kiepski system transakcyjny w produkcji kosztuje tyle
>
> Tylko we wdrożeniu może kosztować mniej. Wiesz jakie oferty dostał
> Eurobank na swój system
> a) centralny
> b) internetowy?
Nie - skąd ? Ja tam nie pracuję. Natomiast podejrzewam, że gówny
system od początku był przygotowany do podpięcia do niego
internetowego systemu transakcyjnego, bo EB to młody bank, a
zakładał go - nieżyjący już zdaje się - facet co stworzył Lukasa.

> Twierdzenie, że wszyscy oferenci dali taką samą cenę, jest ... śmiałe,
> żeby nie powiedzieć dosadniej.

Ale ja tego nie twierdziłem - to już Twoja rozszerzająca
interpretacja :-)
Ja po prostu trochę ;-) wiem , jak się pisze systemy...

> A skoro nie dali takiej samej, to znaczy,
> że ktoś musiał się zastanowić "czy funkcjonalność A jest nam potrzebna
> na tyle, żeby za nią zapłacić"
> Poza tym, IIRC ichni system był wybierany _zanim_ wprowadzili np. konta
> oszczędnościowe. Jeśli przy wyborze systemu nikt nie pomyślał o
> subtelnościach "który przelew kiedy wykonujemy" to mieli do wyboru:

To nie tak. Jeżeli w ogóle system jest przystosowany do
przetwarzania wielu strumieni transakcji (a tak wynika z tego, co mi
powiedziano w ramach odpowiedzi na moje zarzuty, i ze zdrowego
rozsądku), to albo strumienie te są synchronizowane/sekwencjonowane,
albo nie.
Teraz, jeśli w ramach dowolnego przetwarzania (powiedzmy - na
początek dnia) wykonać trzeba zlecenia z pewnych klas w określonej
sekwencji (np. najpierw wszystkie przelewy z zapadających lokat,
potem "zwykłe" przelewy), to mechanizm rozróżniania zleceń z tych
klas i ich sekwencjonowania musi być wbudowany w system od początku.
[Nie jest możliwe, aby tego nie przewidziano w najprostszej nawet
wersji systemu w EB.]
Jeżeli taki (poprawnie zbudowany) mechanizm już istnieje, to
rozbudowanie go do postaci, w której może działać dla trzech, czy
więcej klas zleceń (powiedzmy, lokat, przelewów wewn. i przel.
zewn.) nie nastręcza trudności.
[To trochę dlatego, że programiści znają tylko cztery liczebniki:
"zero", "jeden", "dwa" i "wiele" :-) ].
Natomiast oczywiście czym innym jest wprowadzenie odpowiedniej
synchronizacji *wielu* strumieni w warunkach wielowątkowości
przetwarzania, zwłaszcza gdy obliczenia idą na klastrze, złożonym z
wielu komputerów. Nie wiem czy tak to jest zrobione w EB. [Natomiast
wiem, że system mBanku działa na takim właśnie wielokomputerowym
klastrze.]
I właśnie od tego, czy to zrobiono dobrze, średnio, czy źle, może
zależeć istnienie mnóstwa efektów, z których część zapewne
obserwujemy. Ewidentnie EB nad systemem pracuje, bo co jakiś czas
coś zmienia się także i w widocznej dla nas powłoce (ST). Niemniej
część działań (gorączkowych...) musiało nastąpić w reakcji na wzrost
obciążenia (pamiętasz, jak system "mulił", gdy wprowadzono po 15
kont oszczędnościowych?). Podejrzewam, że przy zmianach
wprowadzonych przy tej okazji, wprowadzono też jakieś usterki. I nie
spróbowano ich *całkowicie* wyplenić, zgodnie z zasadą, że jeśli
podstawowe funkcje systemu działają dobrze, drobne usterki - nie
ograniczające zasadniczej funkcjonalności systemu - można usuwać bez
pośpiechu.

> a) zaakceptować kolejność, jaką narzucił im system księgowy (i
> poinformować o tym klientów)
> b) wydać kasę na napisanie softu wymuszającego taką, a nie inną
> kolejność.
> Jak myślisz, co wybrali?

Jak zapewne domyślasz się z tego, co napisałem powyżej, odpowiedź
brzmi: i jedno i drugie - najpierw (a), potem (b).

Dla mnie rzecz leży głownie w tym, że oni wszystko
poprawiają/ulepszają strasznie powoli, bo nic/nikt ich właściwie nie
pogania: formalnie są w porządku (oprócz pokazywania nieprawdziwych
sald i historii rachunków), mają z tego dodatkowe profity, a jeszcze
jak jeden czy drugi narzeka na nich na pbb, to zaraz ktoś się za
nimi ujmie i wytłumaczy, żeby nie powiedzieć: pochwali ;-)


witrak()