Через токи утечки блока питания (они малые, но они есть) у корпуса компа появляется потенциал.
Через токи утечки прибора на его корпусе тоже появляется потенциал.
Когда прибор подключается к компу – их корпуса соединяются через провод заземления, который может идти внутри кабеля, или может быть соединен с защитной оплеткой кабеля.
Между корпусами начинает течь ток, и этот ток частично может пойти на материнскую и другие плат внутри компа. Этого может хватить чтобы сжечь платы.
PS. Смысл такой. Кто разбирается в схемотехнике, поправьте, если я ошибся.
а то у меня в доме розетки от 3х фаз и ничего не горит
Постарайтесь не подключать в эти розетки связанные приборы, например системный блок и монитор.
Даже если приборы не связаны, нельзя одновременно к ним прикасаться. Иначе проводом, выравнивающим потенциалы их корпусов, станете вы.
А как исправить эту ошибку? Как потратить ещё меньше денег на производство статьи?
У меня есть два ответа. Хороший и плохой. Начну с плохого:
Извините, конечно, а почему меня как читателя должно волновать желание компании экономить на статьях? Нет денег - не пишите. Другие напишут.
Теперь хороший.
А вы заинтересуйте своих сотрудников нематериально, чтобы они добровольно и с песней писали статьи. Я вот (не хвастаюсь, просто излагаю факты) пишу совершенно бесплатно, потому что мне по кайфу.
Человек, которого наймут на эту должность, будет каждую неделю выпускать 8 газетных полос с текстами нейтросетки
Лучше одна добротная статья чем 8 никудышных. В том числе и экономически.
Был такой забавный мультик, когда жадный богач захотел семь шапок из одного куска
На практике работодатель зарабатывает все то, что не доплатил работнику. Поэтому в ход идет все что угодно, чтобы увеличить разницу между прибылью и затратами.
А еще на практике работодатель это не человек, это организация с своими не всегда логичными правилами. Например, бюджет на найм - один, а на повышения - другой, и сильно ограниченный. И начальнику бывает проще не дать повышения, человек уйдет, а потом нанять на еще бОльшие деньги с рынка. Потому что повышение сотрудника ему не согласуют. А найм по причине замены - другая история.
10 разработчиков, несколько проектов, 20% времени на управление, остальное — код, пресейлы, обучение и личные цели. Звучит как типичный день teamlead’а, правда?
Нет, не звучит.
Извините, но так просто не бывает. С 10-ю разработчиками времени писать код не будет. Максимум- ревью, и то не всего. Времени на обучение людей тоже не хватит. Учитывая что вам еще пресейлами надо заниматься.
20% на управление? На пообщаться с разрабами, со стейками, чего-то там запланировать, задачек там нарезать, поставить, проконтролировать выполнение. Так не бывает. 70% на управление - норм. 50% - ну.... если у вас есть пара синьоров на которых вы делегируете половину своей работы. И скорее всего это не ваш случай, т.к. вы описываете себя как единую входную точку.
Мне нравится принцип "ты мне, я - тебе". Пришлось переработать - ок. Но потом если днем надо куда-то отойти - то я так и делаю. И ни у кого никаких вопросов.
Обычно мне удается договориться. Хотя не всегда.
Была у меня недавно одна продакт, которая закатила истерику по поводу того, что в 12-30 я не был на рабочем месте. Я эскалировал выше, и сказал: хотите формализма? ОК. Буду работать строго 9-18 с перерывом в 13. Но учтите, что теперь продукт не будет обновляться в принципе, потому что в релизное окно (которое согласовано только для нерабочих часов) я работать не буду. Ну или откатываем ситуацию, забываем этот скандал, и все будет как раньше, неформально, с гибкими рабочими часами.
Однажды он даже отчитал меня за «слишком долгий» обеденный перерыв, который длился 62 минуты вместо положенных 60
При малейшем опоздании (даже на 2 минуты) он писал мне сообщение: «Где ты? Почему не на работе?»
Может существовать в одной вселенной с этим:
Я всё чаще стал задерживаться допоздна, работать по выходным, но результат всё равно не устраивал Александра
Если у нас гибкий график, и приходится сидеть по вечерам, то та же логика касается, скажем, обедов.
Если обед четко 60 минут и ни минутой больше, значит, 18:01 комп гастится, на рабочие телефонные звонки и на сообщения в мессенджере ответ будет завтра не ранее 09:00
Если уж решил колоться но продолжать есть кактус, то в эту корпоративную игру можно играть вдвоем.
Обновил статью, приведя конкретный пример из жизни.
Мой позиция в том, что массовое АйТи - это не про соцсети. В соцсетях все очень классно работает с микро-сервисами и микро-фронтами. Классно, но абсолютно бесполезно для 99%+ разработчиков. Потому что 99% разработчиков в РФ в аджайл-командах такими вещами не занимаются. Хорошо это или плохо, они пишут что-то под локальные потребности бизнеса. И это что-то выполняет конкретную бизнес-задачу. Оно является либо частью системы, либо очень маленькой системой. В обоих случаях еще мельче дробить это "что-то" редко бывает целесообразно. Нагрузка на это "что-то" маленькая, людей выделяют мало.
А канонические примеры (тот же Амазон, или запрещенный Фейсбук) - это десятки тыщ инженеров. Там только над управлением профиля работают такие толпы, что их приходится делить на отделы и выдавать им крохотный кусочек функционала.
Прощу прощения, возможно, у меня плохо получается выразить простую мысль:
Многие смотрят на подходы тех же соцсетей или Нетфликса, и пытаются применить у себя на работе. Например, пытаются сделать какой-то генератор отчетов в виде десятка сервисов. Задача была на три месяца на одного разработчика и половину тестировщика, а превращается на три месяца на двух разработчиков, тестировщика и девопса.
Я так и не понял, где в статье описывается что всё-таки такое нано сервис
Исправляюсь!
Дано: написать сервис, который берет из бэк-офиса данные о продажах и отправляет операторам электронных касс. Операторы печатают электронные чеки. Пример оператора: Атол (не реклама)
Из-за очень настойчивого мнения руководителя (на прошлой работе) принято решение писать на "микро-сервисах". Микро-сервис "Ядра", преобразующий данные бэк-офиса в нужный формат и балансирующий нагрузку между микро-сервисами адаптеров к операторам.
Теория:
Модно и молодежно. Это же "микро-сервисы"
Максимальная гибкость: можно подключать и отключать операторов без даунтайма ядра.
Масштабируемость
Разные сервисы можно раскидать по разным разрабам
Практика:
Х2 трудозатрат на реализацию. Потому что оверхед на взаимодействие между сервисами, трейсинг и т.д.
Х3 затрат на поддержку. Потому что вместо одного "монолита" получили ряд нано-сервисов. С алертингом, мониторингом, трейсингом, логами. И разбором инцидентов от бухгалтерии вида: "вы опять чек пролюбили"
Полное отсутствие необходимости горизонтального масштабирования. В пике оно кушало пару сотен мб оперативки и 10% ядра процессора. Узкое место - скорость онлайн касс, а не сервисов.
Все заняло у меня 5 недель на разработку и 2 недели на ОПЭ. Привлекать команду для такого микро-проекта избыточно. Более того, в виде одного сервиса реализация была бы в 1.5 раза быстрее.
Вывод: получились нано-сервисы с завышенной стоимостью владения.
Не надо так делать.
Правильно было бы сделать в виде одного микро-сервиса, со своим доменом: печать чеков.
Из-за таких вот определений мир наполнили нано-сервисы: рой сильно-связанных сервисов, которые никак не ложатся ни на домен, ни на орг. структуру.
Приходишь в компанию, а там 30 команд пилят 1500 сервисов. Да еще гордятся этим. Чтобы хоть как-то начать в этом ориентироваться, надо потратить полгода и километр нервов.
Мне удобна вещь которая принадлежит мне. За скромные деньги (+- чашка кофе) покупаю китайский картридж, закрывающий потребности семьи в печати на полгода. Не совсем понимаю, зачем платить в 6 раз дороже. Картридж закончился - беру из ящика запасной, и тут же делаю заказ следующего.
Ах да, раз в год надо лезть рукой куда-то вглубь принтера чтобы нажать на кнопку сброса счетчика страниц. А то эта немецкая техника отказывается принимать китайские расходники. Видимо, исключительно из-за заботы обо мне. Это бесит, но придает уверенности в том, что я все делаю правильно.
Ну не скажите, регулярно пользуюсь. Перекинуть какие-то объемы между двумя компами, один из который - корпоративный. С кучей ограничений, в т.ч. на скачивания из облака.
Через токи утечки блока питания (они малые, но они есть) у корпуса компа появляется потенциал.
Через токи утечки прибора на его корпусе тоже появляется потенциал.
Когда прибор подключается к компу – их корпуса соединяются через провод заземления, который может идти внутри кабеля, или может быть соединен с защитной оплеткой кабеля.
Между корпусами начинает течь ток, и этот ток частично может пойти на материнскую и другие плат внутри компа. Этого может хватить чтобы сжечь платы.
PS. Смысл такой. Кто разбирается в схемотехнике, поправьте, если я ошибся.
Постарайтесь не подключать в эти розетки связанные приборы, например системный блок и монитор.
Даже если приборы не связаны, нельзя одновременно к ним прикасаться. Иначе проводом, выравнивающим потенциалы их корпусов, станете вы.
У меня есть два ответа. Хороший и плохой. Начну с плохого:
Извините, конечно, а почему меня как читателя должно волновать желание компании экономить на статьях? Нет денег - не пишите. Другие напишут.
Теперь хороший.
А вы заинтересуйте своих сотрудников нематериально, чтобы они добровольно и с песней писали статьи. Я вот (не хвастаюсь, просто излагаю факты) пишу совершенно бесплатно, потому что мне по кайфу.
Лучше одна добротная статья чем 8 никудышных. В том числе и экономически.
Был такой забавный мультик, когда жадный богач захотел семь шапок из одного куска
Пора НЛО добавить еще один пункт "Сгенерировано нейросетью" в окошко
"Укажите причину минуса, чтобы автор поработал над ошибками"
В теории все очень красиво.
На практике работодатель зарабатывает все то, что не доплатил работнику. Поэтому в ход идет все что угодно, чтобы увеличить разницу между прибылью и затратами.
А еще на практике работодатель это не человек, это организация с своими не всегда логичными правилами. Например, бюджет на найм - один, а на повышения - другой, и сильно ограниченный. И начальнику бывает проще не дать повышения, человек уйдет, а потом нанять на еще бОльшие деньги с рынка. Потому что повышение сотрудника ему не согласуют. А найм по причине замены - другая история.
А чем вас эта не устраивает: "Cracking the coding interview"?
Очевидно же! Будет другой интервьюер.
Нет, не звучит.
Извините, но так просто не бывает. С 10-ю разработчиками времени писать код не будет. Максимум- ревью, и то не всего. Времени на обучение людей тоже не хватит. Учитывая что вам еще пресейлами надо заниматься.
20% на управление? На пообщаться с разрабами, со стейками, чего-то там запланировать, задачек там нарезать, поставить, проконтролировать выполнение. Так не бывает. 70% на управление - норм. 50% - ну.... если у вас есть пара синьоров на которых вы делегируете половину своей работы. И скорее всего это не ваш случай, т.к. вы описываете себя как единую входную точку.
А вот если взглянуть на восточную рекламу (корейская, японская , китайская) - там все наоборот.
Так что эти выводы неверны как минимум для половины населения Земли
Аналогично, коллега )
Нас развели по классике:
Ну вот, кто везет - на том и едут.
Мне нравится принцип "ты мне, я - тебе". Пришлось переработать - ок. Но потом если днем надо куда-то отойти - то я так и делаю. И ни у кого никаких вопросов.
Обычно мне удается договориться. Хотя не всегда.
Была у меня недавно одна продакт, которая закатила истерику по поводу того, что в 12-30 я не был на рабочем месте. Я эскалировал выше, и сказал: хотите формализма? ОК. Буду работать строго 9-18 с перерывом в 13. Но учтите, что теперь продукт не будет обновляться в принципе, потому что в релизное окно (которое согласовано только для нерабочих часов) я работать не буду. Ну или откатываем ситуацию, забываем этот скандал, и все будет как раньше, неформально, с гибкими рабочими часами.
Начальство выбрало второй вариант ))
Непонятно, как вот это:
Может существовать в одной вселенной с этим:
Если у нас гибкий график, и приходится сидеть по вечерам, то та же логика касается, скажем, обедов.
Если обед четко 60 минут и ни минутой больше, значит, 18:01 комп гастится, на рабочие телефонные звонки и на сообщения в мессенджере ответ будет завтра не ранее 09:00
Если уж решил колоться но продолжать есть кактус, то в эту корпоративную игру можно играть вдвоем.
Кажется, в начале статьи нет определения кто же такой тех лид и чем он конкретно занимается.
А раз нет границ зон ответственности, то и возникают казусы вроде прибегающих дизайнеров.
Ничего кроме правды - это тоже может быть сильный ход.
Вот как я первый раз устроился тимлидом:
На обесе рассказал, что работал синьором, ставил задачи двум коллегам, контролировал, собирал результаты их труда вместе, релизил.
Интервьюер спосил: а, так ты управлял?
Я говорю не, у них же другой начальник. Я просто синьор, я отвечал за кусок системы.
Интервьюер: а, так ты еще и скромный. А у нас тут позиция лида тоже имеется. Хочешь?
Обновил статью, приведя конкретный пример из жизни.
Мой позиция в том, что массовое АйТи - это не про соцсети. В соцсетях все очень классно работает с микро-сервисами и микро-фронтами. Классно, но абсолютно бесполезно для 99%+ разработчиков. Потому что 99% разработчиков в РФ в аджайл-командах такими вещами не занимаются. Хорошо это или плохо, они пишут что-то под локальные потребности бизнеса. И это что-то выполняет конкретную бизнес-задачу. Оно является либо частью системы, либо очень маленькой системой. В обоих случаях еще мельче дробить это "что-то" редко бывает целесообразно. Нагрузка на это "что-то" маленькая, людей выделяют мало.
А канонические примеры (тот же Амазон, или запрещенный Фейсбук) - это десятки тыщ инженеров. Там только над управлением профиля работают такие толпы, что их приходится делить на отделы и выдавать им крохотный кусочек функционала.
Прощу прощения, возможно, у меня плохо получается выразить простую мысль:
Многие смотрят на подходы тех же соцсетей или Нетфликса, и пытаются применить у себя на работе. Например, пытаются сделать какой-то генератор отчетов в виде десятка сервисов. Задача была на три месяца на одного разработчика и половину тестировщика, а превращается на три месяца на двух разработчиков, тестировщика и девопса.
Исправляюсь!
Дано: написать сервис, который берет из бэк-офиса данные о продажах и отправляет операторам электронных касс. Операторы печатают электронные чеки. Пример оператора: Атол (не реклама)
Из-за очень настойчивого мнения руководителя (на прошлой работе) принято решение писать на "микро-сервисах". Микро-сервис "Ядра", преобразующий данные бэк-офиса в нужный формат и балансирующий нагрузку между микро-сервисами адаптеров к операторам.
Теория:
Модно и молодежно. Это же "микро-сервисы"
Максимальная гибкость: можно подключать и отключать операторов без даунтайма ядра.
Масштабируемость
Разные сервисы можно раскидать по разным разрабам
Практика:
Х2 трудозатрат на реализацию. Потому что оверхед на взаимодействие между сервисами, трейсинг и т.д.
Х3 затрат на поддержку. Потому что вместо одного "монолита" получили ряд нано-сервисов. С алертингом, мониторингом, трейсингом, логами. И разбором инцидентов от бухгалтерии вида: "вы опять чек пролюбили"
Полное отсутствие необходимости горизонтального масштабирования. В пике оно кушало пару сотен мб оперативки и 10% ядра процессора. Узкое место - скорость онлайн касс, а не сервисов.
Все заняло у меня 5 недель на разработку и 2 недели на ОПЭ. Привлекать команду для такого микро-проекта избыточно. Более того, в виде одного сервиса реализация была бы в 1.5 раза быстрее.
Вывод: получились нано-сервисы с завышенной стоимостью владения.
Не надо так делать.
Правильно было бы сделать в виде одного микро-сервиса, со своим доменом: печать чеков.
Мне этот жанр тоже нравится.
Дальше обычно следует: "что вы знаете про нашу компанию?", "кем вы себя видите [в нашей компании] через 5 лет?"
Из-за таких вот определений мир наполнили нано-сервисы: рой сильно-связанных сервисов, которые никак не ложатся ни на домен, ни на орг. структуру.
Приходишь в компанию, а там 30 команд пилят 1500 сервисов. Да еще гордятся этим. Чтобы хоть как-то начать в этом ориентироваться, надо потратить полгода и километр нервов.
Мне удобна вещь которая принадлежит мне. За скромные деньги (+- чашка кофе) покупаю китайский картридж, закрывающий потребности семьи в печати на полгода. Не совсем понимаю, зачем платить в 6 раз дороже. Картридж закончился - беру из ящика запасной, и тут же делаю заказ следующего.
Ах да, раз в год надо лезть рукой куда-то вглубь принтера чтобы нажать на кнопку сброса счетчика страниц. А то эта немецкая техника отказывается принимать китайские расходники. Видимо, исключительно из-за заботы обо мне. Это бесит, но придает уверенности в том, что я все делаю правильно.
Т-сссс!
Вообще-то блочат, но у меня почему-то досуп остался. И я все забываю дойти до СБ чтобы об этом доложить.
Ну не скажите, регулярно пользуюсь. Перекинуть какие-то объемы между двумя компами, один из который - корпоративный. С кучей ограничений, в т.ч. на скачивания из облака.