Як я побувала на HolyJS Moscow і чи треба туди ходити



Минулої неділі, 11 грудня, мені випала нагода взяти участь в HolyJS Moscow, грандіозному заході, цілком і повністю присвяченому JavaScript. Кількість інформації на конференції вражало уяву (не обійшлося навіть без згадування інших технологій, хоча це логічно: у світі веб-розробки все взаємопов'язано), однак з усього масиву особисто мені запам'яталося чотири доповіді. Відразу обмовлюся: справа не в тому, що інші були краще або гірше, просто саме ці привернули мою увагу найбільше. І тут я поясню докладно, чому це так.

Для початку — невеликий ліричний відступ. Одна з причин мого переїзду до Москви полягала якраз у тому, щоб мати можливість брати участь у подібних заходах, перебувати в центрі останніх новин і технологій, завжди бути на гребені хвилі і в курсі модних тенденцій в світі frontend. Я навіть не пам'ятаю, коли саме мене охопила манія до вивчення всієї інформації, яка мене оточує, але так було не завжди. Впевнена, що в цьому прагненні я не самотня. Багато хто з вас намагалися або навіть намагаються в даний момент вивчити 16 фреймворків та 23 бібліотеки за тиждень і за одну ніч викотити шість проектів. Звідки це береться? З одного боку, інтуїтивно зрозуміло, що, якщо не встигати за новими технологіями, можна виявитися незатребуваним. Так що, можливо, всіма нами рухає страх. Але з іншого — задайте собі питання: чи так це насправді? Залишаться хлопці без знання webpack, наприклад, або изоморфного рендеринга не у справ? Адже іронія перегонів за технологіями полягає в тому, що можна напоротися на фреймворк, про який всі говорять, почати її вивчати, вбити -дцять ночей і одного разу прокинутися разом з релізом нової, несумісною із зворотного, версії цього ж фреймворка. Більше того, ця версія буде з новим синтаксисом, термінами і абсолютно іншим підходом.


Цю історію ми всі знаємо або з власного досвіду, або з чужих розповідей. Ми починаємо говорити: «За технологіями не угонишься», «Це сьогодні модно, завтра вже немає» або «Поки я буду розбиратися з цією бібліотекою, вийде ще сім». Проте навіть знаючи, що таке станеться, все одно поспішаємо зібрати новий проект на модних інструментах хоча б в пісочниці, щоб позбутися страху, що ми не в темі. Я зовсім не хочу сказати, ніби вивчати нове — це погано! Але що саме вивчати? Скільки часу витрачати? Іншими словами, як залишитися затребуваним frontend-розробником, щоб не померти від недосипу і стресу до 30 років?

Зовсім недавно я прийшла до висновку, що життя у форматі нічного кодинга та цілодобової роботи над вивченням технологій — це не життя. Підводить здоров'я, рано чи пізно накриває депресія, а найжахливіше — ти починаєш думати, що в тебе нічого не виходить, та й як розробник ти, в принципі, так собі. Це називається фрустрація. Знайоме? А адже головна її причина криється в банальної втоми. Тому в моєму житті з'явилося обмежений час на роботу. Воно постійно намагається вирватися з рамок і захопити все життя, але я тримаюся. Саме з цих причин мене так зачепив доповідь Дениса Мишунова під назвою «Debugger».



Першим ділом Денис вказав на симптом, за яким можна виявити у себе цю «хворобу», навівши елементарний приклад. Отже, ви прийшли на конференцію, де в один і той же момент читають три цікаві доповіді, і не знаєте, куди йти. А коли вже вибрали — думаєте: а раптом там, на іншому доповіді, інформація більш важлива… Знайома ситуація? Я від душі посміялася, тому що приклад потрапив в точку.

Зазначив Денис і те, що звична багатьом фрустрація насправді тільки заважає мозку вивчати нову інформацію. Тема перфекціонізму (без якого ми взагалі не живемо) була розкрита на факт з біографії Генрі Форда, який одного разу прислухався до слів свого помічника і зважився випустити неідеальну (на думку Форда) машину. У підсумку саме це ключове рішення зробила його всесвітньо відомим і надзвичайно багатою людиною. Ще один приклад — лист Гарвардського університету з заголовком «Slow down» («Зменште темп»), в якому студентів закликали не побиватися, вивчаючи інформацію, і не прагнути укласти два або навіть три роки навчання в один.

Це був єдиний нетехнічний доповідь на конференції, який, прозвучавши в самому завершенні заходу, виділявся більше всіх. Впевнена, що незабаром він з'явиться в Мережі. Обов'язково подивіться його і задумайтеся: чи правильно ви робите? Може, ночами слід спати? Або ви залишаєтеся при думці, що сон для слабаків?

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

Суть в тому, що веб-розробка ускладнюється з кожним днем, з кожною годиною. З'являється все більше складових частин і, як наслідок, питань комунікації між ними. Проблема створення плагіна для налагодження складання або продукту, в якому потрібно проводити транзакції між сервером і клієнтом, стає все гострішою. Нам потрібно покривати все більше і більше кейсів і вирішувати все більше проблем, про які ми раніше навіть не підозрювали. Варіанти виходу з цього складного становища були описані в доповідях Роми Дворнова про Rempl і Андрія Ситника про Logux.



Rempl (remote platform) — це платформа для контрольованого доступу до віддаленого JavaScript runtime з використанням UI. Якщо зрозуміліше, це набір всього найнеобхіднішого, що спрощує створення віддалених інструментів. Інтерфейс таких інструментів може запускатися як у плагіні для Chrome, так і в окремій вкладці або в плагіні до редактора. Можливості використання Rempl просто підривають мозок — від інструментів, бібліотек і фреймворків до «божевільних» ідей начебто простого файлообмінника. Колеги з компанії Avito створили Rempl, вирішуючи свої завдання, але вирішили поділитися напрацюваннями з усіма. Тепер замість мук з проблемами інфраструктури ми відразу думаємо, що можна зробити, маючи віддалений доступ до одного JavaScript runtime з іншого через користувальницький інтерфейс. Якісь частини платформи ще в розробці, але вже зараз хлопці запрошують усіх взяти участь в житті opensource-проекту та втілити свої фантазії в життя. До того ж самому вас закликаю і я!



Logux — це транспорт, синхронізуючий стан даних на сервері і клієнті і вирішальний, таким чином, проблему втрати інтернету у користувача. Назва технології може здатися вам співзвучним з Redux, і це не випадковість. Logux є свого роду об'єднанням Redux і Swarm.js. Перша частина назви Logux відображає підхід до синхронізації даних — через логи. Наприклад, якщо ви опинилися у лісі, горах або на безлюдному острові і відправили коментар під фоточку з котиком, то, коли ви з'явитеся в Мережі, хронологічно він виявиться саме там, де і повинен був знаходитися, коли ви натискали кнопку «відправити». Логи на сервері і клієнті синхронізуються по часу. Андрій зазначив, що технологія поки ще сира, а готову версію обов'язково будуть надавати відразу з рекомендаціями до застосування та кращими практиками. Незважаючи на різницю двох технологій, Rempl і Logux, погодьтеся: вони дійсно перегукуються, вирішуючи проблеми складних комунікацій.



Останній доповідь, про яку я хочу розповісти («Мутація Web»), представив Павло Кондратенко. Зокрема, він розповідав про способи, за допомогою яких Lenta.ru утримує користувачів на сайті: про push-повідомлення, AMP (js-бібліотеці від Google для прискорення роботи web-сторінок на мобільних пристроях, яка ще і сприяє їх індексації) і… про хрестики-ноликах. Так, саме про хрестики-ноликах. Міні-гра відкривається, якщо користувач вже був на сторінці Lenta.ru з телефону, але у нього пропав інтернет. Тепер читач більше не закриває сторінку, а залишається на ній і грає в хрестики-нулики. Круто? Дуже круто. Можна прямо зараз рвонути і перевірити, що це так. Єдиний мінус — опція працює тільки для смартфонів на Андроїд. Питання «чому?» пропоную поставити Павлу особисто. Що ж стосується push-повідомлень, то вони є новинкою для сучасного ринку і тільки-тільки починають привертати увагу бізнесу. А між тим, як показує досвід Lenta.ru кількість відвідувань сторінок сайту після початку використання повідомлень збільшилася на 2 %.

Такі чотири доповіді, які я вирішила виділити з усієї конференції. Повторюся, це зовсім не означає, що інші опинилися нудними або неважливими! На HolyJS Mosсow було величезну кількість цікавої інформації, яку представили прекрасні англо — і російськомовні спікери. Окремо хотілося б відзначити відмінний звук і подарунки на зразок шоколаду від HolyJS (щоб мозок краще працював) або моєї нової худі з написом «JavaScript» (щоб тепер вже точно було видно, що я веб-розробник). Нарешті, не можна не згадати майданчик для холиваров після виступів, яка не пустувала ні на хвилину, і, звичайно ж, afterparty з душевними розмовами про технології та спілкуванням зі спікерами. Я можу з упевненістю сказати, що з кожною такою конференцією ми стаємо все ближче і ближче до європейського ком'юніті розробників.

На завершення. На заході я зустріла колег зі свого попереднього місця роботи, які самі вже працюють в інших компаніях. Ми обмінялися новинами і теплими спогадами. Також я побачила знайомих з минулих конференцій, налагодила нові зв'язки, подружилася з відмінними розробниками, надихнулася на чергові звершення і просто була щаслива, що я є частиною цього великого співтовариства. Варто відвідувати такі заходи і тусовки, як HolyJS Moscow? Безперечно, так! Тому що тільки тут ви зможете не тільки зустріти своїх старих знайомих або познайомитися з майбутніми друзями-колегами-однодумцями, але й набратися знань і натхнення на створення по-справжньому крутих речей!

P. S. Знаєте, що найжахливіше? Після конференції, а точніше після закриває доповіді Дениса про те, що потрібно зменшити темп, я просиділа півночі за комп'ютером, перебираючи в інтернеті все почуте і вивчаючи документації… Впевнена, що в цьому я була не самотня! Все-таки ми невиліковні: ми розробники.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.