XP Days Ukraine - корисний відпочинок, щоб краще працювати

[Person]
Вадим Михайлюк
Java Developer [/ person] [person]
Роман Павлов
PM [/ person] [person]
Станіслав Шимов
Java Developer [/ person] [person]
Елліна Азадова
QA [/ person] [person]
Алена Надеева
.NET Developer [/ person]

DataArt виступив діамантовим спонсором на XP Days Ukraine 2013, яка пройшла в жовтні в Києві. Ми розіграли призи (три зовнішніх вінчестера на терабайт) і пам'ятні футболки, пригостили всіх кави. Несподіваним розвагою для учасників став новий друг DataArt - робот Фаня, який люб'язно розважав гостей і пригощав цукерками. Крім того, Андрій Альперт, Senior PHP Developer DataArt, представить доповідь «TDD з AngularJS і Karma».

Ми активно беремо участь в XP Days Ukraine третій рік поспіль.

Коні дохнуть від роботи! Від неї самі клопоти. Я люблю роботу все ж, але спаси мене, о Боже! А. Гольцер

Більш 370 чоловік рятувалися від роботи на конференції XP Days Ukraine, але не щоб ухилитися, а навпаки, - маючи на меті робити улюблену роботу ще краще. Жага нових знань та обміну досвідом не оминула й команду колег DataArt, в складі Олени Надєєва (Київ), Вадима Михайлюка (Київ), Романа Павлова (Харків), Станіслава Шимова (Одеса), Елліни Азадовой (Херсон), які два дні просвітіться, спілкувалися з колегами, попиваючи каву, дивувалися роз'їжджає на велосипеді роботу Фане.

Не дивлячись на твердження Бернарда Шоу, що єдиний урок, який можна винести з історії - люди не витягують з історії ніяких уроків, прийнято вважати корисним знати її, щоб перейняти існуючий досвід. Так Сандер Hoodendoorn ( "One man, a whiteboard and three markers. Sander on software architecture and patterns", Sander Hoodendoorn. ), Який працює в галузі програмного забезпечення більше 30 років, розповідав про свій досвід, і, що характерно, відразу про все. Харизма доповідача, його неосяжний досвід і незвичайний формат доповіді викликала лише дві реакції: WoW і WTF. Почавши з азів - з не менш важливого розповіді про нетривіальною технології розробки методом Ctrl + C Ctrl + V - він плавно перейшов на більш банальні MVC / MVP / MVVM, більш відомі всім як MVWTF. Під кінець доповіді, обмалював дошку маркерами (при чому, смію зауважити, трьома, як і було заявлено в назві доповіді), він не стримався і перейшов на другу. Нижче представлено фото лицьового боку - результати творчості Сандера.

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

Бенджамін Франклін говорив, що лінь робить кожну справу важким. На щастя, в в світі програмної розробки все в точності до навпаки: саме лінь мотивує творити. Керуючись принципом оптимізації всієї рутинної роботи, зараз уже можна насолоджуватися навіть автоматизацією написання коду. Саме InteliJ IDEA вміє спростити життя розробника, але мало купити і поставити собі цей інструмент, важливо ще й вміти ним користуватися. Переслідуючи мету зробити життя розробника ще простіше, Микола Чашников ( "Efficient coding in InteliJ IDEA", Nikolay Chashnikov ) Показав, як лише кількома натисканнями клавишь писати, виправляти і рефактору код. Ні для кого не секрет, що за 50 хвилин видається нереальним вивчити всі магічні поєднання клавіш, але це і не було метою доповіді. Зате Микола показав кілька прихованих фич, і розповів кілька способів оптимізації своєї роботи.

Наприклад, в InteliJ IDEA є фіча, яка показує, які shortcut були використані і скільки разів за всю історію. Проаналізувавши ці дані, можна ще прискорити написання свого коду в майбутньому.

Синхронізація - це дуже важливо. Кому не сподобається мати доступ до актуальних даних з будь-якого наявного девайса? Так і в розробці дуже важливо, щоб на всіх серверах була актуальна БД. Саме про те, як цього досягти, і каже Андрій Солнцев ( "Agile development of enterprise database code with LiquiBase", Andrei Solntsev ). Адже, напевно, кожен стикався з необхідністю підтримки декількох різних баз або накочуванням оновлення схеми і даних БД. Не секрет, що при цьому доводиться стикатися з відмінностями в синтаксисі SQL. Так ось LiqueBase, про який йде мова, - тул, який не просто накладає в певній послідовності набори sql-інструкцій, хоча це теж може (див.), Але і дозволяє описувати їх на власній незалежній від БД заснованому на xml-мові. Таким чином гарантірутеся синтаксична правильність на будь-якому з підтримуваних діалектів SQL. Андрій на прикладі показав, що xml-конфігурація - не недолік, а перевага системи LiqueBase. Наприклад, кожен можна гнучко параметризованих списком БД (oracle, mysql і т.д.) або набором енвароментов (dev, tests, prod і т.п.), тільки для яких він повинен застосовуватися. Варто також відзначити, що інші цікаві можливостями системи - можливість використовувати в ченжсетах інструкції для завантаження даних з CSV-файлу, а також исполения команд, наприклад скрипта бекапу. А вибір як завжди за Вами!

Ще в дитинстві ми вивчили, що «разом весело крокувати по просторах ...». Як показує практика розробки, код писати разом теж куди веселіше: як мінімум, завжди корисно обмінятися досвідом з колегою, буть один одному взаємно корисним, так би мовити.

Такий підхід давно культивується в Xtreme Programming. Команда, в якій працюють Вадим Герасимов і Андрій Солнцев ( "EXtreme Banking", Vadim Gerasimov, Andrei Solntsev ), Складається всього з чотирьох розробників, які вміють робити все і люблячих XP. Доповідачі цілу годину ділилися досвідом, розповідали чому вони вибрали саме ті, а не інші технології / методології. Вони стверджують, що XP командної дух (немає конкретної людини, який написав той чи інший код - весь код належить команді) і дозволяє в тій чи іншій мірі розуміти, як працює вся система цілком.

Це досягається за допомогою постійної зміни пар і в тій чи іншій мірі роботи з кожним окремим модулем. В цілому, хлопці самі спілкуються з замовниками, самі пишуть код, самі ж його тестують. Навіть кредо цих хлопців говорить: «Пацан накодо, пацан протесту». Незрозумілим залишається одне: що буде коли до них в команду потрапить дівчина, або ж дівчатам туди не потрапити?

Варто зазначити, що не всі так люблять парне програмування. Дехто ставиться до цього підходу дещо скептично. Так, в стрічці твіттера з'явилося приблизно таке повідомлення

Черговим прихильником XP виявився Дмитро Миндру ( "XP in the real world", Dmytro Mindra ), Який залучений в розробку крос-платформного ігрового движка, що використовується більш ніж 2 млн гейм-девелоперів у всьому світі. В першу чергу, не можна залишитися байдужим до доповіді Дмитра, завдяки його харизмі, дуже гарячій темі (адже хто з нас не грає в ігри?) І, звичайно ж, оригінальності. Адже хіба можна залишитися байдужим коли доповідач раптом включає шутер і продовжує доповідь, носячи по лабіринту, стріляючи і показуючи свої слайди, розвішані прямо на стінах?

Складно уявити, як працює XP в розподілених командах, але Дмитро зумів донести на прикладі компанії Unity 3d, команди якої розкидані по всьому світу, що це не тільки можливо, але і дуже ефективно. Здзвонюючись по Skype і використовуючи TeamViewer безпосередньо для програмування, можна досягти тих же результатів що і при особистому контакті. Ну а щоб трохи розвіятися, 2 тижні в році все розробники відкладають всю свою роботу, збираються в одному місці і влаштовують HackWeek event, для реалізації будь-яких своїх ідей і обміну досвідом.

Продовжуючи тему методологічних практик, варто зауважити, що сліпо дотримуючись правил Agile, ми далеко не обов'язково прирікаємо проект на успіх. Так Микола Алименко ( "Tech Lead - required role for Agile project success", Mikalai Alimenkou ) В своєму короткому доповіді на тему ролі Tech Lead в Agile-проектах трохи іронічно оцінив методологію SCRUM, яка не передбачає виділеної ролі архітектор / тех. керівник в проекті, а передбачає, що всі просто "team members". Доповідач визначив, що Tech Lead - член команди, здатний приймати правильні технічні рішення і призводять проект до успіху. Ця роль об'єднує кілька подролей: спілкування з командою, спілкування з замовником, архітектура, поставка й ризики. Ця людина просто ідеальний для ролі scrum майстер. І що не менш важливо, він також пише код! Таким чином Tech Lead виглядає надзвичайно цінним членом будь-якої команди, і за рахунок нього можна економити на менеджерах. Таку людину треба ще знайти :)

Як ми пам'ятаємо з розповіді Сандера, на жаль, не завжди трапляється працювати в dream-team, і з добре спроектованими додатками. Так коуч і ментор технічних і бізнескоманд Ola Ellnestam ( "Mikado Method", Ola Ellnestam ) Розповідав про legacy code в одному з його проектів, робота з яким нагадувала автору бій з Гідрою з давньогрецьких міфів. Код був настільки пов'язаний, що будь-яка зміна породжувало безліч помилок збірки, а їх усунення - по кілька нових на кожне виправлення. Команда спробувала вирішити проблему в лоб, т. Е. Виправляючи помилку за помилкою, минали дні, кількість файлів росло, як і кількість помилок ... Через два тижні хлопці взяли сміливе рішення викинути всі ці напрацювання і почати заново. Другий раз вирішили відзначати всі залежності на графі залежностей, до тих пір, поки вони не стануть атомарними. Таким чином, настало не тільки щастя для команди, але і, в результаті узагальнення такого досвіду, з'явився «Метод Мікадо», що отримав назву по імені гри, в якій потрібно витягати палички з купи, не зачепивши інших і не зруйнувавши конструкції. Коли-небудь даний метод буде підтримуватися середовищами розробки і дозволить прискорити роботу, як вбудовані засоби рефакторинга.

Світ змінюється дуже швидко, виходять з моди речі, недавно ще актуальні технології морально застарівають, методи в фреймворками йдуть на пенсію. А що, якщо критично важливий метод для поточного Проет зник з нової версії програмного інструментарію? Що в цій ситуації робити, як будувати архітектуру проекту так, щоб такі казуси не створювали труднощі, розповідає Sander Hoodendoorn ( "How frameworks can kill your projects and patterns to prevent you from getting killed", Sander Hoodendoorn ) В півторагодинний презентації всього за годину. Більше конкретних прикладів і конкретних методів боротьби з потенційними проблемами, разом з посиланнями на соответствующуюю літературу, в тому числі, і його авторства, представив доповідач глядачам.

«Сім разів відміряй - один раз відріж», - стверджує народна мудрість. Яким Бойко ( "Architecture and Design Validation in .Net", Akim Boyko ) Акцентує увагу на тому, що архітектура і дизайн додатків повинні тестуватися, як модулі, що дозволяє виявляти проблеми на ранніх стадіях. Серед причин, на думку автора, статична типізація, прив'язка / контекст, внутрішня «конвенція». Для боротьби з цим Яким запропонував наступні "рецепти":

• TDD в загальному;
• фіксація і тестування залежностей проекту, напр., якщо збірка А посилається на Б, а Б - на В, то А не повинна посилатися на В;
• аспектно-орієнтоване програмування на основі Postsharp, що дозволяє впроваджувати код валідації архітектурних обмежень;
• динамічний API компілятора C # за допомогою проекту Rolsyn, дозволяє використовувати компілятор для аналізу коду.

Плавно змінюючи тему валідації на тему тестування, не можна не погодитися з Наталією Рикол ( "Definition of Quality", Natalya Rykol ), Яка стверджує, що, коли ви сідаєте в таксі, не просіть водія відвезти вас «додому», а називаєте конкретну адресу. Поняття «якісного» ПО у кожного своє. Якраз тому варто визначати вимірні стандарти якості.

Наталя дуже докладно розповіла про зовнішні і внутрішні метриках якості, за якими його варто оцінювати, дала рекомендації з власного досвіду, як і коли їх краще застосовувати. Важливим був наступну пораду: не використовувати метрики заради метрик, т. Е. Все метрики повинні підходити конкретним проектом.

Говорячи про тестування, не можна обійти стороною автоматизоване тестування, зокрема TDD. Наш колега Андрій Альперт ( "TDD with AngularJS and Karma", Andrey Alpert ) Не залишився байдужим до цього. Перш за все, він розповів про Angular на практиці і поділився відкликанням про нього на основі його використання протягом тривалого часу. Загалом, UI-код з використанням фреймворку від Google в разі грамотного застосування останнього дійсно добре читається і містить переважно незамутнену деталями роботи з DOM логіку. Що, відповідно, дуже спрощує написання тестів і розробку через тестування. У той же час, крива відносини колег до використання Angular - досить ламана, зі спадами і стрибками від «Angular - кращий фреймворк» до «як ми взагалі вибрали це, проект приречений», і назад. Презентація доповіді Андрія Альперта .

Продовжив тему TDD Микола Алименко ( "TDD for database related code, how is it possible?", Mikalai Alimenkou ), Який постарався переконати аудиторію, що написання коду баз даних і доступу до даних через TDD не тільки можливо, але досить просто за рахунок використання деяких непересічних технік і сучасних інструментів.

Не секрет, що дані набагато важливіше вихідного коду програми. Маніпуляції над ними в продакшені повинні бути максимально безпечними. Це досягається тестуванням нових змін. Треба тестувати все, щоб бути впевненим в коді БД (схема БД, дані, кількість посилань цілісність даних, об'єкти БД, продуктивність і ін.). Найголовніше, що треба тестувати на реальній БД. Моки на рівні драйвера БД, або ORM / DAL не вирішують задачу тестування БД. Існує кілька відомих технік тестування: «чорний ящик»; тест - транзакція; тест - «герой» - сам готує собі дані, сам очищає. Інструменти діляться на групи: для управління міграціями (Liquibase, dbmigration) і для тестування (dbunit, Unitils). Т. о., TDD в базах даних, на думку автора, дозволяє позбутися від «простирадлом» чекліст з таємними знаннями, які потребують ручної роботи, диктує мінімально необхідний код змін, повний контроль коду доступу даних, легкий процес рефакторинга.

У реальному світі не завжди покриття автоматичними тестами гарантує щастя. Войцех Селіг ( "Automated Test Hell - Our Journey", Wojciech Seliga ) Розповів про проблеми, з якими зіткнувся, про шляхи їх вирішення і чому при цьому він і його команда навчилися. В цілому, доповідь була присвячена case study, як їхня компанія, розробник JIRA, боролася з проблемами CI. Зокрема: червоні білди, десятки тисяч повільних і нестабільних легаси -Тест, невірне ставлення до тестами у команди і сприйняття невдалого билда і т.д. Для поліпшення ситуації хлопці вжито такі заходи.

• Оптимальний баланс між ізоляцією, швидкістю, покриттям, зусиллями.
• Тести - це не сміття, а такий же код!
• Рівні білдів (A1, A2, A3) і чіткі політики. Кожен рівень відображає глибину інтеграції тестів. Вимоги: чим нижче рівень, тим вище вимоги до успішності билда.
• Візуалізація процесу билда важлива. Всі повинні бачити статус і реагувати вчасно.
• Навчання: як писати тести, політики, хороші / погані практики.
• Детермінованість тестів, боротьба з race conditions.
• Поліпшення продуктивності: тестів, git, компіляції, доступності білд-агентів, публікації результатів.

Команда з тих людей працювала над поліпшеннями CI більше року. Вони досягли певних успіхів, базової мети не досягли, але були зроблені наступні висновки:

• прозорість і розуміння реальних проблем допомагає з ними боротися;
• підтримка величезного масиву тестів дуже складна і витратна;
• треба «заміряти» проблему, вирішувати її, а потім заміряти результат;
• автоматичні тести - це не одноразова інвестиція, а постійна робота;
• продуктивність і ще раз продуктивність.

Залишається сподіватися, що ці висновки приведуть хлопців до кінцевої мети, і, звичайно ж, допоможуть іншим з вирішенням подібних проблем або взагалі їх запобіганням.

Рутинна робота може народжувати в голові лише одну думку: «А чи можна це автоматизувати?» На щастя, все більше і більше коштів виникає для автоматизації таких процесів.

Олександр Дорошенко. ( "Enterprise Provisioning with Chocolatey", Alexander Doroshenko ), Розробник і ентузіаст ALM і DevOps, з натхненням розповів, як в останні роки все більше скорочувався час розгортання серверів і як Chocolatey і Boxstarter допомагають конфігурувати Windows-машини. Якщо кому-небудь із слухачів після вивчення засобів автоматизації конфігурації UNIX-систем не вистачало такого ж в Windows, доповідь в якійсь мірі заповнив цей вакуум.

Використання Chocolatey і Boxstarter дозволяє, зокрема, отримувати ідентичні конфігурації і на десктопах розробників, не кажучи вже про економію часу на початок роботи з новим проектом. У двох словах, Chocolatey - аналог apt-get для Windows, а Boxstarter спрощує конфігурацію свіжовстановленому систем за допомогою Chocolatey, додаючи такі можливості, як управління процесом установки при перезагрузках, інсталяція Windows-оновлень, зміна налаштувань системи і т. Д

Чи може ровері додаток дозволіті Собі піті в оффлайн для деплоя хоча б на п'ять хвилин? Може, ви и скажете, що так, но подумайте, скільки Користувачів виявляв незадоволення. Саме тому zero downtime - наше все. Так Axel Fontaine ( "Architecting for Continuous Delivery and Zero Downtime", Axel Fontaine ), Розробник и консультант, нагадала, что сучасні компании на кшталт Facebook, Flickr, Stackoverflow давно перейшлі на Continuous Delivery и проілюстрував це скриншотами. Например, у StackOverflow внизу Сторінки вказує номер Версії и дата редеплоя. Причем зазвічай вона збігається з потокової, отже, оновлюється Досить часто. Далі розповів, як код проходить різні кроки на CI-сервері, починаючи від моменту коммітов і закінчуючи установкою на production і оновленням конфігурації. Згідно автору, кожен інсталяційний артефакт, наприклад, WAR-файл для Java, слід забезпечувати набором конфігураційних файлів для кожного енвайромента і використовувати автовизначення для вибору потрібного при запуску. Таким чином, все необхідне знаходиться в одному артефакті, яким легко керувати. Також згадав про Feature Toggles як рішення для проблеми заливки на VCS ще не повністю готового коду. Як пояснив доповідач, це дозволяє відмовитися від фич-бранчів і вести всю роботу в Транки VCS, що сприяє ранній інтеграції коду. Також не були забуті Blue / green-деплойменти - як спосіб поновлення додатків з мінімальним downtime.

Підхопив тему діплоймента Андрій Ребров ( "Building deployment pipeline: DevOps way", Andrey Rebrov ), Розробник і коуч, який розповів про DevOps як про спосіб підвищити якість, швидкість і прозорість процесу поставок через подолання суперечностей між Dev- і Ops-командами. Відзначив і складові цього процесу: Культуру, Автоматизацію, Вимірювання та Обмін знаннями, що втілюється в життя шляхом проведення тімбілдінгу, спрощення деплоймент-скриптів за рахунок використання різноманітних інструментів, всеосяжного моніторингу логів і їх аналізу і збору статистики, побудови на їх основі різних графіків.

Було цікаво подивитися на аналіз логів за допомогою Splunk: довгий 5-рядковий запит виводив коррелляціі між різними подіями в балці, розраховував середні значення і відхилення показників.

У Іцхака Адізеса є чудове твердження "if it does not get better it gets worse", з яким навряд чи хтось сперечатиметься. Тому кожну систему, випущену в продакшн, потрібно підтримувати і моніторити. Андрій Самиляк ( "DevOps Engineering in real-time", Andriy Samilyak ), Що має багатий досвід організації і координації DevOps, розповідав про проблему конфігурації і підтримки систем з дуже широкою географією в режимі 24х7 операційними командами.

Основний інструмент, який вони використовують для автоматизованого управління конфігураціями, - Chef, написаний на Ruby. Це одна з чотирьох найпотужніших систем управління конфігураціями для Linux. Продукт дозволяє створювати «рецепти», які описують, як Chef управляє серверами додатків.

Крім того, DevOps-команда активно використовує Jenkins для CI, який дозволяє робити багато в плані управління тестовими, дев-оточеннями і створювати «пісочниці» для команд розробників.

І останній найбільш важливий атрибут якісного DevOps, який у них активно впроваджується і розвивається, - моніторніг. Без нього DevOps просто сліпий. Їх команда використовує такі інструменти, як Sensu, Splunk. Це відмінні Тули для агрегації і репортінгу різних статистик роботи сервера додатків.

Ну, і куди ж без хмар? Олександр Демидов ( "Living in the cloud without system administrators", Alexander Demidov ) Не зміг обійти хмари стороною, і повідав історію досвіду побудови високонавантаженої хмарної системи, повідав з обґрунтуваннями того, чому його команда прийшла до того чи іншого рішення. В першу чергу доповідь буде цікавий архітекторам і DevOps-інженерам ну і всім, хто планує розгортання систем в хмарі Amazon. Основні ідеї, які хотів донести автор:

• Amazon - гарне хмара.
• Не вірте рекламі, яка говорить, що хмарні рішення надійніше звичайних: наш досвід показує, що хмарні системи навіть таких перевірених компаній, як Amazon, схильні до збоїв на рівні «заліза» і впливу людського фактора.
• Думайте про масштабованості на етапі проектування продукту (як приклад, використовують абстрактний файловий API, що дозволяє їм працювати прозоро з будь-хмарної ФС)!
• Percona (fork MySQL) показує кращі результати, ніж MySQL. Це і швидше рестарт і веде внутрішню статистику запитів і доступу до даних.
• Майстер-майстер реплікація між дата-центрами з розділенням по парності.
• Застосовуйте автомасштабирование системи - використовуйте СloudWatch-систему для автоматичного старту / видалення додаткових нод на підставі середнього завантаження CPU.
• Будь-яке повідомлення від системи моніторингу вимагає реакції, інакше цей потік нікому потрібен.
• Автоматизуйте реакцію на деякі рутинні повідомлення системи моніторингу!
• Моніторьте систему моніторингу!
• Постійний feedback розробникам (статистика по продуктивності, логи помилок, логи повільних запитів і т.д.).

Якщо хочете дізнатися докладніше, дивіться доповідь Олександра.

Ось так і пролетіли два дні конференції. Хочеться подякувати доповідачів за час, сили і величезний досвід, яким ніхто не скупився ділитися; організаторам за таке прекрасна подія і, звичайно ж, DataArt за можливість взяти участь в ньому.

Перш ніж завершити цей нескінченний потік букв, напевно, варто відзначити, що скоро часу всі матеріали конференції будуть доступні на сайті XP Days в розділі History . Там можна буде детальніше ознайомитися з матеріалами, і навіть посметреть відосікі з доповідями не тільки тим, хто не знав, як розірватися між розумними і красивими і на який stage піти, але і просто всім бажаючим.

наш фотозвіт

Фотозвіт від організаторів