С законом ома знаком и даже имел когда-то допуски по электробезопасности. Сопротивление человека считается от 500Ом до 100КОм в зависимости от повреждений кожи или ее влажности. На 500ом(для мокрой кожи) на 5в как-раз даст 10мА протекающего тока.
Википедия отличный источник, но нужно внимательно к нему подходить. 100-300мА из википедии это фибрилляционный порог, когда перестает нормально биться сердце. 10мА это порог неотпускающего тока для ребенка, т.е. сердце бьется, но вот руку которой схватился за провод разжать уже не получится. Тут я ошибся, 10мА - это для переменного тока, для постоянного от 50мА, поэтому может показаться, что вроде как 5в безопасны, но есть нюанс.
5В это напряжение между контактами зарядного устройства, но вот между контактами и батареей или лужей разлитой у вас на полу вполне может получиться и 100В и все 220в. Так бывает из-за особенностей конструктива китайских зарядок или просто из-за неисправности. Это может привести к летальным последствиям. Батарейки безопаснее.
Ну и погуглите - "ребенок умер от зарядки телефона". К сожалению, есть прецеденты и достаточно много.
Электрику выкидывать не предлагаю, но среда для ребенка должна быть безопасной, пока он не научится осознанно ей управлять.
Летальный исход и от 5 вольт возможен. Главное ток. А ребенку много не нужно, уже 10мА мышцы спазмирует так, что отпустить провод без помощи не сможет.
Да, вы правы, отсутствие коммуникации и управление по фантазиям - это боль индустрии. Но это тема для отдельной статьи. В этой удалось коснуться только краем, в заключении.
Спасибо за комментарий. Герцберг это классика на ряду с Маслоу, но это не единственные теории разобранные в статье, посмотрите дальше по тексту. Так же я буду благодарен если вы порекомендуете, что из более актуального стоит подсветить или буду рад почитать вашу статью по этой теме.
Спасибо за ответ. Это не перевод и не генерация. Это русскоязычная терминология в данной области. Просто наберите в поиске "Теория мотивации Герцберга".
Нужно просто дать модели шанс. :) она делает то, что ее просят, наилучшим возможным образом. Если в промт добавить - "если у тебя нет необходимой информации или ты не можешь ответить на вопрос - ответь - я не могу вам помочь" - многие модели становятся честнее
Спасибо за вопрос. Самое правильное и простое - поговорить с руководителем. Объяснить что хочешь расти в тимлида. Лучше сразу обсудить, не только название должности, но и что именно и почему хочется делать. Это важно, так как тимлид в конкретной компании это просто шильдик в резюме, важно какие обязанности за этим словом стоят. Так же важно спросить, на сколько ты соответствуешь желаемой должности с точки зрения руководителя и если чего-то не хватает, то совместно составить план развития, что бы улучшить недостающие навыки.
Позиция действительно часто возникает сумбурно и если если у вас она закрывается случайным человеком, то ваш руководитель будет только рад такому разговору. У него появится кадровый резерв в виде вас, особенно если вы действительно этого хотите и готовы потратить время и силы на свое развитие. В такой ситуации возможно вы получите свою первую команду даже без ухода предыдущего тимлида. Компании растут и в них появляются новые позиции даже без увольнений.
В том то и проблема, что стандарта названий должностей нет. Но тот вариант, который вы упоминаете это скорее техлид. Обычно в такой структуре управлением командой занимается руководитель подразделения. Управлением в рамках проекта ПМ. Он отвечает за технические аспекты и коммуникацию, но не управляет командой, а только влияет на нее.
Ну а разделение обязанностей - оно меняется от проекта к проекту. В продвинутых компаниях часто есть стандартное разделение, зафиксированное в виде матрице RACI и обычно компания ему следует, но даже в этом случае от проекта к проекту в ней могут быть нюансы.
Это не совсем так. Проектный менеджер и тимлид это роли. Они могут пересекаться, но чаще нет. Так же нужно разделять функциональное и проектное управление. Тимлидом/непосредственным руководителем для тимлида в разработке обычно является руководитель подразделения к которому он относится (Lead Backend, CTO и т.д.)
ПМ — это руководитель проекта, временная роль, существующая с момента инициации проекта до его завершения. Его зона ответственности — это проект, а не команда. Он управляет сроками, качеством, скоупом проекта, рисками, может запрашивать ресурсы, но обычно не может их распределять единолично. Он не отвечает за найм тимлида, обычно не занимается обучением (так как у него другой набор скиллов), он не отвечает за карьерный и профессиональный рост команды и тимлида, работа с мотивацией у него ограничена и т. д. Часто в его ведении проектные бонусы, но основную часть зарплаты он не определяет.
Существуют варианты, когда ПМ выполняет роль тимлида. Это называется проектной оргструктурой (не путать с проектной организацией работы). Она в основном характерна для консалтинговых компаний, в которых ПМ собирает команду контракторов под проект.
В компаниях по разработке ПО обычно матричная оргструктура. Тимлид разработки относится к ветке производства, а ПМ — к ветке бизнеса. В рамках проекта ответственность между ПМ и тимлидом разделяется. Да, по многим аспектам ПМ ставит цели тимлиду и отвечает за результат, но всё же это параллельные должности, а не функциональное подчинение. По завершению проекта они расходятся, тимлид остается с командой. ПМ идет руководить другим проектом.
В небольших компаниях, особенно в слабой матричной оргструктуре, на проекте может вообще не быть выделенного тимлида. Руководством командой (выполнением роли тимлида) занимается руководитель подразделения.
При этом, в ветке ПМов есть свои тимлиды, обычно это CPO или Lead PM. У них есть подчиненные.
Спасибо за комментарий. Транзакции в kafka немного отличаются от транзакций в БД и они не входят в скоуп данной статьи, но возможно я глубже раскрою эту тему в следующей. Транзакции отлично помогают реализовать сценарий все-или-ничего и exactly-once при отправке сообщений, но при получении все немного сложнее. Со стороны Consumer, у Kafka, нет семантики гарантирующей exactly-once. Транзакционный коммит в consumer это ручной вызов commit с параметром указывающим на смещение. Если приложение упадет до того, как commit будет вызван, оно повторно получит то же самое сообщение.
Да, большое спасибо за замечание. Потерял часть текста. Исправил. В случае с автокоммитами возможны 2 негативных кейса - получение дубликатов и потеря необработанных сообщений, если автокоммит слишком частый, а сообщения обрабатываются долго. Ручной коммит может снижзить вероятность первого (в зависимости от сценария использования) и устраняет второй
Да, использование Кафки действительно не всегда оправданно. У каждой технологии есть своя область применения и есть внешние факторы влияющие на выбор. Факторы могут быть как технические так и организационные. Цель данной статьи помочь разобраться тем, кто планирует использовать именно Кафку.
На самом деле не очень минимален. Если диски от отдного производитеоя и одной серии, есть высокая вероятность, что выйдут из строя практически одновременно. Просто потому, что идентичное оборудование, идентичные условия эксплуатации, если на линии был брак, он тоже будет с высокой вероятностью в обоих устройствах. Был замечательный прецедент, когда у одного именитого производителя была проблема с герметизацией ввода кабеля и диски сыпались массово при примерно одинаковом сроке использования.
>Потому что выделяли норматив на брак/бой, и если сдать дом без списания плит на брак, то дадут переходящий вымпел, но норматив на следующий дом урежут, и в случае реального брака дом вовремя не сдать, вот и зарывали социалистическую собственность в годном виде в землю-матушку.
Оригинальный подход. Интересно, в каком регионе это происходило? Я видел немного другую ситуацию при социализме. На объект выделялось ровно необходимое количество материалов. В случае возникновения брака/боя объект достраивали за счет материалов выделенных на следующий объект. Благо строительство было типовое. Но это приводило к тому, что в итоге появлялся недострой, на который не хватило материала и который стоял несколько лет заброшенным.
С законом ома знаком и даже имел когда-то допуски по электробезопасности.
Сопротивление человека считается от 500Ом до 100КОм в зависимости от повреждений кожи или ее влажности.
На 500ом(для мокрой кожи) на 5в как-раз даст 10мА протекающего тока.
Википедия отличный источник, но нужно внимательно к нему подходить. 100-300мА из википедии это фибрилляционный порог, когда перестает нормально биться сердце. 10мА это порог неотпускающего тока для ребенка, т.е. сердце бьется, но вот руку которой схватился за провод разжать уже не получится.
Тут я ошибся, 10мА - это для переменного тока, для постоянного от 50мА, поэтому может показаться, что вроде как 5в безопасны, но есть нюанс.
5В это напряжение между контактами зарядного устройства, но вот между контактами и батареей или лужей разлитой у вас на полу вполне может получиться и 100В и все 220в.
Так бывает из-за особенностей конструктива китайских зарядок или просто из-за неисправности.
Это может привести к летальным последствиям.
Батарейки безопаснее.
Ну и погуглите - "ребенок умер от зарядки телефона". К сожалению, есть прецеденты и достаточно много.
Электрику выкидывать не предлагаю, но среда для ребенка должна быть безопасной, пока он не научится осознанно ей управлять.
Летальный исход и от 5 вольт возможен. Главное ток. А ребенку много не нужно, уже 10мА мышцы спазмирует так, что отпустить провод без помощи не сможет.
Да, вы правы, отсутствие коммуникации и управление по фантазиям - это боль индустрии. Но это тема для отдельной статьи. В этой удалось коснуться только краем, в заключении.
Спасибо за комментарий.
Герцберг это классика на ряду с Маслоу, но это не единственные теории разобранные в статье, посмотрите дальше по тексту.
Так же я буду благодарен если вы порекомендуете, что из более актуального стоит подсветить или буду рад почитать вашу статью по этой теме.
Спасибо.
Статья именно об этом. У каждого своя мотивация.
Кстати, рекомендую поискать статью https://huntflow.media/povyshenie-vovlechennosti/ - возможно это ваша модель.
Спасибо за ответ.
Это не перевод и не генерация. Это русскоязычная терминология в данной области. Просто наберите в поиске "Теория мотивации Герцберга".
Нужно просто дать модели шанс. :) она делает то, что ее просят, наилучшим возможным образом. Если в промт добавить - "если у тебя нет необходимой информации или ты не можешь ответить на вопрос - ответь - я не могу вам помочь" - многие модели становятся честнее
Спасибо за вопрос. Самое правильное и простое - поговорить с руководителем. Объяснить что хочешь расти в тимлида. Лучше сразу обсудить, не только название должности, но и что именно и почему хочется делать. Это важно, так как тимлид в конкретной компании это просто шильдик в резюме, важно какие обязанности за этим словом стоят. Так же важно спросить, на сколько ты соответствуешь желаемой должности с точки зрения руководителя и если чего-то не хватает, то совместно составить план развития, что бы улучшить недостающие навыки.
Позиция действительно часто возникает сумбурно и если если у вас она закрывается случайным человеком, то ваш руководитель будет только рад такому разговору. У него появится кадровый резерв в виде вас, особенно если вы действительно этого хотите и готовы потратить время и силы на свое развитие.
В такой ситуации возможно вы получите свою первую команду даже без ухода предыдущего тимлида. Компании растут и в них появляются новые позиции даже без увольнений.
В том то и проблема, что стандарта названий должностей нет. Но тот вариант, который вы упоминаете это скорее техлид.
Обычно в такой структуре управлением командой занимается руководитель подразделения. Управлением в рамках проекта ПМ. Он отвечает за технические аспекты и коммуникацию, но не управляет командой, а только влияет на нее.
Ну а разделение обязанностей - оно меняется от проекта к проекту. В продвинутых компаниях часто есть стандартное разделение, зафиксированное в виде матрице RACI и обычно компания ему следует, но даже в этом случае от проекта к проекту в ней могут быть нюансы.
Возможно отраслевая специфика. У меня ситуация обратная. За те же 25 лет видел всего 2 таких случая, но они были очень специфические.
Привет.
Это не совсем так.
Проектный менеджер и тимлид это роли. Они могут пересекаться, но чаще нет.
Так же нужно разделять функциональное и проектное управление.
Тимлидом/непосредственным руководителем для тимлида в разработке обычно является руководитель подразделения к которому он относится (Lead Backend, CTO и т.д.)
ПМ — это руководитель проекта, временная роль, существующая с момента инициации проекта до его завершения. Его зона ответственности — это проект, а не команда.
Он управляет сроками, качеством, скоупом проекта, рисками, может запрашивать ресурсы, но обычно не может их распределять единолично.
Он не отвечает за найм тимлида, обычно не занимается обучением (так как у него другой набор скиллов), он не отвечает за карьерный и профессиональный рост команды и тимлида, работа с мотивацией у него ограничена и т. д.
Часто в его ведении проектные бонусы, но основную часть зарплаты он не определяет.
Существуют варианты, когда ПМ выполняет роль тимлида. Это называется проектной оргструктурой (не путать с проектной организацией работы).
Она в основном характерна для консалтинговых компаний, в которых ПМ собирает команду контракторов под проект.
В компаниях по разработке ПО обычно матричная оргструктура. Тимлид разработки относится к ветке производства, а ПМ — к ветке бизнеса.
В рамках проекта ответственность между ПМ и тимлидом разделяется.
Да, по многим аспектам ПМ ставит цели тимлиду и отвечает за результат, но всё же это параллельные должности, а не функциональное подчинение. По завершению проекта они расходятся, тимлид остается с командой. ПМ идет руководить другим проектом.
В небольших компаниях, особенно в слабой матричной оргструктуре, на проекте может вообще не быть выделенного тимлида.
Руководством командой (выполнением роли тимлида) занимается руководитель подразделения.
При этом, в ветке ПМов есть свои тимлиды, обычно это CPO или Lead PM. У них есть подчиненные.
Спасибо!
Спасибо за комментарий.
Транзакции в kafka немного отличаются от транзакций в БД и они не входят в скоуп данной статьи, но возможно я глубже раскрою эту тему в следующей.
Транзакции отлично помогают реализовать сценарий все-или-ничего и exactly-once при отправке сообщений, но при получении все немного сложнее.
Со стороны Consumer, у Kafka, нет семантики гарантирующей exactly-once.
Транзакционный коммит в consumer это ручной вызов commit с параметром указывающим на смещение.
Если приложение упадет до того, как commit будет вызван, оно повторно получит то же самое сообщение.
Да, большое спасибо за замечание. Потерял часть текста. Исправил. В случае с автокоммитами возможны 2 негативных кейса - получение дубликатов и потеря необработанных сообщений, если автокоммит слишком частый, а сообщения обрабатываются долго. Ручной коммит может снижзить вероятность первого (в зависимости от сценария использования) и устраняет второй
Да, использование Кафки действительно не всегда оправданно. У каждой технологии есть своя область применения и есть внешние факторы влияющие на выбор. Факторы могут быть как технические так и организационные. Цель данной статьи помочь разобраться тем, кто планирует использовать именно Кафку.
Кости грызть даете?
У зверюшки зубы чешутся.
А можете дать пример из жизни, где этот подход полезен и удобнее, чем создание отдельных интерфейсов?
У меня на 1 тб. Был.
На самом деле не очень минимален. Если диски от отдного производитеоя и одной серии, есть высокая вероятность, что выйдут из строя практически одновременно. Просто потому, что идентичное оборудование, идентичные условия эксплуатации, если на линии был брак, он тоже будет с высокой вероятностью в обоих устройствах. Был замечательный прецедент, когда у одного именитого производителя была проблема с герметизацией ввода кабеля и диски сыпались массово при примерно одинаковом сроке использования.
>Потому что выделяли норматив на брак/бой, и если сдать дом без списания плит на брак, то дадут переходящий вымпел, но норматив на следующий дом урежут, и в случае реального брака дом вовремя не сдать, вот и зарывали социалистическую собственность в годном виде в землю-матушку.
Оригинальный подход. Интересно, в каком регионе это происходило?
Я видел немного другую ситуацию при социализме.
На объект выделялось ровно необходимое количество материалов. В случае возникновения брака/боя объект достраивали за счет материалов выделенных на следующий объект. Благо строительство было типовое. Но это приводило к тому, что в итоге появлялся недострой, на который не хватило материала и который стоял несколько лет заброшенным.