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