По поводу СТО и порядка вы ошибаетесь. Одновременность и интервал связанных событий может не соблюдаются в различных системах отчёта, однако порядок остаётся всегда одинаковым. В противном случае, это приводит к парадоксам, где причина случается после следствия.
Подробные парадоксы возникают в системах доставки сообщений, где не соблюдается гарантия упорядоченности. В распределенных системах это основной и самый трудноотлаживаемый тип сбоев.
Учитывая общий уровень освещенности днём за рабочим местом, а также эффекты типа бликов от ярких источников света, днём темная тема имеет гораздо более худшую контрастность.
Темная тема фокусирует внимание на яркие объекты типа текста, тогда как фон остаётся неконтрастным и поэтому незаметным. Проблема в том, что это делает практически невидимыми оконные элементы интерфейса, которые-таки несут смысловую нагрузку.
По поводу лимита файловых дескрипторов: практически во всех дистрибутивах он установлен в 1024.
В JVM процессах ещё есть такая неприятная вещь, как non-heap memory, которая выходит за рамки лимита по Xmx и собственно вообще ничем не лимитируется. Его любят использовать всякие вещи, IO подсистемы и т.д. В итоге возможна ситуация, когда процесс убивается ОС, хотя в куче полно места, и OOM с дампом не сгенерированны. Особенно актуально, когда выставлены лимиты cgroups на контейнер.
Ещё неплохая практика выставлять Xms равным Xmx, таким образом жёстко резервируя память для java процесса.
Учу джунов, что каждая строчка кода -- это отнюдь не ценность, а долг. В особенности для тех, кто потом будет поддерживать, отлаживать и дорабатывать программу. Поэтому я категорически против раздувания шаблонного кода, ссылаясь на зазубренные "паттерны" или "лучшие практики" от дяди гуру.
С другой стороны, системный функционал, который способствует уменьшению шаблонного кода в бизнес логике, всегда должен приветствоваться. Этим собственно и должны заниматься сеньоры -- сделать разработку бизнес функционала простой и понятной.
То, что тесты отдельных частей кода зеленые отнюдь не гарантирует, что весь бизнес кейс работает корректно. Кроме того, тестирование по частям накладывает дополнительные расходы на мокирование и фейкирование зависимостей, а это не тривиальная задача. Например, как тестировать по-частям монорепозиторный фронт с зависимостями от 100 микросервисов?
В те времена для того, чтобы запустить программу, надо было принести ее в вычислительный центр. Помещение, размером с современный дата центр
Создаётся впечатление, что с тех пор концепт не особо изменился. Сегодня чтобы протестить код, нужно залить его в репозиторий, скомпилировать, запаковать в контейнер, развернуть в облаке, сделать необходимые тесты, достать результаты, и по новой... Только вместо оператора там теперь сидит девопс инженер. Каждый раз на умные люди изобретают новые препятствия на пути между программистом и исполняемой средой...
То есть в обоих случаях сначала дампим и копируем все данные с основного сервера на реплику, а затем слушаем изменения. Не совсем понятно можно ли это делать online, и что будет происходить в промежутке между копированием реплики и началом подписки, ведь данные на мастере постоянно изменяются. Или для поднятия реплики нужно мастер тоже останавливать?
P.S. вроде как были автоматические решения для HA типа PgPool.
В свое время, помню, Oracle CBO часто ошибался при объединении двух таблиц с where. Выборка по первой таблице была огромной, а по второй - давала лишь несколько строчек. По какой-то причине в определенный момент он предпочитал сначала делать выборку именно по первой таблице, что увеличивало время запроса с 0.1 сек до 5-6. Не помогали ни переписывания запросов (Oracle индифферентен к форме запроса), ни прогоны анализатора статистики. Лечилось только явными хинтами, поставленными в запросе. Не знаю, баг ли это был или что-то ещё, но факт в том, что CBO не гарантирует оптимальное выполнение.
Можно оптимизировать, как делают многие JPA: сделайте SQL sequence сразу с шагом 10, и кешируйте промежуточные значения. Однако, в этом случае могут появляться "дырки" и будет нарушен порядок по Id в случае нескольких инстансов.
Идея состоит в том, что на выполнение задачи уходит ровно столько времени, сколько было выделено.
А это как раз очень натурально получается. Всегда есть некий баланс между качеством и скоростью. Оптимальное решение всегда рождается, когда времени на реализацию достаточно: можно хорошо подумать, исследовать, отрефакторить и протестить.
Кроме того, практически любая задача включает в себя элемент неопределенности, связанный с проведением сторонних технологий или неким исследованием. Это может неожиданно увеличить время задачи, поскольку на этапе планирования все оптимисты.
Проблема в том, что в обратную сторону это не работает. Если удалось выполнить задачу за меньшее время, то никто не горит желанием брать себе следующую и тупо ждут следующего спринта.
Работаю над проектом в лучших традициях методологий: матрицы оценок, груминг, стендапы, etc. Все больше убеждаюсь, что все это не более чем формальность. Есть четкий функционал, который надо сделать к концу года, согласованный с клиентом. Есть некий план задач, что нужно сделать для этого. И внутри этого периода всегда есть пространство для маневра: разные неожиданности, сложности, сделать хорошо или быстро... Поэтому дробить каждую из задач дальше не имеет смысла: сразу теряется гибкость к адаптации, затрудняются изменения, а народ теряет из виду цели работы и фокусируется на тикетах, которые со временем имеют свойство растягиваться.
Общаясь с разными разработчиками, я заметил интересную тенденцию мнений по поводу спринга: чем лучше человек в нем разбирается, тем больше он его ненавидит.
Спринг из коробки предлагает много нужных вещей, которых не надо идти искать, рыская по всей экосистеме. С другой стороны, посредственный, а иногда отвратительный дизайн (привет Spring Securituy), куча неявных соглашений, @заклинания, кейсы, прибитые гвоздями без возможности модификации -- убивают все удовольствие от разработки. Впрочем, в этом заключается участь всех индустриальных стандартов. Шедевры не находят массового пользователя.
По поводу СТО и порядка вы ошибаетесь. Одновременность и интервал связанных событий может не соблюдаются в различных системах отчёта, однако порядок остаётся всегда одинаковым. В противном случае, это приводит к парадоксам, где причина случается после следствия.
Подробные парадоксы возникают в системах доставки сообщений, где не соблюдается гарантия упорядоченности. В распределенных системах это основной и самый трудноотлаживаемый тип сбоев.
Пара моментов:
Учитывая общий уровень освещенности днём за рабочим местом, а также эффекты типа бликов от ярких источников света, днём темная тема имеет гораздо более худшую контрастность.
Темная тема фокусирует внимание на яркие объекты типа текста, тогда как фон остаётся неконтрастным и поэтому незаметным. Проблема в том, что это делает практически невидимыми оконные элементы интерфейса, которые-таки несут смысловую нагрузку.
По поводу лимита файловых дескрипторов: практически во всех дистрибутивах он установлен в 1024.
В JVM процессах ещё есть такая неприятная вещь, как non-heap memory, которая выходит за рамки лимита по Xmx и собственно вообще ничем не лимитируется. Его любят использовать всякие вещи, IO подсистемы и т.д. В итоге возможна ситуация, когда процесс убивается ОС, хотя в куче полно места, и OOM с дампом не сгенерированны. Особенно актуально, когда выставлены лимиты cgroups на контейнер.
Ещё неплохая практика выставлять Xms равным Xmx, таким образом жёстко резервируя память для java процесса.
Учу джунов, что каждая строчка кода -- это отнюдь не ценность, а долг. В особенности для тех, кто потом будет поддерживать, отлаживать и дорабатывать программу. Поэтому я категорически против раздувания шаблонного кода, ссылаясь на зазубренные "паттерны" или "лучшие практики" от дяди гуру.
С другой стороны, системный функционал, который способствует уменьшению шаблонного кода в бизнес логике, всегда должен приветствоваться. Этим собственно и должны заниматься сеньоры -- сделать разработку бизнес функционала простой и понятной.
Если быть точным, то TCP никак не гарантирует доставку данных, а лишь то, что принятые данные всегда корректны.
Еще скажите, что у вас монолит, и вас сразу закидают гнилыми помидорами :)
Именно по этой причине в тренд входит serverless и лямбды :)
То, что тесты отдельных частей кода зеленые отнюдь не гарантирует, что весь бизнес кейс работает корректно. Кроме того, тестирование по частям накладывает дополнительные расходы на мокирование и фейкирование зависимостей, а это не тривиальная задача. Например, как тестировать по-частям монорепозиторный фронт с зависимостями от 100 микросервисов?
Создаётся впечатление, что с тех пор концепт не особо изменился. Сегодня чтобы протестить код, нужно залить его в репозиторий, скомпилировать, запаковать в контейнер, развернуть в облаке, сделать необходимые тесты, достать результаты, и по новой... Только вместо оператора там теперь сидит девопс инженер. Каждый раз на умные люди изобретают новые препятствия на пути между программистом и исполняемой средой...
К сожалению, опыт и грабли.
удаленоЕщё один способ - постоянное запугивание и сравнивание с конкурентами :)
Вообще любой успешный проект проходит как минимум 4 стадии легаси, при котором необходимо полное или частичное переписывание:
Когда наспех стряпанный прототип выстрелил, и требуется делать полноценный коммерческий продукт.
Когда выбранный дизайн уже не позволяет эффективно реализовать скопившиеся требования.
Когда одна команда уже не справляется с потоком требований и требуется распределить разработку.
Когда количество клиентов и нагрузка резко возросли, и требуется менять существующую архитектуру решения.
То есть в обоих случаях сначала дампим и копируем все данные с основного сервера на реплику, а затем слушаем изменения. Не совсем понятно можно ли это делать online, и что будет происходить в промежутке между копированием реплики и началом подписки, ведь данные на мастере постоянно изменяются. Или для поднятия реплики нужно мастер тоже останавливать?
P.S. вроде как были автоматические решения для HA типа PgPool.
В свое время, помню, Oracle CBO часто ошибался при объединении двух таблиц с where. Выборка по первой таблице была огромной, а по второй - давала лишь несколько строчек. По какой-то причине в определенный момент он предпочитал сначала делать выборку именно по первой таблице, что увеличивало время запроса с 0.1 сек до 5-6. Не помогали ни переписывания запросов (Oracle индифферентен к форме запроса), ни прогоны анализатора статистики. Лечилось только явными хинтами, поставленными в запросе. Не знаю, баг ли это был или что-то ещё, но факт в том, что CBO не гарантирует оптимальное выполнение.
Можно оптимизировать, как делают многие JPA: сделайте SQL sequence сразу с шагом 10, и кешируйте промежуточные значения. Однако, в этом случае могут появляться "дырки" и будет нарушен порядок по Id в случае нескольких инстансов.
А это как раз очень натурально получается. Всегда есть некий баланс между качеством и скоростью. Оптимальное решение всегда рождается, когда времени на реализацию достаточно: можно хорошо подумать, исследовать, отрефакторить и протестить.
Кроме того, практически любая задача включает в себя элемент неопределенности, связанный с проведением сторонних технологий или неким исследованием. Это может неожиданно увеличить время задачи, поскольку на этапе планирования все оптимисты.
Проблема в том, что в обратную сторону это не работает. Если удалось выполнить задачу за меньшее время, то никто не горит желанием брать себе следующую и тупо ждут следующего спринта.
2016: left-pad npm package
Работаю над проектом в лучших традициях методологий: матрицы оценок, груминг, стендапы, etc. Все больше убеждаюсь, что все это не более чем формальность. Есть четкий функционал, который надо сделать к концу года, согласованный с клиентом. Есть некий план задач, что нужно сделать для этого. И внутри этого периода всегда есть пространство для маневра: разные неожиданности, сложности, сделать хорошо или быстро... Поэтому дробить каждую из задач дальше не имеет смысла: сразу теряется гибкость к адаптации, затрудняются изменения, а народ теряет из виду цели работы и фокусируется на тикетах, которые со временем имеют свойство растягиваться.
То есть где-то посередине подковы время стоит?
Общаясь с разными разработчиками, я заметил интересную тенденцию мнений по поводу спринга: чем лучше человек в нем разбирается, тем больше он его ненавидит.
Спринг из коробки предлагает много нужных вещей, которых не надо идти искать, рыская по всей экосистеме. С другой стороны, посредственный, а иногда отвратительный дизайн (привет Spring Securituy), куча неявных соглашений, @заклинания, кейсы, прибитые гвоздями без возможности модификации -- убивают все удовольствие от разработки. Впрочем, в этом заключается участь всех индустриальных стандартов. Шедевры не находят массового пользователя.