Недавно один из моих знакомых инженеров устраивался на работу в Facebook. Он успешно прошел несколько кругов собеседований, его позвали на собеседование в офис, и уже там на этапе leadership and drive что-то пошло не так. Как признавался знакомый позднее, отвечать на вопросы в виде «как вы сработались со сложным коллегой» или «как вы добивались целей в токсичной обстановке» он был не очень готов.

Именно подобные вопросы позволяют оценить так называемые гибкие навыки (soft skills) инженеров. История собеседования в Facebook меня сильно заинтересовала, поэтому я решил изучить тему soft skills, их проверки и тренировки поподробнее. Бонусом прикладываю список полезных ресурсов и статей, на которые наткнулся в процессе подготовки материала. Поехали!

Привет, Хабр! Меня зовут Паша Доронин и бóльшую часть жизни я работаю в индустрии переводов и локализации. Я долгое время проработал в компании Smartcat, где прошел путь от аналитика до менеджера по продукту. Несколько месяцев назад я переехал в Дублин и решил заняться дальнейшим развитием своей карьеры.

На этот раз я решил сменить схему поиска вакансий – раньше я просто смотрел на то, «что есть», и выбирал интересные варианты. Теперь же хотелось исходить из того, что хочу получить на новом месте я, и уже соответственно фильтровать объявления. За период активного поиска я связался с 17 компаниями из Европы и США, и устроился в AI-стартап Intento (недавно поднял новый раунд инвестиций). Вот что я понял по итогам этого процесса.

Всем привет!

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

Основные стереотипы о шизоидах в одной картинке

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

Сам этот характер довольно тяжело описать одновременно коротко и корректно. Некоторые называют их «гиками», «интровертами», «чудаками», «ботаниками», «хикканами», «эксцентричными», «нердами», «компьютерными гениями»[1, стр. 231], и все эти характеристики в той или иной мере имеют отношение к, собственно, шизоидам, но ни одна из них не является определяющей.

Проще всего шизоида описать через динамику его внутренних процессов, но такое описание займёт слишком много места, поэтому ограничимся простым (и неточным определением): для целей этой статьи шизоид — это человек, имеющий внутренний конфликт по поводу желания близости и потребности сохранить свою независимость, и решающий этот конфликт через отказ от контактов с внешним миром в пользу погружения в мир собственных фантазий и абстрактных построений.

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

К сожалению, адекватно перевести название затеянного мной безобразия на русский язык оказалось не просто. С удивлением я обнаружил, что официальная документация MSDN называет "дженерики" "шаблонами" (по аналогии с C++ templates, я полагаю). В попавшемся мне на глаза 4-м издании "CLR via C#" Джеффри Рихтера, переведенном издательством "Питер", дженерики именуются "обобщениями", что гораздо лучше отражает суть понятия. В этой статье речь пойдет о небезопасных обобщенных математических операциях в C#. Учитывая, что C# не предназначен для высокопроизводительных вычислений (хотя, безусловно, на это способен, но не в состоянии тягаться с тем же C/C++), математическим операциям в BCL уделено не так много внимания. Давайте попробуем упростить работу с базовыми арифметическими типами силами C# и CLR.

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

Вернее, не так.

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

• Почему по умолчанию все решают задачу именно так?
• Можно ли сделать лучше?

Постановка задачи

Код на языке C# нужно перевести в код на Rust. Точнее, требуется такая процедура перевода (разработка продолжается на C#), чтобы в любой момент можно было получить работающий код на Rust. Эту задачу я решал для языков Java, Python, JavaScript и PHP, написав конвертер из C# в эти языки. Концепция такого конвертирования была изложена в статье UniSharping пару лет назад. Я разрабатывал этот конвертер, чтобы переводить код своего проекта SDK Pullenti (лингвистический анализ текста). И подумалось мне: а не замахнуться ли на Rust? Да, слышал разные отзывы, что язык необычный и пр., но попытка же не пытка… Тем более, что у одного из заказчиков группа программистов увлечённо пишет на нём.

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


Но это уже не имело значения, потому что вызов был принят.

Перевод Neural Network Architectures

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


Сравнение популярных архитектур по Top-1 one-crop-точности и количеству операций, необходимых для одного прямого прохода. Подробнее здесь.

Перевод Demystifying Convolutional Neural Networks.


Свёрточные нейросети.

В прошлом десятилетии мы наблюдали удивительный и беспрецедентный прогресс в сфере компьютерного зрения. Сегодня компьютеры умеют распознавать объекты на изображениях и кадрах видео с точностью до 98 %, уже опережая человека с его 97 %. Именно функции человеческого мозга вдохновляли разработчиков при создании и совершенствовании методик распознавания.

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

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

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

Введение

В последнее время большинство новичков в программировании начинают с высокоуровневых языков, таких, как Java, Python, C#, или любой другой язык, содержащий в себе “джентльменский набор” в виде сборщика мусора, готовых структур данных и так далее. Конечно, такой подход имеет свои плюсы, но, как правило, начинающий разработчик, использующий готовый функционал языка, упускает самое главное – его устройство и механизмы работы и имплементации.

Powershell — удобная API построенная на .net. Powershell позволяет пользователям писать скрипты, не упираясь в программирование, при этом получая схожие результаты. Что происходит на КДВП, автор объяснит позже по тексту. Сейчас нам срочно нужно притвориться, что мы программируем на C#.

TL;DR: Postman не нужен, если есть Powershell. Но сперва нужно зайти издалека.

На этой неделе пользователи Hacker News решили обсудить вопрос «Каков максимальный объем плохого — но при этом работающего — кода вам доводилось видеть?» (позже к ним присоединились и пользователи Reddit). В комментариях было рассказано немало «веселых» историй про то, с чем мы все время от времени сталкиваемся; но больше всего внимания привлек рассказ про код «передовой СУБД, которую используют большинство компаний, входящих в список Fortune 100».

Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика Oracle, который работал над Oracle Database в период разработки версии 12.2. Объем кодовой базы СУБД на тот момент составлял 25 миллионов строк на языке C — и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов.

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

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

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

Техдир пришёл к ним, поздоровался и спросил: «Ребята, скажите честно, какой аццкий зверь меня ждёт в этом проекте? Потому что стейкхолдеры рассказали только о единорогах с радужными хвостами и розовых пони? Legacy, да?»

«Legacy, ...», — грустно ответили разработчики.

Сказка закончилась. Началась работа — и непростые решения.

Привет, Хабровчане!
В конце августа в OTUS запускается 2 мощных курса по обратной разработке кода (реверс-инжиниринг). В связи с этим приглашаем вас на День Открытых дверей, где Артур Пакулов (Ex-вирусный аналитик в Kaspersky Lab.) расскажет подробнее о программах, особенностях онлайн-формата, навыках, компетенциях и перспективах, которые ждут выпускников после обучения. А также приглашаем вас принять участие в бесплатных открытых уроках: «Анализ буткита» и «Анализ банковского трояна».

---

Предпосылки

Все описанное здесь основано на проекте, который я завершил в начале 2011 года, спустя аж несколько лет после его начала. Принимая участие в CanSecWest в 2009 году, Анибал Сакко и Альфредо Ортега из Core Security провели презентацию «Persistent BIOS Infection», где продемонстрировали, как можно пропатчить BIOS, чтобы совершить некоторые неприятные/удивительные вещи. Можете ознакомится с их докладом здесь. На то время это действительно впечатляло, но мне так и не выпал шанс попробовать это на практике. Год спустя мне нужно было подготовить групповой проект для учебы, поэтому я решил вернуться к взлому BIOS и самостоятельно реализовать что-нибудь из этого.

Исключения являются частью языка C++. Неоднозначной его частью. Кто-то их принципиально не использует. Вот вообще не использует. От слова совсем. Но не мы. Поскольку считаем их весьма полезной штукой, существенно повышающей надежность кода.

К сожалению, далеко не везде исключения можно задействовать. Во-первых, исключения не бесплатны и, во-вторых, не всякий код способен "пережить" возникновение исключений.

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

По большому счету, у нас в распоряжении есть только спецификатор noexcept. Штука полезная, конечно, но недостаточная.

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

У меня отключена лента Фейсбука и Вконтакте, нет подписок в Инстаграме, Ютубе и Твиттере. При этом я ниоткуда не удалялся, в монастырь не уходил и продолжаю вести нормальную жизнь человека 2020 года. Надевайте шапочку из фольги и присаживайтесь поудобнее, я расскажу о своём крестовом походе против социальных медиа. Вы узнаете, как мне удалось сократить влияние умной ленты на свою жизнь, ничего существенного при этом не потеряв.

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

Что делать, если поймал HardFault? Как понять, каким событием он был вызван? Как определить строчку кода, которая привела к этому? Давайте разбираться.

Всем привет! Сложно найти программиста микроконтроллеров, который ни разу не сталкивался с тяжелым отказом. Очень часто он никак не обрабатывается, а просто остаётся висеть в бесконечном цикле обработчика, предусмотренном в startup файле производителя. В то же время программист пытается интуитивно найти причину отказа. На мой взгляд это не самый оптимальный путь решения проблемы.

В данной статье я хочу описать методику анализа тяжелых отказов популярных микроконтроллеров с ядром Cortex M3/M4. Хотя, пожалуй, «методика» — слишком громкое слово. Скорее, я просто разберу на примере то, как я анализирую возникновение тяжелых отказов, и покажу, что можно сделать в подобной ситуации. Я буду использовать программное обеспечение от IAR и отладочную плату STM32F4DISCOVERY, так как эти инструменты есть у многих начинающих программистов. Однако это совершенно не принципиально, данный пример можно адаптировать под любой процессор семейства и любую среду разработки.

Привет, интернет.

Решил написать статью об указателях на методы классов. Недавно мне пришлось столкнуться с тем, как они работают изнутри, когда писал некоторые вещи ориентированные под компилятор. Эти указатели работают не совсем как обычные указатели, не имеют возможности быть приведенными в void, и часто имеют размер больше 8 байт. Информации на эту тему в интернете я нашел относительно немного, потому решил разобраться сам.