У нас в фирме создано впечатление, что нам (разработчикам) следует всё же изучать эти инструменты, потому что они теперь являются базовыми, как, например, умение работать с git или с командной строкой (что тоже как бы не фронтенд, но всем необходимо).
Как вы считаете, куда сейчас «дует ветер»: это правильное впечатление, и нам всё же следует всё это осваивать, или нормально было бы в нашем случае возмущаться и требовать, чтоб девопсы приходили и сами пилили свои дженкинсфайлы в наших проектах?
Пишу из большой компании, где есть целый отдел девопсов, готовых помочь. Я не сомневаюсь в их профессионализме, и не оспариваю всю идеологию, пусть она вся состоит сплошь из преимуществ. Но я совершенно точно ощущаю на себе возросшую необходимость изучать не очень релевантные технологии. Например, мне приходится самому конфигурить дженкинс, кубернетис, ингресс и прочие чудеса, каждое из которых предполагает изучение новых сред и языков со своими особенностями и прибамбахами. Дженкинсфайл вроде бы пишется на груви, но недостаточно прочитать мануал по груви, потому что это не совсем груви, а ещё он работает не по всему дженкинсфайлу, а при каких-то определённых условиях. Коллега из SRE присылает мне пулреквест в докерфайл, чтоб тесты и линтер запускались внутри поднятого контейнера, а не в пайплайне, потому что это обладает преимуществами. Все эти процессы выглядят очень разумно, мне здесь нечем возразить. С точки здрения SRE-инженера, у нас, как у фронтендщиков теперь есть больше возможностей. Мы теперь можем сами сконфигурить себе пайплайн, под нужды конкретного проекта. У нас есть контроль над всеми происходящими процессами. Но я уже забыл, а что я делал-то вообще. У меня вроде стояла задача сделать какой-то UI, мне бы хотелось заниматься компонентами, рендерингом, состоянием, UX, визуальной красотой в конце концов, но почему-то я давно застрял в пайплайнах. Мне точно нужно всё это знать? Решают ли эти методики проблем больше, чем создают?
Я бы объявил идеальным девопс-специалистом не такого своего коллегу, который хорош в коммуникации и взаимоотношениях, а такого, который смог бы организовать процесс не требующий столько моего внимания. В идеале я вообще хотел бы не знать, кто у нас там девопс. Как, например, я не знаю, кто у нас в фирме настраивает wifi, потому что мне никогда не приходилось к ним обращаться.
Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.
Здравствуйте, я такой фронтендщик, есть ли какое-то решение проблемы? Или предлагается «принять философию»?
Потому что попап появляется внезапно и помимо воли пользователя. Это пренебрежение UX, несмотря на то, что это сейчас и правда распространено.
В результате пользователя выхватывают из контекста, и заставляют решать новую задачу «Блин, как эту херню закрыть» (хинт: самый простой и надёжный способ — закрыть всю вкладку целиком)
Спасибо! Я и не ожидал, что все прям воодушевятся и поддержат идею. Наоборот так даже интересней, и кроме того благодаря критике там уже много чего было улучшено.
Про тормоза — как я уже говорил, тормозит на самом деле меню, а не индикатор. Меню нужно было для того, чтобы продемонстрировать, как это должно совместно заменить скролбар (иначе жаловались «как теперь перемещаться без колёсика»).
На самом деле, я не собирался изначально убирать скроллбар, но возникало очень много сложностей, потому что он непредсказуемого размера, не очень ясно, как размещать индикатор совместно со скроллбаром, и вообще тогда непонятно зачем индикатор, если всё и так видно на скроллбаре. Зато код сильно упростился, когда скроллбара не стало.
В качестве замены скроллбару я предлагаю не сам индикатор, а индикатор совместно с навигацией. Но мне, похоже, ещё нужно поучиться, как эту мысль яснее сформулировать.
ну мне они кажется неудобными тем, что всплывающая штуковина появляется сама по себе, непредсказуемо и кажется что она сейчас вообще отвалится. я её боюсь и стараюсь не подводить курсор к краю :-(
Меню, которое на сайте — это как раз пример такой навигации. Конкретно в нём можно ткнуть в любое место и приехать туда. Вделяется тот блок, где мы сейчас.
Я сейчас не могу вспомнить точно, но почему-то такой способ не всегда работал (то ли для горизонтального скроллбара, то ли для каких-то броузеров). У меня решение основано частично на идеях как раз из статьи по вашей ссылке. Внутренний элемент раздвигает внешний (со скроллбаром). Но у внутреннего элемента ширина задаётся в пикселях, поэтому ещё нужно уметь отлавливать ресайз элемента, что отдельный гемор.
Как вы считаете, куда сейчас «дует ветер»: это правильное впечатление, и нам всё же следует всё это осваивать, или нормально было бы в нашем случае возмущаться и требовать, чтоб девопсы приходили и сами пилили свои дженкинсфайлы в наших проектах?
Я бы объявил идеальным девопс-специалистом не такого своего коллегу, который хорош в коммуникации и взаимоотношениях, а такого, который смог бы организовать процесс не требующий столько моего внимания. В идеале я вообще хотел бы не знать, кто у нас там девопс. Как, например, я не знаю, кто у нас в фирме настраивает wifi, потому что мне никогда не приходилось к ним обращаться.
Здравствуйте, я такой фронтендщик, есть ли какое-то решение проблемы? Или предлагается «принять философию»?
В результате пользователя выхватывают из контекста, и заставляют решать новую задачу «Блин, как эту херню закрыть» (хинт: самый простой и надёжный способ — закрыть всю вкладку целиком)
нет
Про тормоза — как я уже говорил, тормозит на самом деле меню, а не индикатор. Меню нужно было для того, чтобы продемонстрировать, как это должно совместно заменить скролбар (иначе жаловались «как теперь перемещаться без колёсика»).
На самом деле, я не собирался изначально убирать скроллбар, но возникало очень много сложностей, потому что он непредсказуемого размера, не очень ясно, как размещать индикатор совместно со скроллбаром, и вообще тогда непонятно зачем индикатор, если всё и так видно на скроллбаре. Зато код сильно упростился, когда скроллбара не стало.
В качестве замены скроллбару я предлагаю не сам индикатор, а индикатор совместно с навигацией. Но мне, похоже, ещё нужно поучиться, как эту мысль яснее сформулировать.
github.com/asvd/intence/blob/master/intence.js#L1800