SOWA OPAC : Katalog komputerowy książek, czasopism i zbiorów specjalnych

9 wyników

Książka

W koszyku

Autor

Bass Len. Clements Paul (1955- ). Kazman Rick. Walczak Tomasz.

Forma i typ

Książki Publikacje fachowe

Odbiorca

Programiści

Temat

Architektura oprogramowania Programowanie (informatyka) Programy komputerowe

Gatunek

Podręcznik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

Wydanie 4. odnosi się do oryginału.

Bibliografia, netografia na stronach 493-510. Indeks.

Atrybuty jakościowe Dostępność Łatwość wdrażania Efektywność energetyczna Integrowalność Modyfikalność Wydajność Bezpieczeństwo Zabezpieczenia Testowalność Użyteczność Praca nad innymi atrybutami jakościowymi Interfejsy oprogramowania Wirtualizacja Chmura i przetwarzanie rozproszone Systemy mobilne Wymagania o znaczeniu architektonicznym Projektowanie architektury Ewaluacja architektury Dokumentowanie architektury Zarzadzanie długiem architektonicznym Rola architektów w projektach Przetwarzanie kwantowe

Sygnatura czytelni BWEAiI: XII J 114

dostępna w czytelni

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 152995 (1 egz.)

Książka

W koszyku

Autor

Buczyński Sebastian (informatyka).

Forma i typ

Książki Publikacje fachowe

Odbiorca

Programiści

Temat

Aplikacja internetowa Architektura oprogramowania Programowanie (informatyka) Python (język programowania)

Gatunek

Podręcznik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

Bibliografia, netografia na stronach 279-280.

Dla średnio zaawansowanych programistów zajmujących się rozwojem aplikacji internetowych.

Era narzędzi . PODSTAWY CZYSTEJ ARCHITEKTURY . System płytki kontra system głęboki . CRUD, czyli system płytki 2.3. Założenia czystej architektury Niezależność od frameworków Wysoka testowalność Niezależność od API i interfejsu użytkownika . Niezależność od bazy danych . Niezależność od firm trzecich Elastyczność Rozszerzalność Warstwy, czyli horyzontalna organizacja kodu Świat zewnętrzny Infrastruktura . Aplikacja Domena Zasada zależności . Granice IMPLEMENTOWANIE CZYSTEJ ARCHITEKTURY W PYTHONIE WZORCOWA IMPLEMENTACJA Oznajmienie Przepływ sterowania w czystej architekturze Wymagania biznesowe . Implementacja Diagram sekwencji Granica wejściowa (input boundary) Granica wyjściowa (output boundary) Prezenter (presenter) . Model widoku (view model) Przypadek użycia (use case) Interfejs dostępu do danych (data access interface) Dostęp do danych (data access) Encja oferty (bid) Encja aukcji (auction) 4. MODYFIKACJE CZYSTEJ ARCHITEKTURY Dylemat prezentera Pozbywamy się granicy wejściowej Alternatywne podejścia do projektowania przypadków użycia Fasada Mediator pomiędzy wejściowym DTO a przypadkiem użycia. Użycie modeli bazodanowych jako encji WSTRZYKIWANIE ZALEŻNOŚCI . Wszędobylskie abstrakcje i klasy Abstrakcje w czystej architekturze . Odwrócenie sterowania a zależności Kontener IoC kontra service locator . Wstrzykiwanie zależności kontra konfiguracja CQRS Co to ma wspólnego z czystą architekturą? Osobny stos odczytu Zapytanie jako DTO Zapytania jako osobne klasy Fasada modelu do odczytu CQRS kontra REST API CQRS kontra GraphQL Słowo o złożoności Granica pomiędzy warstwą aplikacji a światem zewnętrznym Pisanie wejściowego DTO Value objects PLATFORMA AUKCYJNA Jak zacząć, czyli chodzący szkielet . Przypadek użycia dla składania oferty na aukcji Nazewnictwo Argumenty Encje aukcji i oferty Nazewnictwo Value objects jako identyfikatory Implementacja . Testy jednostkowe Implementacja Abstrakcyjne repozytorium Implementacja Implementacja działająca w pamięci Rozwijanie implementacji pod osłoną TDD Kończymy przypadek użycia — składanie oferty Wstrzykiwanie zależności Sprawiamy, że pierwszy sensowny test przechodzi . Refaktoryzacja Organizacja kodu Jak można ułożyć kod w Pythonie? Organizujemy kod projektu Organizujemy kod warstwy infrastruktury Łączymy wszystko razem w komponencie main Wystawiamy API IMPLEMENTOWANIE CZYSTEJ ARCHITEKTURY W PYTHONIE Finalizujemy aukcję w kolejnym przypadku użycia Zarys przypadku użycia i wejściowe DTO Rozszerzamy encję, by spełnić nowe wymagania Skoro encje nie powinny mieć żadnych zależności, Wprowadzamy port dla płatności . Implementujemy adapter Obsługa błędów kontra zasada zależności A co, gdybyśmy chcieli dodać zapamiętywanie karty płatniczej? Jak żyć, gdy adapter rośnie? Bramka płatności ma już SDK. Nie możemy go po prostu użyć? Przypadek użycia — rozpoczynanie nowej aukcji Skąd się biorą nowe aukcje? Encja aukcji i jej opis w jednym obiekcie — za i przeciw Wprowadzamy deskryptor Repozytorium z interfejsem kolekcji Które repozytorium wybrać? Operacje odczytu danych Podejście z przypadkami użycia CQRS na ratunek Zapytania jako klasa Model do odczytu Podsumowanie operacji odczytujących dane Odwracamy kontrolę za pomocą zdarzeń wysyłka e-maili . Techniki odwracania kontroli . Implementacja zdarzeń Skąd wziąć szynę zdarzeń? Jak wydostać zdarzenia z encji? Encja gromadzi zdarzenia, które potem publikuje repozytorium . Encja zwraca zdarzenia z metod, które zmieniają jej stan Testowanie encji, które zwracają zdarzenia Subskrybowanie się na zdarzenia Zdarzenia kontra transakcje kontra efekty uboczne Niezawodne publikowanie zdarzeń — outbox pattern Wprowadzamy jednostkę pracy Czas życia jednostki pracy Relacja pomiędzy jednostką pracy a szyną zdarzeń Radzimy sobie z innymi przekrojowymi zagadnieniami Konfiguracja Walidacja Synchronizacja MODULARNOŚĆ Ciężar sukcesu — rozrost i ciągłe zmiany Komponenty i kohezja Organizacja kodu według komponentu Komponenty i swoboda architektoniczna . Komponenty kontra mikroserwisy Komponenty a użytkownik Komponenty a bounded context Komponenty — implementacja Zależności między komponentami Oddzielne drogi Bezpośrednia zależność Niebezpośrednia zależność Zależność, gdy jeden z komponentów nie implementuje czystej architektury Odmiany integracji za pomocą zdarzeń Zależności między komponentami — podsumowanie platforma aukcyjna Odkrywamy komponenty Komponenty platformy aukcyjnej Co komponent wystawia na zewnątrz? . Tam, gdzie wszystko składa się w całość — komponent main Korzystamy z komponentu main do uruchomienia aplikacji Jedna architektura dla wszystkich komponentów Zależności pomiędzy komponentami Integrowanie komponentów za pomocą zdarzeń Wewnętrzna obsługa zdarzeń w tym samym komponencie Integracja różnych komponentów za pomocą zdarzeń — Integracja różnych komponentów za pomocą zdarzeń. Inne ciekawe zastosowania menadżera procesu Menadżer procesu kontra wyścigi IMPLEMENTOWANIE CZYSTEJ ARCHITEKTURY W PYTHONIE TESTOWANIE Strategia testowania i odmiany funkcji Piramida testów — mit czy jedyna słuszna droga? Jak przetestować przeglądarkę do bazy danych? Jak przetestować proxy? Jak przetestować system głęboki? Odkrywamy testowanie jednostkowe na nowo Ile musi wiedzieć test? Testowanie stanu kontra testowanie interakcji Niebezpieczeństwa związane z inspekcją stanu Niebezpieczeństwa związane ze sprawdzaniem interakcji Stuby kontra mocki Rodzaje obiektów dublerów Testujemy cały komponent jednostkowo . Ustawiamy komponent w pożądanym stanie Wywołujemy akcję na komponencie Weryfikujemy rezultat akcji na poziomie komponentu Radzimy sobie z zależnościami w postaci portów i repozytoriów MIGRACJA Z PROJEKTU ODZIEDZICZONEGO „Nie mogę przestać dostarczać nowych funkcji!” SUPLEMENT B: WPROWADZENIE DO EVENT SOURCING Co to jest event sourcing? Agregat z event sourcing kontra agregat z domain-driven design Prosty przykład agregatu Zamówienie jako encja Istotne zmiany zamówienia w formie zdarzeń Zamówienie jako agregat . Testowanie agregatów . Persystencja Nowe zdarzenia są dołączane na koniec strumienia zdarzeń Pobieranie strumienia zdarzeń . Dopisywanie nowych zdarzeń do strumienia . Wybór bazy danych — podsumowanie wymagań Przykładowa implementacja z użyciem PostgreSQL Użycie event store Co robić, gdy wykryjemy wyścig? Użycie repozytorium do ukrycia event store Migawki stanu agregatu Projekcje Event sourcing w aplikacji składającej się z komponentów Event sourcing to szczegół implementacyjny komponentu Stosuj zdarzenia domenowe na potrzeby integracji

Sygnatura czytelni BWEAiI: XII Ł 218

dostępna w czytelni

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 153019 (1 egz.)

Książka

W koszyku

Architektura ewolucyjna : projektowanie oprogramowania i wsparcie zmian / Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage ; przekład: Krzysztof Sawka. - Gliwice : Helion, 2023. - 230, [2] strony : ilustracje, wykresy ; 24 cm.

Autor

Ford Neal (1942- ). Parsons Rebecca. Kua Patrick. Sadalage Pramod J. Sawka Krzysztof.

Forma i typ

Książki Publikacje fachowe

Odbiorca

Architekci oprogramowania

Temat

Architektura oprogramowania

Gatunek

Poradnik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

Wydanie II - dotyczy oryginału.

Na okładce także nazwa wydawcy oryginału: O'Reilly.

Mechanika Ewoluowanie architektury oprogramowania Architektura ewolucyjna Zmiana kierowana przyrostowa Wielowymiarowość architektury W jaki sposób możemy po stworzeniu architektury zabezpieczyć ją przed degradacją2. Funkcje dopasowania Kategorie Zakres: atomowe/holistyczne Miarowość: wywoływane/ciągłe/czasowe Rezultat: statyczne/dynamiczne Wywołanie: zautomatyzowane/ręczne Proaktywność: zamierzone/wyłaniające się Pokrycie: funkcje dopasowania specyficzne dla domeny? Kto pisze funkcje dopasowania? Gdzie znajduje się platforma testowania moich funkcji dopasowania? Rezultaty a implementacje Zmiana przyrostowa Potoki wdrażania : dodawanie funkcji dopasowania do usługi fakturowania w firmie Kapitalne Patenty : sprawdzanie spójności API w automatycznych kompilacjach Automatyzacja zarządzania architekturą Funkcje dopasowania w zarządzaniu architekturą Funkcje dopasowania na poziomie kodu Sprzężenie aferentne i eferentne Abstrakcyjność, niestabilność i odległość od głównej sekwencji Kierunkowość importowanych elementów Złożoność cyklomatyczna i zarządzanie przez kierowanie zespołami Kompletne narzędzia Legalność otwartych bibliotek A11y i inne obsługiwane parametry architektury ArchUnit Lintery do zarządzania kodem : funkcja dopasowania dostępności testowanie obciążenia wraz z wydaniami kanarkowymi Funkcje dopasowania, z których już korzystasz Architektura integracji Zarządzanie komunikacją w mikrousługach DevOps Architektura korporacyjna: restrukturyzacja architektury podczas 60 wdrożeń dziennie Funkcje dopasowania wierności Dokumentowanie funkcji dopasowania Splątanie Skrzyżowanie splątania z ograniczonym kontekstem Kwanty architektury i ziarnistość Wysoce funkcjonalna spójność Znaczne sprzężenie statyczne Sprzężenie dynamiczne kwantu Kontrakty : mikrousługi jako architektura ewolucyjna Wzorce wieloużywalności kodu Skuteczna wieloużywalność = abstrakcja + mała ulotność Przyczepy i siatka usług: ortogonalne sprzężenie operacyjne Siatka danych: sprzężenie ortogonalne danych. Dane ewolucyjne Projektowanie ewolucyjnej bazy danych Ewoluowanie schematów Integracja współdzielonych baz danych Nieprawidłowe nakładanie się danych Zatwierdzanie dwufazowe transakcji Wiek i jakość danych : ewolucja trasowania w firmie Kapitalne Patenty Od funkcji natywnej do funkcji dopasowania

Zgodność powiązań Duplikacja danych Zastępowanie wyzwalaczy i przechowywanych procedur Analiza przypadku: ewoluowanie od architektury relacyjnej do nierelacyjnej Tworzenie ewoluowalnych architektur Zasady architektury ewolucyjnej Projektuj i twórz z myślą o ewoluowalności Prawo Postela Projektuj z myślą o testowalności Prawo Conwaya Mechanika Identyfikacja wymiarów podlegających ewolucji Definiowanie funkcji dopasowania dla każdego wymiaru Stosowanie potoku wdrażania do automatyzacji funkcji dopasowania Modernizowanie istniejących architektur Prawidłowe sprzężenie i spójność Skutki stosowania modelu COTS Migrowanie architektur Etapy migracji Ewoluowanie oddziaływań pomiędzy modułami Wskazówki dotyczące tworzenia architektur ewolucyjnych Usuń niepotrzebną zmienność Zagwarantuj odwracalność decyzji Przedkładaj ewoluowalność nad przewidywalność Twórz warstwy przeciwdegradacyjne Tworzenie architektur ofiarniczych Minimalizuj wpływ zmian zewnętrznych Aktualizowanie bibliotek i szkieletów Wersjonuj usługi wewnętrznie ewoluowanie systemu oceniania w firmie Kapitalne Patenty Architektura sterowana funkcjami dopasowania Pułapki i antywzorce architektury ewolucyjnej Architektura techniczna Antywzorzec: pułapka ostatnich 10% i mało kodu/ brak kodu : wieloużywalność w firmie Kapitalne Patenty Antywzorzec: monopolista Pułapka: nieszczelne abstrakcje Pułapka: projektowanie zorientowane na CV Zmiany przyrostowe Antywzór: nieprawidłowe zarządzanie : zarządzanie „na styk” w firmie Kapitalne Patenty Pułapka: brak szybkości wydawania Kwestie biznesowe Pułapka: dostosowywanie produktu Antywzorzec: raportowanie na wierzchu systemu rekordów Pułapka: nadmiernie długie horyzonty planowania Stosowanie architektury ewolucyjnej w praktyce Czynniki organizacyjne Nie walcz z prawem Conwaya Parametry sprzężenia zespołów Kultura Kultura eksperymentowania Dyrektor finansowy i przygotowywanie budżetu Kwestia biznesowa Projektowanie zorientowane na hipotezy i dane Funkcje dopasowania jako media eksperymentalne Tworzenie korporacyjnych funkcji dopasowania : podatność zabezpieczeń na ataki dnia zerowego Wyznaczanie ograniczonych kontekstów w istniejącej architekturze integracji Testowanie Infrastruktura : architektura korporacyjna w firmie Kapitalne Patenty Funkcje dopasowania wykorzystujące sztuczną inteligencję Testowanie generatywne

Sygnatura czytelni BWEAiI: XII A 102

dostępna w czytelni

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 154650 N (1 egz.)

Książka

W koszyku

Autor

Geers Michael Stangel Karolina

Forma i typ

Książki Publikacje fachowe

Odbiorca

Programiści

Temat

Aplikacja internetowa Architektura oprogramowania Interfejs użytkownika Programowanie (informatyka)

Gatunek

Podręcznik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

Dla programistów aplikacji internetowych, architektów oprogramowania i inżynierów.

CZĘŚĆ I POCZĄTEK PRZYGODY Z MIKROFRONTENDAMI (21) 1. Czym jest mikrofrontend? (23) 1.1. Szerszy kontekst (24) 1.1.1. Systemy i zespoły (26) 1.1.2. Frontend (28) 1.1.3. Integracja frontendu (31) 1.1.4. Wspólne tematy (32) 1.2. Jakie problemy rozwiązuje architektura mikrofrontendowa? (34) 1.2.1. Optymalizacja rozwoju funkcjonalności (34) 1.2.2. Precz z frontendowym monolitem (34) 1.2.3. Gotowość na zmiany (36) 1.2.4. Korzyści z niezależności (38) 1.3. Wady architektury mikrofrontendowej (40) 1.3.1. Redundancja (40) 1.3.2. Spójność (41) 1.3.3. Różnorodność technologii (41) 1.3.4. Więcej kodu frontendowego (42) 1.4. Kiedy stosować model mikrofrontendowy? (42) 1.4.1. Dla średnich i dużych projektów (42) 1.4.2. Najlepiej działa w sieci (43) 1.4.3. Produktywność i koszty (44) 1.4.4. Kiedy unikać mikrofrontendów? (44) 1.4.5. Kto używa mikrofrontendów? (45) 2. Mój pierwszy projekt mikrofrontendowy (49) 2.1. Przedstawiamy TraktoryOnline (50) 2.1.2. Uruchamianie aplikacji (52) 2.2. Przejścia między stronami za pomocą łączy (54) 2.2.1. Własność danych (54) 2.2.2. Kontrakt między zespołami (55) 2.2.4. Zmiany adresów URL (59) 2.2.7. Kiedy stosować łącza? (60) 2.3. Kompozycja za pomocą ramek iframe (61) 2.3.4. Kiedy stosować ramki iframe? (64) CZĘŚĆ II ROUTING, KOMPOZYCJA I KOMUNIKACJA (67) 3. Kompozycja techniką AJAX i routing po stronie serwera (69) 3.1. Kompozycja techniką AJAX (70) 3.1.2. Przestrzenie nazw dla stylów i skryptów (73) 3.1.3. Deklaratywne ładowanie z biblioteką h-include (76) 3.1.6. Kiedy stosować technikę AJAX? (79) 3.2. Routing przez współdzielony serwer WWW (80) 3.2.2. Przestrzenie nazw dla zasobów (85) 3.2.3. Metody konfiguracji przekierowań (86) 3.2.4. Odpowiedzialność za infrastrukturę (87) 3.2.5. Kiedy stosować? (88) 4. Kompozycja po stronie serwera (91) 4.1. Kompozycja - Nginx i SSI (92) 4.1.2. Szybsze ładowanie (95) 4.2. Obsługa niepewnych fragmentów (97) 4.2.1. Zawodny fragment (97) 4.2.2. Integracja fragmentu "W okolicy" (98) 4.2.3. Limity czasu i treści zastępcze (99) 4.2.4. Treści zastępcze (101) 4.3. Analiza wydajności łączenia fragmentów (102) 4.3.1. Ładowanie równoległe (102) 4.3.2. Zagnieżdżone fragmenty (103) 4.3.3. Opóźnione ładowanie (103) 4.3.4. Czas do odebrania pierwszego bajta a streaming (104) 4.4. Szybki przegląd innych rozwiązań (106) 4.4.1. Edge-Side Includes (106) 4.4.2. Tailor firmy Zalando (107) 4.4.3. Podium (109) 4.4.4. Którego rozwiązania użyć? (115) 4.5. Zalety i wady kompozycji po stronie serwera (115) 4.5.3. Kiedy integracja po stronie serwera ma sens? (117) 5. Kompozycja po stronie klienta (119) 5.1. Mikrofrontend w komponencie webowym (120) 5.1.1. Jak to zrobić? (122) 5.1.2. Framework w komponencie webowym (126) 5.2. Izolacja stylów dzięki mechanizmowi Shadow DOM (128) 5.2.1. Tworzenie ukrytego elementu głównego (128) 5.2.2. Ograniczenie widoczności stylów (129) 5.2.3. Kiedy używać mechanizmu Shadow DOM? (131) 5.3. Zalety i wady komponentów webowych jako metody kompozycji (132) 5.3.3. Kiedy integracja po stronie klienta ma sens? (133) 6. Wzorce komunikacji (135) 6.1. Komunikacja interfejsów użytkownika (136) 6.1.1. Od komponentu nadrzędnego do podrzędnego (137) 6.1.2. Komunikacja od komponentu podrzędnego do nadrzędnego (140) 6.1.3. Komunikacja między fragmentami (144) 6.1.4. Mechanizm publikacji/subskrypcji interfejsu API Broadcast Channel (148) 6.1.5. Kiedy komunikacja między interfejsami użytkownika się sprawdza? (149) 6.2. Inne mechanizmy komunikacji (150) 6.2.1. Globalny kontekst i autentykacja (151) 6.2.2. Zarządzanie stanem (152) 6.2.3. Komunikacja między frontendem a backendem (153) 6.2.4. Replikacja danych (153) 7. Routing po stronie klienta i powłoka aplikacji (157) 7.1. Powłoka aplikacji z płaskim routingiem (160) 7.1.1. Czym jest powłoka aplikacji? (160) 7.1.2. Anatomia powłoki aplikacji (160) 7.1.3. Routing po stronie klienta (162) 7.1.4. Renderowanie stron (164) 7.1.5. Kontrakty między powłoką aplikacji a zespołami (167) 7.2. Powłoka aplikacji z dwupoziomowym routingiem (168) 7.2.1. Router pierwszego poziomu (169) 7.2.2. Routing na poziomie zespołu (170) 7.2.3. Co się dzieje przy zmianie adresu? (171) 7.2.4. Interfejsy API powłoki aplikacji (174) 7.3. Rzut oka na metaframework single-spa (175) 7.3.1. Jak działa single-spa? (176) 7.4. Wady połączonych aplikacji jednostronicowych (181) 7.4.1. Tematy do przemyślenia (181) 7.4.2. Kiedy stosować połączone aplikacje jednostronicowe? (184) 8. Kompozycja i uniwersalne renderowanie (187) 8.1. Połączenie dwóch kompozycji (188) 8.1.1. Mechanizm SSI i komponenty webowe (190) 8.1.2. Kontrakt między zespołami (194) 8.1.3. Inne rozwiązania (195) 8.2. Kiedy stosować uniwersalną kompozycję? (195) 8.2.1. Uniwersalne renderowanie z kompozycją wyłącznie po stronie serwera (196) 8.2.2. Większa złożoność (196) 8.2.3. Uniwersalnie renderowane połączone aplikacje jednostronicowe? (196) 9. Który rodzaj architektury pasuje do mojego projektu? (199) 9.1. Przypomnienie terminologii (200) 9.1.1. Routing i przejścia między stronami (201) 9.1.2. Metody kompozycji (201) 9.1.3. Wysokopoziomowe modele architektoniczne (203) 9.2. Porównanie złożoności (206) 9.2.1. Architektoniczna niejednorodność (207) 9.3. Witryna czy aplikacja? (207) 9.3.1. Kontinuum między dokumentem a aplikacją (208) 9.3.2. Serwer, klient czy uniwersalne renderowanie? (209) 9.4. Wybór odpowiedniej architektury i metody integracji (210) 9.4.1. Silna izolacja (przestarzały kod / kod strony trzeciej) (212) 9.4.2. Szybkie pierwsze załadowanie / stopniowe ulepszanie (212) 9.4.3. Błyskawiczna reakcja (213) 9.4.4. Miękka nawigacja (214) 9.4.5. Wiele mikrofrontendów na jednej stronie (214) CZĘŚĆ III SZYBKOŚĆ, SPÓJNOŚĆ I EFEKTYWNOŚĆ (217) 10. Ładowanie zasobów (219) 10.1. Strategie odnoszenia się do zasobów (220) 10.1.1. Odniesienia bezpośrednie (220) 10.1.2. Cache-busting a niezależne wdrożenia (221) 10.1.3. Odniesienie przez przekierowanie (klient) (222) 10.1.4. Odniesienia w dyrektywie include (225) 10.1.5. Synchronizacja wersji kodu i zasobów (227) 10.1.6. Zasoby we fragmencie (230) 10.1.7. Zintegrowane rozwiązania (Tailor, Podium itp.) (230) 10.1.8. Szybkie podsumowanie (232) 10.2. Podział na pakiety (233) 10.2.1. Protokół HTTP/2 (233) 10.2.2. Wszystko w jednym pakiecie (234) 10.2.3. Pakiet na zespół (235) 10.2.4. Pakiet dla każdej strony i fragmentu (235) 10.3. Ładowanie na żądanie (235) 10.3.1. Komponenty pośredniczące (236) 10.3.2. Opóźnione ładowanie stylów (237) 11. Wydajność to klucz (239) 11.1. Projektowanie z myślą o wydajności (240) 11.1.1. Różne zespoły, różne pomiary (240) 11.1.2. Międzyzespołowy budżet wydajności (242) 11.1.3. Odpowiedzialność za spowolnienia (243) 11.1.4. Korzyści w obszarze wydajności (244) 11.2. Biblioteki zewnętrzne (246) 11.2.1. Koszt autonomii (246) 11.2.2. Małe jest piękne (247) 11.2.3. Jedna globalna wersja (249) 11.2.4. Wersjonowane pakiety z bibliotekami zewnętrznymi (250) 11.2.5. Unikaj współdzielenia kodu biznesowego (262) 12. Interfejs użytkownika i system projektowania (265) 12.1. Po co nam system projektowania? (266) 12.1.1. Cel i rola (268) 12.1.2. Korzyści (268) 12.2. Centralny system projektowania a autonomia zespołów (269) 12.2.1. Czy potrzebuję własnego systemu projektowania? (269) 12.2.2. Proces, a nie projekt (270) 12.2.3. Stały budżet i odpowiedzialność (270) 12.2.4. Poparcie zespołów (271) 12.2.5. Proces rozwoju - centralny czy federacyjny? (273) 12.2.6. Etapy rozwoju (274) 12.3. Integracja w czasie wykonania czy wersjonowanie? (276) 12.3.1. Integracja w czasie wykonania (276) 12.3.2. Wersjonowany pakiet (278) 12.4. Artefakty generyczne i specyficzne (281) 12.4.1. Wybór formatu komponentów (281) 12.4.2. Nieuchronne zmiany (285) 12.5. Co powinno wchodzić w skład centralnej biblioteki wzorców? (286) 12.5.1. Koszt współdzielenia komponentów (286) 12.5.2. Centralny czy lokalny? (286) 12.5.3. Centralne i lokalne biblioteki wzorców (289) 13. Zespoły i granice (293) 13.1. Dopasowanie między systemami i zespołami (294) 13.1.1. Granice między zespołami (295) 13.1.2. Głębia integracji (297) 13.1.3. Zmiana kulturowa (300) 13.2. Dzielenie się wiedzą (301) 13.2.1. Wspólnota praktyków (302) 13.2.2. Nauka (303) 13.2.3. Zaprezentuj swoją pracę (303) 13.3. Globalne problemy (303) 13.3.1. Centralna infrastruktura (304) 13.3.2. Zespół ds. specjalistycznych komponentów (305) 13.3.3. Globalne uzgodnienia i konwencje (305) 13.4. Różnorodność technologiczna (306) 13.4.1. Zestawy narzędzi i opcje domyślne (306) 13.4.2. Szablon frontendowy (306) 13.4.3. Odrzuć strach przed kopiowaniem (308) 13.4.4. Wartość podobieństw (308) 14. Migracje, lokalne środowisko rozwojowe i testowanie (311) 14.1. Migracja (312) 14.1.1. Model koncepcyjny na przetarcie szlaku (312) 14.1.2. Strategia nr 1: kawałek po kawałku (314) 14.1.3. Strategia nr 2: najpierw frontend (315) 14.1.4. Strategia nr 3: od zera do wielkiego wybuchu (317) 14.2. Rozwój w środowisku lokalnym (318) 14.2.1. Bez kodu pozostałych zespołów (319) 14.2.2. Tworzenie atrap fragmentów (319) 14.2.3. Fragmenty w izolacji (321) 14.2.4. Pobieranie mikrofrontendów innych zespołów ze środowiska testowego lub produkcji (323) 14.3. Testowanie (323)

Sygnatura czytelni BWEAiI: XII N 158

dostępna do wypożyczenia

Ta pozycja znajduje się w zbiorach 2 placówek. Rozwiń listę, by zobaczyć szczegóły.

Wypożyczalnia

Są egzemplarze dostępne do wypożyczenia: sygn. 151378 (1 egz.)

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 151377 N (1 egz.)

Książka

W koszyku

Zostań architektem oprogramowania : zaprojektuj swoja karierę! / Michael Keeling ; przekład Mariusz Rogulski, Magdalena Rogulska na zlecenie WITKOM Witold Sikorski. - Wydanie 1. - Warszawa : Wydawnictwo Naukowe PWN, 2019. - XVII, [1], 336 stron : ilustracje (w tym kolorowe) ; 24 cm.

Autor

Keeling Michael (programista). Rogulski Mariusz. Rogulska Magdalena.

Temat

Architektura oprogramowania.

U góry okładki nazwa serii oryginału: The Pragmatic Programmers.

Na stronie redakcyjnej ISBN wydania oryginalnego: 978-1-68050-209-1.

Bibliografia na stronach 333-336.

Wprowadzenie do architektury oprogramowania Zostać architektem oprogramowania Czym zajmują się architekci oprogramowania? Czym jest architektura oprogramowania? Zostańmy architektami w naszym zespole Budowanie niesamowitego oprogramowania Studium przypadku: Projekt Lionheart Podstawy myślenia projektowego Cztery zasady myślenia projektowego Zastosowanie nastawienia projektowego Myślenie, robienie, sprawdzanie Podstawy projektowania architektury Opracowywanie strategii projektowania Poszukiwanie satysfakcjonującego projektu Decydowanie, ile zaprojektować na początku Niech ryzyko będzie naszym przewodnikiem Tworzenie planu projektowania Projekt Lionheart: do tej pory... 4. Wczuwanie się w interesariuszy Rozmawianie z właściwymi ludźmi Tworzenie mapy interesariuszy Odkrywanie celów biznesowych Projekt Lionheart: do tej pory Go dalej 5. W poszukiwaniu wymagań istotnych dla architektury Zawężanie możliwości projektowych za pomocą ograniczeń Definiowanie atrybutów jakościowych Poszukiwanie klas wymagań funkcjonalnych Dowiedzmy się, co jeszcze wpływa na architekturę Poszukiwanie potrzebnych informacji Budowanie specyfikacji ASR Projekt Lionheart: do tej pory 6. Wybór architektury (zanim ona wybierze nas) Rozszerzamy, aby dostrzegać możliwości, zawężamy, aby decydować Akceptowanie ograniczeń Wspieranie pożądanych atrybutów jakościowych Przypisywanie elementom funkcjonalnych obowiązków Projektowanie z myślą o zmianach Projekt Lionheart: do tej pory 7.Tworzenie fundamentów z użyciem wzorców Czym jest wzorzec architektoniczny? Wzorzec warstwowy Wzorzec porty i adaptery Wzorzec potoki i filtry Wzorzec architektury zorientowanej na usługi Wzorzec publish-subscribe Wzorzec współdzielonych danych Wzorzec wielowarstwowy Wzorzec centrum kompetencji Wzorzec otwartego udziału Wzorzec wielkiej kuli błota Odkrywanie nowych wzorców Projekt Lionheart: do tej pory 8. Zarządzanie złożonością za pomocą sensownych modeli Myślenie o architekturze Projektowanie metamodelu Wbudowywanie modeli do kodu Projekt Lionheart: do tej pory 9- Prowadzenie architektonicznych warsztatów projektowych Planowanie architektonicznych warsztatów projektowych Wybieranie odpowiednich działań projektowych Zapraszanie właściwych uczestników Zarządzanie grupą Praca z rozproszonymi zespołami Projekt Lionheart: do tej pory Co dalej 10. Wizualizacja decyzji projektowych Przedstawianie architektury z różnych perspektyw Rysowanie fantastycznych diagramów Projekt Lionheart: do tej pory 11- Opisywanie architektury Opowiadanie całej historii Dopasowywanie metody opisu do sytuacji Szanowanie swoich odbiorców Tworzenie widoków wokół potrzeb interesariuszy Wyjaśnianie powodów naszych decyzji Projekt Lionheart: do tej pory 12. Karty oceny dla architektury Ocenianie służy uczeniu się Testowanie projektu Prowadzenie warsztatów ewaluacyjnych Oceniajmy wcześnie, oceniajmy często, oceniajmy w sposób ciągły Projekt Lionheart: do tej pory 8.Wzmacnianie architektów w zespole Promowanie myślenia architektonicznego Ułatwianie podejmowania decyzji i wspieranie rozwoju umiejętności Stworzenie możliwości bezpiecznej praktyki Delegowanie kompetencji projektowych Wspólne projektowanie architektury Projekt Lionheart: epickie podsumowanie Skrzynka narzędziowa architekta 9. Działania na rzecz zrozumienia problemu Działanie 1. Wybór jednej rzeczy Działanie 2. Mapa empatii Działanie 3. Warsztaty cel-pytanie-metryka Działanie 4, Wywiad z interesariuszami Działanie 5. Lista założeń Działanie 6. Sieć atrybutów jakościowych Działanie 7. Miniwarsztaty atrybutów jakościowych Działanie 8. Mad łib „punkty widzenia" Działanie 9. Miara odpowiedzi sofizmatu rozszerzenia Działanie 10. Mapa interesariuszy 10. Działania wcelu zbadania potencjalnych rozwiązań Działanie 11.Personifikacja architektury Działanie 12.Architektoniczny fłipbook Działanie 13.Karty komponent-odpowiedzialność-współpracownilc Działanie 14.Mapa pojęć Działanie 15.Dzielenie i zdobywanie Działanie 16.Burza zdarzeń Działanie 17.Grupowe postery Działanie 18.Projektowanie karuzelowe Działanie 19.Wspólna sesja przy białej tablicy 11.Działania służące osiągnięciu namacalności projektu .. Działanie 20. Zapisy decyzji architektonicznych Działanie 21. Architektoniczne haiku Działanie 22. Diagram kontekstowy Działanie 23. Lista najpopularniejszych haseł Działanie 24. Tablica koncepcyjna Działanie 25. Modularny diagram dekompozycji Działanie 26. Odrzucone ścieżki Działanie 27. Prototypowanie w celu zdobycia wiedzy łub podjęcia decyzji Działanie 28. Diagram sekwencji Działanie 29. Metafora systemowa 12.Działania służące ocenie możliwości projektowych Działanie 30. Briefing architektury Działanie 31. Przegląd kodu Działanie 32. Macierz decyzyjna Działanie 33. Obserwacja zachowania Działanie 34. Pytanie-komentarz-potrzeba Działanie 35. Burza ryzyk Działanie 36. Sprawdzanie poczytalności Działanie 37. Przegląd scenariusza Działanie 38. Szkicowanie i porównywanie

Sygnatura czytelni BWEAiI: XII J 101

dostępna w czytelni

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 148591 N (1 egz.)

Brak okładki

Książka

W koszyku

Mikrousługi : budowa i działanie : przewodnik po budowaniu architektury mikrousług / Ronnie Mitra, Irakli Nadareishvili ; przekład: Marek Włodarz. - Warszawa : APN Promise, 2021. - XII, 307, [1] strona : ilustracje ; 23 cm.

Autor

Mitra Ronnie Nadareishvili Irakli. Włodarz Marek.

Forma i typ

Książki Publikacje dydaktyczne Publikacje fachowe

Temat

Architektura oprogramowania Mikroserwis

Gatunek

Podręcznik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

Tytuł oryginału: Microservices Up and Running.

Na stronie tytułowej i okładce: O'REILLY®.

Indeks.

1. W stronę architektury mikrousług Czym są mikrousługi? Redukowanie kosztów koordynacji Problem kosztów koordynacji Trudne części Nauka przez praktykę Model mikrousług "Up and Running" Decyzje, decyzje Tworzenie lekkiego rekordu decyzji architektonicznej 2. Projektowanie modelu operacyjnego mikrousług Dlaczego ludzie i zespoły są istotne Wielkość zespołu Umiejętności zespołu Koordynacja międzyzespołowa Przedstawiamy Team Topologies Typy zespołów Tryby interakcji Projektowanie topologii zespołu mikrousług Ustanowienie zespołu projektowania systemu Budowanie szablonu zespołu mikrousług Zespoły platformowe Zespoły umożliwiające i skomplikowanych podsystemów Zespoły konsumentów 3. Projektowanie mikrousług: proces SEED(S) Wprowadzenie do siedmiu zasadniczych ewolucji projektowania usług: Metoda SEED(S) Identyfikowanie aktorów Przykładowi aktorzy w naszym projekcie Identyfikowanie zadań, które mają wykonywać aktorzy Używanie formatu historyjki zadania do formułowania JTBD Przykłady JTBD w naszym projekcie Odkrywanie wzorców interakcji za pomocą diagramów sekwencji Wyprowadzanie akcji i zapytań z JTBD Przykład zapytań i akcji w naszym projekcie Opisywanie każdego zapytania i akcji jako Open API Spec Przykład OAS dla akcji w naszym projekcie Uzyskanie informacji zwrotnych na temat specyfikacji API Implementowanie mikrousług Mikrousługi kontra API 4. Właściwe wymiarowanie mikrousług: odszukiwanie granic usług Dlaczego granice są ważne, kiedy są ważne i jak je znaleźć Domain-Driven Design i granice mikrousług Mapowanie kontekstów Integracje synchroniczne kontra asynchroniczne Agregaty DDD Wprowadzenie do Event Storming Proces Event Storming Wprowadzenie do uniwersalnej formuły wymiarującej Uniwersalna formuła wymiarująca 5. Postępowanie z danymi Zdolność do niezależnego wdrażania a współużytkowanie danych Mikrousługi osadzają swoje dane Osadzanie danych nie powinno prowadzić do eksplozji liczby klastrów bazodanowych Osadzanie danych i wzorzec delegata danych Wykorzystanie duplikowania danych w celu za pewnienia niezależności Transakcje rozproszone i przetrwanie niepowodzenia Event Sourcing i CQRS Event Sourcing Poprawianie wydajności przy użyciu kroczących migawek Magazyn zdarzeń Command Query Responsibility Segregation Event Sourcing i CQRS poza mikrousługami 6. Budowanie potoku infrastruktury Zasady i praktyki DevOps Niezmienność infrastruktury Infrastruktura jako kod Ciągła integracja i ciągłe dostarczanie Konfigurowanie środowiska IaC Konfigurowanie GitHuba Instalowanie Terraform Konfigurowanie Amazon Web Services Konfigurowanie konta operacyjnego AWS Konfigurowanie AWS CLI Konfigurowanie uprawnień AWS Tworzenie zaplecza S3 dla Terraform Budowanie potoku IaC Tworzenie repozytorium Sandbox Istota Terraform Tworzenie kodu dla środowiska Sandbox Budowanie potoku Testowanie potoku 7. Budowanie infrastruktury mikrousług Komponenty infrastruktury Sieć Usługa Kubernetes Serwer wdrażania GitOps Implementowanie infrastruktury Instalowanie kubectl Konfigurowanie repozytoriów modułów Moduł sieciowy Moduł Kubernetes Konfigurowanie Argo CD Testowanie środowiska Sprzątanie infrastruktury 8. Miejsce pracy dewelopera Standardy kodowania i przygotowanie stanowiska programistycznego 10 wskazówek budowania doskonałego środowiska programisty Lokalne konfigurowanie środowiska skonteneryzowanego Instalowanie Multipass Wchodzenie do kontenera i mapowanie folderów Instalowanie Dockera Testowanie Dockera Zaawansowane wykorzystanie lokalnego Dockera: instalowanie Cassandry Instalowanie Kubernetes 9. Programowanie mikrousług Projektowanie punktów końcowych mikrousług Mikrousługa ms-flights Mikrousługa ms-reservations Projektowanie specyfikacji OpenAPI Implementowanie danych dla mikrousługi Redis dla modelu danych rezerwacji Modele danych MySQL dla mikrousługi lotów Implementowanie kodu mikrousługi Kod dla mikrousługi lotów Sprawdzanie kondycji Wprowadzanie drugiej mikrousługi do projektu Zahaczanie usług za pomocą projektu parasolowego 10. Wydawanie mikrousług Konfigurowanie środowiska staging Moduł wejściowy Moduł bazy danych Kopiowanie projektu infrastruktury przejściowej Konfigurowanie przepływu pracy dla środowiska staging Edytowanie kodu infrastruktury dla środowiska staging Wysyłanie kontenera mikrousługi informacji o lotach Wprowadzenie do Docker Hub Konfigurowanie Docker Hub Konfigurowanie potoku Wdrażanie kontenera usługi lotów Istota wdrożeń Kubernetes Tworzenie schematu Helm Tworzenie repozytorium wdrażania mikrousług Argo CD dla wdrożeń GitOps Sprzątanie 11. Zarządzanie zmianą Zmiany w systemie mikrousług Zorientowanie na dane Wpływ zmian Trzy wzorce wdrażania Uwarunkowania architektury Zmiany infrastruktury Zmiany w mikrousługach Zmiany danych 12. Koniec podróży (i nowy początek) O złożoności i upraszczaniu za pomocą mikrousług Kwadrant mikrousług Mierzenie postępów transformacji mikrousługowej

Sygnatura czytelni BWEAiI: XII J 109

dostępna w czytelni

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 150574 N (1 egz.)

Książka

W koszyku

Architektura oprogramowania bez tajemnic : wykorzystaj język C++ do tworzenia wydajnych aplikacji i systemów / Adrian Ostrowski, Piotr Gaczkowski ; przekład: Krzysztof Bąbol. - Gliwice : Helion, copyright 2022. - 472 strony : ilustracje ; 24 cm.

Autor

Ostrowski Adrian Gaczkowski Piotr Bąbol Krzysztof

Forma i typ

Książki Publikacje fachowe

Odbiorca

Programiści

Temat

Architektura oprogramowania C++ (język programowania) Programowanie (informatyka) Programy komputerowe Systemy informatyczne

Gatunek

Podręcznik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

W książce także ISBN oryginału.

Bibliografie, netografie przy większości rozdziałów.

Część I. Koncepcje i składniki architektury oprogramowania Rozdział 1. Znaczenie architektury oprogramowania i zasady dobrego projektowania Zrozumienie pojęcia "architektura oprogramowania" Uświadomienie sobie znaczenia właściwej architektury Badanie podstaw dobrej architektury Opracowywanie architektury według zasad podejścia zwinnego Filozofia języka C++ Stosowanie zasad SOLID i DRY Sprzężenie i spójność Rozdział 2. Style architektoniczne Wybór pomiędzy podejściem stanowym i bezstanowym Zapoznanie się z monolitami - dlaczego należy ich unikać i jakie są wyjątki Zrozumienie działania usług i mikrousług Badanie architektury opartej na zdarzeniach Zrozumienie działania architektury warstwowej Zapoznanie się z architekturą opartą na modułach Rozdział 3. Wymagania funkcjonalne i niefunkcjonalne Zapoznanie się z typami wymagań Rozpoznawanie wymagań istotnych dla architektury Zbieranie wymagań z różnych źródeł Dokumentowanie wymagań Dokumentowanie architektury Wybór właściwych perspektyw do udokumentowania Generowanie dokumentacji Część II. Projektowanie i wytwarzanie oprogramowania w języku C++ Rozdział 4. Projektowanie architektur i systemów Zrozumienie specyfiki systemów rozproszonych Zapewnienie systemowi dostępności i odporności na uszkodzenia Integrowanie systemu Osiąganie wydajności w dużej skali Wdrażanie systemu Zarządzanie interfejsami API Rozdział 5. Wykorzystywanie cech języka C++ Projektowanie doskonałych interfejsów API Pisanie deklaratywnego kodu Przenoszenie obliczeń na czas kompilacji Wykorzystanie potęgi bezpiecznych typów Pisanie modularnego kodu C++ Rozdział 6. Wzorce projektowe a język C++ Wymagania techniczne Pisanie idiomatycznego kodu C++ Ciekawie rekurencyjny wzorzec szablonu Tworzenie obiektów Śledzenie stanu i odwiedzanie obiektów w języku C++ Efektywne postępowanie z pamięcią Rozdział 7. Budowanie i pakowanie Wykorzystanie kompilatorów do granic ich możliwości Zapewnianie abstrakcji procesu budowania Korzystanie z modułów zewnętrznych Wielokrotne korzystanie z kodu o dobrej jakości Pakowanie przy użyciu narzędzia Conan Część III. Architektoniczne atrybuty jakościowe Rozdział 8. Pisanie testowalnego kodu Po co testować kod? Wprowadzenie do frameworków testowych Zapoznanie się z atrapami i imitacjami Projektowanie klas sterowane testami Automatyzowanie testów na potrzeby ciągłej integracji/ciągłego wdrażania Rozdział 9. Ciągła integracja i ciągłe wdrażanie Zapoznanie się z ciągłą integracją Recenzowanie zmian w kodzie Badanie automatyzacji sterowanej testami Zarządzanie wdrażaniem jako kodem Budowanie kodu wdrożeniowego Budowanie potoku CD Korzystanie z niezmiennej infrastruktury Rozdział 10. Bezpieczeństwo kodu i wdrażania Sprawdzanie zabezpieczeń kodu Sprawdzanie, czy zależności są bezpieczne Utwardzanie kodu Utwardzanie środowiska Rozdział 11. Wydajność Mierzenie wydajności Pomaganie kompilatorowi w generowaniu wydajnego kodu Zrównoleglanie obliczeń Używanie koprocedur Część IV. Zasady projektowania natywnego dla chmury Rozdział 12. Architektura zorientowana na usługi Zapoznanie się z architekturą zorientowaną na usługi Wdrażanie zasad wymiany komunikatów Korzystanie z usług sieciowych Wykorzystywanie usług zarządzanych i dostawców chmury Rozdział 13. Projektowanie mikrousług Wniknięcie w temat mikrousług Budowanie mikrousług Obserwowanie mikrousług Łączenie mikrousług Skalowanie mikrousług Rozdział 14. Kontenery Wymagania techniczne Reaktywacja kontenerów Budowanie kontenerów Testowanie kontenerów i integrowanie ich ze sobą Zapoznanie się z orkiestracją kontenerów Rozdział 15. Projektowanie rozwiązań natywnych dla chmury Zapoznanie się z rozwiązaniami natywnymi dla chmury Orkiestracja obciążeń natywnych dla chmury przy użyciu platformy Kubernetes Obserwowalność w systemach rozproszonych Łączenie usług za pomocą siatki usług Podejście GitOps

Sygnatura czytelni BWEAiI: XII J 113

dostępna w czytelni

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 152499 (1 egz.)

Książka

W koszyku

Strategiczne monolity i mikrousługi : jak napędzać innowacyjność za pomocą przemyślanej architektury / Vaughn Vernon, Tomasz Jaskuła ; przedmowa Mary Poppendieck ; przekład: Maksymilian Gutowski. - Gliwice : Helion, copyright 2023. - 296 stron : ilustracje, wykresy ; 24 cm.

Autor

Vernon Vaughn. Jaskuła Tomasz (informatyka). Poppendieck Mary. Gutowski Maksymilian.

Forma i typ

Książki Publikacje fachowe

Odbiorca

Informatycy Menedżerowie

Temat

Architektura oprogramowania Innowacje Mikroserwis Przedsiębiorstwo Systemy informatyczne zarządzania Transformacja cyfrowa Zarządzanie

Gatunek

Poradnik

Dziedzina i ujęcie

Informatyka i technologie informacyjne Zarządzanie i marketing

W książce rok wydania: 2023, data wpływu egzemplarza obowiązkowego: 2022.

Bibliografie, netografie przy rozdziałach.

Dla kadry kierowniczej najwyższego szczebla i osób sterujących rozwojem oprogramowania w firmie.

Strategiczne uczenie się poprzez eksperymenty na potrzeby transformacji . Cele biznesowe i transformacja cyfrowa Architektura oprogramowania - szybki przegląd Dlaczego oprogramowanie się nie sprawdza? Metafora długu Entropia oprogramowania Twoje przedsiębiorstwo a prawo Conwaya Komunikacja dotyczy wiedzy (Nowe) podejście do strategii oprogramowania Myślenie Przemyślenie na nowo Czy monolity są złe? Czy mikrousługi są dobre? Nie obwiniaj Agile Podstawowe narzędzia strategicznego uczenia się Decyzje: właściwe i niewłaściwe, wczesne i późne Kultura i zespoły Kultura porażki to nie kultura zrzucania winy Jak właściwie rozumieć prawo Conwaya? Umożliwianie bezpiecznego eksperymentowania Najpierw moduły Wszystko pomiędzy Zdolności biznesowe, procesy biznesowe i cele strategiczne Celowe dostarczanie Podejmowanie decyzji za pomocą Cynefin Gdzie jest spaghetti i jak długo się je gotuje? Architektura strategiczna Zastosowanie narzędzi Eksperymentowanie i odkrywanie zorientowane na zdarzenia Stosowanie modeli oprogramowania Szybkie uczenie się przy użyciu EventStormingu Kiedy konieczne są sesje zdalne Prowadzenie sesji Modelowanie ogólnej wizji Zastosowanie narzędzi Wspieranie innowacji biznesowych Dziedziny i poddziedziny Wiedza kontekstowa Kontekst ograniczony i język wszechobecny Dziedzina główna Poddziedziny pomocnicze, generyczne i mechanizmy techniczne Poddziedziny pomocnicze Poddziedziny generyczne Mechanizmy techniczne Zdolności biznesowe i konteksty Mapowanie, porażka i sukces - wybierz dwa Mapowanie kontekstów Partnerstwo Wspólny rdzeń Klient - Dostawca Konformizm Warstwa przeciwuszkodzeniowa Usługa open-host Język opublikowany Modelowanie topografii Ponoszenie porażek i odnoszenie sukcesów Zastosowanie narzędzi Modelowanie konceptów dziedzinowych Encje Obiekty wartości Agregaty Usługi dziedzinowe Zachowania funkcyjne Zastosowanie narzędzi Architektura zorientowana na zdarzenia . Architektura podstaw Style architektoniczne, wzorce i czynniki decyzyjne Porty i adaptery (architektura heksagonalna) Modularyzacja Zapytania/odpowiedzi REST Atrybuty jakości Bezpieczeństwo Prywatność Wydajność Skalowalność Wytrzymałość - niezawodność i odporność na błędy Złożoność Architektury oparte na komunikatach i zdarzeniach REST oparty na komunikatach i zdarzeniach Dzienniki zdarzeń Subscriber polling Server-Sent Events Zarządzanie procesami i oparte na zdarzeniach Event Sourcing CQRS Serverless i Function as a Service Tworzenie przemyślanej architektury - dwie ścieżki . Monolity na poważnie Poprawnie od samego początku Zdolności biznesowe Decyzje architektoniczne Od chaosu do ładu Zmiany na zmianach Rozerwanie sprzężenia Utrzymanie stanu właściwego Od monolitu do mikrousług Przygotowanie mentalne Od modularnego monolitu do mikrousług Od monolitu wielkiej kuli błota do mikrousług Interakcje użytkowników Harmonizacja zmian danych Co należy udusić? Odłączanie starszego monolitu Równowaga i strategia Równowaga a atrybuty jakości Strategia i cel Cele biznesowe kierują transformacją cyfrową Używanie narzędzi strategicznego uczenia się Lekkie modelowanie oparte na zdarzeniach Wspieranie innowacji biznesowych Architektura zorientowana na zdarzenia Monolity jako najważniejsze zagadnienie Tworzenie mikrousług z monolitu Równowaga wymaga bezstronności, innowacja jest niezbędna

Sygnatura czytelni BWEAiI: XII A 62

dostępna w czytelni

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 153049 (1 egz.)

Brak okładki

Czasopismo

W koszyku

Modelling and evaluation of software architectures / Andrzej Zalewski. - Warszawa : Oficyna Wydawnicza Politechniki Warszawskiej, 2013. - 118 s. : il. ; 23 cm.

(Prace Naukowe / Politechnika Warszawska. Elektronika, ISSN 0137-2343 ; z. 187 Sygn. P 645/C 42867.)

Autor

Zalewski Andrzej.

Temat

Architektura oprogramowania

Opis wg okl.

Bibliogr. s. 107-116.