Среди этих двух вариантов всё зависит от того, как принято в рамках проекта, т. к. они эквивалентны с точки зрения Си.
Аналогично с обработчиком завершения.
Глобальные переменные в заголовочном файле — это бессмысленная и крайне плохая практика. Такой файл никуда больше не подключишь, т. к. будет повторное создание переменных. Крайний случай — extern, но лучше писать полностью реентерабельные решения без использования глобальных переменных.
Форматирование тоже выбрано не очень удачным. Рекомендую везде и всегда ставить фигурные скобки, это повышает единообразие кода, соответственно, и читабельность.
Работа со строками тоже не является качественной. Как минимум в таких случаях делают PATH_MAX: char* result=(char*)calloc(1024,sizeof(char));
Но в таком случае обходятся обычно стековым массивом, тут вообще нет смысла выделять память, т. к. алгоритм не предполагает выполнения realloc() в случае нехватки выделенной памяти.
Просмотрел бегло, если интересно, могут отрецензировать более подробно.
вот тут не вижу взаимосвязи с моно- или полирепозиторием, мы в своем монорепозитории собираем отдельные пакеты для каждого микросервиса под разные платформы, работало и на maven, работает и на bazel
К сожалению Java хоть и знаю, но в продакшене пока ещё не использую (равно как и монорепозитории, которые с самого начала решил не делать), поэтому мне сложно в этом контексте что-либо оценивать.
Идея, которую я пытался донести в том, что каждый подпроект описывается отдельно и подключается там, где это требуется как подмодуль. При этом сам подпроект обрабатывается Gitlab (CI/CD) как самостоятельный проект, который не знает о существовании чего-либо ещё. При этом для каждого проекта создаётся шаблонный yaml-файл для CI/CD в котором по сути меняется лишь название проекта. А сама сборка осуществляется с помощью ещё одного универсального подмодуля, который подключается к каждому проекту. А уже этот подмодуль берёт из проекта файл конфигурации под каждую платформу для текущего проекта.
В результате любой разработчик может быстро склонировать всего лишь один репозиторий (с рекурсивными зависимостями), перейти на любой коммит и собрать пакет, например, для тестов. Или тесты прогнать, дописав новый. Система сборки в этом случае будет самодостаточной.
Это правда, что в проекте из 2-3 человек не нужно несколько репозиториев. Это просто добавить слишком много накладных расходов.
Это зависит не от количества людей, а от сложности проекта.
Одно из преимуществ, которое мне нравится — подмодули заставляют тебя так декомпозировать код, что ты не можешь сделать проекты A и B взаимозависимыми (если всё правильно организовано). А если случайно так получилось, — это требуется исправить, а результат гарантированно можно проверить, просто собрав эти два подмодуля по-отдельности.
Ещё одно преимещуство — это пакетирование. CI/CD автоматически собирает каждый проект, отдельно его тестирует и пакетирует, например, в свой deb- или rpm-пакет под заданные платформы. Но тут сложнее, т. к. требуется автоматизировать зависимую сборку проектов. Зато не требуются такие надстройки как над монорепозиторием.
Ещё одно преимущество — можно делать глобальный рефакторинг не по всему проекту сразу, а частями через подмодули, таким образом распределив задачу по разным людям. При этом нигде ничего не ломается.
Статья описывает большую часть мелких компаний, которые в конечном итоге не выживают, либо не развиваются вообще.
А умный джуниор хуже всего себя показывает в тех случаях, когда есть ведущий программист, и он один на всех. Если джуниор будет прислушиваться у более опытных и может учиться на своих ошибках, то умный джуниор будет придумывать себе всё новые и новые проблемы, особенно если давить по срокам. С одной стороны учится быстрее, с другой результат в плане соотношения производительность/качества лучше не становится в течение очень длительного времени. Зато потом выходит неплохой профессионал в будущем.
Одно могу сказать, — из таких вот компаний выходят потом хорошие опытные программисты. Правда участь компании остаётся печальной — тяжело поддерживаемый продукт с множеством ошибок, который невозможно развивать.
Радует что Китай не парится по этому поводу. Они скорей всего и толкнут планету вперёд, в этой сфере. А как запахнет упущенной прибылью, там и западный мир подтянется.
Планету толкнут вперёд, а сами тихонько Луну заселят. У них и по космической программе всё по нарастающей идёт.
Я, видимо, Вас не понял, но в физике принято, что ток течёт от плюса к минусу (электроны, соответственно, по историческим причинам — наоборот). Ноль — не есть минус, на нём потенциал равен нулю (по сути — заземление). Напряжение есть разница потенциалов, соответственно, между нулём и фазой (или плюсом) будет значение фазы (или плюса). Может, я, конечно, что-то подзабыл, но мне так всё это запомнилось.
Они и в офисе могут отвлекаться, ничто не помешает сотруднику работать плохо, если он не хочет работать.
В офисе сидят живые люди. Стадный инстинкт — все работают и я работаю. Дома ты либо один, либо тебя отвлекают. Был период, две недели работал дома, один. Очень нагоняло тоску, потом просто мечтал на работу попасть. Немного помогало периодическое отвлечение на физические упражнения.
Излишний контроль демотивирует.
Излишний, если на него тратится время разработчика, — да. Иначе — привыкаешь и спокойно работаешь.
Для того, чтобы контролировать разработчиков достаточно трекера задач и системы контроля версий.
Не получится контролировать всё только с помощью трекера задач. Если каждая задача будет выполняться на 30% медленнее, чем у офисного сотрудника, то выгоднее тогда уже искать в офис людей. Но даже чтобы это понять, требуется каким-то образов вычислять производительность. А для этого нужны специальные системы мониторинга рабочего времени. Худших вариант — кнопочки «Начать задачу» и «Закончить задачу».
Оптимальный вариант — слежение за заголовками открываемых окон и непрерывностью работы. На себе проводил эксперимент с такой открытой утилитой, результаты очень понравились, достаточно объективные. Так я узнал соотношение моего времени по разным языкам программирования, например. Оказалось, что на Питоне в то время я программировал аж 30% времени.
И да, как сказано выше, от таких контор лучше подальше держаться.
Подсчитал, там по текущему курсу доллара з/п чистыми выходит около 193 т.р., если платить налоги как физ. лицо (13 %). На должность архитектора — в 2 раза больше. Так что держаться подальше — это Ваше полное право. А я, например, рассматриваю разные варианты.
Не забывайте, что на удалёнку тоже есть отдельные статьи расходов. В случае, например, Crossover — это снимок экрана каждые 10 минут. А это уже сервера или облако и их обслуживание, — одна статья расходов; менеджер, который будет периодически проверять данные аналитики по разработчикам — другая статья расходов. Контролировать удалённых сотрудников и их производительность намного сложнее.
Подскажу ещё одну интересную тему для тестирования. Вопрос, который не охвачен статьёй. Параллельное исполнение распараллеленных программ. Если в системе большую часть процессора берёт на себя одна высоконагруженная программа, то будет выигрыш, но если таких программ будет много, то производительность может, в зависимости от роста их количества и от количества ядер, сравняться с последовательным исполнением, а затем стать медленнее его. Но это теоретически.
На этих реализациях есть и резисторы и стабилитроны (например, стр. 21). Правда, на вторичной обмотке. Я ожидал увидеть хотя бы один резистор на стороне плюса от диодов, странно видеть контроль на минусе. Тем не менее, защита там есть.
У меня в квартире такое было, во время ремонта обнаружил. Все провода ровно шли, а один под 30 градусов. Думаю, в советских кирпичных домах такое часто встречается.
Это все, конечно, относительно маловероятно, но, тем не менее, возможно.
Вероятность всегда есть, просто она крайне маленькая, на мой взгляд. Я много раз слышал, как взрываются кондёры, если что-то пошло не так, а после второй обмотки наверняка будет хотя бы один кондёр для сглаживания напряжения. Даже он может просто взорваться, тогда всё обойдётся лёгким испугом. А после первой обмотки всё равно ток пойдёт ограниченный каким-либо резистором, это не сравнится с КЗ.
Итого, в случае трансформатора изоляция должна оказаться пробитой в двух местах, чтобы возникла дуга, причём на двух обмотках на коротком расстоянии друг от друга, чтобы дуга вообще могла возникнуть. При этом между ними не должно быть никакого диэлектрика. Это должно произойти ровно тогда, когда человек заряжает гаджет, лёжа в ванной. Розетка в ванной должна оказаться подключенной к основной сети мимо УЗО, что запрещено правилами ПУЭ, по крайней мере в России, правда, нигде не соблюдается. Любой пробой в блоке питания не должен повлечь собой быстрое сгорание элементов, не рассчитанных на большие нагрузки со стороны второй обмотки, иначе цепь разорвётся. Ток, проходя через все элементы, должен иметь достаточную силу, чтобы причинить вред. То есть, если есть резисторы на пути, то это проблема. Кстати, думаю первая обмотка тоже через резисторы подключена, иначе большой ток в холостую будет гоняться. А вода должна обладать достаточным количеством растворённых солей, чтобы проводить достаточное количество тока.
Если нет гальванической развязки, то все те же проблемы, только без обмоток.
Не знаю, что там за бугром, но я спросил у коллег, разрабатывающих электронику, может ли заряжающийся гаджет, упавший в воду причинить вред, мне дали чёткий и ясный ответ, совпадающий с моими представлениями.
А насчёт электрической дуги — как насчёт сопротивления воздуха? Будет ли там достаточная сила тока, чтобы это вообще почувствовалось?
Если напряжение, приложенное между первичной и вторичной частями схемы, окажется выше, чем электрическая прочность изоляции — изоляция пробивается, и через неё начинает течь ток.
Именно напряжение? Просто тогда сам гаджет выйдет из строя как минимум, либо уйдёт в защиту, а это уже заметно будет. Если не ещё нет пробоя и, например, гаджет в воду кинуть со включенной струёй воды, то заземление будет равносильно закорачиванию вторичной обмотки на 0, т. к. никаких 220 из первичной обмотки там не будет (и пробой это не спровоцирует, если только не поплавится обмотка вместе с изоляцией). Правильно я рассуждаю?
Вот эту всю информацию, которую Вы привели, неплохо было бы товарищу Sound_cULT добавить в статью.
Сюда должен передаваться указатель на data:
Далее в обработчике эти данные можно получить:
Получение данные рекомендую делать однотипно и всегда первой строкой. Однако можете даже сразу в функции объявить требуемый тип данный:
Среди этих двух вариантов всё зависит от того, как принято в рамках проекта, т. к. они эквивалентны с точки зрения Си.
Аналогично с обработчиком завершения.
Глобальные переменные в заголовочном файле — это бессмысленная и крайне плохая практика. Такой файл никуда больше не подключишь, т. к. будет повторное создание переменных. Крайний случай — extern, но лучше писать полностью реентерабельные решения без использования глобальных переменных.
Форматирование тоже выбрано не очень удачным. Рекомендую везде и всегда ставить фигурные скобки, это повышает единообразие кода, соответственно, и читабельность.
Работа со строками тоже не является качественной. Как минимум в таких случаях делают PATH_MAX:
char* result=(char*)calloc(1024,sizeof(char));
Но в таком случае обходятся обычно стековым массивом, тут вообще нет смысла выделять память, т. к. алгоритм не предполагает выполнения realloc() в случае нехватки выделенной памяти.
Просмотрел бегло, если интересно, могут отрецензировать более подробно.
К сожалению Java хоть и знаю, но в продакшене пока ещё не использую (равно как и монорепозитории, которые с самого начала решил не делать), поэтому мне сложно в этом контексте что-либо оценивать.
Идея, которую я пытался донести в том, что каждый подпроект описывается отдельно и подключается там, где это требуется как подмодуль. При этом сам подпроект обрабатывается Gitlab (CI/CD) как самостоятельный проект, который не знает о существовании чего-либо ещё. При этом для каждого проекта создаётся шаблонный yaml-файл для CI/CD в котором по сути меняется лишь название проекта. А сама сборка осуществляется с помощью ещё одного универсального подмодуля, который подключается к каждому проекту. А уже этот подмодуль берёт из проекта файл конфигурации под каждую платформу для текущего проекта.
В результате любой разработчик может быстро склонировать всего лишь один репозиторий (с рекурсивными зависимостями), перейти на любой коммит и собрать пакет, например, для тестов. Или тесты прогнать, дописав новый. Система сборки в этом случае будет самодостаточной.
Это зависит не от количества людей, а от сложности проекта.
Одно из преимуществ, которое мне нравится — подмодули заставляют тебя так декомпозировать код, что ты не можешь сделать проекты A и B взаимозависимыми (если всё правильно организовано). А если случайно так получилось, — это требуется исправить, а результат гарантированно можно проверить, просто собрав эти два подмодуля по-отдельности.
Ещё одно преимещуство — это пакетирование. CI/CD автоматически собирает каждый проект, отдельно его тестирует и пакетирует, например, в свой deb- или rpm-пакет под заданные платформы. Но тут сложнее, т. к. требуется автоматизировать зависимую сборку проектов. Зато не требуются такие надстройки как над монорепозиторием.
Ещё одно преимущество — можно делать глобальный рефакторинг не по всему проекту сразу, а частями через подмодули, таким образом распределив задачу по разным людям. При этом нигде ничего не ломается.
А умный джуниор хуже всего себя показывает в тех случаях, когда есть ведущий программист, и он один на всех. Если джуниор будет прислушиваться у более опытных и может учиться на своих ошибках, то умный джуниор будет придумывать себе всё новые и новые проблемы, особенно если давить по срокам. С одной стороны учится быстрее, с другой результат в плане соотношения производительность/качества лучше не становится в течение очень длительного времени. Зато потом выходит неплохой профессионал в будущем.
Одно могу сказать, — из таких вот компаний выходят потом хорошие опытные программисты. Правда участь компании остаётся печальной — тяжело поддерживаемый продукт с множеством ошибок, который невозможно развивать.
Планету толкнут вперёд, а сами тихонько Луну заселят. У них и по космической программе всё по нарастающей идёт.
В офисе сидят живые люди. Стадный инстинкт — все работают и я работаю. Дома ты либо один, либо тебя отвлекают. Был период, две недели работал дома, один. Очень нагоняло тоску, потом просто мечтал на работу попасть. Немного помогало периодическое отвлечение на физические упражнения.
Излишний, если на него тратится время разработчика, — да. Иначе — привыкаешь и спокойно работаешь.
Не получится контролировать всё только с помощью трекера задач. Если каждая задача будет выполняться на 30% медленнее, чем у офисного сотрудника, то выгоднее тогда уже искать в офис людей. Но даже чтобы это понять, требуется каким-то образов вычислять производительность. А для этого нужны специальные системы мониторинга рабочего времени. Худших вариант — кнопочки «Начать задачу» и «Закончить задачу».
Оптимальный вариант — слежение за заголовками открываемых окон и непрерывностью работы. На себе проводил эксперимент с такой открытой утилитой, результаты очень понравились, достаточно объективные. Так я узнал соотношение моего времени по разным языкам программирования, например. Оказалось, что на Питоне в то время я программировал аж 30% времени.
Подсчитал, там по текущему курсу доллара з/п чистыми выходит около 193 т.р., если платить налоги как физ. лицо (13 %). На должность архитектора — в 2 раза больше. Так что держаться подальше — это Ваше полное право. А я, например, рассматриваю разные варианты.
Большое спасибо за разъяснения. Ещё раз убедился, насколько плохо, что в большинстве наших домой земля вообще отсутствует.
Но это ведь значит, что ток пойдёт по кратчайшему пути на землю в виде КЗ, после чего выбьет автомат фазы?
www.compel.ru/item-pdf/c03a37b26d88b61723622e7b4c7a2d78/pn/pi~top253en.pdf
На этих реализациях есть и резисторы и стабилитроны (например, стр. 21). Правда, на вторичной обмотке. Я ожидал увидеть хотя бы один резистор на стороне плюса от диодов, странно видеть контроль на минусе. Тем не менее, защита там есть.
Вероятность всегда есть, просто она крайне маленькая, на мой взгляд. Я много раз слышал, как взрываются кондёры, если что-то пошло не так, а после второй обмотки наверняка будет хотя бы один кондёр для сглаживания напряжения. Даже он может просто взорваться, тогда всё обойдётся лёгким испугом. А после первой обмотки всё равно ток пойдёт ограниченный каким-либо резистором, это не сравнится с КЗ.
Итого, в случае трансформатора изоляция должна оказаться пробитой в двух местах, чтобы возникла дуга, причём на двух обмотках на коротком расстоянии друг от друга, чтобы дуга вообще могла возникнуть. При этом между ними не должно быть никакого диэлектрика. Это должно произойти ровно тогда, когда человек заряжает гаджет, лёжа в ванной. Розетка в ванной должна оказаться подключенной к основной сети мимо УЗО, что запрещено правилами ПУЭ, по крайней мере в России, правда, нигде не соблюдается. Любой пробой в блоке питания не должен повлечь собой быстрое сгорание элементов, не рассчитанных на большие нагрузки со стороны второй обмотки, иначе цепь разорвётся. Ток, проходя через все элементы, должен иметь достаточную силу, чтобы причинить вред. То есть, если есть резисторы на пути, то это проблема. Кстати, думаю первая обмотка тоже через резисторы подключена, иначе большой ток в холостую будет гоняться. А вода должна обладать достаточным количеством растворённых солей, чтобы проводить достаточное количество тока.
Если нет гальванической развязки, то все те же проблемы, только без обмоток.
Понимаете, почему я иронизирую?
А насчёт электрической дуги — как насчёт сопротивления воздуха? Будет ли там достаточная сила тока, чтобы это вообще почувствовалось?
Прошу прощения, если это прозвучало обидно, но высказывалось в форме шутки.
Именно напряжение? Просто тогда сам гаджет выйдет из строя как минимум, либо уйдёт в защиту, а это уже заметно будет. Если не ещё нет пробоя и, например, гаджет в воду кинуть со включенной струёй воды, то заземление будет равносильно закорачиванию вторичной обмотки на 0, т. к. никаких 220 из первичной обмотки там не будет (и пробой это не спровоцирует, если только не поплавится обмотка вместе с изоляцией). Правильно я рассуждаю?
Вот эту всю информацию, которую Вы привели, неплохо было бы товарищу Sound_cULT добавить в статью.