Pull to refresh
46.2
Karma
0
Rating

Кто такой DevOps и когда он не нужен

У нас в фирме создано впечатление, что нам (разработчикам) следует всё же изучать эти инструменты, потому что они теперь являются базовыми, как, например, умение работать с git или с командной строкой (что тоже как бы не фронтенд, но всем необходимо).

Как вы считаете, куда сейчас «дует ветер»: это правильное впечатление, и нам всё же следует всё это осваивать, или нормально было бы в нашем случае возмущаться и требовать, чтоб девопсы приходили и сами пилили свои дженкинсфайлы в наших проектах?

Кто такой DevOps и когда он не нужен

Пишу из большой компании, где есть целый отдел девопсов, готовых помочь. Я не сомневаюсь в их профессионализме, и не оспариваю всю идеологию, пусть она вся состоит сплошь из преимуществ. Но я совершенно точно ощущаю на себе возросшую необходимость изучать не очень релевантные технологии. Например, мне приходится самому конфигурить дженкинс, кубернетис, ингресс и прочие чудеса, каждое из которых предполагает изучение новых сред и языков со своими особенностями и прибамбахами. Дженкинсфайл вроде бы пишется на груви, но недостаточно прочитать мануал по груви, потому что это не совсем груви, а ещё он работает не по всему дженкинсфайлу, а при каких-то определённых условиях. Коллега из SRE присылает мне пулреквест в докерфайл, чтоб тесты и линтер запускались внутри поднятого контейнера, а не в пайплайне, потому что это обладает преимуществами. Все эти процессы выглядят очень разумно, мне здесь нечем возразить. С точки здрения SRE-инженера, у нас, как у фронтендщиков теперь есть больше возможностей. Мы теперь можем сами сконфигурить себе пайплайн, под нужды конкретного проекта. У нас есть контроль над всеми происходящими процессами. Но я уже забыл, а что я делал-то вообще. У меня вроде стояла задача сделать какой-то UI, мне бы хотелось заниматься компонентами, рендерингом, состоянием, UX, визуальной красотой в конце концов, но почему-то я давно застрял в пайплайнах. Мне точно нужно всё это знать? Решают ли эти методики проблем больше, чем создают?

Я бы объявил идеальным девопс-специалистом не такого своего коллегу, который хорош в коммуникации и взаимоотношениях, а такого, который смог бы организовать процесс не требующий столько моего внимания. В идеале я вообще хотел бы не знать, кто у нас там девопс. Как, например, я не знаю, кто у нас в фирме настраивает wifi, потому что мне никогда не приходилось к ним обращаться.

Кто такой DevOps и когда он не нужен

Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.


Здравствуйте, я такой фронтендщик, есть ли какое-то решение проблемы? Или предлагается «принять философию»?

CleverScrollbar.js — Сайдбар для понятной навигации

Как-то для решения подобных проблем я написал свою библиотеку viewport.js

Как создавать визуально эффективные призывы к действию

Потому что попап появляется внезапно и помимо воли пользователя. Это пренебрежение UX, несмотря на то, что это сейчас и правда распространено.

В результате пользователя выхватывают из контекста, и заставляют решать новую задачу «Блин, как эту херню закрыть» (хинт: самый простой и надёжный способ — закрыть всю вкладку целиком)

Как создавать визуально эффективные призывы к действию

Его можно разместить в поп-ап окне ...

нет

Вышла первая стабильная версия MenuetOS 64

А для ассемблера разве есть большая разница между закрытым и открытым кодом? Или речь о лицензии?

Интенс, индикатор прокрутки (или жизнь после скроллбара)

Спасибо! Я и не ожидал, что все прям воодушевятся и поддержат идею. Наоборот так даже интересней, и кроме того благодаря критике там уже много чего было улучшено.

Про тормоза — как я уже говорил, тормозит на самом деле меню, а не индикатор. Меню нужно было для того, чтобы продемонстрировать, как это должно совместно заменить скролбар (иначе жаловались «как теперь перемещаться без колёсика»).

На самом деле, я не собирался изначально убирать скроллбар, но возникало очень много сложностей, потому что он непредсказуемого размера, не очень ясно, как размещать индикатор совместно со скроллбаром, и вообще тогда непонятно зачем индикатор, если всё и так видно на скроллбаре. Зато код сильно упростился, когда скроллбара не стало.

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

Интенс, индикатор прокрутки (или жизнь после скроллбара)

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

Интенс, индикатор прокрутки (или жизнь после скроллбара)

кстати адово неудобная вещь, из-за неё я испытываю страдание, когда нужно приложение на GTK использовать

Интенс, индикатор прокрутки (или жизнь после скроллбара)

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

Интенс, индикатор прокрутки (или жизнь после скроллбара)

а что спрашивать? «норм идея, или лучше скролбар оставить»? понятно же что выберут :-)

Интенс, индикатор прокрутки (или жизнь после скроллбара)

не тестил на маке под фаерфоксом, но вроде не сообщали о таком баге

Интенс, индикатор прокрутки (или жизнь после скроллбара)

Меню, которое на сайте — это как раз пример такой навигации. Конкретно в нём можно ткнуть в любое место и приехать туда. Вделяется тот блок, где мы сейчас.

Интенс, индикатор прокрутки (или жизнь после скроллбара)

это предполагается делать с помощью какого-то другого виджета для навигации

Интенс, индикатор прокрутки (или жизнь после скроллбара)

Я сейчас не могу вспомнить точно, но почему-то такой способ не всегда работал (то ли для горизонтального скроллбара, то ли для каких-то броузеров). У меня решение основано частично на идеях как раз из статьи по вашей ссылке. Внутренний элемент раздвигает внешний (со скроллбаром). Но у внутреннего элемента ширина задаётся в пикселях, поэтому ещё нужно уметь отлавливать ресайз элемента, что отдельный гемор.

Интенс, индикатор прокрутки (или жизнь после скроллбара)

вот в этом комменте примерно объяснено как прячется скроллбар и создаётся индикатор:

github.com/asvd/intence/blob/master/intence.js#L1800

Information

Rating
6,108-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity