Это рассказ о том, как потратить 3 недели на тестовое задание от работодателя мечты и провалить второй тур собеседования. Несмотря на то, что работу я не получил, тестовое задание оказалось испытанием, с которым я справился, попутно вынеся для себя несколько важных уроков.

Доброго времени суток, Хабр!

Лет пять назад мы купили себе освежитель воздуха Air Wick. Я его разобрал, вытащил и выкинул плату, в надежде, что так я быстрее сделаю свою … Если Вы решите, что оно того не стоило, то я готов поспорить.

Приветствую, Хабр!

Статья о разработке контроллера измерения влажности почвы с передачей данных по Wi‑Fi. Конкретно это устройство было разработано для вертикальной фермы на 64 ячейки.

Очередная зарисовка, как всегда, выросшая из практической задачи.
Имеется устройство -аккумуляторная батарея, состоящая из трех секций аккумуляторных ячеек (АЯ) (литий-ионных, хотя это неважно) и необходимо обеспечить их совместную работу на общую нагрузку. Для решения данной задачи поставлены три ключа на полевых транзисторах, индивидуально управляемых с микроконтроллера. Естественно, что каждый ключ образован двумя последовательно включенными транзисторами, управляемыми минусом на затворе (я постоянно путаю буквы n и p, так что пользуюсь такой терминологией), так что стоят они в плюсах батарей - пока ничего нового, таких схем двенадцать на дюжину, см рис.1.

Но случилась беда - при попытке включиться при глубоком минусе (-40) батареи неожиданно начали отключаться под нагрузкой, хотя всего лишь год назад вполне выдерживали такой режим. Связано это было с изменившимися параметрами ячеек.

Вводные:

Вы уже находитесь в проекте (договор заключен, работы идут).
Внешний Заказчик.
Кейс: Заказчик выдвигает новое требование (или уточняет старое) и просит сделать это бесплатно.
Эти работы для вас существенны, и вы очень не хотели бы их делать бесплатно.

Что делать?

Релиз начинается с идеи. Когда в потоке мозгового штурма приходит та самая идея, которая понравится всем пользователям и привлечёт новых клиентов. Идея презентуется команде менеджеров, маркетологов и безоговорочно поддерживается всеми.

Прорабатывается ТЗ и задача отдаётся разработчикам. Затем новая версия тестируется и уходит конечным пользователям. На этом жизненный цикл идеи завершён. Теперь остаётся дождаться массива свежей аналитики и отпраздновать…

Однако эта идея изначально была обречена. Она была поддержана лишь схожими с её автором людьми. Однако эти люди не самая подходящая ЦА, а возможно и вовсе её редкие исключения. И есть только один гарантированный способ проверить гипотезу - проверить её именно на аудитории бизнеса. Но, не на всей. Этот способ называется А/Б тестированием.

И именно ему будет посвящена данная статья. От идеи до конкретной реализации тестирования на next.js (которую можно повторить и на других технологиях).

Допустим, у нас есть массив чисел с плавающей запятой, и мы хотим их суммировать. Можно наивно подумать, что их достаточно просто сложить, например, на Rust.

Однако это запросто может привести к произвольно большой накопленной погрешности. Давайте проверим:

naive_sum(&vec![1.0; 1_000_000]) = 1000000.0
naive_sum(&vec![1.0; 10_000_000]) = 10000000.0
naive_sum(&vec![1.0; 100_000_000]) = 16777216.0
naive_sum(&vec![1.0; 1_000_000_000]) = 16777216.0

Ой-ёй… Что произошло? Проблема в том .что следующее 32-битное число с плавающей запятой после 16777216 — это 16777218. Так что при вычислении 16777216 + 1, значение округляется до ближайшего числа с плавающей запятой, имеющей чётную мантиссу, то есть снова до 16777216. Мы зашли в тупик.

К счастью, есть более совершенные способы суммирования массива.

В этой статье представлен большой тренинг Рика Хартли по разводке земли в печатных платах. Перевёл и озвучил данное видео Dmitry Muravyev, за что ему огромное спасибо. Я всего лишь сделала конспект этого замечательного тренинга, чтоб люди могли ознакомиться с ним быстрее, чем смотреть двухчасовое видео, либо вернуться к каким-то отдельным темам, если позабылось. Категорически рекомендую ознакомиться с источником.

Впервые люди начали использовать землю в качестве проводника около 300 лет назад для отведения молний от зданий. Молния сама естественным образом стремится разрядиться на землю. Так что установив железный стержень на крыше здания и проведя от него  большой толстый провод вниз по зданию к балке, вбитой в землю, люди отводили молнии от зданий. Это был первый опыт использования земли в качестве возвратного пути для протекания тока. Из чего скоро стало ясно, что землю можно использовать в качестве возвратного пути и для других целей.

Это одиннадцатая часть серии мега-учебника Flask, в которой я собираюсь рассказать вам, как заменить базовые HTML-шаблоны новым набором, основанным на платформе пользовательского интерфейса Bootstrap.

Это двенадцатая часть серии мега-учебника Flask, в которой я собираюсь рассказать вам, как работать с датами и временем таким образом, чтобы это работало для всех ваших пользователей, независимо от того, где они проживают.

Однажды, смотря на матричное табло, я подумал, что было бы не плохо, если бы смена текста была анимированной. Как раз необходимо было заменить часы дома. Стало интересно попробовать сделать точечный матричный шрифт с анимацией.

Привет, Хабр! Представляю вам перевод технического документа от Confluent, который посвящен тому, как определить, что именно нужно оптимизировать (пропускная способность, задержка, надежность или доступность), как настроить развертывание Kafka в соответствии с этими целями и убедиться в их достижении с помощью мониторинга. Сегодня я выкладываю первую часть, в которой обсуждается, как определить цели оптимизации и улучшить пропускную способность Kafka. Последующие статьи будут посвящены задержке, надежности, доступности, мониторингу и бенчмаркингу.

Для создания AC/DC источников питания есть две микросхемы, которые можно назвать «народными» - IR2153 и TL494.

В этой статье рассмотрю простейшее включение микросхемы IR2153.

Думаю не сильно ошибусь, если скажу что довольно большое количество людей сталкивались с выходом электронных устройств из строя в результате попадания повышенного напряжения. Происходит это из-за разных причин, но результат почти всегда один, выгорает источник питания.

Так же как бывают разные причины возникновения подобного, существуют и разные методы борьбы с этим и вот об этом мы сегодня и поговорим.

Сегодня мы рассмотрим, что стоит учесть в конструкторской документации, чтобы защититься от проблем на этапе автоматизированного монтажа компонентов на плате. Я покажу, как можно организовать подбор элементов, их взаимное расположение и разводку для монтажа, чтобы увеличить коэффициент выхода годных плат и упростить их диагностику на производстве.

Подход, на который мы будем опираться, называется DFA — Design for Assembly (проектирование для сборки). Набор методов DFA гарантирует возможность сборки компонентов на плате, когда она поступит на монтажный участок, и позволяет отправлять плату в тираж без страха потерять деньги и время.

В наши дни архитектуры на базе микросервисов стали внедряться практически повсеместно. И нередки ситуации, когда какая-нибудь бизнес-функция может генерировать большое количество сетевого трафика в форме обмена сообщениями между несколькими микросервисами, которые она использует. Если мы сможем сделать способ передачи сообщений более эффективным за счет, например, уменьшения размера сообщений, то мы сможем использовать ту же инфраструктуру для работы с более высокими нагрузками.

Как описать хороший код в трех словах? Исходя из опыта — это код, который [приятно поддерживать и эксплуатировать]. СОЛИД, SOLID, СОЛИД... Редко код ревью обходится без упоминания этих принципов, но для разработчика это не означает ничего хорошего. А что, если я скажу вам, что есть альтернатива? Недавно я наткнулся на одну англоязычную статью в блоге автора по имени Dan North. Он поднимает крайне интересные темы: написание хорошего кода, поддержка кодовой базы, порочные практики следования устаревшим трафаретам. 

Думаю, для каждого программиста не секрет, что не всегда есть время и возможность подгонять свое решение под SOLID. Иногда проще оценивать свой код по шкале «хорошего кода» без трафаретов. Тут, конечно, прибегут некоторые люди, которые будут утверждать, что их проекты не содержат говнокода и легаси... Это все просто побег от реальности, нежелание принимать то, что любые проекты и их кодовые базы — это вечные «макароны». В общем, идеализация разработки, которая ни к чему, кроме душевных страданий, не ведет.