Ну, все-таки, чтобы собиралось нужно стараться. А вот не все тесты прошли и не все функционально готово — да, иногда этим придется пожертвовать. Альтернатива — PR с багами, который особо не смотрели.
Не все имеет смысл делить (особенно обновление из upstream), вопрос же не в 100%/0%, а общем правиле (95/5).
Исключения всегда есть, но это исключения (5%/95%).
Плюс, если я правильно понял пример, то мы вводим другой вид дерева параллельно за фиче-флагом. И постепенно разрабатываем отдельными PR пока не будет достаточно для релиза. А уж при релизе можем старое удалить сразу (хотя странно), а можем вводить новый функционал через настройку.
PR не означает, что новая функциональность доступна. Можно, например, включать через feature flags.
PR не означает, что сразу пойдет в релиз. Например, есть один большой PR — разбили на небольшие, они прошли все процессы в рамках одного релиза.
А про мелкие инкременты — это как раз реальность. Как в софте, так и в реальном мире. Например, сначала провели маркетинговый анализ, потом нашли поставщиков, заключили договора, добавили товар в кассу, изменили инструкции работы персонала, заказали новые маркетинговые материалы, закупили морозильные лари для мороженного — много-много разных этапов как в оффлайн, так и в софте. Понятно, что ценность начинается с момента начала продаж мороженного, но как до, так и после начала есть множество этапов, которые имеет смысл постепенно поставлять.
Хорошая аналогия малых PR в магазине: выложить новые рекламные таблички, переставить товар и т.п.: их много, они нужны практически каждый день, они немного улучшают продажи. Это не отменяет и большие, но они обычно так же вполне реально постепенно добавляются, хоть и не (особо) заметно для пользователя, пока выключены.
Если посмотреть на техническую часть, то удивил мониторинг процессов через Telegram: с ним борятся, время от времени сбоит, а тут коммерческая компания завязывается на запрещенный сервис. Уж легче бесплатный тариф Slack — вероятность, что будет работать все равно выше.
Непонятно чем ваш подход надежнее: тут запускается скрипт, человек на него смотрит и, в случае ошибки, немедленно что-то сделает. CI/CD — это тот же скрипт только по коммиту — вряд ли запуск отсматривается человеком, а, значит, информация о проблемах (а куда без них время от времени) будет получена позже.
> Интересно что это значит. Что сейчас все крутится на больших серверах, используется 1% мощности и за все платится с оверхедом?
Да, в статье есть скриншот — там до 10% загрузка CPU.
Единственно, если ничего интересного от AWS не используется (ни LB, ни автоскейлинг, ни preemtive vms) я бы переехал на DigitalOcean — должно получиться в 2 раза дешевле.
> На продакшне. ОК.
В old school это называется install server или jump host, совершенно обычная практика.
Так это wework — они на инвестициях (вроде бы не прибыльны еще).
У нас актуальнее просто снимать комнату в офисном центре (или даже квартиру, особенно если несколько человек). Немного больше проблем (уборка, интернет, обустройство кухонного уголка, мебель), но дешевле и во многом удобнее.
Интересно, но с учётом ввода онлайн касс появляется желание весь приход брать из этой кассы, а не вводить отдельно вручную. Смотрели на этот счёт? Наверняка есть варианты выгружать в Гуглдокс для каких-то вариантов касс.
Добавлю минусов:
1. Нет возможности поставить чистый K8s без Ansible, Jenkins и прочего.
2. Сама по себе странная идея, что в production будем разворачиваться из исходников.
3. Довольно низкокачественный Ansible Playbook: если что-то пошло не так, то не исправляется (да и удаление не всегда отрабатывает). Чаще нужно переставлять операционную систему.
4. Встроенный стек мониторинга — спорный вопрос. Мы еще деплоимся в публичные облака через managed K8s и там такого блока нет. Соответственно, в облаке и OpenShift ставим свой стек. В OpenShift получается 2 установки похожих сервисов — неоптимально.
Вы правда думаете, что некое ООО или сервис «Яндекс.Картинки» владеет авторскими правами хотя бы на одно из приведенных изображений? Это как ставить (С) Интернет…
Есть утверждение (Х переходят на У), которое в статье никак не подтверждается, а сразу идёт обсуждение почему. Этим читатель вводится в заблуждение, что тенденция действительно существует и изменилась недавно (новость же как бы). Нужны статистические данные, чтобы понять есть ли процесс и кто именно в нем задействован.
Облака же интересны:
— при большой стоимости людей и их низкой компетентности (не российский случай)
— незначительность затрат (2-3 сервера на всероссийскую компанию постаматов)
— сезонность (а-ля выставочная компания)
— временная ситуация (ждём поставки серверов)
— редкие разовые эксперименты/проекты
— безудержный рост, когда не до оптимизаций побочных вещей, нужно рынок захватывать (бывает, но редко)
Все-таки serverless сейчас уже далеко не только функции. Мне нравится в этом случае определение и сервисы Google.
Определение:
— нет управления инфраструктурой (включая автоматическое масштабирование)
— отсутствие оплаты за простой (оплата за реальное использование)
— безопасность на стороне поставщика
И их 3 основных сервиса:
— функции
— AppsEngine (свой фреймворк приложений для нескольких языков)
— Cloud Run (любой контейнер без состояния, который реагирует на http)
Как по мне, всё приложение на функциях писать неудобно
(поэтому и появились всякие фреймворки для функций, но все равно сложно),
AppsEngine несколько ограничен и заточен на Google (первый serverless сервис, который никак массово не взлетает, в о основном из-за зависимости кода от Google),
а Cloud Run — выглядит как раз как то, что надо.
1. Тесты сами по себе — это сразу фора американцам, т.к. у нас их столько не сдают (тайминг, внимательность, похожие вопросы раньше, привычка выкладываться на тестах по полной (т.к. от этого реально жизнь зависит), ...)
2. Computer science != программирование
3. В науке (сomputer science) же важны скорее лучшие (ИМХО), чем среднее значение
А уж про ухудшение высшего образование по ИТ — это вообще странно звучит. Сейчас ИТ компании кафедры создают, чтобы учить именно ИТ, а не физ-мат-тех. Да и отдельные выпускники возвращаются в ВУЗ преподавать программирование (по совместительству) с хорошим коммерческим опытом. Хотя, в детали не особо вникал, сам непосредственно не связан.
Вопрос актуальности для людей, которые собираются изучать язык — это количество вакансий и их динамика. Вакасии есть, но их не очень много. И динамики по увеличению не видно.
Почему архитекторы отвернулись от RubyOnRails (Ruby без RoR никогда не был особо популярен) — тут можно порассуждать, но факт остается фактом.
В целом, Rails хорош для
* сильных программистов (и соответственно, плох уже для средних)
* для генерации html/js на сервере (а это уже сейчас более-менее редкость).
Я вот реально не вижу причин начинать новый проект на Rails сейчас. Только то, что в компании все Ruby разработчики. Для любителей фулстаков есть нода, для любителей разделения Golang и, в некоторых случаях, Spring.
Понятно, что это перевод. Статью много кто прочитает. Может кто-то знает reference app для микросервисов на Go, чтобы можно было посмотреть на более-менее все реальные аспекты микросервисного приложения.
Код несколько упрощен (может это и out of scope для gokit, но как на практике без этого в реальном проекте непонятно):
1. обычно в БД содержатся еще поля, которые не хочется выдавать наружу (по крайней мере всегда). Поэтому интересно посмотреть GetByIDResponse, который содержит только часть ордера. Hint: в Java для этого есть mapstruct.org, интересно как это реализуется в Go / Gokit.
2. хотелось бы так же посмотреть пример валидации данных запроса и подготовка модели для сохранения (только часть полей модели БД может задаваться в моделе запроса), т.к. это опять же обычно обязательная вещь.
В репозитарии, наверное, указан некорректный метод ChangeOrderStatus: обычно репозитарий валидирует только возможность сохранения модели (например, что строка по длине помещается в ячейку БД), но не контролирует корректность переходов между состояниями — это функция сервисов. Поэтому, обычно, просто метод сохранения, без ограничения на только изменения статуса. Хотя и так можно, особенно, если реализация такого метода генерируется автоматически.
Из интересного можно отметить, что в Spring обычно нет отдельного слоя Endpoint: там связка протокола и сервиса в одном классе. Так же довольно многословно получается в Endpoint и Transport: цена за отсутствие «магии».
С одной стороны интересный терми «мультимидл», с другой стороны он не до конца верен. Все-таки такой человек лучше мидла и очень быстро приближается к сеньору по мере работы в одной технологии (скажем, где-то 6 мес, а после этого вполне тяжело отличить от сеньора). Время уходит на ментальную перестройку под платформу и обновление знаний. Плюс, кругозор позволяет время от времени гораздо эффективнее решать задачи, так что это вполне покрывает эффективность реального узкого сеньора (не просто по годам).
На каждой платформе (нечто более узкое, чем просто яп) нужно писать в соответствии с практиками платформы. Это да, важно осознавать. Так же важно понимать, что ментально работа на UI и бекенд разная: разные вещи важны. Нужно осознанно перестраиваться. Внутри одной недели делать разное с качеством сеньора не получится.
Мультимидлы хороши в аутсорсе и малых компаниях: там важно иметь реальную возможность перебросить человека с бека на фронт и наоборот. Оплачивается в таком случае не хуже сеньора, даже если вполне реальный мидл, а не мультисеньор.
Из мультимидлов получаются мультисеньоры, а потом архитекторы, т.к. им обязательно иметь кругозор.
Если человек средних способностей, то не нужно ему идти в мультимидлы, т.к. это гораздо сложнее с точки зрения «вычислительных» затрат человека, но легче с точки зрения мотивации.
Важно так же понимать, что 90% сеньоров в одной технологии особо много не знают, т.к. чем дальше учишься, тем прогресс слабее, а большинство вообще бросает это дело. Так что с точки зрения работодателя в среднем человек, который владеет несколькими технологиями гораздо лучше обучен (будет писать более поддерживаемый протестированный код с меньшим количеством багов, хотя и может что-то редко упустить в особенностях платформы), чем человек в одной технологии. Но ещё не все так считают: обычно отбрасывается «в среднем» и пытаются найти исключение.
4к телеков много, у меня тоже оно есть, но контента еще очень мало. Когда покупал не осознавал этого, сейчас бы наверняка без этого купил. Все фильмы 4к за экстра деньги, что не очень.
Я о том, что контент запаздывает за технологией вполне себе заметно. Еще несколько лет нужно ждать пока 4к не станет таким же стандартом как Full HD сейчас.
Не все имеет смысл делить (особенно обновление из upstream), вопрос же не в 100%/0%, а общем правиле (95/5).
Плюс, если я правильно понял пример, то мы вводим другой вид дерева параллельно за фиче-флагом. И постепенно разрабатываем отдельными PR пока не будет достаточно для релиза. А уж при релизе можем старое удалить сразу (хотя странно), а можем вводить новый функционал через настройку.
PR не означает, что сразу пойдет в релиз. Например, есть один большой PR — разбили на небольшие, они прошли все процессы в рамках одного релиза.
А про мелкие инкременты — это как раз реальность. Как в софте, так и в реальном мире. Например, сначала провели маркетинговый анализ, потом нашли поставщиков, заключили договора, добавили товар в кассу, изменили инструкции работы персонала, заказали новые маркетинговые материалы, закупили морозильные лари для мороженного — много-много разных этапов как в оффлайн, так и в софте. Понятно, что ценность начинается с момента начала продаж мороженного, но как до, так и после начала есть множество этапов, которые имеет смысл постепенно поставлять.
Хорошая аналогия малых PR в магазине: выложить новые рекламные таблички, переставить товар и т.п.: их много, они нужны практически каждый день, они немного улучшают продажи. Это не отменяет и большие, но они обычно так же вполне реально постепенно добавляются, хоть и не (особо) заметно для пользователя, пока выключены.
> Интересно что это значит. Что сейчас все крутится на больших серверах, используется 1% мощности и за все платится с оверхедом?
Да, в статье есть скриншот — там до 10% загрузка CPU.
Единственно, если ничего интересного от AWS не используется (ни LB, ни автоскейлинг, ни preemtive vms) я бы переехал на DigitalOcean — должно получиться в 2 раза дешевле.
> На продакшне. ОК.
В old school это называется install server или jump host, совершенно обычная практика.
У нас актуальнее просто снимать комнату в офисном центре (или даже квартиру, особенно если несколько человек). Немного больше проблем (уборка, интернет, обустройство кухонного уголка, мебель), но дешевле и во многом удобнее.
1. Нет возможности поставить чистый K8s без Ansible, Jenkins и прочего.
2. Сама по себе странная идея, что в production будем разворачиваться из исходников.
3. Довольно низкокачественный Ansible Playbook: если что-то пошло не так, то не исправляется (да и удаление не всегда отрабатывает). Чаще нужно переставлять операционную систему.
4. Встроенный стек мониторинга — спорный вопрос. Мы еще деплоимся в публичные облака через managed K8s и там такого блока нет. Соответственно, в облаке и OpenShift ставим свой стек. В OpenShift получается 2 установки похожих сервисов — неоптимально.
Облака же интересны:
— при большой стоимости людей и их низкой компетентности (не российский случай)
— незначительность затрат (2-3 сервера на всероссийскую компанию постаматов)
— сезонность (а-ля выставочная компания)
— временная ситуация (ждём поставки серверов)
— редкие разовые эксперименты/проекты
— безудержный рост, когда не до оптимизаций побочных вещей, нужно рынок захватывать (бывает, но редко)
Определение:
— нет управления инфраструктурой (включая автоматическое масштабирование)
— отсутствие оплаты за простой (оплата за реальное использование)
— безопасность на стороне поставщика
И их 3 основных сервиса:
— функции
— AppsEngine (свой фреймворк приложений для нескольких языков)
— Cloud Run (любой контейнер без состояния, который реагирует на http)
Как по мне, всё приложение на функциях писать неудобно
(поэтому и появились всякие фреймворки для функций, но все равно сложно),
AppsEngine несколько ограничен и заточен на Google (первый serverless сервис, который никак массово не взлетает, в о основном из-за зависимости кода от Google),
а Cloud Run — выглядит как раз как то, что надо.
2. Computer science != программирование
3. В науке (сomputer science) же важны скорее лучшие (ИМХО), чем среднее значение
А уж про ухудшение высшего образование по ИТ — это вообще странно звучит. Сейчас ИТ компании кафедры создают, чтобы учить именно ИТ, а не физ-мат-тех. Да и отдельные выпускники возвращаются в ВУЗ преподавать программирование (по совместительству) с хорошим коммерческим опытом. Хотя, в детали не особо вникал, сам непосредственно не связан.
Почему архитекторы отвернулись от RubyOnRails (Ruby без RoR никогда не был особо популярен) — тут можно порассуждать, но факт остается фактом.
Например, мой комментарий о Rails 2016 года: habr.com/post/306564/#comment_9719652
В целом, Rails хорош для
* сильных программистов (и соответственно, плох уже для средних)
* для генерации html/js на сервере (а это уже сейчас более-менее редкость).
Я вот реально не вижу причин начинать новый проект на Rails сейчас. Только то, что в компании все Ruby разработчики. Для любителей фулстаков есть нода, для любителей разделения Golang и, в некоторых случаях, Spring.
Годогенерация = магия, но часто это не плохо.
Код несколько упрощен (может это и out of scope для gokit, но как на практике без этого в реальном проекте непонятно):
1. обычно в БД содержатся еще поля, которые не хочется выдавать наружу (по крайней мере всегда). Поэтому интересно посмотреть GetByIDResponse, который содержит только часть ордера. Hint: в Java для этого есть mapstruct.org, интересно как это реализуется в Go / Gokit.
2. хотелось бы так же посмотреть пример валидации данных запроса и подготовка модели для сохранения (только часть полей модели БД может задаваться в моделе запроса), т.к. это опять же обычно обязательная вещь.
В репозитарии, наверное, указан некорректный метод ChangeOrderStatus: обычно репозитарий валидирует только возможность сохранения модели (например, что строка по длине помещается в ячейку БД), но не контролирует корректность переходов между состояниями — это функция сервисов. Поэтому, обычно, просто метод сохранения, без ограничения на только изменения статуса. Хотя и так можно, особенно, если реализация такого метода генерируется автоматически.
Из интересного можно отметить, что в Spring обычно нет отдельного слоя Endpoint: там связка протокола и сервиса в одном классе. Так же довольно многословно получается в Endpoint и Transport: цена за отсутствие «магии».
На каждой платформе (нечто более узкое, чем просто яп) нужно писать в соответствии с практиками платформы. Это да, важно осознавать. Так же важно понимать, что ментально работа на UI и бекенд разная: разные вещи важны. Нужно осознанно перестраиваться. Внутри одной недели делать разное с качеством сеньора не получится.
Мультимидлы хороши в аутсорсе и малых компаниях: там важно иметь реальную возможность перебросить человека с бека на фронт и наоборот. Оплачивается в таком случае не хуже сеньора, даже если вполне реальный мидл, а не мультисеньор.
Из мультимидлов получаются мультисеньоры, а потом архитекторы, т.к. им обязательно иметь кругозор.
Если человек средних способностей, то не нужно ему идти в мультимидлы, т.к. это гораздо сложнее с точки зрения «вычислительных» затрат человека, но легче с точки зрения мотивации.
Важно так же понимать, что 90% сеньоров в одной технологии особо много не знают, т.к. чем дальше учишься, тем прогресс слабее, а большинство вообще бросает это дело. Так что с точки зрения работодателя в среднем человек, который владеет несколькими технологиями гораздо лучше обучен (будет писать более поддерживаемый протестированный код с меньшим количеством багов, хотя и может что-то редко упустить в особенностях платформы), чем человек в одной технологии. Но ещё не все так считают: обычно отбрасывается «в среднем» и пытаются найти исключение.
Я о том, что контент запаздывает за технологией вполне себе заметно. Еще несколько лет нужно ждать пока 4к не станет таким же стандартом как Full HD сейчас.