Дивовижний світ веброзробки

Товариство! 9 травня відбудеться зйомка нового випуску формату "Одне питання — три відповіді" у Львові. Шукаю одного джуніора, одного мідла і одного синьйора аби ставити їм різні хитрі запитання зі співбесід і потім душно розбирати кожну відповідь. Хочете потрапити в телевізор? Залишайте заявку ось тут: https://forms.gle/nTk163B1KEJ7qeRG9 Або пишіть мені особисто, це може суттєво підвищити ваші шанси потрапити в число учасників ;) Зйомка відбудеться за підтримки компанії appflame.

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

Так, ну а хто вже подивився відео, з вас по десять гривень. Бо збір на РЕБ для 115 ОМБр триває. Зібрано: 8 065 грн Мета: 230 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743

Як вдало розпочати новий робочий тиждень? Правильно — з перегляду нового відео! https://youtu.be/Fds47q02RNQ

Товариство, останнє нагадування! Svitla Systems розігрує бананку і крутяцьку парасольку (дивлюсь у вікно — актуально шо капєц) просто за те, що ви дасте відповідь на запитання у формі. Цього разу, до речі, єдино правильної відповіді немає, тож участь в розіграші братимуть усі, хто заповнять формочку до кінця сьогоднішнього дня! І ще — якщо зберемо достатньо відповідей, то окрім бананки й парасольки, ми розіграємо персональну консультацію від мене особисто. Скільки це достатньо? Ну явно більше, ніж є зараз ;) Чекаємо на ваші відповіді на "Питання від партнера"! https://forms.gle/rqHKzisACJxDsSCp9

Я так і не навчився вайбкодити. Увесь вайб зникає вмить, щойно у мене зʼявляється думка — "гм, а шо воно там нагенерувало?". Знаєте, є приказка "деякі двері краще не відкривати"? У випадку з LLM її можна переробити на "деякі файли краще не відкривати". Або навіть "всі файли". Я постійно заглядаю в ці файли, і результаті або це перестає бути вайбкодингом, коли я починаю робити вже серйозний сетап зі скілами, вікі та іншими правилами, або ж я дякую за напрямок і починаю писати сам. До речі, другий шлях мені подобається більше. Я дивлюсь на цей код, відзначаю, що я б зробив по-іншому і… роблю по-іншому. Чому для мене цей шлях кращий? Бо я впертий як віслюк в своїй недовірі до LLM, і через це постійно шукаю кращі, на мою думку, шляхи зробити те чи інше. Чи то інший архітектурний підхід, чи то використання іншого бравзерного API, чи моє улюблене "це вміє CSS". Певною мірою я можу сказати, що для мене вайбкодинг є потужним поштовхом для самовдосконалення, адже піддаючи сумніву кожне рішення LLM, я здобуваю нові знання. Проблема LLM в тому, що вони генерують усереднений код. Не такий, що підходить під цю конкретну задачу, а такий, яким в середньому є увесь той код, на якому LLM вчилась. А людство, в середньому, не є наймудрішою колективною свідомістю, будьмо відверті. Відмовляючись приймати посередність, я прагну знайти досконалість через нові знання. І часто це призводить до цікавих відкриттів. І нагадаю вкотре — я чітко розділяю вайбкодинг та AI assisted розробку. Радити в цьому випадку будувати пайплайни з агентів, створювати безліч скілів і будувати knowledge-wiki для маленького проєкту-досліду це усе одно, що радити рибалці, що сидить на березі ставка з однією вудкою, обовʼязково придбати 800 спінінгів і авіаносець для виходу у відкритий океан.

#css_in_action Анімуючи небуття Ми усі звикли до анімацій в CSS. Зокрема я зараз говоритиму про transition: воно змінює значення від початкового до кінцевого в залежності від часової функції на заданому часовому проміжку. І тут важливо згадати про дві умови: анімація не може відбутися, якщо немає так званого before-change style — попереднього відрендереного стану, від якого анімація може стартувати, а також якщо значення, яке ми намагаємося "оживити", не може мати проміжних станів, тобто є дискретним. В CSS обидві умови можна зламати, просто використавши display: none. Тривалий час задача "показати/сховати елемент і додати анімацію появи/зникнення" покладалась на JavaScript та його ненадійні таймери. Згодом зʼявилася дещо надійніші події на кшталт transitionend, але вони вирішували лише частину проблеми. Але сьогодні ця задача більше не є проблемою. CSS надає нам дуже цікаві інструменти, що дозволяють дещо більше, ніж просто "анімувати `display:none`". Мова про @starting-style та allow-discrete. Коли елемент переходить від display: none до "видимого" значення, за замовчуванням усі кінцеві значення властивостей застосовуються одразу, навіть попри transition-duration. Чому? Бо у елемента немає *початкового стану*, на основі якого можна розрахувати перий кадр анімації. Чому? Бо він на момент початку переходу просто ніколи не був *відмальований*. Це якщо ми говоримо про видиму зміну стану.

Примітка Елемент може не мати відмальованого стану з кількох причин. Наприклад, display: none означає, що елемент взагалі не бере участі в рендерингу, а от visibility: hidden значить, що елемент невидимий, але займає місце в макеті.

Так от, тут в нагоді нам стає @starting-style. Це @-правило дозволяє "допомогти" бравзеру створити той самий перший кадр, від якого він уже буде спроможний розрахувати анімацію. Тобто сама суть не в тому, що бравзер не може інтерполювати певні значення, а в тому, що він просто не розуміє, як має виглядати перший кадр.

element {
  transition: 1s;
  display: none;

  &.visible {
   display: block;
   opacity: 1;

   @starting-style {
     & { opacity: 0; }
    }
  }
}

Таким чином можна додати анімацію не лише до display: none -> block, а й при вставці нового елементу в DOM. Тож, якщо коротко: @starting-style це шпаргалка, яку ми надаємо бравзеру, аби він зміг зрозуміти, як намалювати перший кадр анімації для елементу, у якого не було відмальованого (rendered) стану до того. Наступна проблема — анімація від видимого стану до "невідмальованого", і полягає вона в абсолютно іншому механізмі: оскільки дискретні значення анімувати неможливо, бравзер за замовчуванням просто "перемикає" їх на *початку переходу*. І саме тому намагаючись "анімувати" елемент в небуття від display: block до display: none ми не бачимо переходу, а лише миттєве зникнення. Це можна було б вирішити, якби можна було "відкласти" перемикання на потрібний нам час замість миттєвої зміни. І от якраз це раніше можна було вирішити виключно за допомогою JavaScript: або ставити таймери, або слухати події завершення анімації, і вже тоді "клацати перемикач" вручну. І, нарешті, цей механізм є і в CSS. Це значення allow-discrete для властивості transition-behavior. Він робить рівно те, що необхідно: дозволяє відкласти перемикання дискретної властивості на потрібний час.

element {
  transition:
    opacity 1s,
    display 1s allow-discrete;
  display: none;
  opacity: 0;
}
element.visible {
  display: block;
  opacity: 1;
}

Якщо ми приберемо .visible з елементу, то спочатку побачимо, як той поступово "зникає", і лише в кінці, коли opacity досягне нуля, display набуде значення none. Якщо коротко, то allow-discrete дозволяє визначити для перемикання значення дискретної властивості певну точку на часовій шкалі анімації, але з купою виключень, звісно. Які я вам пропоную дослідити самим. MDN: @starting-style MDN: allow-discrete *** @babichdev

Ще шість донатів не вистачає до нового допису. Маєте часу до вечора )

Подивіться трози смішного, може подобрієте і пару гривень закинете на збір. https://www.youtube.com/watch?v=4IbYcY0-va0

#коштозбір Товариство, збір на РЕБ для 115 ОМБр триває. Зібрано: 47 210 грн (+3055грн) Мета: 300 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743 P.S. Я дуже хочу написати один допис про крутяцьку фічу CSS, але не маю достатньої мотивації. Мотивація може зʼявитися, якщо сьогодні до вечора зʼявиться щонайменше 20 донатів.

#коштозбір Товариство, збір на РЕБ для 115 ОМБр триває. Зібрано: 44 155 грн (+1050грн) Мета: 300 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743

#розіграш А ще маємо "Питання від партнера", товариство. Svitla Systems розігрує бананку і крутяцьку парасольку (дивлюсь у вікно — актуально шо капєц) просто за те, що ви дасте відповідь на запитання у формі. Цього разу, до речі, єдино правильної відповіді немає, тож участь в розіграші братимуть усі, хто заповнять формочку до 13 квітня. https://forms.gle/rqHKzisACJxDsSCp9 І якщо ви ще досі з якихось причин не подивилися нове відео "Що робить Engineering Manager" — не зволікайте. Вийшло дуже цікаво.

Нове відео на каналі! Товариство, запрошую до перегляду нашої розмови з Павлом Зубенко, Engineering Manager в Svitla Systems. Обговорили багато цікавого — що то за роль така, чи пише Павло код, що найважче в роботі і так далі. І ще трошки про джунів поговорили. https://youtu.be/wUruDAKZj0E *** Відео вийшло за сприяння Svitla Systems, глобальної IT-компанії з більш ніж 20-річним досвідом, головний офіс якої знаходиться в Каліфорнії, а операційна діяльність поширюється на більш ніж 15 країн, зокрема США, Канаду, Мексику, Коста-Ріку, Аргентину, Україну і Польшу. Svitla об'єднує понад 1000 спеціалістів з різних технологій. Серед клієнтів як інноваційні стартапи, так і компанії із Fortune 500. Вакансії Svitla Systems @babichdev

Маленький тизе на завтра )

За кілька хвилин почнемо потихеньку запис "Вайбкод ревʼю для трейні", тож як маєте бажання, заходіть до студії. https://riverside.com/studio/-s-studio-3uCyp

#анонс Товаристо, сьогодні відбудеться онлайн-зйомка на ютуб. Це буде вайбкод-ревʼю для трейні. Не те, щоб зовсім новий формат, але мій підхід буде сильно відрізнятися від того, що я вже робив на публічних співбесідах. По-перше, фокус буде не на коді як такому, а радше на відповідальності за цей код. Чому? Бо головна умова — задачу має бути виконано вичключно за допомогою ШІ. По-друге, буду мати бога в серці, бо учасницею буде людина, яка ще вчиться і не має комерційного досвіду. Тому я не буду сильно придиратися до самого коду, а радше до підходу, до того, як цей код зʼявився на світ. По-третє, я спробую перетворити це не на рознос, а на дружню ментор-сесію. Тому окрім відповідей, будуть ще й практичні поради від мене. Ну й тривалість має бути меншою за звичні дві години, але хто зна, хто зна… Планую почати зйомку о 19 годині, тож хто має час та натхнення долучитися, чекатиму вас у віртуальній студії: https://riverside.com/studio/-s-studio-3uCyp

#коштозбір Товариство, збір на РЕБ для 115 ОМБр триває. Зібрано: 44 155 грн (+150грн) Мета: 300 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743

Громадо! 2 квітня робимо чергову лампову, і вже знаємо, що буде гаряче. Двоє спікерів, обидва з темами про ШІ — але не з тими, де “ой які ми всі молодці, живемо в майбутньому”. А з тими, де чесно і в лоб. Мирослав Танцюра розкаже, чому ШІ пише фігню — і чому це не його провина (спойлер: це наша). Марк Абрагамович підніме тему, яку всі бояться обговорювати вголос — що відбувається з нашими навичками, поки ми радісно делегуємо все штучному інтелекту. Формат як завжди — ніякого “сиди тихо і слухай”. Хочеш перебити — перебивай. Хочеш челенджити спікера — будь ласка, тільки будь готовий, що тобі теж прилетить. Без образ, але й без дипломатії. І так — на цій зустрічі ми анонсуємо наступну лампу. Нова локація, новий формат, спонсори, подарунки, афтепаті на свіжому повітрі. Коротше, ми трохи підросли і хочемо показати, що з цього вийшло. 📅 2 квітня, двері о 18:00 📍 Львів, офіс Sigma Software Приходь, якщо не боїшся думати вголос. Ну і якщо боїшся — тим більше приходь, ми тебе розговоримо. Реєструйся ось тут за ціну менше смузі

#коштозбір Товариство, збір на РЕБ для 115 ОМБр триває. Зібрано: 43 105 грн Мета: 300 000 грн 🔗Посилання на банку https://send.monobank.ua/jar/46FX59UkXS 💳Номер картки банки 4874100026432743

#думки_вголос Що таке код-ревʼю і кому воно потрібне? Особливо сьогодні, в часи LLM, які прямо все-все можуть робити за нас. Я стикався з різними підходами, які варіюються від "нафіг воно кому треба", "ревʼювить тільки тімлід" і до "поки не отримаєш тисячу зелених галочок, твої два рядочки в стейдж не попадуть". З деякими я не погоджуюсь, деяким лишаю право на існування, деякі підтримую беззаперечно. І з плином часу мій цей розподіл змінюється. Але одне залишається постійним — я вважаю, що код-ревʼю необхідні і потрібні. В першу чергу це спосіб не пропустити сумнівні рішення не лише в кодову базу, а й у голову автора. Адже схваливши такі пул-ріквести, ми прямо кажемо — "молодець, нам норм". І якщо таке рішення проходить раз, другий, то на третій автор уже буде впевнений, що його підходи до коду — правильні. Далі — код-ревʼю це чудовий спосіб для обміну досвідом. До того ж, попри поширену думку, старші колеги теж іноді можуть чогось навчитися від менш досвідчених, але часто більш жадібних до знань розробників. Це, певно, одна з найперших порад, які я даю щодо покращення процесу ревʼю — вчіться один у одного. Код-ревʼю це чудова нагода для цього. Щодо LLM в код-ревʼю. Це прекрасний інструмент для визначення механічних хиб — потенційних багів чи відхилень від конвенцій. В цьому плані використання LLM не відрізняється від того ж лінтера чи ще якого статичного аналізатора. Усе, що може бути автоматизоване — має бути автоматизоване. Але й повністю віддати на плечі алгоритму весь процес ревʼю мені не видається можливим. Він може покрити більшість речей, які можна формалізувати, а от відкриті до дискусій питання будуть приречені на довічне лімбо "це вже майже ідеальний варіант, але…". З LLM дуже важко сперечатися, воно завжди знайде до чого доколупатися. Навіть у рішеннях, запропонованих ним же. Насправді, на мою думку, головна причина неможливості повної автоматизації код-ревʼю LLM — це відповідальність. У LLM її немає. "Так, дійсно, я пропустив цей PR. Хочеш, більше не буду його пропускати?". Тому людське ревʼю має обовʼязково бути. Це засіб для обміну досвідом, для навчання, місце для дискусій й спільних рішень. Хороше код-ревʼю має шукати відповідь на питання "Чому автор зробив саме так?". Не "чому тут let а не const", не "Boolean() vs ||", чи ще якесь технічне душнільство, яке має бути знайдено пайплайном. А саме "Чому автор обрав цей шлях?". Хороше код-ревʼю заохочує. До дискусії, до обміну знаннями, до професійного росту. Хороше код-ревʼю — спільна справа. Джуни мають ревʼювати техлідів, так само як і мідли — синьйорів. Одним словом — усі мають ревʼювати усіх. Хороше код-ревʼю важко зробити. Погане — взагалі не вимагає зусиль. Тому я часто чую історії про те, що ревʼю проводить тільки техлід за попереднім записом, чи що джуни не ревʼювлять нікого, зате їх — усі. І так далі. Код-ревʼю — це точка росту не лише для одного розробника, а й для усієї команди, продукту.