Thread by @xanf_ua

Повбрасываем? :) Один лайк - один факт о жизни фронтенд-разработчика в GitLab :)

#1 Фронтенд - очень широкое понятие в GitLab. Фронты должны уметь писать HAML-шаблоны (для меня это бооль), e2e-тесты на rspec + Capybara, helper'ы для отображения и прочие ужасы. Ruby придётся подтянуть, хотя есть команды, где пишут всё новое и такого нет

#2 Если брать всю кодовую базу GitLab - то можно найти уникальные вещи. К примеру при редактировании проекта в ответ приезжает JS-код, который надо eval'ить. Таких мест немного, но они есть. Это связано с тем что долгое время в GitLab было очень мало фронтов и код писали рубисты

#3 GitLab построен на Bootstrap, но у нас планы это изменить - для этого разрабатывается "пижамка" (теплая и ламповая дизайн-система GitLab) design.gitlab.com. Цель - перееехать целиком на нее. Сейчас это во многом обертка над бутстрапом, но это пройдет

#4 Из-за Bootstrap'а на данный момент практически невозможно в данный момент выпилить JQuery из кодовой базы - так-как очень многие вещи слушают бутстраповские-события, а они JQuery. Меня это лично печалит

#5 Мы мигрируем на Vue. На данный момент около 15% кодовой базы написано на Vue, и мы все еще не можем определиться, мы умные или красивые - пропагандировать подход Vue-first, или все-таки оставлять серверные шаблоны и progressive enhancement

#6 Систему i18n в GitLab можно показывать в разделе "реликты" - это связано с тем, что внедряли ее давно, она должна была работать с JQuery-кодом, в итоге во Vue всё смотрится противоестественно - но работает

#7 CI-пайплайн в GitLab занимает около полутора часов. В работе находятся сразу несколько задач, пока ты смиренно ждешь результата. Билд становится красным на каждый чих - знаю разработчиков, которые включили на почту уведомления только об успешных билдах, чтобы не спамить себе

#8 Если вам кажется, что полтора часа это долго, то бывают "особые случаи" - когда изменения затрагивают образ, для авто-тестов гитлаба (не путать с е2е тестами). В таком случае триггерится "зависимый" пайплайн - и общий результат будет через 3-4 часа

#9 У нас три фреймворка для тестирования - karma (использовалась раньше), jest (для unit-тестов) и rspec + capybara. Мы изучаем возможность использования github.com/smooth-code/je… для написания интеграционных тестов тоже на Jest

#10 Если вы хотите "практического" опыта поддержки продукта (а не bleeding edge) - GitLab очень хорошее all-remote место с правильной атмосферой для обучения. В 2020 у нас будет тестовый internship (преимущественно для студентов) about.gitlab.com/handbook/engin… Вдруг кому интересно

На первой десятке пойду сделаю себе кофе, дождусь результатов пайплайна gitlab.com/gitlab-org/git… и через пару часов продолжу :)

И да, мне нравится работать в GitLab. У меня были офферы в 2 раза больше на старте, и сейчас сманивают, но здесь для меня реальный челлендж

#11 GitLab - documentation-first компания. Это значит, что если чего-то нет в developer-документации или handbook - это будет сделано неправильно :)

#12 Когда я смотрю на наши karma-тесты, написанные пару-тройку лет назад - бездна бытия Ruby-разработчика вглядывается в меня. Очень ощущается, что стиль тестирования принятый на backend'е переиспользовали на фронте (к примеру тесты computed во Вью-компонентах)

#13 В GitLab нет CODEOWNERS конкретных фич - все фронтендеры ревьювят, и мейнтейнеры frontend'а отвечают целиком за всю кодовую базу :) Это значительно снижает bus factor и позволяет открывать для себя новые стороны кодовой базы даже спустя полгода работы

#14 В то же время отсутствие CODEOWNERS, имеет ряд проблем. К примеру GraphQL - сравнительно новая тема в GitLab, и не все фронтендеры и мейнтейнеры имеют в ней значительную экспертизу, что иногда значит, что конкретный этап ревью может быть просто формальностью

#15 Каждый merge request ревьювится минимум двумя людьми - frontend/backend reviewer (просто коллега в GitLab) и frontend/backend maintainer. Если ваш MR затрагивает и бэк и фронт - будет 4 ревьювера. Если тесты - еще пара. Если миграции... И так до 12 человек на один MR

#16 Чаще всего MR ревьювится 2 или 4 людьми (в зависимости от того, трогали ли вы то, что система считает backend'ом или нет). Среднее время с момента перехода MR в "In review" до мерджа превышает 10 дней, GitLab старается сейчас оптимизировать эту метрику

#17 Ревьюверы назначаются "рулеткой", но это рекомендация. Вы можете назначать назначать MR на других ревьюверов, это не запрещено. Это позволяет, к примеру, принудительно отправить MR ревьюверу, что уже в теме предыдущих MR'ов, повышая качество ревью

#18 Ревьюверы назначаются "рулеткой", но это рекомендация. Вы можете назначать назначать MR на других ревьюверов, это не запрещено. Это открывает пространство для злоупотреблений, когда разработчики устраивают междусобойчик, и, как по мне, повышает риски некачественного ревью

#19 Мне ревьювить в GitLab очень сложно - кроме конкретных изменений в конкретном MR уходит много времени на то, чтобы за деревьями увидеть лес - как конкретный код конкретного MR соотносится со старым кодом, может что-то надо выкинуть в старом коде или переписать

#20 К сожалению у нас (пока) нет "платформенной" команды, которая заведовала бы базовыми примитивами, плюс команды не всегда взаимодействуют между собой - в итоге в коде можно найти пачку разных реализаций Event bus и прочих подходов. Вычищать такое очень сложно.

Еще одна десятка :) Кофе закончилось (да, к сожалению "оно"), ждите следующую через пару часов

#21 GitLab многому меня научил. В этой десятке поговорим об этом.

Прежде всего, all-remote культура учит думать "на два шага вперёд", когда в своих MR ты сразу поясняешь, почему так сделано, не дожидаясь вопроса

#22 GitLab научил на практике (а не в теории) максимально защитному программированию - начиная от CSS, заканчивая валидацией пропсов

#23 Я научился культуре boring solutions - которые не хайпуют, но и позволяют не увеличивать технический долг

#24 С другой стороны, я все ещё учусь (и мне это безумно нравится) быть грамотным инноватором - не просто вбрасывая варианты "давайте используем что-то", а анализируя последствия своих решений

#25 До GitLab'а я никогда не использовал локально pinning testы для рефакторинга - когда ты максимально быстро пишешь грязный тест, который фиксирует текущее поведение, и при рефакторинга следишь чтоб его не сломать (это не отменяет необходимости хороших тестов в принципе)

#26 GitLab учит commit, disagree and commit - подавать голос, не соглашаться но и следовать линии партии, если решение принято

#27 В GitLab работают люди из более 60 стран с разными культурами. То, что звучит вежливо для нас, может прозвучать странно для ваших коллег и наоборот. Умение всегда искать positive intention, даже если кажется, что допустим ревьювер идёт на конфликт - важный навык

#28 В GitLabе учат не боятся плохого кода. Ценность iteration, когда плохой код улучшается до хорошего (но никогда до идеального) на бумаге звучит просто, но я этому учился

#29 Фронтенд в GitLab сейчас развивается огромными шагами. И очень важный навык, которому я учусь - думать о том, как те решения что только обсуждаются отразятся на моем коде - не станет ли он легаси через день после написания

#30 И конечно GitLab учит смирению и вере. Смирению, потому что ты не можешь поменять все сразу, чтобы стало хорошо и вере, что ты, да, именно ты, можешь шаг за шагом сделать кодовую базу лучше.

Культура GitLab'а всячески поощряет эту веру и главное не опускать руки

Спонсор сегодняшней серии твитов - жёлтый Лотус. Переобуть на зиму, поставить жёсткую крышу вместо тканевой, помыть - куча времени, чтобы твитить. И как бы я всё это без машины бы успел (с)

#31 На Новый Год у Деда Мороза я попрошу typescript в GitLab'е

Жаль, что Деда Мороза не существует

#32 Те, кто следят за мной на YouTube знают, что я не люблю typescript. Здесь я выбираю его как most boring solution и инструмент, который может начать приносить пользу с первого дня

#33 К примеру использование typescript позволит нам гарантировать корректность optimistic responses в graphql относительно серверной схемы

#34 У нас Vue, поэтому сверхтипизированного фронтенда, увы не выйдет. Фактически typescript важен не только и не столько как инструмент контроля, но как инструмент описания внутренних типов, которыми обмениваются сущности в GitLab

#35 GitLab - не SPA и не планирует пока что им становиться. Фактически мы делаем микрофронтенды и это позволяет нам к примеру безопасно поэкспериментировать с TypeScript на одном из приложений внутри GitLab

#36 Дискуссии о TypeScript уже пару лет и его принятию мешает детская травма - у GitLab был coffeescript, который умер и теперь брать что-то отличное от JavaScript обоснованно страшно

#37 Внедрять или не внедрять TypeScript - холиварная тема и консенсуса по ней не будет никогда. Это скорее бизнес-решение.

Если подходить к применению TypeScript прагматично и не ждать чуда - мне кажется он будет полезен

#38 Я очень жду, что случится одно из двух: или компилятор шаблонов Vue3 бекпортируют на Vue2 или мы переедем на Vue3. Наличие сорсмапов для шаблонов позволит наконец здраво оценить качество покрытия компонентов нашими тестами

#39 Вообще экосистема тестирования во Vue безнадежно отстаёт от одной в React и это очень чувствуется на таком большом проекте как GitLab. Сейчас бы я не рекомендовал бы ни одному крупному проекту брать Vue именно поэтому

#40 Я очень много говорю про тестирование, потому что мне это болит. Я безумно рад, что @wallabyjs + jest работает на кодовой базе GitLab - мне это мега облегчает написание тестов и войну за coverage

Война войной, а обед по расписанию. Lotus почти переобули, сейчас обед, упражнения на гибкость (ставить жёсткую крышу) и снова вернусь к Вам. Вы замечательная публика, спасибо за лайки :)

#41 Поговорим о DX фронтендера в GitLab.

Развернуть локальный GitLab легко - есть публичный gitlab-development-kit, который после установки зависимостей сам устанавливает все необходимое - сам GitLab, gitaly и прочие ужасы. Он же запускает и останавливает сервисы

#42 Каноничная форма разворачивания gitlab'а для разработки - на железе, без всяких docker'ов. Это связано с тем, что GitLab про дисковый I/O, основная платформа разработки - OS X, а там производительность дисковой подсистемы в docker / vagrant так себе

#43 Изоляция локального gitlabа от окружения банальна до невозможности - NVM, RVM и go, который сам по себе не мусорит в систему. Но нюансы с бинарными зависимостями иногда всплывают - так у меня недавно на ArchLinux не собирался какой-то гем из-за gawk 5.0

#44 Локальный GitLab работает... ох как небыстро. Причем съедает и процессор и память. Наверное поэтому GitLab покупает инженерам верхнюю конфигурацию MacBook pro (ок, ок, со вчера уже не верхнюю) с core i9

#45 Тяжёлое наследие rails все ещё взирает на нас из бездн кодовой базы. К примеру, наш scss до сих пор собирается sprockets, что лишает нас ряда привычных простому пользователю webpack'а трюков

#46 У нас есть свой плагин для eslint. Пока что он, в основном, следит за интернационализацией, но его наличие приятно греет мне душу - есть пространство для улучшения и расширения

#47 На продакшне мы собираем ряд логов о производительности наших страниц (в том числе и рендеринге), естественно логируем ошибки, но, к сожалению, мне пока не довелось с этим столкнуться

#48 Кстати, о QA - реализовал фичу — будь любезен сам протестировать ее на staging. "Этот парашют я укладывал сам" - ручных QA у нас нет, а automated занимаются "глобальными вопросами", а не тестами конкретных фич

#49 Никакого storybook или аналога в основном проекте gitlab'а нет. Я предлагал это, но идея не нашла поддержки. Это приводит к тому, что изменения во vue-компонентах достаточно сложно и мучительно тестировать, особенно если реальный сценарий требует специфического окружения

#50 Одна из болей современного GitLab - это a11y и местами ux в принципе. Каждый раз когда я не могу отправить форму по enter - я искренне огорчаюсь. Мы об этом знаем и это одно из основных направлений работы в 2020

Полсотни твитов спустя вставим дисклеймер: все в этом треде мое субъективное мнение. В треде уже отметились мои коллеги @Vitalliumm и @mishunov и у них может быть свое мнение - GitLab не монолитен, вещи их ощущение вполне могут отличаться от команды к команде

#51 Гитлаб объединил большое количество крутых frontend-разработчиков. Мы не нанимаем на данный момент джуниоров (они же дети, им нельзя показывать такую кодовую базу), но сеньйоры у нас мега крутые как на подбор

#52 С этим связан вопрос, который был для меня самым сложным на собеседовании: "у нас крутые специалисты по Vue, по webpack и т.д. — какую ценность вы принесёте в команду GitLab?"

#53 Мой ответ на вопрос из предыдущего твита был "я работал с GitLab, когда ещё даже не было omnibus-пакета, я понимаю как функционирует GitLab с низу до верху и это поможет мне быть эффективным в моей роли и помочь коллегам, которые не имеют devops-опыта"

#54 Однако то, что у нас есть много крутых сеньйоров и ни одного staff engineer (это развитие сеньйора в сторону технической экспертизы, альтернативный путь - engineering manager) создаёт дополнительные трудности

#55 Любой сеньйор - это автономная единица сама в себе, тем более в GitLab. Для того чтобы вести эти автономные единицы строем в едином направлении нужно что-то что задаёт вектор развития - документация или люди

#56 Как я говорил, фронтенд у нас достаточно молодой и много вещей не покрыто в документации. Иметь staff engineerлв как средство медиации было бы очень круто

#57 about.gitlab.com/job-families/e…

Когда я смотрю на требования к роли (staff - это скорее роль, а не позиция), на меня накатывает лёгкая депрессия — столь далёк я и, к сожалению, по моему ощущению, у нас нет ни одного фронтенд инженера, который подходил бы под эти критерии

#58 Для frontend-инженеров в GitLab сейчас уникальное окно возможностей — возглавить, задокументировать, взять на себя смелость принимать сложные решения, бороться за них и решать трудности. Как по мне, звучит как достойная строчка в послужном списке. Может это будете именно Вы?

#59 Писать понятную документацию — архисложно. У меня в черновике спрятан большой раздел документации который нужен ГитЛабу, но он пока не дошел даже до стадии "не стыдно кому-то показать" для последующей итерации

#60 handbook GitLab - по-моему более 2000 страниц. На таких масштабах становится очень сложно отслеживать важные для тебя и твоей роли изменения. Хоть назначай дежурного по хендбуку, который будет дайджест формировать

Я стараюсь в своих твитах всё-таки делать акцент на особенности жизни фронтенд-разработчика. Безлимитные отпуска, all-remote и прочие плюшки в гитлаб - все это правда, просто в этом мало фронтенд специфики

#61 Я пользуюсь GitLabом и как пользователь на общих основаниях. Причем честно плачу полную стоимость - нам положен бесплатный GitLab Gold, но только на персональный аккаунт, а мне нужны фичи на группу. Поговорим немного о вещах, которые бесят

#62 Больше всего бесит регулярно ломающийся и меняющийся в мелочах UI от релиза к релизу. Лекарство от этого давно известно - скриншоты страниц и сравнение их от версии к версии - но это не сработает пока у нас не будет внедренной дизайн-системы

#63 Фактически у нас есть два (в реальности больше) CSS влияющих друг на друга - старый "глобальный" CSS гитлаба и новый, основанный на utility классах, применяющийся в том числе в gitlab-ui

#64 gitlab-ui задуман быть обособленной библиотекой, но поскольку в реальности он используется в GitLab, у нас есть галочка "включать GitLab css" в сторибук, чтобы оценить не поломает ли чего в компонентах старый CSS

#65 Недавно мои изменения в компоненте поиска сломались в основном проекте, причем галочка в сторибук их не поймала (мы применяем тестирование скриншотами в gitlab-ui). Выяснилось - из-за разного порядка подключения CSS в сторибук и в основном проекте

#66 Ещё одна вещь, которая заставляет меня огорчаться - функциональность, которая есть в web, но которой нет в API. Пример - управление group deploy tokens

Внедрение GraphQL в GitLab имеет в том числе цель создать общий API и для frontendа и для простых клиентов

#67 В предыдущем твите я перепутал group deploy tokens с group environment variables 😅. Group deploy tokens у нас (пока) нет.

Вообще, на каждую мою хотелку уже есть ишью в GitLab. Некоторые из них пора отдавать в детский садик уже

#68 Иногда конечно бывают проблемы, которые, если искать везде заговор выглядят как способ забрать ещё денег. К примеру когда только-только ввели покупку минут CI-runnerа, то вначале расходовались купленные минуты и только потом бесплатные. Это поправили, но было забавно

#69 Gitlab.com если мне не изменяет память составляет около 5% в структуре доходов GitLab, поэтому не стоит искать в предыдущем твите заговора. И да, 40% времени наши раннеры занимаются сборкой самого GitLab

#70 Самое для меня важное в GitLab - это опенсорс. Для одной из своих задач как клиента, которая расходится с линией партии, я просто пропатчил GitLab runner и подключил пропатченный раннер из своего облака к своей группе на GitLab.com. И это мега круто :)

Не ожидал такого отклика 💥😅. Пока что мои ответы напоминают работу с ишью в гитлабе - было 4 ишью, 2 исправили, 7 осталось :) Ещё 10 и возьму перерыв, работать же тоже надо :)

#71 Немного фактов россыпью.
В GitLab нету прекоммит хуков, lint-staged и вот этого всего. Причина - очень много гитлаберов любят делать коммиты нарушая правила, чтобы зафиксировать свой прогресс и причесывать MR в самом конце. Squash on merge спаасает нашу историю в таком случае

#72 Я знаю много гитлаберов, которые сделав кусочек работы его сразу коммитят и пушат. Мне страшно представить огромное количество пайплайнов, которые запускаются впустую из-за этого

Hint: если сделать git push -o ci.skip то для этого пуша пайплайны стартовать не будут

#73 Handbook инструктирует нас всегда хвалить за что-то в merge request при code review. Это очень важный пункт, потому что сфокусировавшись на недостатках, очень легко демотивировать человека, несмотря на очевидную пользу его вклада

#74 Несмотря на требование хвалить из предыдущего твита, мне, как воспитаннику советской школы образования иногда сложно найти, за что похвалить искренне.

Так что GitLab развивает ещё и soft skills

#75 Из-за специфики нашего CSS и отважносьи в его написании в прошлые годы обновление сторонних зависимостей превращается в увлекательную игру " найди 10 отличий и где сломалось"

#76 Ревьюверы бывают разные. Некоторые односложно говорят "здесь надо сделать так, здесь вот так", некоторые пишут пространные рассуждения и прикладывают готовый git diff на сотни строк. Истина, по моему мнению, где-то посередине - учиться по готовому git diffу менее полезно

#77 Комьюнити контрибьюшны - предмет особого внимания в GitLab. Мы ценим каждого, кто помогает нам становиться лучше. Мы всегда поможем и расскажем

#78 В гитлабе принцип "unblock others first" – то есть ревью чужих MR есть высший приоритет. Поэтому я, к примеру, слегка саботирую свой путь в мейнтейнеры — где и как находить время для «великих» дел при и объеме нагрузки - я не представляю

#79 По моим ощущениям GitLab development kit в разы стабильнее работает на Linux, чем на Mac. Особенно, когда приходится прыгать из ветки в ветку. Windows как платформа для разработки gitlabерам запрещен, хотя gdk терпимо работает и на ней

#80 давным-давно я поставил лайк под предложением "давайте не будем использовать миксины во Вью", а потом столкнулся с задачей, которая иначе чем миксином красиво не решается. Лайк стыдливо убрал :)

Так, машина приведена в порядок, пора и поработать. Вернусь через пару часов, доведу до сотни :)

#81 Немного о ремоуте. Немногие осознают что "all-remote" – не является базовой ценностью GitLab, а лишь способом достижения 6 базовых ценностей
about.gitlab.com/handbook/value…

#82 Я изначально не верил в all-remote, но поскольку меня приучили попробовать, прежде чем критиковать - вот, пробую. Все ещё испытываю смешанные чувства

#83 С одной стороны именно благодаря all-remote можно собрать команду таких крутых специалистов. К примеру, если с @N_Tepluhina или @Vitalliumm у меня были теоретические шансы где-то вместе поработать, то @mishunov из далёкой Норвегии и это конечно же не предел

#84 С другой стороны, all-remote разрушает "кухонную" передачу фоновых знаний от разработчика к разработчику. Можно сказать, что любой бизнес стремится избежать незадокументированных знаний - но они все равно всегда есть

#85 В Слаке Гитлаба с недавних пор сообщения хранятся 90 дней — чтобы Слак не превращался в ещё одну базу знаний для людей и чтобы стимулировать людей обновлять документацию и хендбук

#86 Я уважаю гитлаб за максимальную асинхронность в коммуникациях - а не так что, да мы all-remote, но давайте собираться все в одной часовой зоне для совещаний

#87 Чего мне не хватает в таком прозрачном проекте как GitLab - кладбища решений - списка подходов и т.п. от чего решили отказаться и почему. Эта информация размазана по issues, хотя для меня это представляет конкретный такой интерес

#88 Не в тему all-remote, но потом забуду. Тестирование скриншотами неизбежно натыкается на различия рендеринга шрифтов, а понижать точность сравнения - казалось бы всего 1% разницы скриншотов, а по факту этот 1% это важный исчезнувший бррдер

#89 В контексте предыдущего твита - правило 34 для нейросетей - готов поспорить где-то есть сетка или стартап с machine learning отвечающий по скриншотам что именно изменилось и значимо ли это

#90 Я все ещё считаю, что в офисе я был бы сильно продуктивнее. Но работал бы над GitLab меньше - слишком часто я в разъездах где попало

#91 Моя команда должна за следующий год разрастись с 6 до 30 фронтендеров. Меня это искренне пугает

#92 Каждый человек, который приходит в команду несёт в себе культурный код предыдущей компании и как он будет "переварен" Гитлабом меня беспокоит

#93 Больше всего меня огорчает, когда от нас уходят люди, проработавшие в GitLab долго. Конечно, банальная математика говорит, что вероятность их ухода больше – но именно они носители первичного культурного кода GitLab

#94 В контексте предыдущего твита хочу выразить респект @dzaporozhets — будучи создателем GitLab и техническим человеком, он понимает ценность getting things done и того самого культурного кода. По моему опыту, это редкость в мире программирования

#95 Недавно у нас был традиционный ежегодный опрос удовлетворенности сотрудников, жаль, что он настолько анонимный, что нельзя к примеру разделить бэкендеров и фронтендеров. У меня ощущения что индексы удовлетворенности различались бы на статистически значимую величину

#96 Если вам кажется, что в GitLab все плохо с фронтендом - то все относительно. Я искренне верю, что мы живём в эпоху перемен и мне нравится быть их частью

#97 Я нахожу особую иронию вселенной в том, что мне приходится работать с Vue, который я регулярно критиковал

#98 Вообще я нахожу удивительную схожесть Вью и Rails - и там и там много магии, которую надо осознавать :)

#99 Самые сложные и интересные таски для меня - это миграция. С karma на jest и с vuex на Apollo client к примеру

#100 🎉🎉🎉 Сотый контентный твит в треде. Во второй сотне начнем разговаривать о крутых вещах в нашей кодовой базе. Начну рассказ с web ide, поскольку это вотчина @mishunov — готовьтесь, он будет меня поправлять и наставлять

Перекур, пока накопятся потенциальные твиты в моей голове :)

#101 В GitLab есть фича, которая на первый момент кажется "бесполезной финтифлюшкой" - Web IDE. И нет, это не возможность открыть один файлик и поправить его, а инструмент, позволяющий редактировать несколько файлов, с подсветкой кода и так далее. О ней и поговорим

#102 Web IDE - самый большой и сложный Vue application в нашей системе. Он же один из самых старых. В основе у него Vue, Vuex и много много бизнес магии

#103 Основной нюанс реализации WebIDE - что файлы в git имеют три версии - из репозитория, staged version и working copy. При этом "видеть" мы можем всего две. Уже одно это делает логику работы неочевидной простому смертному

#104 Возможность быстро переключаться между ветками и при этом осознавать что у нас как-то открыты табы с файлами и с этими табами надо что-то делать - ещё одна боль, когда фронт из простой штуки для отображения данных с сервера превращается в хардкорное хранилище бизнес-логики

#105 А ещё в Web IDE есть кольцевая зависимость, потому что стора использует роутер, а роутер стору. По хорошему использовать роутер внутри сторы - плохая идея, но имеем что имеем

#106 по коду Web IDE как по годовым кольцам можно следить за эволюцией философии написания Vue-приложений в GitLab. На первый взгляд итоговый франкенштейн ужасен, и я восхищаюсь @mishunov который продуктивно с ним работает

#107 WebIDE - хороший пример изолированного домена, с очень специфическими знаниями. Постороннему ревьюверу очень тяжело ревьювить такое, потому что вопросы "WTF" будут возникать регулярно

#108 Возвращаясь к вопросу о бесполезности у WebIDE - помним о ценности итерации. Возможно WebIDE не самый полезный артефакт, хотя он выручал несколько раз, но в планах добавить туда поддержку лайвкодинга что сразу повысит ценность

#109 Отвечая на незаданный вопрос про "ведь есть продукт Х" - GitLab стремится быть полноценным self-hosted solution "замкнутого цикла", в том числе заимствуя фичи у конкурентов. Продукт Х вы не всегда сможете поставить в личное изолированное облако

#110 WebIDE - проект, который у меня чешутся руки "переписать с нуля" при условии бесконечного доступного времени. А вот как его итеративно отрефакторить я не знаю, что говорит о том, что мое дао рефакторинга далеко не достигло пика

#111 Давайте поговорим об открытости как об одной из ценностей GitLab.

Открытость - одна из основных причин, по которой я выбрал именно GitLab в качестве места работы

#112 Открытость означает, что у legal-отдела GitLab нету возражений касательно того, что я стримлю свою работу публично — оказывается, многим интересно смотреть на мучения инженера в реальном времени

#113 Открытость означает, что я могу использовать свои знания и код из GitLab для своих обучающих материалов на Patreon

(Здесь должна была быть ссылка на патреон JavaScript.ninja, но у меня нет цели продать вам подписку)

#114 Открытость также означает что из своей деятельности в GitLab я даже могу устроить шоу —

#115 Но иногда, как мы помним последние жёлтые заголовки про GitLab, эта открытость выходит боком.

Обсуждения, которые большинство привыкли проводить за закрытыми дверями, становятся достоянием общественности, и если что-то может быть понято не так - оно будет понято не так

#116 От себя замечу, что я крайне огорчаюсь, когда программисты не читают дальше жёлтого заголовка.

Я отказался от участия в одной из конференций, потому что член программного комитета позволил себе достаточно радикальные, обличающие и несоответствующие фактам высказывания

#117 Мое любимое проявление открытости в GitLab — страница "список недостатков нашего СЕО"
about.gitlab.com/handbook/ceo/#…

И это не шоу - GitLab действительно руководствуется принципами открытости во многих аспектах

#118 Открытость это в том числе и умение признавать ошибки. Я с удовольствием прочитал 27-страничный постмортем "что мы сделали не так" после нашего эпичного фейла с телеметрией

#119 Открытостью часто пытаются спекулировать критики GitLab. Однако открытость - лишь одна из ценностей, и GitLab ей руководствуется, когда она не противоречит остальным 5 и это не скрывается. GitLab это прежде всего бизнес и я уважаю, что правила известны на берегу

#120 И последнее про открытость - я не боюсь делиться с вами всем, что есть в этом треде, потому что у нас почти нет непубличной информации

#121 GitLab это dogfooding от А до Я. Если что-то удовлетворительно может быть сделано с помощью GitLab - это будет делаться с его помощью и регулярно будут задаваться вопросы "а как мы можем это улучшить для нас"

#122 В issue GitLab есть даже метка "internal customer" - что конкретно эта боль болит у нас самих. Мы специфическая компания относительно многих наших клиентов, но чаще всего эта специфичность "в лучшую сторону" – GitLab более сложный и запутанный

#123 Любовь к dogfooding часто обуславливает переусложненные на первый взгляд решения - так design.gitlab.com билдится , валидируется и так далее существенно более сложным пайплайном, чем стоило бы - мы догфудим собственный AutoDevOps

#124 К несчастью для фронтендеры, ГитЛабу пока нечего особо предложить нам для догфудинга, хотя я не удивлюсь, если рано или поздно мы начнем что-то публиковать во внутренний package registry

#125 Оффтоп: мы используем yarn. Я, честно говоря, не интересовался мотивами перехода, но мне интересно понаблюдать будут ли дискуссии о возврате на npm в свете ситуации с yarn 2

#126 Несмотря на то, что мы боимся обновлять npm-пакеты основного проекта, у нас свежий nodejs и webpack - и почти каждый апгрейд приносит ощутимые выигрышы, чаще всего по памяти

#127 Иногда апдейты удивляют. Апдейт css-loaderа однажды сломал стили в одном из vue-приложений. Сколько бы мы не верили в semver - часто эти цифры личное убеждение автора (в мире JavaScript)

#128 Втягивание новой библиотеки в GitLab - всегда требует обсуждения, потому что кому-то это поддерживать. Особенно много опасений у людей связано с магией. Поэтому, к примеру, в своем rfc про immer я старался быть очень убедительным
gitlab.com/gitlab-org/fro…

#129 На самом деле AutoDevOps потихоньку учится быть полезным и для js-разработчиков. К примеру кроме банального сканирования списка npm пакетов на уязвимости, скоро он сможет прогнать eslint-plugin-react если у вас react на проекте. Ценность - в том что это работает из коробки

#130 Вообще вся история AutoDevOps - про вменяемые умолчания. Если вам важна скорость билда или к примеру не нравится, что AutoDevOps тянет за собой гигабайтный docker-образ для сканирования на уязвимости - всегда можно написать yaml для ci вручную

#131 Одна из вещей, чему я пока ещё плохо научился в GitLab - вовремя просить помощи. Чаще всего я могу разобраться с проблемой сам, но чтобы быть действительно эффективным - надо уметь остановиться и запросить помощь

#132 Из-за асинхронной природы коммуникации в GitLab запрос помощи может зависнуть на день-два, а мой мозг продолжает думать. Первое время это просто убивало, да и сейчас я не скажу, что целиком избавился от этой напасти

#133 У меня ещё не было падавана, которого надо было менторить, но эффективное обучение на расстоянии будет для меня новым челленджем. Вариант "ждать когда спросит" - несомненно рабочий в гитлабе, но точно не самый эффективный

#134 Гитлаб настолько большой и сложный, что у нас в Слаке есть канал #is-this-known где люди пытаются понять баг это или фича

#135 В GitLab я научился одной очень важной вещи. "Это знание не хочешь ты". Некоторые аспекты пкк что надо просто принять на веру. К примеру логику работы гема webpacker

#136 Когда бэкендеры делают ревью моего frontend-кода я понимаю, что они ощущают, когда я ревьювлю их код на js. Если у нас есть крутые фулстеки - то мне не везло и на ревью их код мне не попадал. Или они хорошо скрываются

#137 GitLab до недавнего времени поддерживал MySql в качестве базы данных. Это тяжёлое наследие до сих пор осталось в коде и на бэке и на фронте. Сейчас поддерживаем только PostgreSQL

#138 Моя любимая мелкая фича в GitLab - quick actions. docs.gitlab.com/ee/user/projec…
Я keyboard monkey, и возможность прям в тексте заапрувить MR, обновить метки и так далее- музыка для моих пальцев

#139 Удивительно, но 5 вебпак (пока ещё не релизнутый) почти не ускоряет холодный билд гитлаба с включенными кешами. Прирост есть, но менее 25%. Почему - собираюсь поковырять на досуге

#140 А ещё GitLab научил меня вовремя останавливаться в своей работе. Спасибо огромное, я не ожидал такого количества лайков, но на цифре около 200 я собираюсь остановиться, так что скорее всего вы прочитали уже две трети этого мегатреда

#141 Если вы решили устроиться в GitLab frontend-разработчиком срочно начинать учить Vue и грокатт алгоритмы не стоит

#142 За все свои собеседования в GitLab я писал код наверное минут 7. Остальное время мы разговаривали

#143 Вообще весь процесс найма детально описан в хендбуке и GitLab его реально придерживается, будьте готовы рассказывать истории про то, что вы делали, и помните о формате STAR

#144 Зарплатный калькулятор about.gitlab.com/job-families/e… сответствует действительности. Да, я получаю зарплату по нему. Да, мы платим разные суммы в зависимости от страны. Я не считаю это несправедливым

#145 К зарплате прилагается огромное количество плюшек - к примеру $500 в месяц на каждую профильную конференцию. Или возможность слетать на co-working day к коллегам и полностью компенсировать стоимость перелета. Про плюшки читать здесь about.gitlab.com/handbook/spend…

#146 Каминг-аут, все равно в треде на 146 комментариев никто не заметит. Мой менеджер считает что я underperforming. Я считаю что он прав и исправляюсь. Виноват в этом прежде всего я, как я и сказал, переход на удаленку имеет свои трудности

#147 Про прошлый твит - я могу привести кучу оправданий. Более того, в GitLab важен прежде всего глобальный импакт, а не вклад в деятельность команды, но я не смог обеспечить достаточную прозрачность своей деятельности

#148 Продолжая тему, underperforming - это моя личная оценка, мне вслух никто этого не говорил, даже менеджер (хотя стоило бы, я люблю когда вещи называют своими именами). Это не приговор, а обратная связь. Тем более что делать с этим - понятно

#149 Ещё немного про найм: HR на behavioral interview завернули одного из самых крутых спецов в моем окружении. Я с удивлением согласился с их вердиктом и был приятно удивлен профессионализму - определить это за полчаса интервью

#150 Найм на Frontend позицию в среднем длится около 45 дней. @N_Tepluhina наняли за 8 :)

Так, ещё один перекур на несколько часов перед началом финишной полсотни твитов. Я очень стараюсь быть предметным и рассказывать про фронтенд и свои ощущения в нем, а не абстрактные тезисы и лозунги

#151 В GitLab есть discretionary bonus - фиксированный бонус в $1000, у которому тебя может представить любой человек. Его в среднем получает 5-10% компании в месяц. Я не получал ни разу. Это хороший показатель видимости твоего перформанса в масштабах компании

#152 Я не считаю, что я заслужил бонус за какую-то свою активность, но на данный момент фронтенд разработчику для получения бонуса надо не просто что-то сделать, а и "продать" эту ценность в масштабах компании

#153 Кто-то скажет что по факту получение такого бонуса чистая политика, я же скажу что умение презентовать свой вклад и влияние- важный и полезный навык. Если мы (фронтендеры) не научимся это делать, то так и останемся в GitLab людьми второго сорта

#154 Когда я говорю что "фронтендеры в gitlabе люди второго сорта" - это не оскорбление, а элемент сложившейся культуры, связанный с тем, что бэк исторически доминировал при разработке. Это просто плюс одна задача для фронтенд команды - доказать и донести ценность до всех вокруг

#155 На всякий случай напоминаю, что я делюсь своими впечатлениями. Никто и никогда не скажет вам, что вы второго сорта. Никто так не считает, но исторически сложившиеся вещи все равно оказывают влияние намумы людей и они не испаряются в один клик.

#156 (ночь, традиционно время философии) GraphQL может стать важным геймчейнжером в философии GitLab. Будучи по-сути ориентированной на потребителя технологией это возможность перехватить инициативу "кто здесь главный - бэк или фронт"

#157 То что фронтенд-команда в GraphQL является не "службой верстки данных, предоставляемых бэком", а воплощением конечного потребителя API даёт мощный рычаг в бизнес-спорах

#158 Почти программное заявление: frontend в GitLab это важный и просветляющий опыт, возможность не на словах, а на деле почувствовать себя underrepresented group

#159 Наш фронтенд покрыт метриками, но я крайне редко вижу их использование в аргументации. А ведь когда есть конкретные цифры, доказывать полезность того или иного действия гораздо проще. Впрочем я и сам полез в графану только при подготовке доклада про graphql в gitlab

#160 К сожалению, насколько мне известно, механизма качественного A/B тестирования на фронтендеу нас нет, что затрудняет проверку гипотез.

Я буду рад, еслияя ошибаюсь. Если же нет - то я уверен, что мы точно придем к этому и очень скоро

Хочу извиниться за большое количество очепяток в треде - 90% набрано с телефона, а твиттер не даёт редактировать сообщения

#161 GitLab релизится каждый месяц 22 числа, как часы. Для того чтобы фича попала в релиз она должна быть замерджена в мастер до 18. Поэтому вот как раз в 15 числах начинается слегка нездоровое на мой взгляд движение по проталкиванию фич в релиз как на фронте, так и на бэке

#162 Каждый раз, когда в MR остаются нерешённые вопросы, есть два пути - решить их здесь и сейчас или "давайте создадим follow-up issue". Как показывает быстрая аналитика за 5 дней до релиза количество создаваемых follow-up issue растет почти в 2 раза

#163 К сожалению, очень часто эти follow-up issue остаются висеть достаточно долго, создавая существенную когнитивную нагрузку на любого, кто пытается потом поправить связанный код - "да, мы знаем, про это уже есть follow-up issue, вот только движения по нему нет"

#164 В случае с follow-up issue каждый сам проводит границу "этот код достаточно качественный, чтобы увидеть master" и у мейнтейнера фактически нету легальных оснований сказать "нет, стоп, давайте разрешим эту проблему здесь и сейчас"

#165 Из удивительного - лишь недавно у нас разрешили merge requestы, которые не привносят немедленного value, но не ломают мастер. С одной стороны - здравый стимул разбивать фичу на отдельные MR которые проще ревьювить, с другой стороны - способ накрутки метрики MR/месяц

#166 Раньше у нас был жёсткий feature freeze 7 числа и за пару дней до этого CI вскипала от нагрузки. Сейчас мы по-сути собираем staging-билд раз в неделю и стало существенно лучше

#167 Я себе завел отдельную on-demand билд машину под GitLab в Google cloud - за десятки долларов я получаю фидбек о билде гораздо быстрее и стабильнее чем от облака GitLab потому что там я гоняю лишь подмножество тестов

#168 У нас безлимитные отпуска в GitLab, но в "большой" отпуск я ещё не ходил, потому что на данном этапе своей жизни я как акула – нельзя останавливаться, иначе всплыву кверху брюхом. GitLab в этом не виноват, здесь заботятся о выгорании

#169 Для меня отпуск на 300% — это сразу после достижения какой-то мажорной ачивки. И я благодарен GitLab, что когда я такую достигну - мне не придется ждать пары вечностей, чтобы отдохнуть

#170 Мне безумно нравится, что во Frontend команде GitLab есть место как мне, с принципами "добейся или сдохни", так и, к примеру, @mishunov с его почти каноничным норвежским Хюгге :)

Всем доброго утра и продуктивной пятницы из серого Харькова

#171 Только я попросил у Деда Мороза TypeScript в

https://twitter.com/xanf_ua/status/1194909827325190144?s=19

, как issue которое было без движения несколько месяцев перенесли в раздел Frontend RFC. Совпадение? Не думаю

#172 Frontend RFC - крайне здравый прозрачный механизм внесения изменений в жизнедеятельность Frontend команды в GitLab - предлагаешь, продвигаешь, реализовываешь

gitlab.com/gitlab-org/fro…

#173 Как и всегда - первые шаги по реализации RFC - не очень удачные - скопилось множество RFC которые висят без движения

#174 Я вижу несколько причин, тормозящих принятие решений:

- отсутствие фиксированного таймфрейма на решение
- размытые требования, кто и в каком количестве должен одобрить то или иное решение
- отсутствие видимых различий между "воздержался" и "не видел"

#175 А вообще, прежде всего, как сказал @mishunov - надо детальнее прорабатывать предлагаемые изменения. Фактически, надо открывать MR, чтобы люди могли поиграться, оценить масштаб причинения справедливости и выработать свое мнение и под него уже открывать RFC

#176 В контексте предыдущего твита: да, это требует титанических усилий часто, но иначе эту тушу не сдвинуть

#177 В контексте предыдущих двух твитов: написал это и осознал, что когда @mishunov продвигал идею Shadow DOM (я безумно сожалею, что ее не взяли) - он именно так и поступил. Был доступен MR на поиграться для всех

#178 GitLab для меня как фронтенд-разработчика с 14 годами опыта проходит ещё по одному важному критерию - здесь есть люди, у которых мне есть чему научиться и чему я хочу учиться

#179 GitLab для фронтедеров - очень безопасное место. Я уже пару раз ломал мастер (но не продакшн) и каждый раз выносил из этого полезные уроки а не психотравмы

#180 Если вас этот огромный тред про проблемы не напугал и вы хотите присоединиться к нам во frontend-команду - аккуратно выбирайте к какой команде присоединиться - это во многом определяет будете ли вы делать shiny new things или воевать за legacy

#181 Раньше найм frontend-инженеров осуществлялся через pooling-вакансию, фактически вы проходили общий отбор, а потом попадали в команду. Ваши предпочтения, конечно же учитывались.

Сейчас у разных команд разные вакансии. Причины такого изменения мне не известны

#182 Я очень надеюсь, что скоро в GitLab у фронтедеров появится платформенная команда - занимающаяся внутренними инструментами, инфраструктурой и прочим. Я бы, наверное, хотел бы в нее попасть

#183 Почему в предыдущем твите "наверное" — потому что это тоже, отчасти, форма убегания в отдельный мирок с пони и радугой. Оставаться в прикосновении с реальными бизнес-задачами — своя форма смелости

#184 Мне кажется, что неплохим бустом для комьюнити-контрибьюшнов в Frontend-часть GitLabа была бы возможность запуска легковесного окружения для разработки, заточенного под фронтендеров. Этим я обязательно займусь под ёлочкой

#185. I have a dream. Я хочу переписать все существующие тесты с karma на jest. Переписать не бездумно, а правильно. Одному человеку с этим никогда не справиться, а ресурс под это получить не выйдет - у нас сверхмного идей и задач в бэклоге

#186 В контексте предыдущего твита у меня есть решение: записать курс по unit-тестированию Frontend и в качестве платы брать борзыми щенками - рефакторингом gitlab-тестов. Это заодно решает проблему привязки сухой теории к реальной жизни

#187 Я искренне хочу помочь GitLab достичь успеха. И не потому что у меня есть опцион — а потому что прийти в компанию где все хорошо может каждый. Прийти где есть пространство для улучшения и улучшить - вот реальный вызов для меня

#188 Небольшая история: на встрече всех гитлаберов в SF я тащу к столику покупки кучу мерча. "Продавец": куда вам столько? Я - я выступаю на конференцияз, хочу раздавать. - Ок, разбейте на две кучки - мерч для раздачи и ваш и за первую можете не платить

#189 Продолжая предыдущий твит: и есть много компаний, которые конечно же раздают свой мерч и выделяют его спикерам. Но не все компании могут сделать это за 5 секунд и с нулем бюрократии

#190 Из забавного - все сеньйоры и выше могут неделю поработать вместе с Димой Запорожцем (создателем GitLab) вместе и под его руководством. Конечно же расходы на перелеты и проживание покрывает компания. Всегда очень интересно видеть приоретизацию всяких штук из уст создателя

#191 Одна из вещей, которая мне нравится в GitLab как разработчику - то что gitlab.com не отдельный проект - а просто ещё одна инсталяция нашего GitLab Enterprise edition. У GitHub облако и on-premise - два совершенно разных продукта

#192 В GitLab нет developer advocate и евангелистов. Каждый разработчик хвалит GitLab самостоятельно :)

#193 Если вы хотите выступать на конференциях, но не знаете о чем - GitLab станет для вас неиссякаемым источником тем. Война с legacy у людей болит - мой доклад про это на FrontendConf в Москве внезапно взял top-1 по отзывам

#194 (задумался) А кто ещё из единорогов (оценка свыше $1kk) использует Vue? Вряд ли мы первые и единственные, но мы точно значимый участник этой тусовки

#195 Сейчас на фронтенде мы идём в сторону использования utility-классов и их композиции. Это вызывает у меня смешанные чувства. Уж лучше был бы БЭМ :)

#196 Как минимум у некоторых членов команды есть желание избавиться в конце-концов в большинстве мест от Vuex и перейти на Apollo local state. Он, к сожалению, пока многословен и неудобен, но Оккам уже размахивает своей бритвой

#197 Только что осознал, что выбор команды во frontend напоминает выбор факультета в Хогвартсе - вас ждут очень разные приоритеты, разные стили менеджмента и разная философия.

#198 Только что замерил - bin/rake lint:all на моей железке выполняется больше 2 минут. Надо будет хотя бы для себя сделать аналог lint-staged :)

#199 Frontend в GitLab - для меня мой способ менять мир для многих разработчиков. Впервые в жизни мне не надо изучать бизнес-домен ведь я делаю продукт для разработчиков. И это по-своему круто

#200 🎉🎉🎉 Я хочу сказать спасибо @N_Tepluhina без которой я бы не задумался про #gitlab, @mishunov который сам того не осознавая спровоцировал этот тред, @Vitalliumm за ценные комментарии и поправки и @dzaporozhets за его открытость и прозрачность при встречах

Меня можно найти на YouTube youtube.com/javascriptninja, на Patreon patreon.com/javascriptninja и в Телеграме с тем же ником что и в Тви @xanf_ua.

Спасибо, что читали этот поток сознания длиною в сутки, это было очень важно прежде всего для меня.
Присоединяйтесь
about.gitlab.com/jobs/apply/

Спасибо всем, кто продолжает лайкать и ретвитить. Мой марафон длиною в 200 твитов завершён, но я с удовольствием продолжу отвечать на вопросы по ним - не стесняйтесь комментировать, спрашивать и уточнять