Не стоит смешивать теплое с мягким. То, что задача без артефакта - это не задача, никто не спорит.
Вопрос в подходе. Можно обсудить ее, разрешить все противоречия в терминологии, проговорить откуда вообще она взялась, к достижению какой цели приблизит, а потом зафиксировать задачу в виде тикета/письма/сообщения
А можно сразу зафиксировать задачу и потом, к примеру, очень удивиться, что для заказчика сервис=докер образ, а для исполнителя сервис=репозиторий. И хорошо если это приведет к каким-то противоречиям, чтобы исполнитель сказал "бред какой-то" и пошел выяснять что там к чему - чтобы хоть в переписке прояснить несостыковки.
Но такое может запросто проскочить до реализации - исполнитель будет считать, что все понял верно, и потом только на демонстрации выяснится, что это не то и не туда. И хорошо, если это было демо спринта, а не вотерфольный проект с итерацией на полгодика.
На мой взгляд, преимущества легче осели в головах. Я думаю, это связано с тем, что их эффект наступает сразу же при переходе на новый режим:
ух, ты - сразу снизился эпидемиологический риск
ух, ты - теперь я сразу могу выбирать локацию и уровень комфорта своего рабочего места
ух, ты - сразу пропали накладные расходы на дорогу на работу
ух, ты - сразу(ну тут не так сразу, да) можно нанимать более крутых ребят из разных регионов
А вот эффекты, которые обнаруживают себя не сразу - их сложнее заметить, осознать и принять.
И когда год спустя я увидел, что многие мои коллеги как раз таких проявлений не отметили - возникла эта статья. Поэтому получилось однобоко - только то, что болит.
Ну и кроме того - получился бы совсем уже лонгрид.
Но я согласен, что чем больше разных точек зрения - тем ближе к истине. Я с радостью размещу в шапке ссылки на альтернативные точки зрения(пожалуй, даже добавлю про это в текст). Так что, милости прошу излагать развернуто свой взгляд на удаленку
не хабра) hh.ru. Хабр про свою архитектуру расскажет в своем бложике)
У нас 4 человека, все бэкендеры с уклоном в java с разным опытом проектирования систем
Джобы работают на своей поделке. Она работает на нашем jclient. Умеет дергать рестовые ручки по расписанию, собирать обратную связь по запуску и примитивные паттерны реакции — ретрай если не отвечает etc
Да, это угроза безопасности, но т.к. мы об этом знаем, то все не так страшно.
Понятно, что функционал закрыт разрешениями и доступен только нескольким людям.
А что до процесса, то ревьюить, тестировать и складывать скрипты в VCS — можно и нужно, так же как и весь остальной код.
Просто тут все это работает на доверии. В кейсах, которые я описал, польза окупает этот риск
нестандартное обращение пользователя в поддержку: ради одного случая писать боевой код — не хочется, а помочь человеку — хочется
ускорение запуска функционала: админка для фичи еще не готова, а сервисный слой уже вполне работает. можем сегодня запускать фичу в script-driven режиме, а завтра доделаем админку
classloader, который делает что?
загрузить байтики в класс не проблема — вопрос откуда они возьмутся и что это будут за байтики
Предлагаю просто прикинуть скольким критериям удовлетворяет выполнение скомпиленных классов — как скомпилить класс, чтобы перенаправить I/O, чтобы можно было снаружи в него контекст передать…
хочется ну хоть сколько-нибудь реалистичную конфигурацию. с ретраями запросов(которые можно поретраить), с логированием запросов. ну т.е. сам обмен данными это даже не полбеды в микросервисах. гораздо важнее поддержка отказоустойчивости и человекопонятность происходящего во время аварий. именно эти вещи держат многих на http/1.1
Не сложно. В плане сложности как раз все хорошо.
Но там явно есть косяки. Одним из первых приемов, который я проверяю в DAW, является sidechain. И вот LMMS на тесте показал, что sidechain работает плохо — клик присутствует даже на 12мс атаке. На эту тему заведен баг, но пока не починено. А без этого дальше испытывать тулзу вообще смысла не имеет.
Когда я начну подключать рабочий аппарат, то знаний у меня, конечно, поприбавится — может, даже на продолжение накапает) Я пока(и похоже правильно) решил начать с самого простого — заставить работать ноут.
з.ы. главная проблема тут не в том, как в этом разобраться. Можно и спеку HDA раскурить, и из комментов информацию собрать, на худой конец можно сорцы почитать. Главная проблема — что в этом вообще нужно разбираться.
Может, задокументируй разработчики ALSA, как по их мнению надо настраивать звук по шагам с описанием архитектуры, структуры конфигов, как что и для чего крутить, API, то и проблемы бы никакой не было. А я пока вижу, что клочки информации непроверенной разбросаны повсюду, а мой тикет за 3 недели даже отфутболить никто не берется.
Может, задокументируй вы вот эту процедуру настройки мпдшки, многие люди прошли бы с ее помощью на шаг дальше.
А время, которое я потрачу на разбор, я бы с удовольствием потратил на другие вещи — на разбор того же муз. софта доступного, плагинов и т.д.
У нас - вроде приемлемо. Прям WTF'ов после прочтения - совсем не припоминаю
Не стоит смешивать теплое с мягким. То, что задача без артефакта - это не задача, никто не спорит.
Вопрос в подходе. Можно обсудить ее, разрешить все противоречия в терминологии, проговорить откуда вообще она взялась, к достижению какой цели приблизит, а потом зафиксировать задачу в виде тикета/письма/сообщения
А можно сразу зафиксировать задачу и потом, к примеру, очень удивиться, что для заказчика сервис=докер образ, а для исполнителя сервис=репозиторий. И хорошо если это приведет к каким-то противоречиям, чтобы исполнитель сказал "бред какой-то" и пошел выяснять что там к чему - чтобы хоть в переписке прояснить несостыковки.
Но такое может запросто проскочить до реализации - исполнитель будет считать, что все понял верно, и потом только на демонстрации выяснится, что это не то и не туда. И хорошо, если это было демо спринта, а не вотерфольный проект с итерацией на полгодика.
На мой взгляд, преимущества легче осели в головах. Я думаю, это связано с тем, что их эффект наступает сразу же при переходе на новый режим:
ух, ты - сразу снизился эпидемиологический риск
ух, ты - теперь я сразу могу выбирать локацию и уровень комфорта своего рабочего места
ух, ты - сразу пропали накладные расходы на дорогу на работу
ух, ты - сразу(ну тут не так сразу, да) можно нанимать более крутых ребят из разных регионов
А вот эффекты, которые обнаруживают себя не сразу - их сложнее заметить, осознать и принять.
И когда год спустя я увидел, что многие мои коллеги как раз таких проявлений не отметили - возникла эта статья. Поэтому получилось однобоко - только то, что болит.
Ну и кроме того - получился бы совсем уже лонгрид.
Но я согласен, что чем больше разных точек зрения - тем ближе к истине. Я с радостью размещу в шапке ссылки на альтернативные точки зрения(пожалуй, даже добавлю про это в текст). Так что, милости прошу излагать развернуто свой взгляд на удаленку
У нас 4 человека, все бэкендеры с уклоном в java с разным опытом проектирования систем
Но для junior-уровня сейчас ничего не вижу
Понятно, что функционал закрыт разрешениями и доступен только нескольким людям.
А что до процесса, то ревьюить, тестировать и складывать скрипты в VCS — можно и нужно, так же как и весь остальной код.
Просто тут все это работает на доверии. В кейсах, которые я описал, польза окупает этот риск
загрузить байтики в класс не проблема — вопрос откуда они возьмутся и что это будут за байтики
Предлагаю просто прикинуть скольким критериям удовлетворяет выполнение скомпиленных классов — как скомпилить класс, чтобы перенаправить I/O, чтобы можно было снаружи в него контекст передать…
хочется ну хоть сколько-нибудь реалистичную конфигурацию. с ретраями запросов(которые можно поретраить), с логированием запросов. ну т.е. сам обмен данными это даже не полбеды в микросервисах. гораздо важнее поддержка отказоустойчивости и человекопонятность происходящего во время аварий. именно эти вещи держат многих на http/1.1
Но там явно есть косяки. Одним из первых приемов, который я проверяю в DAW, является sidechain. И вот LMMS на тесте показал, что sidechain работает плохо — клик присутствует даже на 12мс атаке. На эту тему заведен баг, но пока не починено. А без этого дальше испытывать тулзу вообще смысла не имеет.
з.ы. главная проблема тут не в том, как в этом разобраться. Можно и спеку HDA раскурить, и из комментов информацию собрать, на худой конец можно сорцы почитать. Главная проблема — что в этом вообще нужно разбираться.
Может, задокументируй разработчики ALSA, как по их мнению надо настраивать звук по шагам с описанием архитектуры, структуры конфигов, как что и для чего крутить, API, то и проблемы бы никакой не было. А я пока вижу, что клочки информации непроверенной разбросаны повсюду, а мой тикет за 3 недели даже отфутболить никто не берется.
Может, задокументируй вы вот эту процедуру настройки мпдшки, многие люди прошли бы с ее помощью на шаг дальше.
А время, которое я потрачу на разбор, я бы с удовольствием потратил на другие вещи — на разбор того же муз. софта доступного, плагинов и т.д.