Привет, Хабр! Мы много разговариваем про найм, и решили запустить новую рубрику — разбор резюме. В ней наши профессиональные HR, которые регулярно просматривают сотни резюме, будут смотреть на присланные CV специалистов и советовать, что в них можно улучшить. Делать мы это будем именно с точки зрения HR-специалистов: они расскажут, что именно их бы оттолкнуло, а что — привлекло. Начнем с резюме бэкендера и дальше пойдем по другим профессиям.

Хабр, привет! Меня зовут Артем Терзьян, я Java-разработчик в IBS. Именно на мои плечи пала нелегкая задача выбора идеального BPMN-движка для реализации с его помощью бизнес-процессов в рамках нашей собственной платформы. Надеюсь, приведенный обзор поможет кому-то сэкономить время при столкновении с аналогичной задачей.

Хобби коллег очень многогранны. Сегодня расскажем об ИТ-шном подходе к выращиванию арбузов в регионе, где, казалось бы, нормально вызревать они не должны. Наш девопс, Игорь Иванов, объединил системный подход к сбору информации и комплектующие с AliExpress и из магазинов для садоводов, и уже не первый год собирает отличный урожай. 

Своеобразная “инструкцию для начинающих” получилась довольно объемной. Мы  разделили ее на две части: в первой автор разбирает теоретические основы, а во второй переходит к практике.

Осторожно, много фото!

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

Год назад в своей статье «Римские и средневековые доспехи. Что лучше?» в качестве одного из параметров сравнения я использовал ударную вязкость. Чтобы понимать, как работает связка свойств – твердость/ударная вязкость в доспехах, представьте себе пластилин и стекло. Если давить пальцем на стекло, то оно будет какое-то время сопротивляться вашему нажиму, но с определенного уровня – трескаться и рассыпаться. Пластилин, напротив, будет тянуться, не давая проникнуть «за». Для доспехов в идеале должны работать оба свойства, но поскольку они противоположны, то на практике нужен компромисс.

❯ 1. Вступление

В позапрошлой статье я описывал китайский BLE микроконтроллер TLSR8258. Честно говоря, он мне не понравился. Главным образом из-за отсутствия нормального Debug режима. Но, как говорится не TeLink-ом единым... Есть у китайцев и другие чипы от отечественных производителей :-) Сегодня мы поговорим о другом семействе, на мой взгляд более интересном. А именно о чипах ch582/583 фирмы WCH.

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

Pino — это мощная платформа ведения логов для Node.js, обладающая молниеносной скоростью и широкими возможностями. Фактически именно скорость Pino и завоевала ему место логгера по-умолчанию в open-source веб-сервере Fastify. Также Pino способен очень просто интегрироваться с другими Node.js-фреймворками, что делает его лучшим выбором для всех разработчиков, ищущих надежное и гибкое решение для ведения логов.

Я объясняю экспериментальные результаты проверки теоремы Белла супердетерминизмом. Далее я показываю, как такая Вселенная может возникнуть и быть совместимой с субъективным опытом свободы воли.

В этой статье рассмотрим как подключиться к консоли Repka Pi 3 через UART.

Repka Pi как и другие компьютеры аналогичного семейства имеет Debug UART выведенный на 40 пиновый разъем платы.

Для начала работы нам потребуется программа PuTTY и USB to TTL конвертер с кабелем.

Скачиваем и устанавливаем программу текущую версию PuTTY с официального сайта https://www.putty.org/. На момент написание статьи версия PuTTY 0.78.

Вот так выглядит PuTTY после установки.

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

Микросервисная архитектура - это подход к построению приложений, в котором они разбиваются на более мелкие и управляемые блоки (микросервисы), каждый из которых выполняет определенную функцию. Такой подход отличается от монолитных приложений, где все компоненты связаны тесно между собой и в одном кодовом базе.

В мае 2015 года Google выпустила отдельное приложение «Фотографии». Люди были поражены тем, что оно способно анализировать изображения, разбирать их на детали, а потом маркировать людей, места и вещи. Даже переводить текст!

Была только одна проблема. Google внедрил «категоризацию фотографий» — все фотографии автоматически размечались и организовывались в папках на основании того, что на них было. И через пару месяцев 22-летний программист-фрилансер Джеки Альсине обнаружил, что все фотографии, на которых был изображен он и его девушка, оба чернокожие, были помечены как «гориллы». Причем если на фотографиях был виден белый человек или человек со светлой кожей, Google маркировал их правильно — например, «выпускной» или «поход в бар». М-да.

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

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

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

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

Американский Джон фон Нейман, выдающийся эрудит, который сделал потрясающий вклад в чистую математику, а затем начал вторую и столь же поразительную карьеру в прикладной математике.

Началось все на лекциях. Для иллюстрации работы нейронной сети нужны простые примеры. Достаточно хорошо известно, что одиночный нейрон формирует разделяющую гиперплоскость, и поэтому задачки типа "а найди мне, какой прямой разделяются два цвета на флаге Монако (который состоит из двух горизонтальных полос)" один нейрон решает на раз. Проблемы начинаются позже, например с флагом Японии (который состоит из красного круга на белом фоне) - один нейрон эту задачу хорошо не решает. Обычно, стандартным методом решения является 'в лоб': а давайте увеличим число нейронов, поставим решаюший слой, и задача решится. И тут возникает проблема номер 1: сколько нейронов в скрытом слое ставить. Традиционный ответ из всей обучающей литературы - подбирайте опытным путем. С одной стороны, их не должно быть сильно много, потому-что будет много неизвестных параметров, а с другой стороны - и сильно мало тоже не очень хорошо, ведь с одним нейроном мы уже обожглись. Итак, стандартный вопрос: сколько-же нейронов все-таки надо?

Оказывается, ответ на этот вопрос давно уже есть: в этой задаче - ровно пять. Есть такая теорема Колмогорова-Арнольда, где доказано, что если взять пять нейронов, то для них существуют какие-то гладкие функции активации, при которых двухслойная нейронка будет решать почти любую простую задачу для двумерных входных данных. И это было доказано аж в конце 50х годов 20 века и решало одну из важнейших математических задач 20го века - 13ю проблему Гильберта. Ключевая проблема здесь - "какие-то гладкие функции активации". Ведь, какие они конкретно - никто не сказал, и поэтому нужно их искать.

Одной из наиболее важных проблем при создании распределенных приложений является вопрос представления данных. Мы должны убедиться, что данные, отправленные компонентом «удаленному» компоненту (т. е. компоненту, который является частью другого процесса), будут получены правильно с теми же значениями. 

Это может показаться простым, но помните, что взаимодействующие компоненты могут быть написаны на совершенно разных языках. Ситуация усложняется еще больше, если учесть, что разные аппаратные/системные архитектуры, скорее всего, имеют различные способы представления «одинаковых» значений. Простого копирования байтов из одного компонента в другой недостаточно. Даже в Java, где мы можем считать себя «защищенными» от такого рода ситуаций, нет требования, чтобы две разные реализации JVM или разные версии от одного производителя использовали одно и то же внутреннее представление для объектов.

Наиболее распространенным решением этой проблемы является определение «канонического» представления данных, которое будет понятно между процессами — даже между языками программирования — и перевод данных в этот формат перед отправкой, а затем обратно в собственный формат получателя после получения. 

Существует несколько таких «форматов передачи», начиная от текстовых стандартов, таких как YAML, JSON или XML, до бинарных вариантов, таких как Protobuf, которые включают метаданные или являются полностью неструктурированными.

В компании Chronicle Software разработан ряд библиотек для поддержки создания приложений, оптимизированных для обмена сообщениями с низкой задержкой, в основном в сфере финансовых услуг. 

Роберт К. Мартин (Robert C. Martin) (дядя Боб) назвал пять основных принципов проектирования программного обеспечения SOLID. Такой акроним помогает людям легче запомнить их. Мне очень нравятся подобные мнемоники, потому что всем нам нужна помощь для фиксации в памяти необходимой информации. Чем проще закрепить знания, тем большему мы способны научиться.

Благодаря большому опыту проектирования программного обеспечения, эти принципы были разработаны для того, чтобы помочь создать ПО, которое можно поддерживать в работоспособном состоянии на протяжении длительного времени. Это благо для мира ОО (object-oriented — объектно-ориентированный), что об этих и подобных принципах так много говорят. Они были идентифицированы, переработаны, названы и кодифицированы. И теперь можно открыто говорить о них, при этом люди понимают, что вы имеете в виду. Такого рода вещей, как ни странно, совершенно не хватает в мире функционального программирования.