Через токи утечки блока питания (они малые, но они есть) у корпуса компа появляется потенциал.
Через токи утечки прибора на его корпусе тоже появляется потенциал.
Когда прибор подключается к компу – их корпуса соединяются через провод заземления, который может идти внутри кабеля, или может быть соединен с защитной оплеткой кабеля.
Между корпусами начинает течь ток, и этот ток частично может пойти на материнскую и другие плат внутри компа. Этого может хватить чтобы сжечь платы.
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 раз дороже. Картридж закончился - беру из ящика запасной, и тут же делаю заказ следующего.
Ах да, раз в год надо лезть рукой куда-то вглубь принтера чтобы нажать на кнопку сброса счетчика страниц. А то эта немецкая техника отказывается принимать китайские расходники. Видимо, исключительно из-за заботы обо мне. Это бесит, но придает уверенности в том, что я все делаю правильно.
Вы в первой же статье всерьез даете советы что и как писать на Хабр, не имея в этом никакого опыта.
С личным брендом на Хабре у вас не задалось, сами видите. А если вы не можете построить свой бренд, как вы можете давать советы другим?
Без обид, но вся статья звучит как "Fake it till you make it"
Через токи утечки блока питания (они малые, но они есть) у корпуса компа появляется потенциал.
Через токи утечки прибора на его корпусе тоже появляется потенциал.
Когда прибор подключается к компу – их корпуса соединяются через провод заземления, который может идти внутри кабеля, или может быть соединен с защитной оплеткой кабеля.
Между корпусами начинает течь ток, и этот ток частично может пойти на материнскую и другие плат внутри компа. Этого может хватить чтобы сжечь платы.
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 раз дороже. Картридж закончился - беру из ящика запасной, и тут же делаю заказ следующего.
Ах да, раз в год надо лезть рукой куда-то вглубь принтера чтобы нажать на кнопку сброса счетчика страниц. А то эта немецкая техника отказывается принимать китайские расходники. Видимо, исключительно из-за заботы обо мне. Это бесит, но придает уверенности в том, что я все делаю правильно.
Т-сссс!
Вообще-то блочат, но у меня почему-то досуп остался. И я все забываю дойти до СБ чтобы об этом доложить.