Temat: Linq - pytanie

Witam,
W pewnym etapie życia pomyślałem o poznaniu rozwiązania LINQ to SQL (na chwilę obecną moja wiedza jest bardzo ograniczona w tym zakresie, do tej pory wszystko budowałem "na piechotę").

O ile samo rozwiązanie wygląda na prawdę przyjemnie, nie znam jego mechanizmów działania (mówię o budowaniu struktur danych).

Planuję stworzyć aplikację ("gruby klient"), która będzie łączyła się z serwerem DB. Stworzę dwa środowiska: dev i prod (2 różne źródła danych).

Co może się stać, jeśli produkcyjna baza danych nie będzie zsynchronizowana z testową (np inne kolumny, nowe/brak tabel, inne procedury, etc)?
Czy sama zmiana źródła danych powinna zadziałać, czy może coś się posypać?
Czy rozwiązanie Linq nadaje się do użycia przy takim rozwiązaniu? Może są jakieś alternatywy :)

Generalnie zależy mi na otrzymaniu gotowych klas z odpowiednimi metodami, w oparciu o strukturę bazy danych; może znacie jakiś "generator kodu", który z automatu zbuduje mi odpowiednie klasy na podstawie założonej struktury DB?

Temat: Linq - pytanie

LINQ 2 SQL jest głównie pod SQL Server (istnieje projekt dblinq pozwalający korzystać z innych silników) i oferuje uproszczone mapowanie. Ale może Ci to wystarczyć (mnie kiedyś wystarczał nawet mikro ORM z ServiceStacka). Wszystko zależy od tego, co chcesz osiągnąć i jakie wzorce dostępu do danych wybierzesz. L2S jest fajny, jeśli chcesz "wyklikać" aplikację.

Rozważ jednak także inne, solidne ORMy, jak Entity Framework i NHibernate. Można w nich korzystać z LINQ tak w notacji "SQL"owej jak i "lambdami" (metody rozszerzające dla interfejsu IQueryable i IEnumerable). Oba oferują podejście code-first (generuje się baza) i database-first (są narzędzia do generowania klas, a napisanie swojego to proste zadanie). NH oferuje sporo dodatków, jak interceptory, wiele strategii generowania kluczy (w tym własne), możliwość wykonywania własnego kodu SQL podczas tworzenia bazy, wiele sposobów odpytywania (HQL, Criteria, QueryOver, LINQ), logery etc. W najprostszym przypadku mapowanie odbędzie się przez konwencje nazw, trzeba tylko zadbać żeby w bazie i klasach były odpowiadajace sobie tabele i kolumny.

Są to na pewno bardziej złożone ORMy. NH nie ma żadnych "designerów" (mapowań dokonuje się w pliku XML, w kodzie - FluentNHibernate, albo automatycznie), choć są do niego różne narzędzia open-source'owe. Z drugiej strony brak "automatów" zapewnia dużą kontrolę nad tym, co się dzieje, co daje szerokie pole do manewru, gdy rzeczywistość okaże się bardziej skomplikowana. Wiesz, co się dzieje. Ich konfiguracja nie jest znowu aż tak straszna (AppConfig lub w kodzie lub jedno + drugie). Znajdziesz do nich w sieci sporo książek (PDF), które później możesz kupić i łyknąć sporą dawkę wiedzy o ORMach. Mnóstwo wiedzy znajdziesz także w sieci.

PS: polecam zastanowienie się, czy na pewno podejście "od bazy danych do kodu" będzie OK. Osobiście preferuję "code-first", chyba, że muszę się "wpiąć" w gotową bazę. Odwykłem już od podejścia "database-centric"...

Co do synchronizacji to zawsze jest jakiś problem, zwłaszcza, gdy baza jest już wypełniona i nie można jej "dropnać". W NH wystarczy poprawić mapowanie i nie trzeba ruszać danych. W EF - podobnie, o ile usunie się z bazy jego tabelę przechowującą wersję modelu (hash) - inaczej poleci wyjątek. EF automatycznie sprawdza zgodność bazy z kodem, co bywa pomocne na początku, gdy powstają pierwsze przybliżenia i bazę się ciągle "drop/recreate/fill", ale przeszkadza gdy już masz w tej bazie dane. W L2S masz z kolei pliki EDMX/DBML, które trzeba będzie zaktualizować.

Co do zachowania ORMa to różnie bywa. Jeśli odwołasz się do properta, dla którego nie ma odpowiadającej kolumny, dostaniesz wyjątek. W drugą stronę to nie problem (z wyjątkiem EF i jego wersjonowania modeli).Ten post został edytowany przez Autora dnia 28.11.13 o godzinie 13:38

Temat: Linq - pytanie

Dziękuję za szczegółowe wskazówki dot. technologii, przejrzę i sprawdzę, co najlepiej mi odpowiada.

Sama idea skorzystania z tego typu narzędzi, to poniekąd chwilowe "lenistwo" - projekt jest na prawdę luźny, elementów DB do obsłużenia całkiem sporo, a założony czas iście krótki :) Większość rzeczy mam już i tak oprogramowanych z poziomu DB.

Adrian O.:
PS: polecam zastanowienie się, czy na pewno podejście "od bazy danych do kodu" będzie OK. Osobiście preferuję "code-first", chyba, że muszę się "wpiąć" w gotową bazę. Odwykłem już od podejścia "database-centric"...

Tutaj wg mnie wszystko zależy od wielkości projektu.
Na początku również trzymałem się dość kurczowo code-first'a (budując bardzo minimalistycznie bazę danych, często bez wnikania w CRUD'y nawet :) ).
Problem pojawia się w chwili, kiedy budowany jest spory system, często pojawiają się mniejsze lub większe zmiany. Jeśli oprzemy 3/4 funkcjonalności o aplikację, często można zyskać odrobinę na wydajności. Niestety pojawienie się jakiejkolwiek modyfikacji wymaga kompilacji, co często przy środowiskach o wysokim SLA generuje nieprzyjemną konieczność zostawania po pracy z powodu wgrania aktualizacji i/lub testów :) Ponadto Code-First w niektórych przypadkach może skutkować nie do końca przemyślanym projektem bazy danych, lub późniejszą modyfikacją samego kodu (dodatkowy czas=koszt), a już prawdziwym złem niedobrym (czasami niestety stosowanym) jest tworzenie zapytań SQL bezpośrednio po stronie aplikacji... Zdarzają się również modyfikacje systemu, których założenia trzeba po krótkim czasie modyfikować, czasami wracając do stanu sprzed zmiany (niezależnie od tego, jak dobrze wspomniane założenia zostaną określone).

Przy DB-first, jeśli mówimy o aplikacjach bardziej bazodanowych niż coś-mielących-potworach algorytmicznych :), zyskujemy pole manewru w postaci bezpośredniej modyfikacji db, szybkiego wdrażania nowych funkcjonalności (oczywiście tych, które można rozwiązać po stronie bazy danych), oraz łatwiejsze możliwości tuningu db. Jest pełno przydatnych narzędzi dla projektantów, które ułatwiają wdrożenie baz danych "w zgodzie ze sztuką" (np SSMS Tools).
Nawet czasami spotkałem się kilkukrotnie z przechowywaniem odpowiednich procedur wraz z wymaganymi parametrami bezpośrednio w bazie - może wydawać się dziwne, ale często jest to na prawdę fajne rozwiązanie z punktu widzenia późniejszej obsługi i administracji systemem.

Oczywiście nie krytykuję code-first, nie faworyzuję również db-first. Wszystko zależy od potrzeby: jeśli aplikacja/system, tudzież baza danych (jeśli istnieje) będzie modyfikowany raz na ruski rok, CF spisze się rewelacyjnie. Z mojego, może nie aż tak wieloletniego doświadczenia wiem jednak, że stworzony w ciągu około roku system będzie jeszcze przez ładnych kilka lat modyfikowany: dostosowywany, rozbudowywany, optymalizowany pod względem wydajności, etc :) W takim wariancie db-first pozwoli zaoszczędzić czasu, a poprawnie stworzony model sprawi, że stworzona aplikacja będzie niemal bezobsługowa dla programisty (w skrajnych przypadkach, przy hardkorowym podejściu do db-first, aplikacja może stać się wręcz "terminalem" do połączenia z bazą) :)

Temat: Linq - pytanie

Emil S.:
Sama idea skorzystania z tego typu narzędzi, to poniekąd chwilowe "lenistwo" - projekt jest na prawdę luźny, elementów DB do obsłużenia całkiem sporo, a założony czas iście krótki :) Większość rzeczy mam już i tak oprogramowanych z poziomu DB.

W dzisiejszych czasach ORM to niekoniecznie lenistwo :) Oczywiście wiele zależy od dziedziny i zagadnienia, np. aplikacje bankowe w dużej mierze do dziś oparte są niemal w całości o bazę i procedury, jednak systemy klasy ERP (i nie tylko) coraz częściej buduje się w oparciu o CF. Oczywiście wszystko w granicach rozsądku. Myślę, że to zagadnienie na osobny wątek, jakich zresztą wiele w sieci, nawet tutaj, na GL zwłaszcza w grupie "Projektowanie i programowanie obiektowe, gdzie zresztą polecam się zapisać, bo zdarzają się ciekawe dyskusje :)

Tutaj wg mnie wszystko zależy od wielkości projektu.

...a także wymagań jego podatności na zmiany.

Na początku również trzymałem się dość kurczowo code-first'a (budując bardzo minimalistycznie bazę danych, często bez wnikania w CRUD'y nawet :) ).

CF nie wymusza "minimalistycznej bazy". Akurat zakończyłem etap projektowania dużego systemu informatyczno-medycznego oraz "migracji" innego, dość wiekowego, opartego w całości o bazę danych (Oracle Forms) na .NETową aplikację RESTową. Model danych okazał się, jak w to medycynie, znacznie rozbudowany, w dodatku zachodziła konieczność integracji z wieloma istniejącymi rozwiązaniami w oparciu o widoki, kolejki integracyjne i webserwisy.

Czekała mnie długa ale i ciekawa misja zmiany podejścia zespołu bazodanowców od ERD do UML (ale nie na zasadzie "klasa to tabela"). W ogóle zapomnieliśmy na etapie projektowania o "bazie danych", ponieważ okazało się, ze źródeł danych będzie więcej, w tym usługi innych systemów. Było to bardzo pouczające, ponieważ wymagało całkowitej zmiany podejścia do projektowania i wykonania oprogramowania. Oczywiście niedogmatycznie i nie ze stanowiska "tak, bo tak", tylko obie strony starały się połączyć istotne informacje.

Wzorzec repozytorium, unikanie anemicznej dziedziny, CQRS, wykorzystanie widoków i dużo wiedzy na temat ORM (bo to nie panaceum, tylko jakaś tam próba tłumaczenia modelu relacyjnego na obiektowy - choć słowo "obiektowy" to tutaj znaczne nadużycie), śledzenie tego, co on tam produkuje i konsultowanie tego z DBA. A wszystko z myślą o tym, że klientowi zależy na szybkim działaniu i podatności na modyfikacje.

Problem pojawia się w chwili, kiedy budowany jest spory system, często pojawiają się mniejsze lub większe zmiany. Jeśli oprzemy 3/4 funkcjonalności o aplikację, często można zyskać odrobinę na wydajności.

Przede wszystkim na elastyczności. Jednak pamiętajmy, że baza danych jest stworzona do ich szybkiego przetwarzania. Czasem procedura składowana i widok to "wyższa konieczność", której nie trzeba się bać.

Niestety pojawienie się jakiejkolwiek modyfikacji wymaga kompilacji, co często przy środowiskach o wysokim SLA generuje nieprzyjemną konieczność zostawania po pracy z powodu wgrania aktualizacji i/lub testów :)

Tak, masz rację. I chociaż staram się ewangelizować ku podejściu "najpierw model, z którego zostanie wygenerowane "data storage"", to sam z tego korzystałem. Np. kiedyś pisałem w SQLu procedury do analizy statystycznej (analiza wariancji, regresji, testy hipotez, statystyki opisowe) - wgranie paczki procedur na serwer z poziomu tylko konsoli SQL, możliwość przetransportowania tego wszystkiego wraz z danymi w jednym "dumpie", a także możliwość podmiany procedur bez wstrzymywania systemu przetwarzania bez jego zatrzymywania było czymś, co zapewniło mi spokojny sen i przełożyło się na finanse.

Czyli - wszystko ma swoje miejsce i zastosowanie.

Code-First w niektórych przypadkach może skutkować nie do końca przemyślanym projektem bazy danych, lub późniejszą

Bo w CF o bazie danych się praktycznie nie myśli. A przynajmniej nie projektant i nie programista. Kiedyś jednak do tej bazy dochodzi i wtedy ważne jest, by w projekcie współpracowali doświadczeni DBA, którzy niektóre aspekty przetwarzania zaprojektują optymalnie w SQL i wystawią odpowiedni widok lub procedurę, zamapowaną na obiekt read-only. Pomaga tutaj wzorzec CQRS, który nie jest oczywiście niczym nowym.

Czasem jednak okazuje się, że źródła danych są tak różne (i to nie fikcja, pracuję przy takim projekcie), że repozytorium obiektów staje się koniecznością. Innymi słowy uniezależniasz się już nie tylko od konkretnego silnika bazy danych, od koncepcji relacyjnej bazy danych, ale nawet od ORM. Obiekt wówczas nie wie, skąd pochodzi i gdzie zostanie utrwalony - może to być baza, może być webserwis, może być plik bądź wysyłka portem szeregowym do urządzenia. W systemie, w którym nie ma anemicznej dziedziny mamy po prostu agregaty, współpracujące ze sobą obiekty, które po prostu utrwalają swój stan (wzorzec active records). Mogą dochodzić nowe atrybuty, nowe powiązania, a baza ma być na to niewrażliwa. A są także inne,bardziej egzotyczne modele, np. wzorzec "event sourcing", gdzie stan obiektu otrzymuje się przez odtworzenie serii "zdarzeń".

Da się to wszystko osiągnąć przez odpowiednie zaprojektowanie, wykorzystanie koncepcji dokumentów (np. XML, JSON), baz NoSQL. Także podejście RESTowe, gdzie staramy się znaleźć i wydzielić jak najbardziej atomowe, minimalnie skojarzone ze sobą (a najlepiej autonomiczne) usługi (widzimy tutaj rzecz znaną z OOP). Wtedy zmiana dotyczy tylko tej usługi bez grzebania i rekompilacji reszty systemu. A najlepiej - polega na dołożeniu kolejnego "klocka" do reszty bez ich ruszania (interfejsy, model "pluginów").

zapytań SQL bezpośrednio po stronie aplikacji...

Święte słowa. Zdarza mi się to tylko w "toolach", w prostych modułach, gdzie z bazy muszę pobrać "config" w postaci SELECT * FROM, albo gdzie nie chcę dodatkowego narzutu w postaci konfiguracji i utrzymania, ponieważ mam ledwie kilka tabel. Wtedy ADO.NET sprawuje się bardzo dobrze.

Przy DB-first, jeśli mówimy o aplikacjach bardziej bazodanowych niż coś-mielących-potworach algorytmicznych :), zyskujemy pole manewru w postaci bezpośredniej modyfikacji db, szybkiego wdrażania nowych funkcjonalności (oczywiście tych, które można rozwiązać po stronie bazy danych), oraz łatwiejsze

Masz rację. Niestety, po obu stronach (DBF, CF) są ludzie, dla których istnieje tylko jeden świat. Jeden całe życie tworzy systemy przetwarzania w SQL i na myśl o wyjściu poza bazę dostaje gęsiej skórki ("wszystko zrobię w formsach"), drugi słysząc "varchar" dostaje apopleksji.

Oczywiście nie krytykuję code-first, nie faworyzuję również db-first. Wszystko zależy od potrzeby: jeśli aplikacja/system, tudzież baza danych (jeśli istnieje) będzie modyfikowany raz na ruski rok, CF spisze się rewelacyjnie. Z mojego, może nie aż tak wieloletniego doświadczenia wiem jednak, że stworzony w ciągu około roku system będzie jeszcze przez ładnych kilka lat modyfikowany: dostosowywany, rozbudowywany, optymalizowany pod względem wydajności, etc :) W takim wariancie db-first pozwoli zaoszczędzić czasu, a poprawnie stworzony model sprawi, że stworzona aplikacja będzie niemal bezobsługowa dla programisty

Tutaj mamy nieco różne doświadczenia. Pracuję przy systemach info-medycznych, gdzie zmiany są częste i liczne. Raz, że zmiany prawne, dwa, że rozwój aplikacji, trzy, że współpraca z innymi systemami. Coraz częściej zaczynamy refaktoryzować kod pod DDD, coraz częściej zaczynamy myśleć domenowo, denormalizować.
Poprawnie stworzony model to odwzorowanie rzeczywistego modelu dziedzinowego. A to coś więcej, niż "relacyjne bazy danych".

Nie wspomniałem tu jeszcze o aspekcie wdrożeń - to temat na kolejną długą i gorącą dyskusję. Jako wieloletni wdrożeniowiec bardzo ceniłem sobie możliwość "grzebania w bazie". W aplikacji, gdzie większość logiki jest w kodzie ciężko uzyskać (albo jest to niemożliwe) potrzebny doraźnie efekt zmieniając coś w bazie. A czasem, w szpitalu, gdzie zainstały problem był "gardłowy", nie można było czekać na poprawki w kodzie, build, testy, release - wtedy możliwość dużego wpływania na aplikację przez modyfikowanie DB był tym, co ratowało skórę firmie, a pacjentom nawet życie.

Bez ściemy - kiedyś szlag trafił moduł do obsługi laboratorium analitycznego, traf chciał, że na stanowisku do gazometrii o 1 w nocy, pacjenci leżą na stołach operacyjnych i na OIOMie, anestezjolog potrzebuje pilnej informacji o równowadze kwasowo-zasadowej krwi. Nie musze mówić, czym to sie mogło skończyć. Udało mi się z pomocą diagnosty przetworzyć odebrane z aparatury wyniki i "przepchnąć" do ADT.

(w skrajnych przypadkach, przy hardkorowym podejściu do db-first, aplikacja może stać się wręcz "terminalem" do połączenia z bazą) :)

Podobnie, jak w przypadku lekki klient + webserwis + "źródło danych" :)

Ha, zresztą, przecież w SQLu można by tworzyć HTMLa (kiedyś zresztą czytałem i tworzyłem
w SQL komunikaty XML do "Diagnostyki" i HL7) i postawić webserwis (SQL Server, Oracle) i mamy gotową aplikację ;)

Ufff...Ten post został edytowany przez Autora dnia 28.11.13 o godzinie 18:35

Temat: Linq - pytanie

Adrian O.:
Bez ściemy - kiedyś szlag trafił moduł do obsługi laboratorium analitycznego, traf chciał, że na stanowisku do gazometrii o 1 w nocy, pacjenci leżą na stołach operacyjnych i na OIOMie, anestezjolog potrzebuje pilnej informacji o równowadze kwasowo-zasadowej krwi. Nie musze mówić, czym to sie mogło skończyć. Udało mi się z pomocą diagnosty przetworzyć odebrane z aparatury wyniki i "przepchnąć" do ADT.

Dammit, czytam z zaciekawieniem - a tu taki cliffhanger ;) Prawie jak Dr House :)

Tak przy okazji, to aż tak niskopoziomowe APi? W sensie na styku sygnałów maszyn diagnostycznych?

Temat: Linq - pytanie

Tomasz M.:
Dammit, czytam z zaciekawieniem - a tu taki cliffhanger ;) Prawie jak Dr House :)

Bywały lepsze historie. Nocne dyżury w laboratorium przez ponad rok obfitują w ekscytujące momenty ;)

Tak przy okazji, to aż tak niskopoziomowe APi? W sensie na styku sygnałów maszyn diagnostycznych?

Nie, w tym przypadku nie. Aparatura w laboratorium analitycznym zwykle "gada" po HL7. Między aparaturą a bazą danych stały komunikatory, odbierające/nadające HL7 i wrzucające/odczytujace informacje z bazy. Jednak od odebrania porcji wyników (z powtórkami, rozcieńczeniami) do ich wysłania na oddział było jeszcze kilka kroków pośrednich. Z kolei podczas jednej integracji w innym labie leciał wyjątek na generowaniu XMLa z wynikami. Zanim chłopaki naprawili soft, trzeba się było wpiąć triggerem na bazę kolejki wyników i generować XML samemu i wrzucać po dblinku gdzie trzeba. Na 2 dni uratowało tyłki wielu ludziom :) Przytaczam zawsze te historie tym, którzy twierdza, że wdrożeniowiec ma być taką "tresowaną małpką", która ma tylko przeczytać "how to" od produkcji i jak automacik wykonać od deski do deski "setup.exe, next, next, next, ok". Nie musi znać SQL i od bazy powinna się trzymać z daleka, dlatego można pewne zagadnienia olać (np. generowanie komentarzy do tabel i kolumn). Może i czasem tak, ale w każdym razie w laboratorium takie umiejętności naprawdę się przydają, zwłaszcza, gdy rzeczywistość jest "cwańsza" od projektantów/programistów, którzy uważają, że "taka a taka sytuacja nie może mieć miejsca i na pewno mieć nie będzie". :)

Przeprowadzałem też w pewnym dużym NZOZie migrację 50GB bazy danych pewnego systemu info-medycznego. Był do tego przygotowany "updater", który jednak poległ (jak sie potem okazało, było 6 miejsc). Trzeba było ze specjalnego skryptu wyciągać polecenia modyfikacji bazy danych (pewien metajęzyk, nie czysty SQL), tłumaczyć na SQL i wykonać, omijając bugi w sofcie (w tym np. problem z odczytem > 64k z kolumny XmlType na starszym Oraclu). Niejeden "szpitalny" wdrożeniowiec może takie przypadki mnożyć. I chociaż to jest offtop (wątek dotyczy LINQ 2 SQL i ORMów), to dotyczy jednak kwestii podejścia do baz danych podczas projektowania systemów.Ten post został edytowany przez Autora dnia 29.11.13 o godzinie 11:50

Temat: Linq - pytanie

Adrian Olszewski:
Nie wspomniałem tu jeszcze o aspekcie wdrożeń - to temat na kolejną długą i gorącą dyskusję. Jako wieloletni wdrożeniowiec bardzo ceniłem sobie możliwość "grzebania w bazie". W aplikacji, gdzie większość logiki jest w kodzie ciężko uzyskać (albo jest to niemożliwe) potrzebny doraźnie efekt zmieniając coś w bazie. A czasem, w szpitalu, gdzie zainstały problem był "gardłowy", nie można było czekać na poprawki w kodzie, build, testy, release - wtedy możliwość dużego wpływania na aplikację przez modyfikowanie DB był tym, co ratowało skórę firmie, a pacjentom nawet życie.

Bez ściemy - kiedyś szlag trafił moduł do obsługi laboratorium analitycznego, traf chciał, że na stanowisku do gazometrii o 1 w nocy, pacjenci leżą na stołach operacyjnych i na OIOMie, anestezjolog potrzebuje pilnej informacji o równowadze kwasowo-zasadowej krwi. Nie musze mówić, czym to sie mogło skończyć. Udało mi się z pomocą diagnosty przetworzyć odebrane z aparatury wyniki i "przepchnąć" do ADT.

Hmm .. gratuluję umiejętności, ale ta historia przeraża. To po co wymyślono robienie kopii zapasowych, budowę systemów redundantnych (mirror, duplex), procedury, itd., itp. . Tam gdzie życie ludzkie jest zagrożone czy nie powinny obowiązywać zaostrzone reguły na budowę bezpiecznych systemów działających w czasie rzeczywistym (hardware + software + zarządzanie) ?

Że niby jest jak jest z zarządzaniem oraz finansowaniem służby zdrowia i powinniśmy się z tą sytuacją pogodzić , a przynajmniej nie dziwić? Bo niby skoro w przetargach do budżetu ma wygrać najtańsza oferta, to wszystko jest OK jak firmy składają takie a nie inne oferty i jest to zrozumiałe bo inaczej nie zarobią? :-(

Jakie warunki winny być spełnione (kiedy choćby w teorii) aby przeciąć to błędne koło?

Adrian Olszewski:
Aparatura w laboratorium analitycznym zwykle "gada" po HL7. Między aparaturą a bazą danych stały komunikatory, odbierające/nadające HL7 i wrzucające/odczytujace informacje z bazy. Jednak od odebrania porcji wyników (z powtórkami, rozcieńczeniami) do ich wysłania na oddział było jeszcze kilka kroków pośrednich. Z kolei podczas jednej integracji w innym labie leciał wyjątek na generowaniu XMLa z wynikami. Zanim chłopaki naprawili soft, trzeba się było wpiąć triggerem na bazę kolejki wyników i generować XML samemu i wrzucać po dblinku gdzie trzeba. Na 2 dni uratowało tyłki wielu ludziom :) Przytaczam zawsze te historie tym, którzy twierdza, że wdrożeniowiec ma być taką "tresowaną małpką", która ma tylko przeczytać "how to" od produkcji i jak automacik wykonać od deski do deski "setup.exe, next, next, next, ok". Nie musi znać SQL i od bazy powinna się trzymać z daleka, dlatego można pewne zagadnienia olać (np. generowanie komentarzy do tabel i kolumn). Może i czasem tak, ale w każdym razie w laboratorium takie umiejętności naprawdę się przydają, zwłaszcza, gdy rzeczywistość jest "cwańsza" od projektantów/programistów, którzy uważają, że "taka a taka sytuacja nie może mieć miejsca i na pewno mieć nie będzie". :)

Ale czy to wszystko razem wzięte ma oznaczać, że doświadczenia inżynierii oprogramowania w zakresie projektowania, najlepszych praktyk, itd. dobrze jak nie są przestrzegane, bo ich i tak nie sposób wyegzekwować, a system dobrze że tworzony jest po bałaganiarsku bo przynajmniej są furtki boczne, które pozwalają na ratowanie życia? :-( Coś tu za dużo sprzeczności. :-(

Temat: Linq - pytanie

Marek K.:
Hmm .. gratuluję umiejętności, ale ta historia przeraża. To po co wymyślono robienie kopii zapasowych, budowę systemów redundantnych (mirror, duplex), procedury, itd., itp. .

Ale jak tutaj miały pomóc procedury kopii zapasowych i redundancja? Był błąd w aplikacji (zresztą już bardzo wiekowej :) ). Co miałem zrobić jako wdrożeniowiec - stać i patrzeć, jak się wszystko sypie, ordynator grozi (słusznie) prokuratorem, pół szpitala jest postawione na nogi, życie pacjenta jest zagrożone, jest środek nocy? Skontaktowałem się natychmiast z zarządem zatrudniającej mnie firmy - podwykonawcy (wdrożeniowca) producenta. Ten z kolei podjął wespół z ordynatorem i kierownikiem laboratorium decyzję - "chłopie ratuj wszelkimi siłami, póki nie zostanie naprawione". W takich sytuacjach liczą się minuty, chociaż każdy przyzna, że taka sytuacja mieć miejsca nie powinna.

Posłużę się tutaj analogią do pilotowania samolotu. Odpowiedzialność jest nieporównywalnie większa - życie kilkudziesięciu osób, a w skrajnym przypadku (upadek samolotu na zakład chemiczny, osiedle, elektrownię jądrową) - setek a nawet tysięcy.

Są zatem skrupulatnie opracowane procedury, dwaj piloci, wieża kontroli lotów, telemetryczna kontrola parametrów lotu itd itp. Co jakiś czas (na szczęście rzadko!) słyszymy jednak, że fatalny zbieg okoliczności sprawił, że samolot uratował "zimnokrwisty" pasażer mający nikłe doświadczenie z aeroklubu, który podjął ryzyko (może nawet nie zdając sobie sprawy, jaka odpowiedzialność na nim spoczywa) i dzięki pomocy wieży kontrolnej (i wielkiemu łutowi szcześcia) wylądował. Nikt z nas nie zakłada, że samolot, którym lecimy i nasze życie może w pewnym momencie zależeć od "pilota-amatora". Nie ma prawa zakładać tego także twórca maszyny. Ma opracować wszystko zgodnie z najlepszymi wytycznymi.

Samolot ma być pilotowany przez osoby z kompetencjami doświadczonego pilota (określona liczba godzin nalotu, szkolenia, testy kompetencji itp. i zgodnie z przeznaczeniem - kropka. A jednak ktoś tam, wśród osób decyzyjnych miał to na uwadze, umieszczając w kokpicie książki procedur (nie tylko dla doświadczonych pilotów!) i szkoląc kontrolerów na wypadek sytuacji, gdyby samolotem musiała pokierować osoba, która normalnie nie ma nawet prawa znaleźć się w przedziale pilotów.

Producent samolotu, przewoźnik, obsługa lotniska i wreszcie prawodawca, nauczeni doświadczeniem, pamiętali o takiej ewentualności. Oczywiście nie z myślą, że ochroni to bezwzględnie przed wielkim "bum", zwiększa jednak nieco szanse na przeżycie. Podobnie, jak poduszki powietrzne w samochodzie.

Co nie zmienia faktu, że systemy kontroli bezpieczeństwa lotu są traktowane (a przynajmniej tak chcielibyśmy wierzyć) priorytetowo i bardzo rozbudowane.

Tam gdzie życie ludzkie jest zagrożone czy nie powinny obowiązywać zaostrzone reguły na budowę bezpiecznych systemów działających w czasie rzeczywistym (hardware + software + zarządzanie) ?

Powinny.

Tu nie chodzi o to, aby stosować podejście "system gotowy na najgorsze, wdrożeniowiec napisze parę update'ów i luz, dlatego olejmy zabezpieczenia", lecz by podczas jego produkcji mieć na uwadze TAKŻE to, że może dojść do sytuacji krytycznej podczas wdrożenia.

Manager, który nie bierze tego pod uwagę - jest na dobrej drodze do kłopotów. A tu nie tylko o jego "cztery litery" chodzi.

Że niby jest jak jest z zarządzaniem oraz finansowaniem służby zdrowia i powinniśmy się z tą sytuacją pogodzić , a przynajmniej nie dziwić? Bo niby skoro w przetargach do budżetu ma wygrać najtańsza oferta, to wszystko jest OK jak firmy składają takie a nie inne oferty i jest to zrozumiałe bo inaczej nie zarobią? :-(

Nie. Abyśmy MY tworzyli systemy, które są "serwisowalne" w sytuacjach gardłowych, a takich jest multum właśnie m.in. w laboratorium analitycznym dużej placówki. Abyśmy byli świadomi pewnych potencjalnych problemów. I tu już nie chodzi o sytuację tak krytyczną, jak opisana, ale także o nieudane update'y i migracje, czy właśnie bugi, takie, jak wspomniana awaria generowania zleceń do laboratorium. Dość spędziłem weekendów śpiąc po 2 godziny na krześle w serwerowni i dłubiąc przy systemach, przy których pracował sztab doświadczonych ludzi, którzy niejedno już w życiu widzieli i projektowali, a jednak czegoś nie przewidzieli (chociażby przyjęcie próbek z materiałem biologicznym dwóch pacjetów, oklejonych barkodami "na krzyż").

Czynnik ludzki można zminimalizować, ale nie da się go wyrugować. Cytując mojego fizyka ze szkoły: "Prawa Murphy'ego są nieubłagane".

Ale czy to wszystko razem wzięte ma oznaczać, że doświadczenia inżynierii oprogramowania w zakresie projektowania, najlepszych praktyk, itd. dobrze jak nie są przestrzegane, bo ich i tak nie sposób wyegzekwować, a system dobrze że tworzony jest po bałaganiarsku bo przynajmniej są furtki boczne, które pozwalają na ratowanie życia? :-( Coś tu za dużo sprzeczności. :-(

Przecież tu nie ma żadnej sprzeczności i nigdzie nie napisałem nawet słowem, że "dobrze, jak coś nie jest przestrzegane". Natomiast, aby dyskusja była kompletna i prezentowała zagadnienie szerzej, dodałem, że solidne doświadczenie wdrożeniowca zdobyte w tak "nieprzyjaznym środowisku" jakim są duże laboratoria i placówki medyczne (tak państwowe, jak i prywatne) nakazuje mi mieć na uwadze także TE zagadnienia. Poruszyłem zagadnienie projektowania typu "database centric", które IMHO bardziej pozwala na takie wolty, chociaż sam staram się obecnie pracować w podejściu "od modelu do bazy".

Nie oznacza to przyzwolenia na bałaganiarstwo, lecz skłania do zastanowienia, jak projektowany system zachowa się w sytuacjach, w których pojawia się nieoczekiwanie błąd (techniczny, czynnik ludzki) mogący doprowadzić do tragicznych następstw. I na tym m.in. polega rola projektanta oprogramowania. Nie należy tego mylić z "olewaniem zagrożenia", a wprost przeciwnie.

Na koniec nadmienię jeszcze, że kwestie bezpieczeństwa i jakości systemów informacyjnych dla służby zdrowia są dla mnie o tyle ważne, że sam jestem częstym pacjentem. I zdaję sobie doskonale sprawę z różnych hmmm... "nieprawidłowości", jakie tam mogą mieć miejsce. I że sam mogę paść ich ofiarą.Ten post został edytowany przez Autora dnia 03.12.13 o godzinie 13:28

Temat: Linq - pytanie

Bardzo ciekawa dyskusja jako offtopic :D

Od siebie dodam tylko że jednak kryterium ceny ma znaczenie.

W pełni zgadzając się z sugestiami Adriana myślę że tutaj mamy spot czynników o różnej wadze:

1. Niska cena = niski czas lub brak (!) testów.
2. Niska świadomość zamawiającego. Pamiętam z dawnych czasów jak mój były szef pracował w firmie świadczącej usługi dzwonków na telefon. Takich co grają jak się do kogoś dzwoni. Test odbiorcy polegał na tym że były 3(!) różne niezależne linie internetowe do operatora i testujący słuchając muzyki wyciągał po kolei wtyczki (lub wkładał). Jeżeli muzyka przestała grać to zespół musiał wrócić i poprawić. O jakich testach myśli zamawiający w ZOZ ?
3. Niska świadomość zarządzających projektami systemów - takie doświadczenie jak Adriana "ustawia" kierownika na właściwej ścieżce. Ale jeżeli zarząd nie jest również "ustawiony" to szkoda takiego gościa.
4. Brak globalnej świadomości techniczno-informatycznej. Komputer dla wielu to taka czarna skrzynka - ma działać. Zwykle działa. Mało kto w NFZ/Ministerstwie zastanawia się jak bardzo jesteśmy zależni od systemów IT. I jak bardzo to się zwiększa.

I niestety/stety to jest również nasza praca - edukować, edukować, edukować. I postulować nowe rozwiązania. Dobre praktyki. Wymagać od zamawiających aby projekty spełniały te dobre praktyki (np. odporność na utratę połączenia na każdym etapie przekazywania danych).

Adrian - dzięki za fajny post.

Pozdrawiam,
MWW

Temat: Linq - pytanie

Mikołaj W.:
Bardzo ciekawa dyskusja jako offtopic :D

1. Niska cena = niski czas lub brak (!) testów.

Z tym nie do końca mogę się zgodzić, aczkolwiek wszystko zależy od podejścia firmy i zespołu (zarówno IT, jak i użytkowników), oraz samego rodzaju wykonywanych testów.

1. Analiza zagadnienia (faza analizy/projektu) - na tym etapie należy znaleźć możliwie jak najwięcej błędów. Wykonanie tego etapu zależy w dużej mierze od klienta, a projektant powinien pomóc w ich odnalezieniu. Kluczowe zatem jest częste zadanie pytań "a co jeśli...", "czy będzie miało to wpływ na..." oraz innych z kategorii -> pozwoli to wyeliminować część późniejszych nieprzewidzianych niespodzianek, często nazywanych błędem aplikacji;

2. Testy podczas developmentu: siłą rzeczy już tutaj programista/zespół programistów wykonuje stosowne testy podczas samego etapu uruchomienia wdrożenia, co prawda często na zasadzie "działa/nie kompiluje się", ale jednak :)

3. Testy akceptacyjne: jeśli coś nie działa, lub nie jest zgodne z założeniami specyfikacji projektu, zostaje cofnięte i nie przechodzimy do wdrożenia --> projekt wraca do poprawki. Zignorowanie tego punktu, to błąd ze strony klienta (niedokładne przeprowadzenie testów, niekorzystna umowa, etc).

4. Testy powdrożeniowe (choćby "dymne") - pozwala uniknąć "klapy" po uruchomieniu na środowisku produkcyjnym.

W moim odczuciu, niezależnie od ceny projektu, siłą rzeczy są wykonywane testy (ewentualnie może nie spotkałem się jeszcze z programistą, który po kompilacji nie wykonał nawet krótkiej weryfikacji działania, pomijając już scenariusze testowe).

Kryterium ceny ma znaczenie i owszem. ale cena nie jest głównym wyznacznikiem jakości projektu (zgodnie ze złotą zasadą "klient nie może zapłacić za projekt więcej niż sam posiada") i niezależnie od tego, czy za projekt X zapłacimy 100'000 PLN, czy 1'000'000 EUR, może coś być "zwalone" w mniejszym lub większym stopniu :)

Problem wielu firm, to nieprzewidywanie możliwych konsekwencji upraszczania lub koncentrowania się na "tu i teraz" (np "tego nie będziemy tak rozbudowywać, bo nie ma teraz takiej potrzeby"). I tak na przykład brak uogólnionego (lub po prostu brak) systemu kolejkowania komunikatów będzie skutkowało tym, że wcześniej czy później taki powstanie. Z drugiej strony permanentne uogólnienie projektu = "Znamy wasze potrzeby, stworzymy, ale jest na rynku gotowy produkt: Visual Studio" :)

Podsumowując: przy projektach IT nie powinniśmy mówić o "niskiej/wysokiej cenie" ale o stosunku ceny do jakości, a projekt powinien spełniać oczekiwania klienta.
Zamawiając pizzę (projekt IT) peperoni z ekstra serem , niezależnie od pizzerii (developera) i ceny, otrzymamy pizzę, będzie miała ekstra ser i peperoni (zgodność ze specyfikacją).
Nawet jeśli zapłacimy za nią 5zł a będzie zimna (działa zdecydowanie za wolno na produkcji) lub brakuje peperoni (nie spełnia wymagań specyfikacji) możemy jej nie przyjmować.
Jednak jeśli spełnia oczekiwania (jest pizzą, ma peperoni i ser i jest ciepła), ale nam nie smakuje: cóż, wina leży po naszej stronie - pizzeria wykonała swoją pracę zgodnie z założeniami :)

Temat: Linq - pytanie

Adrian O.:

Marek K.:
Hmm .. gratuluję umiejętności, ale ta historia przeraża. To po co wymyślono robienie kopii zapasowych, budowę systemów redundantnych (mirror, duplex), procedury, itd., itp. .

Ale jak tutaj miały pomóc procedury kopii zapasowych i redundancja?

To był odbiór i wszystko działało czy nie było odbioru albo czy aby sprawdzono wszystko?

Był błąd w aplikacji (zresztą już bardzo wiekowej :) ).

OK, czyli to sugeruje, że przywrócenie prawidłowego stanu startowego nic by nie pomogło, ale czy aby na pewno?

Co miałem zrobić jako wdrożeniowiec - stać i patrzeć, jak się wszystko sypie, ordynator grozi (słusznie) prokuratorem, pół szpitala jest postawione na nogi, życie pacjenta jest zagrożone, jest środek nocy?

Hmm .. czyli nie tylko mnie to przeraziło. ;-(

Ale nie rozumiem tego kontekstu wdrożenia. Przecież wdrożenie to etap instalacji, uruchamiania, szkolenia personelu, czyli to moment kiedy szpital nie pracuje z aplikacją "na poważnie". Jak to co wymienione zostanie zakończone, jest odbiór mamy etap eksploatacji czyli użytkowania oprogramowania.

Skontaktowałem się natychmiast z zarządem zatrudniającej mnie firmy - podwykonawcy (wdrożeniowca) producenta.

Skoro ordynator grozi prokuratorem, i jest potwierdzenie że nie bez racji, tzn. że zabawa się skończyła, więc co u diabła robi wdrożeniowiec w szpitalu? Nadzór nad eksploatacją to przecież zajęcie dla personelu IT szpitala więc albo nie mówmy, że to wdrożenie bo to użytkowanie, albo tzn, że producent wysłał do szpitala niby celem wsparcia a tak na prawdę w celu zabezpieczenia swojego tyłka, wdrożeniowca bo prawda o aplikacji nie jest taka jak myśli klient (personel szpitala). :-(

Ten z kolei podjął wespół z ordynatorem i kierownikiem laboratorium decyzję - "chłopie ratuj wszelkimi siłami, póki nie zostanie naprawione". W takich sytuacjach liczą się minuty, chociaż każdy przyzna, że taka sytuacja mieć miejsca nie powinna.

Oczywiście, że nie powinna i taka decyzja jedyna rozsądna, bo wątpię aby także ordynator nie miał problemów jakby prokurator miał powód aby wkroczyć.

Posłużę się tutaj analogią do pilotowania samolotu. ..

Dla mnie tłumaczenie zbędne. To oczywiste jak 2 i 2 to 4, że programy komputerowe zawierały, zawierają i będą zawierać mniej lub bardziej poważne błędy. Ale to nie oznacza, że nie jest się w stanie dostarczyć bezpiecznego rozwiązania. Napisałem rozwiązania, a nie aplikacji bo w przypadku systemów o jakich mowa samo oprogramowanie to dużo za mało.

Dość spędziłem weekendów śpiąc po 2 godziny na krześle w serwerowni i dłubiąc przy systemach, przy których pracował sztab doświadczonych ludzi, którzy niejedno już w życiu widzieli i projektowali, a jednak czegoś nie przewidzieli (chociażby przyjęcie próbek z materiałem biologicznym dwóch pacjetów, oklejonych barkodami "na krzyż").

Czynnik ludzki można zminimalizować, ale nie da się go wyrugować. Cytując mojego fizyka ze szkoły: "Prawa Murphy'ego są nieubłagane".

Dlatego napisałem o procedurach, mając na myśli nie tylko te od strony robienia kopii bezpieczeństwa ale także (a może nawet przede wszystkim) procedury medyczne, procedury systemu zarządzania.

Ale czy to wszystko razem wzięte ma oznaczać, że doświadczenia inżynierii oprogramowania w zakresie projektowania, najlepszych praktyk, itd. dobrze jak nie są przestrzegane, bo ich i tak nie sposób wyegzekwować, a system dobrze że tworzony jest po bałaganiarsku bo przynajmniej są furtki boczne, które pozwalają na ratowanie życia? :-( Coś tu za dużo sprzeczności. :-(

Przecież tu nie ma żadnej sprzeczności

Niestety są. Proszę na problem spojrzeć nie tylko od strony wykonawcy usługi IT ale także zarządzania IT, zarządzania placówką służby zdrowia, zarządzania, pacjenta, rodziny pacjenta.

Temat: Linq - pytanie

Zrobił się straszny offtop, ale skoro nikt nie protestuje, to pociągnijmy, w końcu to samo życie :)

Marek K.:
To był odbiór i wszystko działało czy nie było odbioru albo

Na chwilę odbioru działało w zakresie, jaki kierownictwo jednostki akceptowało.

czy aby sprawdzono wszystko?

Nie potrafę sobie nawet tego wyobrazić w oprogramowaniu szpitalnym :)
Sprawdzono dużo (sam wykonywałem kilkaset testów akceptacyjnych, zachowałem do dziś Excela z nimi :)), także w wielu innych szpitalach i laboratoriach.

OK, czyli to sugeruje, że przywrócenie prawidłowego stanu startowego nic by nie pomogło, ale czy aby na pewno?

To był moment po podniesieniu wersji. Kopie owszem, były, ale proces był długi, złożony (nie automatyczny), obejmował wiele aspektów. Powrót zająłby wiele godzin, na to nie było czasu.

Hmm .. czyli nie tylko mnie to przeraziło. ;-(

To była moja pierwsza w życiu taka sytuacja :)

Ale nie rozumiem tego kontekstu wdrożenia. Przecież wdrożenie to etap instalacji, uruchamiania, szkolenia personelu, czyli to moment kiedy szpital nie pracuje z aplikacją "na poważnie".

Urok wdrożeń oprogramowania do obsługi szpitala i laboratorium - takie wdrożenie trwa nieraz miesiącami. Samo "postawienie" bazy i aplikacji to tylko początek. Potem przychodzi wypełnianie słowników, podłączenie i skonfigurowanie aparatury (kiedy okazuje się, że brakuje dokumentacji, że dokumentacja różni się od tego co w aparacie, bo serwisant coś poprzestawiał, bo inna wersja softu, bo inna wersja i inne podłączenie / config RS232, bo to bo tamto), testy, dostrajanie, tuning bazy. Tego się nie robi na raz, ale zwykle pracowniami, a w nich - aparatami. W międzyczasie okazuje się, że zależności między pracowniami, apararatami, stanowiskami są na tyle złożone, że nawet kierownictwo labu tego nie przewidziało. Podobnie nie wdraża się wszystkich oddziałów na raz. W momencie wdrażania jakaś część placówki już pracuje na tym, co jest.

A potem, choć może się to wydawać trudne do uwierzenia, zawsze jest co robić - dopracowywanie formuł dla badań "wyliczanych", przerabianie profili, testów, metod (niektóre laboratoria to bardzo dynamiczne organizmy!), zmiany w konfiguracji aparatury (w niektórych dużych labach zdarza się to często), zmiany w słownikach, formularzach, szablonach itd. itp.

Dalej dochodzą "sytuacje wyjątkowe", gdzie aplikacja zachowuje się niepoprawnie, a próba ominięcia tego (bo nie można nagle "odpiąć systemu od aparatury, oddziałów - przejście na pracę ręczną to nieraz kawał roboty! - np. przestawienie aparatury na inne racki, cupsy, zmiana trybu pobierania materiału) generuje kolejne problemy, które potrafią "zasypać" jak Saszkę ziemniakami w anegdocie o radzieckiej maszynie do ich obierania :)

W międzyczasie są updejty, dorabiane nowe funkcjonalności. Aplikacja, którą wdrażałem, choć praktycznie na tamte czasy bezkonkurencyjna, była dość trudna w administracji. O szczegółach nie będę pisał z pewnych względów.

Dość powiedzieć, że szkolenia stanowiskowe (szkolenia "na sali szkoleniowej" były ok. miesiąca wcześniej) dla kilkudzesięciu osób, konfiguracja systemu, dostrajanie, apdejtowanie, dostosowywanie procedur, konfiguracja aparatury (często pewnie kwestie wychodziły podczas wykonywania oznaczeń) - wszystko to (i wiele więcej) toczyło się na raz. I nie moją decyzją, a wspólną decyzją wykonawcy i zleceniodawcy.

Skoro ordynator grozi prokuratorem, i jest potwierdzenie że nie

Działał pod wpływem emocji, rano już rozmawiał spokojniej :) Ale na mnie to wtedy zrobiło wrażenie :D Oczywiście ja mu się zbytnio nie dziwię.

robi wdrożeniowiec w szpitalu?

Odbębnia kolejny z wielu nocnych dyżurów po odbywającym się dzień wcześniej apdejcie (i przez cały dzień wszystko działało dobrze), drzemiąc na krześle w pokoju socjalnym, kiedy nagle budzi go poruszenie :)

Jak mówiłem - przy systemie było co robić przez niemal 2 lata i to po kilka dni pod rząd nieraz co tydzień. OK, nazwijmy to asystą, helpdeskiem w osobie wdrożeniowca.

przecież zajęcie dla personelu IT szpitala

Owszem, personel IT robił tyle, ile umiał, np. backupy i podnoszenie wersji bazy i aplikacji. Reszta (konfiguracyjna) wymagała mojej obecności. Personel IT szpitala nie znał się zbytnio na aparaturze (nawet RSy lutowałem ja), a jeszcze mniej na procesach wykonywania oznaczeń (to jest kawał wiedzy branżowej), a ta wiedza była potrzebna na etapie wdrożenia czy też "obsłui powdrożeniowej" - zwał jak zwał. Wystarczył mi rzut (lub kilka rzutów :) ) oka na monitory aparatury, logi procesów nadawczo-odbiorczych, adapterów HL7 oraz bazę danych, żeby wiedzieć, co idzie nie tak. Oni też się tego nauczyli, ale sporo później. Poza tym znając terminologię i know-how mniej absorbowałem kierownika laboratorium i diagnostów, którzy i bez tego mieli młyn.

Przy wdrożeniach systemów informatycznych w laboratorium obsługa działu IT sprowadza się często do kwestii czysto techniczno-sieciowo-bazodanowych. Reszta pozostaje w rękach kogoś, kto odróżnia glukozę od glukagonu, surowicę od osocza, a pH od pecha :) Czasem bierze to na siebie kierownik laboratorium, ale to rzadkość.

mówmy, że to wdrożenie bo to użytkowanie,

powiedzmy, że było to wdrożenie przez użytkowanie :)

producent wysłał do szpitala niby celem wsparcia a tak na prawdę w celu zabezpieczenia swojego tyłka, wdrożeniowca bo

To już nie mnie oceniać. Ja tylko piszę jak było i jaką wiedzę podczas tych kilku lat w kilku szpitalach (bo to nie jednostkowe doświadczenie) nabyłem. Te doświadczenia kompletnie zmieniły mój pogląd na wiele kwestii.

prawda o aplikacji nie jest taka jak myśli klient (personel szpitala). :-(

Akurat, pomijając ten incydent z wku....niem ordynatora z OIOMu, obie strony się raczej dogadywały i wszystko szło do przodu. Nie wiem jak tam jest dziś, bo już mnie tam nie było przeszło 6 lat.

Oczywiście, że nie powinna i taka decyzja jedyna rozsądna, bo wątpię aby także ordynator nie miał problemów jakby prokurator miał powód aby wkroczyć.

Na szczęście nie było powodów, bo wszystko dobrze się skończyło.

Dlatego napisałem o procedurach, mając na myśli nie tylko te od strony robienia kopii bezpieczeństwa ale także (a może nawet przede wszystkim) procedury medyczne, procedury systemu zarządzania.

Procedury owszem, były. To nie tak, że wszystko szło na żywioł. Ale na tamten moment zawiodły. Problem nie wyszedł ani w testach, ani nigdy wcześniej się nie zdarzył. Od tamtej pory doszedł kolejny przypadek testowy. Dziś, świadom tego wszystkiego, kiedy siadam do projektowania z ludźmi, którzy w życiu nie przekroczyli progu dużego laboratorium, a próbują mi wmawiać, że "moje zastrzeżenia są nadmiarowe", nóż mi się w kieszeni otwiera :)Ten post został edytowany przez Autora dnia 04.12.13 o godzinie 05:51

Temat: Linq - pytanie

Adrian - lubię Cię :D

Dzięki za wytłumaczenie od środka jak działa wdrożenie w laboratorium. Nie wiem czy sam nie przyjąłbym takiego samego modelu. Dzięki za konkretne info - jak dla mnie kontekst który podałeś ("kroczące wdrożenie") tłumaczy bardzo wiele.

W związku z tym z mojego poprzedniego postu skupiłbym się na braku "dobrych praktyk" - brakuje mi (albo o tym nie wiem) takiego wspólnego działania - IT, lekarzy, kierowników, generalnie służby zdrowia. Brakuje mi takich "zasad dobrych wdrożeń" lub czegoś podobnego, gdzie własnie takie przypadki byłyby opisane. Po to aby inne jednostki wdrażające podobne systemy mogły działać lepiej.

Wiem że takie działania czasami podejmuje się w UK/USA. Ale być może nikt tego nie robi bo a nuż jakiś nadgorliwy prokurator by się spróbował przyczepić ?

Adrian, dzięki za wyjaśnienie. Dla mnie może być koniec offtopicu :D

Pozdrawiam,
MWW

Temat: Linq - pytanie

Adrian O.:
Zrobił się straszny offtop, ale skoro nikt nie protestuje, to pociągnijmy, w końcu to samo życie :)

Można mieć propozycję do moderatora aby założyć nowy wątek i przesunąć wszystkie wypowiedzi w ramach tego offtopicu? ;-)

Marek K.:
czy aby sprawdzono wszystko?

Nie potrafę sobie nawet tego wyobrazić w oprogramowaniu szpitalnym :)

Ja też, ale też nie potrafię sobie wyobrazić aby nie sprawdzono wszystkiego w pewnych zakresach. Nie potrafię też zaakceptować braku dokumentacji szczegółowego programu sprawdzania takiego oprogramowania (auditu?), planu testów, czy wyników i nie mam na myśli ramowego harmonogramu.

Sprawdzono dużo (sam wykonywałem kilkaset testów akceptacyjnych, zachowałem do dziś Excela z nimi :)), także w wielu innych szpitalach i laboratoriach.

Ok, to że sprawdzono nie wątpię ale czy dotrzymano odpowiedniej staranności w realizacji, czy też wszystko to co robiłeś ty i inni którzy sprawdzali to na swój (ich) własny użytek, aby się nie pogubić i z własnej (ich) inicjatywy bo były tylko ogólne zalecenia, a szczegóły i tak spoczywały na wykonawcach?

OK, czyli to sugeruje, że przywrócenie prawidłowego stanu startowego nic by nie pomogło, ale czy aby na pewno?

To był moment po podniesieniu wersji. Kopie owszem, były, ale proces był długi, złożony (nie automatyczny), obejmował wiele aspektów. Powrót zająłby wiele godzin, na to nie było czasu.

Czyli nie wiedziano, że od takiej "pierdoły" może zależeć życie ludzkie i że na taką okoliczność w zakresie bezpieczeństwa systemów czasu rzeczywistego inżynieria systemów IT przewiduje w opcji standard, dwie maszyny, których nie aktualizuje się jednocześnie, tylko jedna po drugiej i to nie "z marszu"? :-(

Sorry: projektant?, analityk?, dyrektor handlowy? szef firmy? do zwolnienia. :-( Ani tak nie wolno było zaprojektować, a przewidzieć że szlag może trafić kompa wie nawet dzieciak w szkole podstawowej, który zazwyczaj z dumą ciągle aktualizuje swojego Windowsa, ani nie wolno było sprzedać taką niebezpieczną konfigurację, ani nie wolno było klientowi coś takiego proponować, wstawiać do oferty handlowej.

Świadomość zagrożenia powinna być po stronie IT i przecież nawet powinno się odmówić klientowi (sprzedaży?, aktualizacji?) gdyby upierał się (zapewne z powodu cięcia kosztów) przy tak niebezpiecznej konfiguracji. :-( Tak, tak, wiem, że prawa rynku to, prawa rynku tamto. ;-(

Ale nie rozumiem tego kontekstu wdrożenia. Przecież wdrożenie to etap instalacji, uruchamiania, szkolenia personelu, czyli to moment kiedy szpital nie pracuje z aplikacją "na poważnie".

Urok wdrożeń oprogramowania do obsługi szpitala i laboratorium - takie wdrożenie trwa nieraz miesiącami. Samo "postawienie" bazy i aplikacji to tylko początek. Potem przychodzi wypełnianie słowników, podłączenie i skonfigurowanie aparatury (kiedy okazuje się, że brakuje dokumentacji, że dokumentacja różni się od tego co w aparacie, bo serwisant coś poprzestawiał, bo inna wersja softu, bo inna wersja i inne podłączenie / config RS232, bo to bo tamto), testy, dostrajanie, tuning bazy.

STOP! To była pierwsza (jedna z pierwszych) sprzedaż tego oprogramowania? To każdy szpital ma inne słowniki? Bez przesady. :-( Przecież podobny zakres mają choćby apteki - setki tysięcy leków, receptur i tego każda apteka nie wklepuje do bazy indywidualnie, a aktualizacje są robione bardzo często. Rozumiem, że w szpitalu dochodzą inne rzeczy ale szpital przecież nie może wykorzystywać nie wiadomo czego, a właściwie wiadomo co może, bo wszystko musi być dopuszczone do obrotu urzędowo. :-(

Przecież wdrożenie w każdym szpitalu wg takiego scenariusza to olbrzymie koszty (liczone nie tylko w pieniądzu ale i w czasie czy w zasobach ludzkich) i w dużej części ta sama praca niepotrzebnie wykonywana wielokrotnie. Olbrzymia ilość pracy może być wykonana raz przez dostawcę rozwiązania poza szpitalem, a następnie tylko "wgrana" w każdym ze szpitali indywidualnie.

Tego się nie robi na raz, ale zwykle pracowniami, a w nich - aparatami.

Podobnie jest w zakładach przemysłowych, gdzie jak przygotowanie produkcji nie upora się z bazą wyrobów, półfabrykatów a do nich normatywów, receptur, przepisów, surowców, i "paru" innych "drobiazgów", to produkcja nie wyprodukuje, handlowcy nie sprzedadzą a księgowość nie rozliczy.

W międzyczasie okazuje się, że zależności między pracowniami, apararatami, stanowiskami są na tyle złożone, że nawet kierownictwo labu tego nie przewidziało. Podobnie nie wdraża się wszystkich oddziałów na raz. W momencie wdrażania jakaś część placówki już pracuje na tym, co jest.

To naturalna kolej rzeczy przy integracji, bo widzę że opis dotyczy w miarę jednolitego, kompleksowego rozwiązania. Tak to już jest nie tylko w szpitalu. ;-)

A wiele stanowisk, konfiguracja rozproszona (stanowisk, laboratoriów, ..) passé? Rozumiem, że rozwiązania zintegrowane czy klasy ERP to dzisiaj żaden luksus dla biznesu tylko signum tempori, ale czy także w przypadku systemów czasu rzeczywistego o istotnym znaczeniu dla życia człowieka?

Rozumiem, że to fajnie hula w teorii, i rozbudza wyobraźnię, jak wszystko jest na jeden click lub ENTER, ale bezpieczeństwo ma swoje wymagania i jeżeli nie dysponuje się "wystarczająco" zintegrowanymi elementami składowymi, to żadne dostrajanie ani tuning bazy nie pomogą. Przecież w takim przypadku od razu pojawia się proteza (i to nie jedna), która będzie "wąskim gardłem" czyli zagrożeniem dodanym na własne życzenie i to że działa się w dobrej wierze nie zmienia faktu, że obniża się poziom bezpieczeństwa. :-(

Przy wdrożeniach systemów informatycznych w laboratorium obsługa działu IT sprowadza się często do kwestii czysto techniczno-sieciowo-bazodanowych. Reszta pozostaje w rękach kogoś, kto odróżnia glukozę od glukagonu, surowicę od osocza, a pH od pecha :)

Ale czy to źle? ;-) A "a pH od pecha" kupuję. ;-)))

Ja tylko piszę jak było i jaką wiedzę podczas tych kilku lat w kilku szpitalach (bo to nie jednostkowe doświadczenie) nabyłem. Te doświadczenia kompletnie zmieniły mój pogląd na wiele kwestii.

Każdego zmienia doświadczenie. ;-)

prawda o aplikacji nie jest taka jak myśli klient (personel szpitala). :-(

Akurat, pomijając ten incydent z wku....niem ordynatora z OIOMu, obie strony się raczej dogadywały i wszystko szło do przodu.

OK, nie wątpię ale problem pozostaje. :-(

Dlatego napisałem o procedurach, mając na myśli nie tylko te od strony robienia kopii bezpieczeństwa ale także (a może nawet przede wszystkim) procedury medyczne, procedury systemu zarządzania.

Procedury owszem, były. To nie tak, że wszystko szło na żywioł. Ale na tamten moment zawiodły.

To, że procedury były to nie wątpię bo NFZ placówkę by zamknął, ale dobrze wiemy, że nie o bycie procedur tylko o stosowanie się do nich oraz etykę tu chodzi. ;-(

Problem nie wyszedł ani w testach, ani nigdy wcześniej się nie zdarzył. Od tamtej pory doszedł kolejny przypadek testowy. Dziś, świadom tego wszystkiego, kiedy siadam do projektowania z ludźmi, którzy w życiu nie przekroczyli progu dużego laboratorium, a próbują mi wmawiać, że "moje zastrzeżenia są nadmiarowe", nóż mi się w kieszeni otwiera :)

No cóż, wpływ mamy na to co mamy, a parafrazując klasyków: każdy ma swojego Kłopotka. ;-)

Temat: Linq - pytanie

Marek K.:
Ja też, ale też nie potrafię sobie wyobrazić aby nie sprawdzono wszystkiego w pewnych zakresach.

System był sprawdzany i funkcjonował w wieeeelu laboratoriach (i szpitalach; ja zajmowałem się wdrożeniami tylko laboratorium) Polski. "Core" było wszędzie wspólne (choć w różnych wersjach), ale wiele zmian było także robionych pod konkretnych odbiorców. Testy były długie (żeby każda firma testowała tyle swój soft :) ), a dodatkowo praca przez długie lata w labach o dużej "przepustowości" potwierdzała, że system pracuje stabilnie. Tak więc to na pewno nie była jakaś "niedoróbka". Pewnym potwierdzeniem tego jest także fakt, że soft przejęła kilka lat temu inna duża i znana firma informatyczna i nadal go rozwija, a on stanowi pewien standard w Polsce.

zaakceptować braku dokumentacji szczegółowego programu sprawdzania takiego oprogramowania (auditu?), planu testów, czy wyników i nie mam na myśli ramowego harmonogramu.

Troszkę Pan przesadził, wszystko to było, ja pisałem o sytuacji wyjątkowej, a nie o takiej, która miała miejsca stale.

Ok, to że sprawdzono nie wątpię ale czy dotrzymano odpowiedniej staranności w realizacji,

Nie wiem, nie pracowałem w tej firmie, tylko w firmie podwykonawcy. Dlatego nie mogę fantazjować i zapewniać, byłoby to nieuczciwe z mojej strony. Ale na pewno nie jechałem na kolejne wdrożenia z "kulą w żołądku", że jadę wdrażać jakieś dziadostwo.

inni którzy sprawdzali to na swój (ich) własny użytek, aby się nie pogubić i z własnej (ich) inicjatywy bo były tylko ogólne zalecenia, a szczegóły i tak spoczywały na wykonawcach?

"I did my best". Za innych nie mogę ręczyć.A szczegółów biznesowych nie znam.

Czyli nie wiedziano, że od takiej "pierdoły" może zależeć

Jakiej "pierdoły"? Nie rozumiem.

A życie ludzkie może zależeć od każdej jednej linijki kodu, każdej jednej przerwy w pracy serwera i sieci, wyjątku w bazie danych, usterce aparatury itd.

bezpieczeństwa systemów czasu rzeczywistego inżynieria systemów IT przewiduje w opcji standard, dwie maszyny,

Które dwie maszyny? Tam był serwer i kilkadziesiąt jednostek klienckich uaktualnianych osobno ręcznie. Do tego były maszyny pośredniczące między aparaturą a bazą. Konfiguracja obejmowała także czasem samą aparaturę. Po dwie maszyny na stanowisku? Po dwa aparaty? Po dwa serwery?
Pamiętajmy, że to wszystko oznacza także koszty nie tylko zakupu i utrzymania sprzętu, sieci, przełączników, wdrożenia, ale także utrzymania spójnych informacji w obu systemach. A teraz przedstawmy te koszty zarządowi szpitala, mówiąc mu jednocześnie, że "błędy nadal mogą się pojawić, bo usuwamy jedne, ale niechybnie pojawią się także inne, wynikające ze skomplikowania infrastruktury".

nie aktualizuje się jednocześnie, tylko jedna po drugiej i to nie "z marszu"? :-(

No i co by to dało tutaj? Jak mówiłem - po podniesieniu wersji wszystko śmigało, cały dzień zleceń (w godzinach szczytu). Problem wystąpił w momencie gdy wszyscy niemal spali, wiele godzin po aktualizacji.

zwolnienia. :-( Ani tak nie wolno było zaprojektować, a

Ten system ma długie lata, projektowany był przez osoby na pewno bardziej doświadczone ode mnie. Nagle wychodzi teraz, że przez jeden taki błąd skreśla Pan cały system, pracujący w setkach jednostek medycznych różnej wielkości, zwalnia całą kadrę projektowo-decyzyjną. Daj Boże, aby w roku 2006 każdy system IT w Polsce był tej miary, co tamten.

Oczywiście, że zawsze wszystko można zrobić lepiej. Dlatego np. ja wykorzystuję wiedzę zdobytą wtedy, uczę się na cudzych błędach, ale nigdy nikt nie powie, że zrobił coś idealnie. Nawet łazik marsjański, projektowany przez super-speców, kosztujący grube pieniądze, ostatnio zaliczył gorący reset - link na elektroda.pl.

przewidzieć że szlag może trafić kompa wie nawet dzieciak w szkole podstawowej, który zazwyczaj z dumą ciągle aktualizuje swojego Windowsa,

Ale tutaj szlag kompa nie trafił. Nie rozumiem. Już nie wspominając o tym, że sieć była "odpięta" od internetu, nic się automatycznie nie aktualizowało, a na kompach nawet porty USB były odpięte, żeby nikt nic nie namieszał, obudowy zaplomowane. A ci, którzy mogli by coś napsuć (w tym ja) mieli podpisane "papierki grożąco-straszące" i zdawali sprawę nie tylko przed swoim pracodawcą, ale także kierownikiem i administratorem laboratorium oraz kierownictwem firmy zlecającej wdrożenie.

ani nie wolno było sprzedać taką niebezpieczną konfigurację, ani nie wolno było klientowi coś takiego proponować, wstawiać do oferty handlowej.

Obawiam się, że jednak, z całym szacunkiem dla Pana doświadczenia i wiedzy, odrobinkę się Pan zapędził w osądzie.

W dyskusji o bazach danych przytoczyłem pewne zdarzenie. Incydentalne, nie regularne. Napisałem, że mając dostęp do bazy mogłem to naprawić, dzięki czemu znacznie zmniejszyłem pozoim zagrożenia. Ten sam błąd w czasie pracy dziennej byłby totalną pierdołą, w tamtym momencie, kiedy jest dyżur nocny i prawie pusto w laboratorium, a programiści śpią - akurat jego znacznie w danej sytuacji wzrosło.

I właśnie dlatego, że ktoś mądry pomyślał o tym i przewidział, że chociaż w godzinach szczytu wszystko wydaje się działać OK, to może pojawić się problem na dyżurze nocnym. I żeby nie zostawić laboraotrium zdanego tylko na siebie, postawił tam mnie. Naprawiłem, produkcja poprawiła - i problem się nie powtórzył.

A Pan odsądza system i cały tworzący go zespół od czci i wiary, jak by to było najgorsze, co się w historii polskiej informatyki zdarzyło. Otóż nie. System był (przynajmniej jak na swoje czasy) naprawdę OK i gdyby nie fakt, że dzisiaj sam projektuję oprogramowanie info-medyczne i czas "wycierania kolanami podłóg w laboratoriach" mam już za sobą, wdrażałbym go dalej.

Zresztą pod względem sposobu pracy i możliwości niewiele się różni od innych, wiodących (tutaj branżowcom przed oczami pojawiają się 2-3 nazwy) systemów na polskim rynku. Może tylko wygąda archaicznie, na aplikację rodem z lat 90 i zastępowany jest przez systemy wyglądające nowowocześniej i lepiej pasujące do nowoczesnych standardów (SOA, lekki klient, wymiana informacji między systemami).

I nie chodzi o to, że bronię tutaj czyjegoś interesu, przecież nie pracuję tam od kilku ładnych lat, w dodatku to konkurencja :) Ale nie popadajmy w skrajności.

aktualizacji?) gdyby upierał się (zapewne z powodu cięcia kosztów) przy tak niebezpiecznej konfiguracji. :-( Tak, tak, wiem, że prawa rynku to, prawa rynku tamto. ;-(

Jakiej niebezpiecznej konfiguracji? Pół Polski stało i stoi na tym systemie (choć owszem, biegiem czasu liczba użytkowników może maleć, bo IT się rozwija, pojawiają się nowe, nowocześniejsze produkty, konkurencja etc). Błędy zdarzają się w systemie każdej firmy.

STOP! To była pierwsza (jedna z pierwszych) sprzedaż tego oprogramowania?

Sto któraś.

To każdy szpital ma inne słowniki?

Mhm.

Bez przesady. :-( Przecież podobny zakres mają choćby apteki - setki tysięcy leków, receptur i tego każda apteka nie wklepuje do bazy indywidualnie, a aktualizacje są robione bardzo często. Rozumiem, że w szpitalu dochodzą inne rzeczy ale szpital przecież nie może wykorzystywać nie wiadomo czego, a właściwie wiadomo co może, bo wszystko musi być dopuszczone do obrotu urzędowo. :-(

Laboratorium to nie apteka.

Każde laboratorium ma nieco inny słownik. Nie mam co prawda tyle czasu, żeby opisać to dokładnie, ale ogólnie naświetlę temat.

Otóż są pewne badania podstawowe, które wykonuje praktycznie każde laboratorium, choć tak naprawdę jest to bardzo wąska grupa badań. W małych labach robi się niedużo. Np. w "mojej" przychodni (tzw. "kolejowej") glukozę, prostą morfologię, OB, ogólne badanie moczu (bardzo ograniczona część osadowa), dwie podstawowe aminotranferazy (aspat, alat), fosfatazę alkaliczną (ale kwasowej już nie), elektrolity, mocznik i kilka innych robi się na miejscu, ale już bilirubinę, białko całkowite, CRP, kolejną aminotransf. - GGTP, LDH, kreatyninę, markery sercowe (CK/-MB, troponina), płytki, retikulocyty, układ krzepnięcia krwi, gospodarka żelazowa, hormony tarczycowe, "kobiece", elektroforeza białek i całą masę innych, choć praktycznie podstawowych badań "outsorcuje się" się do innych laboratoriów. Tamte laboratoria także mają różne zestawy badań. Samych morfologii jest kilka (8, 12, 14, 16, 20, 24, 28, 32, 48, 64, 128 parametrowe, w tym różne rozmazy: 3,5,8 diff; choć najczęściej to między 12 a 26 parametrów). Frakcji cholesterolu HDL i LDL jest kilka, izoenzymów LDH - także. Sam układ krzepnięcia krwi (wykonywany np. przed zabiegiem) może mieć 1-2 parametry, a może mieć ich ponad 30.

Są laboratoria specjalizowane pod kątem "sercowców", "onkologiczne", "płucne" - każde z nich będzie miało pewien podstawowy zbiór (choć trudno do tak do końca opisać) i całą masę badań dodatkowych.

A podałem tu tylko kilka z ponad półtora tysiąca badań, jakie można wykonać. Są laboratoria "codzienne", szpitalne, specjalistyczne, badawcze (np. przy zakładach genetyki molekularnej). Jedne laboratoria robią to, inne tamto. Mają różne pracownie (biochemia kliniczna, immunochemia, koagulologia, serologia grup krwi, analityka ogólna, monitoring leków, mikrobiologia, genetyka), różny zestaw aparatury, aparatura wykorzystywana jest w różnym zakresie (wykorzystywany kanał pomiarowy, metoda aspiracji materiału, zastosowane elektrody i odczynniki), podpisane są umowy z różnymi dostawcami odczynników, do tego dochodzi rachunek ekonomiczny (co się opłaca robić, co outsorcować) - no jest tego po prostu cała masa. Książkę można napisać.

Aha, zapomniałem, że badania mogą mieć różne nazwy i oznaczenia kodowe (skrócone). I wszystkie są w obiegu.

Przykłady z mojego słownika:
* Inhibitor esterazy C, Białkowy inhibitor proteaz serynowych, Serpina
* AlAT, ALT, GPT, Aminotransferaza alaninowa, Transaminaza alaninowa
* Przeciwciała klasy IgM przeciw lipidom krętkowym kiły, Kiła (Lues, Syphilis), Serodiagnostyka kiły, Przeciwciała antyfosfolipidowe, Przeciwciała antykardiolipinowe
* Kinaza fosfokreatynowa - izoenzym sercowy (37°C), Fosfokinaza kreatyniny, Fosfokinaza kreatynowa
* CCP, CCP-Ab, aCCP, anty-CCP, Przeciwciała przeciw białku cyklicznemu cytruliny
* S100B, Białko S100, Marker udaru mózgu, Marker glejaka, Marker czerniaka złośliwego
* aTPO, Przeciwciała anty-TPO, Przeciwciała przeciw peroksydazowe, Przeciwciała anty-mikrosomalne peroksydazowe

Praktycznie każde jedno badanie ma ileś tam wariantów nazw, stosowanych w laboratoriach.

Teraz - mamy profile badań, czyli zestawy. Każde laboratorium łączy sobie testy elementarne w profile ze względów organizacyjnych (zamiast zlecać 10 badań osobno, zleca się profil) i ekonomicznych (cenniki, np. "profil nerkowy" kosztuje 20zł, ale te same X badań osobno to koszt 30zł). Inna sprawa to nomenklatura przyjęta w labie - dla jednego morfologia to badanie elementarne (zlecane i wykonywane jako całość) z np. 16 parametrami (wynikami), a dla innego - to profil 16 badań elementarnych (choć np. nie da się zrobić na aparacie samej tylko hemoglobiny).

Potem idą materiały biologiczne, na jakich można wykonać badanie. Jest ich cała masa - kilka z nich to surowica, osocze, krew pełna na różnych antykoagulantach (i dodatkowo - z żyły, z palca, płucna itd.), płyny z jam ciała (np. mózowo rdzeniowy, otrzewna, opłucna itd.), mocz (przypadkowy lub poranny, dobowa zbiórka), kał, wymazy itd. Nie każde laboratorium robi badania na każdym materiale.

Dalej idą metody wykonywania badań. Niektóre badania można wykonać wieloma różnymi metodami, zależnie od potrzeb (wymaganej czułości i selektywności), od posiadanego sprzętu, od zakupionych odczynników i elektrod, od kosztów.

Z parą metoda-materiał skojarzony jest wynik. I teraz znów nieco konfiguracji. Otóż wynik może pochodzić spoza systemu (z aparatu, manualnie) albo być wyliczony z innych wyników. Przykładem jest np. klirens kreatyniny, gdzie wynik zależy od stężenie kreatyniny w surowicy, wieku, płci i wagi pacjenta lub jej steżenia w moczu i objętości badanego moczu. Trzeba więc podefiniować formuły według zaleceń kierownika laboratorium.

Trzeba przy okazji pamiętać, że kolejne komponenty wyniku (czyli wyniki innych testów) mogą "schodzić z aparatów" w różnym czasie bądź wcale się nie pojawić. Jak uszkodzi się aparat, który wykonuje dane oznaczenie, a nie ma dla niego zastępnika, ale badanie można wykonać ręcznie, to wykonuje się je ręcznie i samemu wprowadza wynik. Trzeba także pilnować rozcieńczeń. Takie aspekty również trzeba skonfigurować.

Dalej - wyniki mogą być numeryczne, jakościowe lub opisowe. Wyniki numeryczne trzeba sformatować (np. liczba zer po przecinku), dla wyników jakościowych i opisowych - podefiniować słowniki i określić jak mają się drukować.

Dalej - do wyniku dochodzą różne flagi (przekroczenie zakresu referencyjnego, komunikaty z aparatu, np. below/above assay range", chemoliza próbki i inne) - te flagi trzeba jakoś wyświetlić, a więc ustalić im format i tekst komunikatu.

Dalej - dla wyników jakościowych w "notacji plusikowej" (widoczne często na biochemicznego wynikach badania moczu) trzeba zdefiniować poziomy (poziom A->"+", poziom B->"++"), a te poziomy są różnie ustalane przez laboratoria, w zależności od przyjętego zakresu referencyjnego.

Dalej - do wyniku dochodzą także zdefiniowane uprzednio, wybierane przez diagnostę lub "trigerowane" komentarze - trzeba zdefiniować ich słownik i ustalić, jak będa się wyświetlać ("zamiast wyniku", "pod wynikiem").

Dalej - zakresy referencyjne zwane popularnie "normą". Oczywiście są pewne "uniwersalne" zakresy referencyjne (stanowiące 95% przedział ufności dla zmiennej), ale laboratorium na takich się nie opiera, tylko podaje dokładne wartości, zależne od wielu czynników: wieku pacjenta, jego płci, metody wykonania oznaczenia i konkretnego aparatu. Wystarczy zmienić elektrodę w aparacie i po kalibracji możemy otrzymać nieco inny zakres. Dla lekarza nigdy nie liczy (a przynajmniej nie powinien!) sam wynik, ale zawsze wynik w ramach danego zakresu referencyjnego.

Dalej idą konfiguracje aparatura-badanie-metoda-materiał. Dany aparat może wykonać dane badanie danymi metodami na danych materiałach. To się zmienia zależnie od tego, czy dany aparat działa (a jeśli tak, to czy działa dany "kanał pomiarowy"), jakie odczynniki, jaka elektroda, jaką ma wgraną wersję oprogramowania.

Jak mówiłem, jest to twór dynamiczny, a proszę mieć na uwadze, że ja tutaj upraszczam.

Swego czasu, w obecnej firmie projektowałem uniwersalny słownik badań, materiałów i metod. Robiłem go kilka miesięcy mało śpiąc i dużo szukając, konsultując z diagnostami. Zgromadziłem ponad 1200 badań, a i tak zadanie mnie przerosło :)

Przecież wdrożenie w każdym szpitalu wg takiego scenariusza to

Tak to wygląda w przypadku chyba każdego wdrożenia w laboratorium i w szpitalach. Wiem, jak to wygląda w różnych firmach.

może być wykonana raz przez dostawcę rozwiązania poza szpitalem, a następnie tylko "wgrana" w każdym ze szpitali indywidualnie.

Hmmm :) Pewna - oczywiście. Np. szefowie laboratorium dostarczają listy badań, kierownictwo placówki dostarcza listy oddziałów, OPKi (ośrodki powstawania kosztów), lekarzy i inne słowniki. No i to w sumie wszystko. Cała reszta zabawy zaczyna sie na miejscu. W między czasie okazuje się, że zmienił sie aparat, laboratorium zmieniło politykę, zmienił się wytyczne w diagnostyce i trzeba przekonfigurowywać różne rzeczy.

Podobnie jest w zakładach przemysłowych, gdzie jak przygotowanie produkcji nie upora się z bazą wyrobów, półfabrykatów a do nich normatywów, receptur, przepisów, surowców, i "paru" innych "drobiazgów", to produkcja nie wyprodukuje, handlowcy nie sprzedadzą a księgowość nie rozliczy.

Etapowe wdrażanie to tutaj podstawa. Po pierwsze żaden kierownik laboratorium nie dopuści do kompleksowego wdrożenia "na raz" na wszystkich pracowniach i aparatach. Jest to zbyt skomplikowany proces, a lab pracuje 24/7, nie ma czasu na przestój wszystkich pracowni, a nawet nie wszystkich aparatów na jednej pracownik. Po drugie - żaden wdrożeniowiec nie podejmie się opanować tego wszystkiego. Już nie wspomnę o szkoleniach stanowiskowych.

Tu się nie da wejść w piątek wieczorem, poustawiać wszystkiego do poniedziałku i w poniedziałek zacząć. Współpraca punktu pobrań, aparatury, stanowisk, opracowanie procedur (które powstają dynamicznie) i wiele innych zagadnień. Najpierw wdraża się najmniej obciążaone pracownie (zwykle koagulologia, monitoring leków, analityka - choć to zależy od profilu labu). Podobnie z oddziałami.

A wiele stanowisk, konfiguracja rozproszona (stanowisk, laboratoriów, ..) passé? Rozumiem, że rozwiązania zintegrowane czy klasy ERP to dzisiaj żaden luksus dla biznesu tylko signum tempori, ale czy także w przypadku systemów czasu rzeczywistego o istotnym znaczeniu dla życia człowieka?
Rozumiem, że to fajnie hula w teorii, i rozbudza wyobraźnię, jak wszystko jest na jeden click lub ENTER, ale bezpieczeństwo ma swoje wymagania i jeżeli nie dysponuje się "wystarczająco" zintegrowanymi elementami składowymi, to żadne dostrajanie ani tuning bazy nie pomogą.

Nie bardzo rozumiem, jak opisane tutaj kwestie mają się do opisywanego problemu.

Ale czy to źle? ;-) A "a pH od pecha" kupuję. ;-)))

Nie źle, tylko uzasadniam, dlaczego dział IT tego nie zrobi.

Toczymy dyskusję nad systemem, którego Pan nie zna (więc trudno go kompleksowo ocenić na podstawie udzielonych przeze mnie szczątkowych informacji na temat pewnego jego zdarzenia, które było jednie ilustracją w dyskusji, ale na tle całokształtu było jedynie incydentem), nad problemem, którego dokładnie nie opisałem (nie mam do tego prawa), nad charakterem wdrożeń w laboratorium, co samo w sobie stanowi dużą porcję wiedzy branżowej i doświadczeń - a to niespecjalnie już pasuje do głównego wątku.

Ze swej strony dziękuję za dyskusję. Możemy ją kiedyś pociągnać w osobnym wątku, wymieniając się doświadczeniami.

Pozdrawiam :)Ten post został edytowany przez Autora dnia 05.12.13 o godzinie 17:26

Temat: Linq - pytanie

Adrian O.:

Marek K.:
Ja też, ale też nie potrafię sobie wyobrazić aby nie sprawdzono wszystkiego w pewnych zakresach.

System był sprawdzany i funkcjonował w wieeeelu laboratoriach (i szpitalach; ja zajmowałem się wdrożeniami tylko laboratorium) Polski.

Czyli tak jak napisaliśmy sprawdzono. ;-)

zaakceptować braku dokumentacji szczegółowego programu sprawdzania takiego oprogramowania (auditu?), planu testów, czy wyników i nie mam na myśli ramowego harmonogramu.

Troszkę Pan przesadził, wszystko to było, ja pisałem o sytuacji wyjątkowej, a nie o takiej, która miała miejsca stale.

To zamyka wątek. ;-)

Czyli nie wiedziano, że od takiej "pierdoły" może zależeć

Jakiej "pierdoły"? Nie rozumiem.

Aktualizacja stanowiska? modułu systemu? od którego zależeć może życie.

A życie ludzkie może zależeć od każdej jednej linijki kodu, każdej jednej przerwy w pracy serwera i sieci, wyjątku w bazie danych, usterce aparatury itd.

Oczywiście ale ja odnoszę się do opisanej sytuacji: wszystko działało -> update -> nie działa i życie jest zagrożone. A ponieważ ze swojej strony nie mam dylematu czy system może mieć awarię, bo na 100% może, więc istotnym pytaniem jest kiedy. Aby być przygotowanym na awarię nie mamy innego wyjścia jak wypracować odpowiednie schematy działania.

Odnoszę się więc do procedur aktualizacji, które powinny być tak skonstruowane aby w przypadku problemów móc przywrócić stan sprzed. Musi być świadomość wad, zalet i konsekwencji korzystania w ramach procedur bezpieczeństwa z shallow copy lub deep copy, a w ślad za tym i odpowiednie regulacje.

bezpieczeństwa systemów czasu rzeczywistego inżynieria systemów IT przewiduje w opcji standard, dwie maszyny,

Wcześniej wskazane było uaktualniane jedno krytyczne stanowisko. Rozumiem, że tutaj problem dotyczył realizacji jakiejś funkcjonalności o licznych powiązaniach w całym systemie.

Które dwie maszyny? Tam był serwer i kilkadziesiąt jednostek klienckich uaktualnianych osobno ręcznie. .. Po dwie maszyny na stanowisku? Po dwa aparaty? Po dwa serwery?

Oj to wymaga odrębnego poważnie potraktowanego projektu. ;-)

A teraz przedstawmy te koszty zarządowi szpitala, mówiąc mu jednocześnie, że "błędy nadal mogą się pojawić, bo usuwamy jedne, ale niechybnie pojawią się także inne, wynikające ze skomplikowania infrastruktury".

A jak jest inna droga jak zaproponowanie redundantnego systemu? Jeżeli jest świadomość, że życie ludzi zależy od tego rozwiązania to musimy dostrzegać, że to co wdrażane to nie tylko oprogramowanie lecz złożony system o nadmiarowości, która musi być bardzo dobrze przemyślana. Właśnie tak należy zrobić i dodatkowo pokazać, przekonać, że to co teoretycznie to samo bo zdublowane, to jednak nie to samo, bo ma swoje solidnie umocowane w realiach budowy bezpiecznego systemu z zawodnych elementów składowych. ;-)

I właśnie dlatego, że ktoś mądry pomyślał o tym i przewidział, że chociaż w godzinach szczytu wszystko wydaje się działać OK, to może pojawić się problem na dyżurze nocnym. I żeby nie zostawić laboraotrium zdanego tylko na siebie, postawił tam mnie. Naprawiłem, produkcja poprawiła - i problem się nie powtórzył.

A Pan odsądza system i cały tworzący go zespół od czci i wiary, jak by to było najgorsze, co się w historii polskiej informatyki zdarzyło. Otóż nie.

Nie kwestionuję lecz proszę odpowiedzieć sobie na pytanie kto miałby problemy z uzasadnieniem, że nie zawinił gdyby prokurator miał powód aby interweniować? Po prostu nie potrafię zaakceptować, że niby nikt nie zawinił, kiedy była awaria a IT nie było w stanie dostarczyć tego co niezbędne, tego co miało dostarczyć i pacjent zmarł. :-(

aktualizacji?) gdyby upierał się (zapewne z powodu cięcia kosztów) przy tak niebezpiecznej konfiguracji. :-( Tak, tak, wiem, że prawa rynku to, prawa rynku tamto. ;-(

Jakiej niebezpiecznej konfiguracji?

Bez nadmiarowości w sekcjach krytycznych, bez procedur pozwalających przywrócić działanie systemu na poziomie nie zagrażającym życiu, wtedy kiedy wszystko kręci się wokół problemów niematerialnych (oprogramowanie użytkowe).

To każdy szpital ma inne słowniki?

.. Każde laboratorium ma nieco inny słownik.

No właśnie .. nieco inny. ;-)

Jak mówiłem, jest to twór dynamiczny, a proszę mieć na uwadze, że ja tutaj upraszczam.

Oczywiście jestem świadom. Odnoszę się tylko do podkreślania całkowitej odrębności każdego szpitala, każdego laboratorium. To oczywiste, że są różnice.

może być wykonana raz przez dostawcę rozwiązania poza szpitalem, a następnie tylko "wgrana" w każdym ze szpitali indywidualnie.

Hmmm :) Pewna - oczywiście. Np. szefowie laboratorium dostarczają listy badań, kierownictwo placówki dostarcza listy oddziałów, OPKi (ośrodki powstawania kosztów), lekarzy i inne słowniki. No i to w sumie wszystko. Cała reszta zabawy zaczyna sie na miejscu.

Uważam że część wspólna jest dużo większa niż na pierwszy rzut oka może dać się zauważać. ;-)

Toczymy dyskusję nad systemem, którego Pan nie zna

Oczywiście. Ale proszę zauważyć, że nie odnoszę się do szczegółów implementacyjnych, których nie znam lecz do zagadnień proceduralnych tak z zakresu IT jak i procedur medycznych czy zarządczych, od których nie sposób się odciąć jeżeli o bezpieczeństwie mowa. Koncentrowanie się na samych szczegółach technicznych, normatywach, aparaturze, kiedy dostarcza się złożone kompleksowe rozwiązanie to dużo za mało. ;-(

Ze swej strony dziękuję za dyskusję. Możemy ją kiedyś pociągnać w osobnym wątku, wymieniając się doświadczeniami.

Pozdrawiam :)

Także dziękuję i pozdrawiam. ;-)

Temat: Linq - pytanie

Tylko jeszcze na koniec chcialbym zaznaczyć, ze po to "wysmarowalem" ten nudny opis slownika, aby podkreślić, że różniły się one "od labu do labu" znacznie. "Nieco" było po prostu eufemizmem, sporym.

Temat: Linq - pytanie

Adrian O.:
Tylko jeszcze na koniec chcialbym zaznaczyć, ze po to "wysmarowalem" ten nudny opis slownika, aby podkreślić, że różniły się one "od labu do labu" znacznie. "Nieco" było po prostu eufemizmem, sporym.

To że zestaw aparatury wyposażenia każdego laba może i jest inny oraz unikatowy i w konsekwencji wdrożenie jest czasochłonne to nic dziwnego. Figurą retoryczną z mojej strony było jednakże nawiązanie także do braku możliwości uczynienia tego procesu powtarzalnym, możliwym do skrócenia, uproszczenia.

Od tamtej pory doszedł kolejny przypadek testowy.

Tylko tyle? :-(

Uzupełniając, proszę się więc nie dziwić użycia przeze mnie dysfemizmu w kontekście problemu. Przecież w opisanym przypadku mogło nawet nie być błędu w oprogramowaniu. Był tak/nie, że tak przez ciekawość zapytam?

Tym bardziej to nie talki błahy problem, bo szpitali w kraju jest na tyle dużo, że raczej nie będzie błędem, że założymy, że codziennie gdzieś odbywa się aktualizacja oprogramowania o krytycznym znaczeniu dla życia człowieka.

A tutaj skoro po wgraniu aktualizacji oprogramowania życie pacjenta było zagrożone, a później programiści musieli popracować wcale nie oznacza, że to dlatego, że nawalił wdrożeniowiec czy koder!

Przecież tu może być kilka innych poważnych "gniotów". Kolejny przypadek testowy to stanowczo za mało bo wyraźnie opis wskazuje na możliwość "schrzanienia" swojej roboty nie tylko wymienionych lecz także (a może nawet przede wszystkim) przez:
- analityka biznesowego po stronie klienta,
- analityka biznesowego po stronie developera (projektant),
- testera.
I proszę nie odbierać, że staram się dewaluować to konkretne oprogramowanie bo kontekst rozciąga się na całą branżę i nie tylko tę jedną aplikację.

Rola testera oczywista więc nie ma się co rozwodzić, tym bardziej że dostał na koniec nowy przypadek testowy. Podobnie wdrożeniowiec, bo sytuacja, że oprogramowanie działało w ciągu dnia i dopiero w nocy "nawaliło" skłania ku przypuszczeniu, że wykonał on swoją pracę raczej właściwie, gdyż niedociągnięcia w tym zakresie zazwyczaj ujawniają się natychmiast. W kontekście zdarzenia programista wydaje się "chłopcem do bicia" ale ja jestem daleki od "odsądzania go od czci i wiary".

Tutaj aż się prosi aby kopa w d..ę dostali PM, analitycy aby się ruszyli, bo dla mnie także możliwość popełnienia przez nich błędów tutaj się ujawnia. Dla mnie zresztą to jest nawet najbardziej prawdopodobne zdarzenia.

Przecież jeżeli założyć, że w czasie poprzedzającym aktualizację wszyscy pracowali najlepiej jak tylko potrafili, to programista zrobił właściwie to co mu kazano, tester sprawdził i żadnego błędu nie przepuścił, a ten który wgrywał aktualizację nie wykonał nic niezgodnie z procedurą. No bo niby dlaczego tak nie biało być i raczej tak było.

Jeżeli więc tak było jak powyżej to jak to możliwe, ze w nocy tylko cud uratował pacjenta, bo ten kto był na dyżurze z IT akurat był dobrym fachowcem, miał wiedzę i szczęście?

Żadne "cudawianki". ;-)

Przecież programiści mogli przygotować wolną od błędów nową wersję lecz to co im zlecono zostało niewłaściwie podzielone na bloki programowe. W ciągu dnia działało - czyli zapewne realizowano te procedury medyczne, które aktualizacja obejmowała. W nocy szlag trafił - czyli mogła zostać uruchomiona procedura medyczna, której nowa wersja oprogramowania nie obejmowała lecz z racji błędnego projektu analityka współużytkowała funkcjonalności z tymi właśnie zaaktualizowanymi.

Jak przyjdzie czas na opracowywanie nowej wersji tej nocnej procedury medycznej wtedy wszystko zostanie zrobione i sprawdzone. A nowy przypadek testowy jako nauka ze zdarzenia? OK, fajnie, ale jak procedura medyczna która "rozsypała" system złożona, to jeżeli analitycy biznesowi klienta nie przeanalizowali poprawności podziału na bloki dla których opracowuje się nowe wersje na zgodność z procedurami medycznymi, to niech wszyscy także się modlą aby historia nie powtórzyła się z "czymś podobnym".

Podobnie jest z sygnałem alarmowym dla analityka developera (projektanta aplikacji). Przecież jeżeli ten kto aktualizuje system nie jest w stanie na wypadek alarmu szybko przywrócić stanu poprzedniego, tzn że procedura aktualizacji jest "do bani" i/lub system nie jest zaprojektowany? skonfigurowany? jako system bezpieczny i/lub podział na bloki programowe jest błędny i/lub sprzeniewierzono się wzorcowi projektowemu LSP (Liskov Substitution Principle).

O procedurze nie ma co dyskutować bo tu wiadomo w czym rzecz. Architektura systemu da o sobie znać w przypadku braku redundancji na wypadek aktualizacji krytycznych (dotyczących całości? dużej części) aplikacji. A ostatni przypadek świadczy o tym, że być może biblioteki nie są ze sobą zgodne w dół czy też nie zagwarantowano możliwości używania jakieś klasy pochodnej w miejsce klasy nadrzędnej by ta tak wykorzystywana klasa zachowywała się w taki sam sposób, jak bez modyfikacji. Po prostu w hierarchii klas być może nie daje się traktować obiektu jakieś klasy, tak samo jak obiektu klasy bazowej.

Doszedł tylko kolejny przypadek testowy? Pozwolę sobie nie rozwijać nasuwającego mi się dysfemizmu. :-(

Temat: Linq - pytanie

Marek K.:

Tutaj aż się prosi aby kopa w d..ę dostali PM, analitycy aby się ruszyli, bo dla mnie także możliwość popełnienia przez nich błędów tutaj się ujawnia. Dla mnie zresztą to jest nawet najbardziej prawdopodobne zdarzenia.

Doszedł tylko kolejny przypadek testowy? Pozwolę sobie nie rozwijać nasuwającego mi się dysfemizmu. :-(

To takie charakterystyczne - ktoś powinien dostać kopa w d...ę.

Można do tego podejść na dwa sposoby.
1. Ktoś jest winny. Znaleźć, ukarać, zamknąć, problem rozwiązany. A konsekwencje - przecież nie ma konsekwencji. To że o przyszłych problemach nie będzie można dyskutować otwarcie bo ludzie będą się bali kary to nie jest konsekwencja - my przecież w poczuciu sprawiedliwości i prawa ukaraliśmy winnego. A jak ktoś ma wątpliwości to jego problem (do czasu jak znowu przyjdzie sprawiedliwość i prawo i wątpiącego skrócimy o głowę).

2. Wdrożyć procedurę naprawczą (przypadek testowy). Przedyskutować w otwarty sposób. Otwarty to znaczy bez szukania winnego i kozła ofiarnego.

Być może ktoś popełnił błąd, a może nie popełnił - czy coś to zmieni w zaistniałej sytuacji ? Ona się już wydarzyła. Możemy tylko uniknąć takiej sytuacji w przyszłości, ale karząc niestety nie rozwiążemy przyczyn, tylko znajdziemy pierwszego z brzegu kozła ofiarnego. Bo karanie zamyka otwartą dyskusję.

Mało kto wie o tym lepiej jak lekarze. Ci prawdziwi. Którzy starają się leczyć najlepiej, a i tak nie wiadomo dlaczego pacjent umiera.

Gdyby wszyscy tak działali karnie to byśmy nigdzie nie doszli. W wypadkach lotniczych nie zmieniono by procedur. Każda teraźniejsza procedura jest pisana krwią ofiar. I co ?? I szuka się winnych ? Idzie do sądu ? Czy mówi się otwarcie że mechanik mógł popełnić błąd bo procedura nie uwzględniała takiego a takiego przypadku. Na przykład segregacji śrubek w magazynie - był kiedyś wypadek że okno pilota wypadło w czasie lotu. Przyczyną było przykręcenie za krótką śrubką.

Szukając winnych - należałoby skrócić o głowę mechanika. Tymczasem ten zły (i "cywilizowany" świat) zrobił dochodzenie i stwierdził że wina mechanika nie jest jasna bo:
1. Instrukcja wymiany nie miała podanych wymiarów śruby,
2. Śrubki nie były prawidłowo posortowane w magazynie

No to dalej należałoby skrócić o głowę twórcę instrukcji i głównego magazyniera, ale jakoś komisja tego nie zrobiła...

Karanie, szukanie winnych, itp. do niczego konstruktywnego nie prowadzi. O czym wiedzą konstruktorzy lotów kosmicznych (czy skazano kogoś za katastrofy promów kosmicznych ?), wszelkiej maści projektanci i wdrożeniowcy, gdyż z niezawinionymi błędami muszą się stykać codziennie.

Wszystkie te metodyki, zasady, wzorce, są pomocne. Tylko i aż. Ale na końcu jest człowiek, maszyna, program i rzeczywistość. I moment w którym wszystkie metodyki, wzorce, itp można wziąć i wyrzucić bo życie bierze i daje w pysk. I trzeba to przyjąć, zrobić co się da i czego się nie da bo inaczej nie można.

Łatwo się szafuje metodykami. Procedurami. Ale mam takie wrażenie że to jest takie prokuratorskie ważenie włosa na czworo. Ktoś zawinił. Kogoś ukarać to sprawa będzie zamknięta. A to nie tędy droga.

Temat: Linq - pytanie

Mikołaj W.:
Łatwo się szafuje metodykami. Procedurami. Ale mam takie wrażenie że to jest takie prokuratorskie ważenie włosa na czworo. Ktoś zawinił. Kogoś ukarać to sprawa będzie zamknięta. A to nie tędy droga.

Przepraszam, że nie mój komentarz to nie panegiryk wysławiający zdolnych programistów i uświetniający sukces nocnego uruchomienia aplikacji, ale zupełnie nie wyłapałeś sedna tego co napisałem. Czy ja gdziekolwiek domagałem się ukarać? A co to zamyka jak wywnioskowałeś z mojej wypowiedzi? Kop w d..ę aby wszyscy się ruszyli i przeczesali każdy swoją "działkę" to ma być niby kara?

A czy jeżeli osobą która by zmarła podczas feralnego dyżuru była mama, tata, twoje dziecko, tylko dlatego że aktualizowano program i IT nie było w stanie wgrać nowej wersji tak aby nie narażać niczyjego życia, to też byłby komentarz, że szafuję metodykami, że dzielę włosa na czworo?

Proszę jeszcze raz przeczytać to co napisałem a tutaj tylko uzupełnię i może kontekst mojego punktu widzenia będzie bardziej zrozumiały. W przypadku tworzenia tak złożonego systemu jak ten dyskutowany pracownicy podzieleni są na zespoły. Jeżeli ktoś, coś aktualizował i w konsekwencji aplikacja nie działa, to ten który pracuje nad czymś innym zazwyczaj odpowie aby się od niego odwalić. Wcześniej było OK? - tak, inni "mieszali" i jest źle - tak, to w takim razie ten kto "mieszał" niech raczy poprawić bo to on namieszał - taką zazwyczaj usłyszy się odpowiedź.

A co ja przekazuję w kontekście powyższego? To jest błędny pogląd! Logika na chłopski rozum tutaj nie sprawdza się. Nic nie robienie przy ostatnich zmianach nie jest żadną gwarancją nie bycia odpowiedzialnym za jej aktualne nieprawidłowe działanie. :-(

Wszyscy korzystają z efektów swojej wcześniejszej pracy i wystarczy, że albo ta wcześniejsza praca została podzielona bez uwzględnienia bieżącego kontekstu, lub korzysta się w inny niż dotychczasowy z funkcji bibliotecznych pisanych przez innych, a problemy pojawić się mogą w najbardziej nieoczekiwanych momentach. :-(