Я в году 2003 решил поменять материнку. Начитался и выбрал одну от Gigabyte в ту пору хороший середнячок. После работы решил все собрать. Благо ночь впереди, если что. Как раз входил новый сокет на проц и дополнительное питание. Собрал, включаю..., а тишина! Аж в пот пробило. Давай разбираться. Тогда ещё шла схема в комплекте. Смотрю на схеме доп питание полярность одна, а на плате зеркальная! Перепроверил несколько раз. Уж думал разучился читать схемы. И доп питание распаяно ж тоже наоборот! Короче, в штекере перебрасываю плюс-минус, включаю - все работает!
Почти через год случается КЗ в квартире, что снимал, проводка дрянь была. Ну, и мамка вылетела, благо на гарантии. Понёс в контору на удачу. Они даже не удивились: вон в углу их по гарантии целая пачка - не заводятся! Показываю в чем причина. Не верят. Пробуем тут же, перебрасывает плюс-минус. Все работает! Мужики мне и мамку северную вместо этой поменяли и видяху прошную в полцены продали. Они всю партию потом нормально реализовали. Получается была ошибка на плате.
Исправьте в тексте. Это достаточно критично в некоторых случаях. Например, Kafka, не меняет порядок сообщений, тогда как JMS поддерживает приоритезацию, которая меняет порядок сообщений.
В Линуксе, а потом и в Винде пользуюсь виртуальными экранами для организации отдельных окружения. Например, 1й - почта и подобное., 2й - разработка, 3й- мониторинг и т.д.
В KDE есть отдельные комнаты там помимо разделения задач можно сохранять и настраивать весь сеанс и иконки и все остальное. На самом деле, инструменты есть, но редко кто "заморачивается", хочется чтоб в е само как-то
Как начинаешь новый frontend проект, так начинается все сначала: какие папки, как назвать, что такое компонент, слой, фича и т.д. и т.п. В одном проекте это согласование заняло около месяца! Уже бэк успели сделать, а все шли дебаты.
Общие компоненты, по-хорошему, должны быть внесены в отдельный репозитой и подтягиваться отдельным артефактом. Если вы положили что-то в определённую папку, это не значит, что это стало тем, что предполагалось помещать в эту папку.
Мы же предлагаем строить приложения более прямолинейно, как мы все привыкли, вокруг Интерфейсов.
Самое смешное, такого же принципа, часто придерживаются UX-дизайнеры. И получается, если нужно сделать принципиально новый дизайн и разработать новый поход, компоненты и прочее, то все в ступоре, т.к. такого никто не делал и интерфейса ещё в природе нет. А плясать нужно от бизнеса, от природы вещей - сущностей. А сущности могу не иметь UI отображения и тогда совсем беда...
Лет 20 назад друг настроил Emacs по образу и подобию Borland'a, но на Linux. Было реально круто, но нужно заморочиться и потратить время знатно. Как-то вспомнил, захотелось попробовать, но не осилил - не было мотивации столько сил тратить. Как вариант, если подготовить шаблоны, чтоб переиспользовать, то можно получить реальную IDE
Больше всего бесило во встроенных в Идею плагинов для БД - зависание. Сидишь, дебажишь, нужно что-то посмотреть в базе, а все зависло. И ни базу не посмотришь ни код. Носишь все и по новой запускаешь. Нет уж увольте. Почему-то ни у кого не возникает желания держать и молоток и пассатижи в одной руке и мультитул считается как непрофессиональный компромисс.
Да, Идея в свое время сделала ставку на рефакторинг и выиграла. Но и у неё есть слабые стороны. Я и сам сижу на Идеи, но если бы была другая ушёл бы, т.к. пару "фич" редактора не исправляются с самого рождения. Отладчик так и не умеет показывать возвращаемого значения из функции. А с внедрением лямд в Java количество нераспозноваемого кода для отладчика только растёт. Мультимодульные проекты не всегда подтягивается корректно... В свое время, когда вынужденно переходил с jBuilder'а, буквально плакал. Жаль Borland не выжил. А в последнее время основная фича - рефакторинг - тоже сбоит. Поменяли интерфейс на спорный...
Не боги горшки обжигают. Если будут почивать на лаврах, то точно так же как и предыдущих "богов" сметут.
Довольно неожиданный взвешанный взгляд. Важно, чтоб аналитик был частью команды, а не надзирателем.
Единственное, с чем не могу согласиться, так это, что аналитик может быть ответственен за архитектуру. Да, такие примеры есть, но, честно говоря, в основном неудачные либо в рамках тренда (от слова трындеть :), тобишь то, что на слуху: "микроскрвисы нынче в моде". Либо отсутствует понимание роли архитектора решения. Именно архитектор может взвесить все за и против с технической точки зрения и проработать нюансы. Нормальный архитектор не зря ест свой хлеб.
Например, недавно был пример. Аналитик хоть и был со стороны компании команды, но противопоставлял себя команде и его решение должно было быть окончательным.
Вы что, мне знаете как сделать "снежинку"?
Ну, если ты тоже архитектор, то будь добр расскажи почему "снежинка","вдруг", не даёт требуемой скорости в нужных запросах? Это ж просто! Все так делают и в книжках написано...
Только книжку, видимо, не дочитал, хотя, скорее, не читал, т.к. там описаны плюсы и минусы снежинки и звезды.
Каждый в команде должен заниматься своим делом в команде, тогда и команда будет эффективной.
Вообще, тёмный фон в любом дизайне, будь то интерьер, фото, интерфейс - это всегда вызов. А почему? Человек - дневное животное. Оттенки черного многим не под силу, ввиду естественного ограничения зрения. Плюс, если говорить о фоне, то любая мелкая, но светлая деталь становится видимой, чёткой, назойливой. Там, где подразумевалась тень, она либо исчезает, либо становиться наоборот засветкой. Поэтому тёмная тема полностью должна быть создана с нуля, т.к. меняется концепция. И именно поэтому многим дорого создавать полностью новую тему. А в некоторых случаях, где скорость реакции имеет критическое значение, приходится отказываться от тёмного интерфейса, как от неестественно го для человека.
Когда тех лид с умным видом на конференции рассказывал, как он проверяет форматирование кода на код ревью, а не использует PM, Checkstyle, Sonar для таких проверок, уровень Сбера стал понятен
И это не про справедливость, а элементарную логику и выгоду для бизнеса. Любому новому человеку нужно время для того, чтобы вникнуть в процессы и специфику на новом месте, даже если он занимался тем же на прежнем месте. И в это время бизнес будет только терять. Конечно, я не говорю про те случаи, когда нанимается специалист с большим опытом и лучшей квалификацией. Поэтому бизнесу выгодней развивать собственных сутрудников, а не нанимать со стороны. Но где выгода компании и выгода конкретного ХР манагера и его начальника.
Перестаньте писать, что архитектор может не иметь хорошей технической базы и не быть разработчиком. Он, конечно, может ее не иметь, но это будет плохой архитектор. И таких, к сожалению, развелось хоть пруд пруди!
Смешно было наблюдать на одних переговорах, когда такой "архитектор" по каждому техническому вопросу выбегал из переговорки и звонил кому-то, советовался. Под конец уже сами заказчики смеялись в голос и комментировали.
Архитектор ответственен за выпуск продукта, выбор доступных инструментов и подходов. Если он сам понятия не имеет, с чем работает, то что он построит?
Нужно как в строительстве, чтоб ответственность за продукт была пожизненно, тогда, глядишь, инженеры будут в отрасли, а не случайные люди.
Вы правы, данная ситуация не уникальна и многие с ней сталкиваются.
Вы правы, настройка должна быть включена. Можно еще принудительно проверять dueDate в диаграммах перез заливкой в репозиторий.
В настройках Kafka слушателя уже есть поддержка мультипоточности и максимального количества потоков. Настройка слушателя необходима, т.к. всегда есть аппаратные ограничения.
Нужно блюсти баланс и, вы правы, просто увеличение пула не решает проблемы
А вот здесь, как раз, и кроется основная проблема и основнаое решение - нужно уменьшить количество висящих процессов. Супер база и железо быстрей обработает ваши сотни тысяч процессов, но и их возможности ограничены. Технические решения могут только на время улучшить картину, но не решат логические ошибки.
В одной компании с сотнями тысяч сотрудников была такая же проблема. Казалось, проще простого стартовать на каждого сотрудника экземпляр процесса и дело с концом. Но...
При увеличении количества сотрудником количество процессов будет расти
При завершении и старте нового периода количество процессов может удваиваться
Если нужно передеплоить новую версию процесса, например, нашли ошибку в логике, то получаем тот же массовый эффект.
Сама по себе поддержка сотен тысяч процессов затратное дело.
При анализе процессов оказалось, что уникальных типов процессов с режимами ожидания всего не более 20ти. Простая переделка процессов решила все остальные. Процесс по времени шлет уникальные сообщения на каждого сотрудника и сообщения стартуют процессы с короткими транзакциями.
Основной совет - не смешивать реалтайм и обработку с таймерами в одном процессе.
Более того, техлид сам джун. У меня в одном проекте такой есть, который прикрывается фразой: "Нужно давать больше свободы разработчикам", - т.к. сам не знает ни языка, ни баз, ни техгологий, ни процессов, но поставлен подаваном менеджером сверху.
К сожалению, не стирается никогда, т.к. нет наработанного навыка доводить начатое дело до конца и это вылазит потом в работе постоянно. Конечно, я не сравниваю с теми, кто просто просиживал штаны в вузе, а с теми, кто знает зачем пришел учиться. Без крепкой инженерной базы и прикладных наук все, кто ушел, остаются на том же уровне мышления тупого копи-пасты, зарабатывания денег и нытья, а не создания новых продуктов, направлений и областей. Да, бывают исключения, кто потом наверстывает упущенное (сам знаю пару таких), но их подавляющее меньшинство.
Правильно замечено: "кодовая база без реального владения со временем деградирует". Сколько людей, столько мнений. И даже, если все профессионалы высокого класса, нужен координатор, чтобы привести к единому соглашению и следить, чтобы все придерживались единой линии.
Сейчас стараюсь четко определить владельца кода или сам станавлюсь им. Тогда можно говорить о каком-то порядке или возможности придерживаться плана и поставки в срок.
Ой, за логи в бинарниках прям отдельный котёл в аду!
Так, systemd уже тоже, типа, не модно и появилось куча своего чуть ли не в каждом дистрибутиве.
А если дальше по размышлять, то все лямбды - это хорошо забытое старое, например, программы на меинфреймах.
Ой, вы так изящно ругаетесь! Инлайн, макросы!..
Тут недавно за инлайн отмотивировали, т.к. читабельность падает.
А макросы, блоки кода и т.п. это ж скакать по коду нужно, а то и в другой файл!
К сожалению, уже и схему выбросил недавно, бумажки разбирал. Так хоть что-то было бы.
Я в году 2003 решил поменять материнку. Начитался и выбрал одну от Gigabyte в ту пору хороший середнячок. После работы решил все собрать. Благо ночь впереди, если что. Как раз входил новый сокет на проц и дополнительное питание. Собрал, включаю..., а тишина! Аж в пот пробило. Давай разбираться. Тогда ещё шла схема в комплекте. Смотрю на схеме доп питание полярность одна, а на плате зеркальная! Перепроверил несколько раз. Уж думал разучился читать схемы. И доп питание распаяно ж тоже наоборот! Короче, в штекере перебрасываю плюс-минус, включаю - все работает!
Почти через год случается КЗ в квартире, что снимал, проводка дрянь была. Ну, и мамка вылетела, благо на гарантии. Понёс в контору на удачу. Они даже не удивились: вон в углу их по гарантии целая пачка - не заводятся! Показываю в чем причина. Не верят. Пробуем тут же, перебрасывает плюс-минус. Все работает! Мужики мне и мамку северную вместо этой поменяли и видяху прошную в полцены продали. Они всю партию потом нормально реализовали. Получается была ошибка на плате.
Исправьте в тексте. Это достаточно критично в некоторых случаях. Например, Kafka, не меняет порядок сообщений, тогда как JMS поддерживает приоритезацию, которая меняет порядок сообщений.
В Линуксе, а потом и в Винде пользуюсь виртуальными экранами для организации отдельных окружения. Например, 1й - почта и подобное., 2й - разработка, 3й- мониторинг и т.д.
В KDE есть отдельные комнаты там помимо разделения задач можно сохранять и настраивать весь сеанс и иконки и все остальное. На самом деле, инструменты есть, но редко кто "заморачивается", хочется чтоб в е само как-то
Как начинаешь новый frontend проект, так начинается все сначала: какие папки, как назвать, что такое компонент, слой, фича и т.д. и т.п. В одном проекте это согласование заняло около месяца! Уже бэк успели сделать, а все шли дебаты.
Общие компоненты, по-хорошему, должны быть внесены в отдельный репозитой и подтягиваться отдельным артефактом. Если вы положили что-то в определённую папку, это не значит, что это стало тем, что предполагалось помещать в эту папку.
Самое смешное, такого же принципа, часто придерживаются UX-дизайнеры. И получается, если нужно сделать принципиально новый дизайн и разработать новый поход, компоненты и прочее, то все в ступоре, т.к. такого никто не делал и интерфейса ещё в природе нет. А плясать нужно от бизнеса, от природы вещей - сущностей. А сущности могу не иметь UI отображения и тогда совсем беда...
Лет 20 назад друг настроил Emacs по образу и подобию Borland'a, но на Linux. Было реально круто, но нужно заморочиться и потратить время знатно. Как-то вспомнил, захотелось попробовать, но не осилил - не было мотивации столько сил тратить. Как вариант, если подготовить шаблоны, чтоб переиспользовать, то можно получить реальную IDE
Больше всего бесило во встроенных в Идею плагинов для БД - зависание. Сидишь, дебажишь, нужно что-то посмотреть в базе, а все зависло. И ни базу не посмотришь ни код. Носишь все и по новой запускаешь. Нет уж увольте. Почему-то ни у кого не возникает желания держать и молоток и пассатижи в одной руке и мультитул считается как непрофессиональный компромисс.
И как же люди жили без нее до Идеи?
Да, Идея в свое время сделала ставку на рефакторинг и выиграла. Но и у неё есть слабые стороны. Я и сам сижу на Идеи, но если бы была другая ушёл бы, т.к. пару "фич" редактора не исправляются с самого рождения. Отладчик так и не умеет показывать возвращаемого значения из функции. А с внедрением лямд в Java количество нераспозноваемого кода для отладчика только растёт. Мультимодульные проекты не всегда подтягивается корректно... В свое время, когда вынужденно переходил с jBuilder'а, буквально плакал. Жаль Borland не выжил. А в последнее время основная фича - рефакторинг - тоже сбоит. Поменяли интерфейс на спорный...
Не боги горшки обжигают. Если будут почивать на лаврах, то точно так же как и предыдущих "богов" сметут.
Довольно неожиданный взвешанный взгляд. Важно, чтоб аналитик был частью команды, а не надзирателем.
Единственное, с чем не могу согласиться, так это, что аналитик может быть ответственен за архитектуру. Да, такие примеры есть, но, честно говоря, в основном неудачные либо в рамках тренда (от слова трындеть :), тобишь то, что на слуху: "микроскрвисы нынче в моде". Либо отсутствует понимание роли архитектора решения. Именно архитектор может взвесить все за и против с технической точки зрения и проработать нюансы. Нормальный архитектор не зря ест свой хлеб.
Например, недавно был пример. Аналитик хоть и был со стороны компании команды, но противопоставлял себя команде и его решение должно было быть окончательным.
Ну, если ты тоже архитектор, то будь добр расскажи почему "снежинка","вдруг", не даёт требуемой скорости в нужных запросах? Это ж просто! Все так делают и в книжках написано...
Только книжку, видимо, не дочитал, хотя, скорее, не читал, т.к. там описаны плюсы и минусы снежинки и звезды.
Каждый в команде должен заниматься своим делом в команде, тогда и команда будет эффективной.
Спасибо огромное за комплексный подход.
Вообще, тёмный фон в любом дизайне, будь то интерьер, фото, интерфейс - это всегда вызов. А почему? Человек - дневное животное. Оттенки черного многим не под силу, ввиду естественного ограничения зрения. Плюс, если говорить о фоне, то любая мелкая, но светлая деталь становится видимой, чёткой, назойливой. Там, где подразумевалась тень, она либо исчезает, либо становиться наоборот засветкой. Поэтому тёмная тема полностью должна быть создана с нуля, т.к. меняется концепция. И именно поэтому многим дорого создавать полностью новую тему. А в некоторых случаях, где скорость реакции имеет критическое значение, приходится отказываться от тёмного интерфейса, как от неестественно го для человека.
Когда тех лид с умным видом на конференции рассказывал, как он проверяет форматирование кода на код ревью, а не использует PM, Checkstyle, Sonar для таких проверок, уровень Сбера стал понятен
И это не про справедливость, а элементарную логику и выгоду для бизнеса. Любому новому человеку нужно время для того, чтобы вникнуть в процессы и специфику на новом месте, даже если он занимался тем же на прежнем месте. И в это время бизнес будет только терять. Конечно, я не говорю про те случаи, когда нанимается специалист с большим опытом и лучшей квалификацией. Поэтому бизнесу выгодней развивать собственных сутрудников, а не нанимать со стороны. Но где выгода компании и выгода конкретного ХР манагера и его начальника.
Перестаньте писать, что архитектор может не иметь хорошей технической базы и не быть разработчиком. Он, конечно, может ее не иметь, но это будет плохой архитектор. И таких, к сожалению, развелось хоть пруд пруди!
Смешно было наблюдать на одних переговорах, когда такой "архитектор" по каждому техническому вопросу выбегал из переговорки и звонил кому-то, советовался. Под конец уже сами заказчики смеялись в голос и комментировали.
Архитектор ответственен за выпуск продукта, выбор доступных инструментов и подходов. Если он сам понятия не имеет, с чем работает, то что он построит?
Нужно как в строительстве, чтоб ответственность за продукт была пожизненно, тогда, глядишь, инженеры будут в отрасли, а не случайные люди.
Спасибо за статью со столь нлубоким описанием.
Вы правы, данная ситуация не уникальна и многие с ней сталкиваются.
Вы правы, настройка должна быть включена. Можно еще принудительно проверять dueDate в диаграммах перез заливкой в репозиторий.
В настройках Kafka слушателя уже есть поддержка мультипоточности и максимального количества потоков. Настройка слушателя необходима, т.к. всегда есть аппаратные ограничения.
Нужно блюсти баланс и, вы правы, просто увеличение пула не решает проблемы
А вот здесь, как раз, и кроется основная проблема и основнаое решение - нужно уменьшить количество висящих процессов. Супер база и железо быстрей обработает ваши сотни тысяч процессов, но и их возможности ограничены. Технические решения могут только на время улучшить картину, но не решат логические ошибки.
В одной компании с сотнями тысяч сотрудников была такая же проблема. Казалось, проще простого стартовать на каждого сотрудника экземпляр процесса и дело с концом. Но...
При увеличении количества сотрудником количество процессов будет расти
При завершении и старте нового периода количество процессов может удваиваться
Если нужно передеплоить новую версию процесса, например, нашли ошибку в логике, то получаем тот же массовый эффект.
Сама по себе поддержка сотен тысяч процессов затратное дело.
При анализе процессов оказалось, что уникальных типов процессов с режимами ожидания всего не более 20ти. Простая переделка процессов решила все остальные. Процесс по времени шлет уникальные сообщения на каждого сотрудника и сообщения стартуют процессы с короткими транзакциями.
Основной совет - не смешивать реалтайм и обработку с таймерами в одном процессе.
Более того, техлид сам джун. У меня в одном проекте такой есть, который прикрывается фразой: "Нужно давать больше свободы разработчикам", - т.к. сам не знает ни языка, ни баз, ни техгологий, ни процессов, но поставлен подаваном менеджером сверху.
К сожалению, не стирается никогда, т.к. нет наработанного навыка доводить начатое дело до конца и это вылазит потом в работе постоянно. Конечно, я не сравниваю с теми, кто просто просиживал штаны в вузе, а с теми, кто знает зачем пришел учиться. Без крепкой инженерной базы и прикладных наук все, кто ушел, остаются на том же уровне мышления тупого копи-пасты, зарабатывания денег и нытья, а не создания новых продуктов, направлений и областей. Да, бывают исключения, кто потом наверстывает упущенное (сам знаю пару таких), но их подавляющее меньшинство.
Правильно замечено: "кодовая база без реального владения со временем деградирует". Сколько людей, столько мнений. И даже, если все профессионалы высокого класса, нужен координатор, чтобы привести к единому соглашению и следить, чтобы все придерживались единой линии.
Сейчас стараюсь четко определить владельца кода или сам станавлюсь им. Тогда можно говорить о каком-то порядке или возможности придерживаться плана и поставки в срок.