XP Days Ukraina - przydatne wakacje do pracy lepiej

[osoba]
Vadim Mikhailuk
Programista Java [/ osoba] [osoba]
Roman Pawłow
PM [/ person] [person]
Stanislav Shimov
Programista Java [/ osoba] [osoba]
Ellina Azadova
Kontrola jakości [/ osoba] [osoba]
Alena Nadeeva
.NET Developer [/ person]

DataArt działał jako sponsor diamentów na XP Days Ukraine 2013, który odbył się w Kijowie w październiku. Graliśmy w nagrody (trzy zewnętrzne dyski twarde na terabajt) i niezapomniane koszulki, leczyliśmy całą kawę. Nowy przyjaciel DataArt, Fan Rob, który uprzejmie zabawiał gości i traktował ich słodyczami, stał się nieoczekiwaną rozrywką dla uczestników. Ponadto Andrei Alpert, starszy programista PHP DataArt, przedstawi raport „TDD with AngularJS and Karma”.

Jesteśmy aktywnie zaangażowani w XP Days Ukraine już trzeci rok z rzędu.

Konie umierają z pracy! Z jej troski. Uwielbiam tę pracę, ale ocal mnie, o Boże! A. Goltser

Ponad 370 osób uciekło z pracy podczas konferencji XP Days na Ukrainie, ale nie po to, by uniknąć, ale wręcz przeciwnie, w dążeniu do celu, aby ich ulubiona praca była jeszcze lepsza. Pragnienie nowej wiedzy i wymiany doświadczeń nie ominęło zespołu kolegów DataArt, w skład którego weszli: Alena Nadeyeva (Kijów), Vadim Mikhailuk (Kijów), Roman Pavlov (Charków), Stanislav Shimov (Odessa), Hellen Azadova (Cherson), którzy przez dwa dni byli oświeceni, komunikowaliśmy się z kolegami, pijąc ekspresy do kawy, byliśmy zaskoczeni, że Fana jeździ na rowerze.

Pomimo stwierdzenia Bernarda Shawa, że ​​jedyną lekcją, jakiej można się nauczyć z historii, jest to, że ludzie nie uczą się żadnych lekcji z historii, uważa się, że warto znać je, aby uczyć się na podstawie istniejących doświadczeń. So Sander Hoodendoorn ( „Jeden człowiek, tablica i trzy markery. Sander na architekturze oprogramowania i wzorach”, Sander Hoodendoorn. ), który pracuje w dziedzinie oprogramowania od ponad 30 lat, opowiadał o swoim doświadczeniu i, co charakterystyczne, o wszystkim naraz. Charyzma mówcy, jego ogromne doświadczenie i niezwykły format raportu spowodowały tylko dwie reakcje: WoW i WTF. Począwszy od podstaw - z ważną historią o nietrywialnej technologii rozwoju wykorzystującej metodę Ctrl + C Ctrl + V - płynnie przełączył się na bardziej banalne MVC / MVP / MVVM, lepiej znane wszystkim jako MVWTF. Na końcu raportu, rysując planszę ze znacznikami (ośmielę się zauważyć, trzy, jak stwierdzono w tytule raportu), nie mógł się oprzeć i przeniósł się do drugiego. Poniżej znajduje się zdjęcie przedniej strony - wyniki pracy Sandera.

[caption id = "attachment_6646" align = "alignnone" width = "525"] © https://twitter.com/xpinjection/status/388686780356370432/photo/1 [/ caption]

Benjamin Franklin powiedział, że lenistwo utrudnia sprawę. Na szczęście w świecie tworzenia oprogramowania wszystko jest dokładnie odwrotne: lenistwo motywuje do tworzenia. Kierując się zasadą optymalizacji wszystkich rutynowych prac, teraz możesz nawet cieszyć się automatyzacją pisania kodu. To InteliJ IDEA może uprościć życie programisty, ale nie wystarczy kupić i skonfigurować to narzędzie, ważne jest również, aby móc z niego korzystać. Dążąc do jeszcze łatwiejszego życia dewelopera, Nikołaj Chasznikow ( „Efektywne kodowanie w InteliJ IDEA”, Nikołaj Chasznikow ) pokazał, jak wystarczy kilka naciśnięć klawiszy, aby napisać, poprawić i zmienić kod. Nie jest tajemnicą, że za 50 minut wydaje się nierealistyczne poznanie wszystkich kombinacji magicznych kluczy, ale nie było to celem raportu. Ale Nicholas pokazał kilka ukrytych funkcji i opowiedział kilka sposobów optymalizacji swojej pracy.

Na przykład w InteliJ IDEA dostępna jest funkcja, która pokazuje, które skróty zostały użyte i ile razy w historii. Po przeanalizowaniu tych danych nadal możesz przyspieszyć pisanie kodu w przyszłości.

Synchronizacja jest bardzo ważna. Kto nie chciałby mieć dostępu do bieżących danych z dowolnego dostępnego urządzenia? W rozwoju jest więc bardzo ważne, aby na wszystkich serwerach była aktualna baza danych. Chodzi o to, jak to osiągnąć i mówi Andrey Solntsev ( „Zwinne tworzenie kodu bazy danych przedsiębiorstwa za pomocą LiquiBase”, Andrei Solntsev ). W końcu prawdopodobnie wszyscy musieli obsługiwać kilka różnych baz danych lub wprowadzać aktualizację schematu bazy danych i danych. Nie jest tajemnicą, że w tym przypadku trzeba poradzić sobie z różnicami w składni SQL. Tak więc przedmiotowa LiqueBase jest narzędziem, które nie tylko narzuca zestawy instrukcji sql w określonej kolejności, chociaż może również (patrz), ale także pozwala opisać je we własnej bazie danych opartej na języku xml. Zatem poprawność składniowa jest gwarantowana w każdym obsługiwanym dialekcie SQL. Andrei pokazał na przykład, że konfiguracja XML nie jest wadą, ale zaletą systemu LiqueBase. Na przykład, każdy może być elastycznie parametryzowany za pomocą listy bazy danych (oracle, mysql itp.) Lub zestawu envaroments (dev, testy, prod, itp.), Dla których powinien być używany. Warto również zauważyć, że inne interesujące funkcje systemu to możliwość używania instrukcji w zestawach zmian do pobierania danych z pliku CSV, a także wykonywania poleceń, takich jak skrypt kopii zapasowej. A wybór, jak zawsze, należy do ciebie!

Już jako dziecko dowiedzieliśmy się, że „wspólne chodzenie po przestrzeniach jest zabawne ...”. Jak pokazuje praktyka programistyczna, wspólne pisanie kodu jest również o wiele przyjemniejsze: co najmniej przydatne jest dzielenie się doświadczeniami z kolegą, które mogą być dla siebie przydatne.

Takie podejście od dawna jest kultywowane w Xtreme Programming. Zespół, w którym pracują Vadim Gerasimov i Andrey Solntsev ( „eXtreme Banking”, Vadim Gerasimov, Andrei Solntsev ), składa się tylko z czterech programistów, którzy mogą robić wszystko i kochać XP. Mówcy podzielili się swoimi doświadczeniami przez godzinę, opowiedzieli, dlaczego wybrali te, a nie inne technologie / metodologie. Twierdzą, że XP to duch dowodzenia (nie ma konkretnej osoby, która napisał ten lub inny kod - cały kod należy do zespołu) i pozwala mniej więcej zrozumieć, jak działa cały system.

Osiąga się to przez ciągłą zmianę par i, w różnym stopniu, pracę z każdym pojedynczym modułem. Ogólnie rzecz biorąc, sami ludzie komunikują się z klientami, sami piszą kod, sami go testują. Nawet credo tych gości brzmi: „Chłopiec był nagi, chłopiec protestował”. Jedna rzecz pozostaje niejasna: co się stanie, gdy dziewczyna dotrze do swojego zespołu, a dziewczyny się tam nie dostaną?

Warto zauważyć, że nie wszyscy tak lubią programowanie parami. Niektórzy są sceptyczni wobec tego podejścia. Tak więc w kanale Twittera pojawił się następujący komunikat

Kolejnym zwolennikiem XP okazał się Dmitry Mindra ( „XP w realnym świecie”, Dmytro Mindra ), która jest zaangażowana w rozwój wieloplatformowego silnika gier, używanego przez ponad 2 miliony twórców gier na całym świecie. Po pierwsze, nie można pozostać obojętnym na raport Dmitrija, dzięki jego charyzmie, bardzo gorącemu tematowi (w końcu, kto z nas nie gra w gry?) I oczywiście oryginalności. W końcu czy można pozostać obojętnym, gdy głośnik nagle włącza strzelca i kontynuuje raport, pędząc po labiryncie, strzelając i pokazując slajdy wiszące na ścianach?

Trudno sobie wyobrazić, jak XP działa w rozproszonych zespołach, ale Dmitriy zdołał przekazać przykład Unity 3d, którego zespoły są rozproszone po całym świecie, że jest to nie tylko możliwe, ale także bardzo skuteczne. Dzwoniąc przez Skype i korzystając bezpośrednio z TeamViewer do programowania, możesz osiągnąć takie same wyniki, jak przy osobistym kontakcie. Cóż, aby odpocząć trochę, 2 tygodnie w roku, wszyscy programiści odkładają całą swoją pracę, gromadzą się w jednym miejscu i organizują wydarzenie HackWeek, aby wdrożyć każdy z ich pomysłów i wymiany doświadczeń.

Kontynuując temat praktyk metodologicznych, warto zauważyć, że ślepe przestrzeganie zasad Agile niekoniecznie skazuje projekt na sukces. So Nikolay Alimenkov ( „Tech Lead - wymagana rola dla zwinnego sukcesu projektu”, Mikalai Alimenkou ) w swoim krótkim raporcie na temat roli lidera techniki w projektach zwinnych trochę ironicznie doceniono metodologię SCRUM, która nie przewiduje dedykowanej roli architekta / technika. szef projektu i zakłada, że ​​wszystko jest po prostu „członkami zespołu”. Mówca określił Tech Lead jako członka zespołu, który może podejmować właściwe decyzje techniczne i prowadzić projekt do sukcesu. Ta rola łączy kilka cech: komunikację z zespołem, komunikację z klientem, architekturę, dostawy i ryzyko. Ta osoba jest idealna do roli scrum master. Poza tym pisze także kod! W ten sposób Tech Lead wygląda jak niezwykle cenny członek każdego zespołu, a kosztem tego można zaoszczędzić na menedżerach. Tę osobę też trzeba znaleźć :)

Jak pamiętamy z historii Sandera, niestety nie zawsze działa się w zespole marzeń i dobrze zaprojektowanych aplikacjach. Więc trener i mentor zespoły techniczne i biznesowe Ola Ellnestam ( „Metoda Mikado”, Ola Ellnestam ) opowiadał o kodeksie spuścizny w jednym ze swoich projektów, z którym praca przypomniała autorowi bitwę z Hydrą ze starożytnych mitów greckich. Kod był tak połączony, że każda zmiana spowodowała wiele błędów kompilacji, a ich eliminacja spowodowała powstanie kilku nowych dla każdej poprawki. Zespół starał się rozwiązać problem bezpośrednio, to znaczy korygować błąd po błędzie, mijały dni, liczba plików rosła, a także liczba błędów ... Po dwóch tygodniach chłopcy podjęli śmiałą decyzję, aby wyrzucić wszystkie te zmiany i zacząć od nowa. Za drugim razem postanowiliśmy oznaczyć wszystkie zależności na wykresie zależności, aż staną się atomowe. Tak więc było to nie tylko szczęście dla zespołu, ale także, w wyniku podsumowania takiego doświadczenia, pojawiła się Metoda Mikado, nazwana tak po grze, w której trzeba wyciągnąć kije ze stosu, bez uderzania w resztę lub niszczenia struktury. Pewnego dnia ta metoda będzie wspierana przez środowiska programistyczne i przyspieszy pracę, podobnie jak wbudowane refaktoryzowanie.

Świat zmienia się bardzo szybko, sprawy wymykają się spod kontroli, ostatnio coraz bardziej odpowiednie technologie stają się przestarzałe, metody w ramach są wycofywane. A co, jeśli krytyczna metoda dla obecnego projektu zniknęła z nowej wersji zestawu narzędzi programowych? Co zrobić w takiej sytuacji, jak zbudować architekturę projektu, aby takie zdarzenia nie stwarzały trudności, mówi Sander Hoodendoorn ( „Sander Hoodendoorn” ) za godzinę i pół prezentacji w ciągu godziny. Prelegent przedstawił bardziej konkretne przykłady i konkretne metody radzenia sobie z potencjalnymi problemami, a także linki do odpowiedniej literatury, w tym jej autorstwa.

„Mierz siedem razy, raz cięć” - mówi przysłowie. Akim Boyko ( „Walidacja architektury i projektu w .Net”, Akim Boyko ) skupia się na fakcie, że architektura i projektowanie aplikacji powinny być testowane jako moduły, co pozwala wykryć problemy na wczesnych etapach. Według autora przyczyną są statyczna typizacja, wiązanie / kontekst, wewnętrzna „konwencja”. Aby temu przeciwdziałać, Akim zasugerował następujące „przepisy”:

• TDD w ogóle;
• naprawianie i testowanie zależności projektu, na przykład, jeśli kompilacja A odnosi się do B, a B odnosi się do C, to A nie powinno odnosić się do C;
• programowanie zorientowane na aspekty oparte na Postsharp, które pozwala zaimplementować kod walidacji ograniczeń architektonicznych;
• Dynamiczne API kompilatora C # za pomocą projektu Rolsyn pozwala na użycie kompilatora do analizy kodu.

Bezproblemowo zmieniając temat walidacji na temat testowania, nie można nie zgodzić się z Natalią Rykol ( „Definicja jakości”, Natalya Rykol ), który mówi, że kiedy wsiadasz do taksówki, nie pytaj kierowcy, aby zabrał cię „do domu”, ale podaj konkretny adres. Koncepcja oprogramowania „jakościowego” ma swoją własną. Dlatego warto określić mierzalne standardy jakości.

Natalya szczegółowo opowiedziała o zewnętrznych i wewnętrznych wskaźnikach jakości, według których powinna być oceniana, wydała zalecenia z własnego doświadczenia na temat tego, jak i kiedy je stosować. Ważna była również następująca rada: nie używać metryk dla celów metryk, to znaczy wszystkie metryki powinny być odpowiednie dla konkretnego projektu.

Mówiąc o testowaniu, nie można ignorować testów automatycznych, w szczególności TDD. Nasz kolega Andrei Alpert ( „TDD z AngularJS and Karma”, Andrey Alpert ) nie pozostał na to obojętny. Przede wszystkim mówił o Angular w praktyce i podzielił się swoją opinią na temat jego używania przez długi czas. Ogólnie rzecz biorąc, kod UI korzystający z frameworka Google w przypadku kompetentnego używania tego ostatniego jest naprawdę dobrze czytany i zawiera w większości nieprzejrzyste szczegóły pracy z logiką DOM. Co w związku z tym znacznie upraszcza pisanie testów i rozwój poprzez testowanie. Jednocześnie krzywa nastawienia kolegów do korzystania z Angulara jest raczej zepsuta, z recesjami i skokami z „Angular to najlepsza struktura” do „tego, jak ogólnie je wybraliśmy, projekt jest skazany” i vice versa. Prezentacja raportu Andrei Alperta .

Kontynuując temat TDD Nikolay Alimenkov ( ��TDD dla kodu związanego z bazą danych, jak to możliwe?”, Mikalai Alimenkou ), który próbował przekonać publiczność, że pisanie kodu bazy danych i dostęp do danych za pośrednictwem TDD jest nie tylko możliwy, ale po prostu dzięki wykorzystaniu wybitnych technik i nowoczesnych narzędzi.

Nie jest tajemnicą, że dane są znacznie ważniejsze niż kod źródłowy programu. Manipulacje nad nimi w produkcji powinny być jak najbardziej bezpieczne. Osiąga się to poprzez testowanie nowych zmian. Konieczne jest przetestowanie wszystkiego, aby upewnić się co do kodu bazy danych (schemat bazy danych, dane, integralność danych referencyjnych, obiekty bazy danych, wydajność itp.). Najważniejszą rzeczą jest przetestowanie prawdziwej bazy danych. Próby na poziomie sterownika bazy danych lub ORM / DAL nie rozwiązują problemu testowania bazy danych. Istnieje kilka dobrze znanych technik testowania: czarna skrzynka; test - transakcja; test - „bohater” - przygotowuje dane dla siebie, sam je usuwa. Narzędzia są podzielone na grupy: do zarządzania migracjami (Liquibase, dbmigration) i do testowania (dbunit, Unitils). W związku z tym TDD w bazach danych, według autora, pozwala pozbyć się arkuszy listy kontrolnej z tajną wiedzą, która wymaga pracy ręcznej, dyktuje minimalny niezbędny kod zmiany, pełną kontrolę kodu dostępu do danych i łatwe refaktoryzowanie.

W rzeczywistym świecie nie zawsze automatyczne pokrycie testowe gwarantuje szczęście. Wojciech Seliga ( „Automated Test Hell - Nasza podróż”, Wojciech Seliga ) mówił o napotkanych problemach, jak je rozwiązać i czego się nauczył. Ogólnie rzecz biorąc, raport był poświęcony studium przypadku, ponieważ ich firma, twórca JIRA, zmagała się z problemami z CI. W szczególności: czerwone kompilacje, dziesiątki tysięcy powolnych i niestabilnych wersji Legacy - testy, niepoprawne podejście do testów zespołu i postrzeganie nieudanej kompilacji itp. Aby poprawić sytuację, chłopcy podjęli następujące kroki.

• Optymalna równowaga między izolacją, prędkością, powłoką, wysiłkiem.
• Testy nie są śmieciami, ale tym samym kodem!
• Buduj poziomy (A1, A2, A3) i jasne zasady. Każdy poziom odzwierciedla głębokość integracji testu. Wymagania: im niższy poziom, tym wyższe wymagania dla udanej kompilacji.
• Ważna jest wizualizacja procesu budowania. Każdy musi zobaczyć status i odpowiedzieć na czas.
• Szkolenie: jak pisać testy, zasady, dobre / złe praktyki.
• Determinacja testów, walka z warunkami wyścigu.
• Poprawiona wydajność: testy, git, kompilacja, dostępność agentów kompilacji, publikowanie wyników.

Zespół tych ludzi pracował nad ulepszeniami IK od ponad roku. Osiągnęli pewien sukces, nie osiągnęli podstawowego celu, ale wyciągnięto następujące wnioski:

• przejrzystość i zrozumienie rzeczywistych problemów pomaga im się uporać;
• obsługa ogromnej liczby testów jest bardzo złożona i kosztowna;
• konieczne jest „zmierzenie” problemu, rozwiązanie go, a następnie zmierzenie wyniku;
• testy automatyczne nie są jednorazową inwestycją, ale stałą pracą;
• wydajność i większa wydajność.

Oczekuje się, że te odkrycia doprowadzą dzieci do ostatecznego celu i, oczywiście, pomogą innym w rozwiązaniu takich problemów lub ich całkowitemu zapobieganiu.

Rutynowa praca może zrodzić tylko jedną myśl: „Czy można ją zautomatyzować?” Na szczęście pojawia się coraz więcej środków do automatyzacji takich procesów.

Aleksander Doroszenko. ( „Enterprise Provisioning with Chocolatey”, Alexander Doroshenko ), deweloper i entuzjasta ALM i DevOps, z entuzjazmem wyjaśnił, jak w ostatnich latach skrócił się czas wdrożenia serwera i jak Chocolatey i Boxstarter pomagają w konfigurowaniu komputerów z systemem Windows. Jeśli ktoś z publiczności, po przestudiowaniu środków automatyzacji konfiguracji systemów UNIX, nie miał tego samego w systemie Windows, raport w pewnym stopniu wypełnił tę próżnię.

Korzystanie z Chocolatey i Boxstarter pozwala w szczególności uzyskać identyczne konfiguracje i na pulpicie programistów, nie wspominając o oszczędzaniu czasu na rozpoczęcie pracy z nowym projektem. W skrócie, Chocolatey jest podobny do apt-get dla Windows, a Boxstarter upraszcza konfigurację świeżo zainstalowanych systemów przy użyciu Chocolatey, dodając funkcje, takie jak zarządzanie procesem instalacji podczas ponownego uruchamiania, instalowanie aktualizacji systemu Windows, zmiana ustawień systemu itp.

Czy duża aplikacja może sobie pozwolić na offline przez co najmniej pięć minut? Możesz to zrobić, ale pomyśl, ilu użytkowników będzie niezadowolonych. Dlatego zero przestojów jest naszym wszystkim. Więc Axel Fontaine ( „Architekting dla ciągłych dostaw i przestojów zerowych”, Axel Fontaine ), deweloper i konsultant, przypomniał, nowe technologie, takie jak Facebook, Flickr, Stackoverflow już dawno przeszły na Continuous Delivery i zilustrowały je zrzutami ekranu. Na przykład StackOverflow ma numer wersji data wdrożenia. Zwykła pokrywa z obecnym, dlatego jest aktualizowany. Następnie opisał, w jaki sposób kod przechodzi przez różne etapy na serwerze CI, począwszy od momentu zatwierdzenia i kończąc na instalacji podczas aktualizacji produkcji i konfiguracji. Według autora każdy artefakt instalacyjny, na przykład plik WAR dla Javy, powinien być zaopatrzony w zestaw plików konfiguracyjnych dla każdego środowiska i używać autodetekcji, aby wybrać to, co jest potrzebne podczas uruchamiania. Tak więc wszystko, czego potrzebujesz, jest w jednym artefakcie, który jest łatwy do zarządzania. Wspomniałem również o Feature Toggles jako rozwiązaniu problemu wylewania na VCS jeszcze nie do końca gotowego kodu. Jak wyjaśnił mówca, umożliwia to rezygnację z gałęzi funkcji i wykonywanie całej pracy w bagażniku VCS, co przyczynia się do wczesnej integracji kodu. Nie zapomniano także o wdrożeniach w kolorze niebieskim / zielonym - jako sposób na aktualizację aplikacji przy minimalnym przestoju.

Podjąłem temat dyplomacji Andreja Rebrova ( „Rurociąg rozmieszczenia budynków: sposób DevOps”, Andrey Rebrov ), deweloper i trener, który opisał DevOps jako sposób na poprawę jakości, szybkości i przejrzystości procesu dostaw poprzez pokonanie sprzeczności między zespołami Dev i Ops. Zauważył również elementy tego procesu: Kultura, Automatyzacja, Pomiar i Dzielenie się wiedzą, które są realizowane przez budowanie zespołu, upraszczanie skryptów wdrożeniowych za pomocą różnych narzędzi, wszechstronne monitorowanie dzienników oraz analizowanie i gromadzenie statystyk i tworzenie różnych wykresów na ich podstawie.

Interesujące było przyjrzenie się analizie dzienników za pomocą Splunk: długie 5-wierszowe zapytanie wyprowadziło korelację między różnymi zdarzeniami w dzienniku, obliczyło średnie wartości i odchylenia wskaźników.

Itzhak Adizes ma wspaniałe stwierdzenie „jeśli nie będzie lepiej, to będzie gorzej”, z którym trudno się spierać. Dlatego każdy system zwolniony podczas produkcji musi być utrzymywany i monitorowany. Andrey Samilyak ( „DevOps Engineering w czasie rzeczywistym”, Andriy Samilyak ), posiadając bogate doświadczenie w organizowaniu i koordynowaniu DevOps, mówił o problemie konfiguracji i wsparcia systemów o bardzo szerokiej geografii w zespołach operacyjnych 24x7.

Głównym narzędziem, którego używają do automatycznego zarządzania konfiguracją, jest Chef napisany w Ruby. Jest to jeden z czterech najpotężniejszych systemów zarządzania konfiguracją dla systemu Linux. Produkt pozwala tworzyć „przepisy” opisujące sposób, w jaki Chef zarządza serwerami aplikacji.

Ponadto zespół DevOps aktywnie korzysta z Jenkins dla CI, co pozwala dużo zarządzać środowiskami testowymi, dev i tworzyć piaskownice dla zespołów programistycznych.

Ostatnim najważniejszym atrybutem wysokiej jakości DevOps, które aktywnie wdrażają i rozwijają, jest monitorowanie. Bez tego DevOps jest po prostu ślepy. Ich zespół używa narzędzi takich jak Sensu, Splunk. Są to doskonałe narzędzia do agregowania i raportowania różnych statystyk serwera aplikacji.

Gdzie jest bez chmur? Alexander Demidov ( „Życie w chmurze bez administratorów systemu”, Alexander Demidov ) nie mógł obejść się po stronie chmury i opowiedział historię o budowaniu wysoko obciążonego systemu chmurowego, opowiedzianej z uzasadnieniem, dlaczego jego zespół podjął tę lub inną decyzję. Przede wszystkim raport będzie interesujący dla architektów i inżynierów DevOps oraz dla każdego, kto planuje wdrożyć systemy w chmurze Amazon. Główne pomysły, które autor chciał przekazać:

• Amazon to dobra chmura.
• Nie wierzcie w reklamę, która mówi, że rozwiązania w chmurze są bardziej niezawodne niż zwykłe: nasze doświadczenie pokazuje, że systemy w chmurze, nawet takie sprawdzone firmy jak Amazon, są podatne na zakłócenia na poziomie sprzętu i czynniki ludzkie.
• Pomyśl o skalowalności na etapie projektowania produktu (na przykład użyj abstrakcyjnego API plików, które pozwala im pracować w sposób przejrzysty z dowolnym systemem plików w chmurze)!
• Percona (fork MySQL) pokazuje lepsze wyniki niż MySQL. Jest to również szybszy restart i prowadzi wewnętrzne statystyki żądań i dostępu do danych.
• Replikacja Master Master między centrami danych z podziałami parzystości.
• Użyj autoskalowania systemu - użyj systemu CloudWatch, aby automatycznie uruchamiać / usuwać dodatkowe węzły na podstawie średniego obciążenia procesora.
• Każda wiadomość z systemu monitorowania wymaga reakcji, w przeciwnym razie nikt nie potrzebuje tego strumienia.
• Zautomatyzuj reakcję na niektóre rutynowe komunikaty systemu monitorowania!
• Monitoruj system monitorowania!
• Stałe informacje zwrotne dla programistów (statystyki wydajności, dzienniki błędów, dzienniki wolnych zapytań itp.).

Jeśli chcesz wiedzieć więcej, zobacz raport Alexandra.

Tak minęły dwa dni konferencji. Chciałbym podziękować prelegentom za czas, wysiłek i ogromne doświadczenie, którego nikt nie przeoczył; organizatorzy tak wspaniałego wydarzenia i, oczywiście, DataArt za możliwość wzięcia w nim udziału.

Przed ukończeniem tego niekończącego się strumienia listów, prawdopodobnie warto zauważyć, że wkrótce wszystkie materiały konferencyjne będą dostępne na stronie XP Days w sekcji Historia . Tam będziesz mógł zapoznać się z materiałami w sposób bardziej szczegółowy, a nawet zobaczyć vidosiki z raportami nie tylko dla tych, którzy nie wiedzieli, jak przełamać eleganckie i piękne i na jakim etapie iść, ale także dla wszystkich.

Nasz raport ze zdjęć

Fotoreportaż od organizatorów