За последние полгода интернет просто наводнила «буква» «й». Я встречал ее на новостных сайтах, в мессенджерах, на хабрахабре и geektimes. «О чем вообще речь?» — спросите вы — «Я вижу обычную букву й!». Вам повезло. Я вижу ее так:
Если вы из тех счастливчиков, у кого буква «й» выглядит так же, как и «настоящая» «й», вот вам фокус: скопируйте ее (букву «й») в блокнот, поставьте курсор в конец буквы и нажмите backspace. Магия, отвал башки просто!
Как же так получается?

Графемы, глифы, code points, компоновка и байты

Очень краткое введение:
Графема — то, что мы привыкли называть буквой в смысле единицы текста. Глиф является единицей графики, и может графически представлять саму графему или же ее часть (например, различные диакритические знаки: ударения, умляуты, надстрочное двоеточие у буквы ё и т.д.).
Code Point — то, как записывается текст в представлении Unicode. Одна графема может записываться разными code points.
Code Points кодируются различным байтовым представлением в зависимости от стандарта: UTF-8, UTF-16, UTF-32, BE, LE…
Языки программирования, как правило, работают с code points; для нас, людей, привычно мыслить глифами.

Давайте же наконец разберемся с нашей буквой й. Что же в ней такого особенного?
Эта буква представляет из себя одну графему («и» краткое), но записана она двумя code points:

U+000438 CYRILLIC SMALL LETTER I
U+000306 COMBINING BREVE

Если вы проделали фокус с нажатием backspace, вы как раз и стерли COMBINING BREVE, или, говоря полиграфическим языком, значок краткости над гласной.

Обычная буква «и» краткое, которую мы все с вами привыкли набирать клавиатурой, представляет из себя композитный символ, который записывается одним code point:

U+000439 CYRILLIC SMALL LETTER SHORT I

Доброго времени суток, %username%! Сегодня мы отправимся изучать бесчисленные возможности фреймворка для реверсера — radare2. В виде подопытного я взял первую попавшую бомбу, она оказалась с сайта Университета Карнеги Меллон.

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

Собеседование — это экзамен

Ведущий — строгий учитель, а кандидат — студент. Классический сеттинг. Обычно проходит так. Спросили откуда ты, что ты, и потом пошло техническое собеседование.

Начинается с простых вопросов на раскачку, примерно таких:

Несколько лет назад я разрабатывал для одного большого телекома новую информационную систему. Нам приходилось взаимодействовать со всё нарастающим количеством веб-сервисов, открываемых более старыми системами или бизнес-партнёрами. Как вы понимаете, мы получили добрую порцию SOAP-ада. Заумные WSDL, несовместимые библиотеки, странные баги… Где только возможно мы старались продвинуть — и использовать — простые RPC-протоколы: XMLRPC или JSONRPC.

Много копий сломано из-за гендерного неравенства в IT: мужчин-программистов гораздо больше, чем женщин. Этот факт подтверждают и стереотипные восприятия, и многочисленные исследования, и статистика Хабра.

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

Компания Interviewing.io провела интересный эксперимент с маскировкой пола на собеседовании — и проверила, как это повлияет на результаты.

Фотография слева: Ведущий программист Маргарет Гамильтон рядом со стопкой распечаток кода управляющего компьютера космического аппарата «Аполлон»

Heroes of Might & Magic III через полтора года исполняется 20 лет. Игра, покорившая не одно поколение своим волшебством, не потеряла своей привлекательности и сегодня — многие называют её «новыми шахматами», утверждая, что превзойти «магическую» формулу третьих «Героев» с тех пор так никому и не удалось.

Сегодня вашему вниманию предлагается рассказ о том, как появились на свет HoMM III и её наследники. Учитывая, что знания, проливающие свет на события тех дней, всегда могут кануть в Лету, и их не спасет даже The Internet Archive (что уже произошло с некоторыми интервью) — а сама серия, по слухам, волей Ubisoft отправлена в глубокую «заморозку» из-за неважных финансовых показателей последней части франшизы — лучше сделать это сегодня, чем завтра.

Мой рассказ является реконструкцией событий, происходивших два десятилетия назад, и в его основе лежат десятки источников — поэтому он может содержать некоторые неточности; к счастью, история пока сохранила для нас достаточно сведений про то, как New World Computing и 3DO смогли произвести на свет игру, удавшуюся настолько, что мы годы спустя продолжаем в неё играть. Узнаете вы и про то, что произошло после выпуска третьих «Героев».

Когда всё закончится, ты забудешь о том, как тяжело тебе было, и захочешь повторить это снова.
Джон Ван Канегем, «Напутствие тем, кто переживает кранч»

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

Прошло уже три месяца с тех пор, как я опубликовал свою первую статью о наших попытках масштабировать Git для очень крупных проектов при помощи инициативы, которую мы назвали «Git Virtual File System». Напомню: GVFS в сочетании с некоторыми правками в Git позволяет работать с ОЧЕНЬ большими репозиториями, виртуализируя как папку .git, так и рабочую директорию. Вместо того, чтобы скачивать репозиторий целиком и проверять все файлы, инструмент динамично скачивает только те фрагменты, которые вам нужны, выявляя их на основании того, над чем вы работали до этого момента.

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

Появление неконтролируемого властями «всеобщего интернета» неприемлемо как для российского государства, так и для отечественных операторов связи.

Глобальный спутниковый интернет

В 2016 году частная аэрокосмическая компания SрaceX запросила в правительстве США разрешение на развертывание сети спутниковой связи для предоставления услуг высокоскоростного доступа в интернет в глобальном масштабе в диапазонах Ku (10,7−18 ГГц) и Ka (26,5−40 ГГц). Кроме SpaceX, заявки на вывод собственных аппаратов связи подали OneWeb, Telesat, O3b Networks (O3b — среднеорбитальная европейская система, курируемая корпорацией SES) и Theia Holdings. Их проекты нацелены на то, чтобы с помощью технологий мобильной спутниковой связи обеспечить пользователей широкополосным доступом в интернет.

Представьте, что вы — IT компания. Может большая или нет, но так получилось, что вам потребовался стажер. Ведь пора, наконец, растить новое поколение в духе вашей идеологии.

Но вот незадача — стажеры такие животные, которые не обладают навыками. И ранее ничего полезного они не делали. Как же не ошибиться в выборе? Что ж, это довольно просто. Если нельзя оценить по результату, то следует искать предпосылки к достижению этого результата…

Статья о серьезной проблеме рекрутинга, которую все почему-то считают нормой.

tl;dr:

Учёные из Колумбийского университета во главе с Кеном Шепардом и Рафой Юсте заявили, что обошли столетнюю теорему отсчётов (теорема Найквиста — Шеннона, теорема дискретизации, в русскоязычной литературе — теорема Котельникова): 1, 2. Теперь фильтры защиты от наложения стали необязательными, ведь шум от наложения спектров можно восстановить после дискретизации. Звучит безумно? Да. Я предлагаю $1000 первому, кто докажет, что это не безумие. Чтобы получить награду, обязательно прочтите до конца.

«Фильтруй перед дискретизацией!»

Эта мантра насмерть вбита в головы поколений студентов-инженеров. Здесь под «дискретизацией» подразумевается преобразование непрерывной функции времени в серию дискретных значений. Такой процесс происходит везде, где компьютер оцифровывает сигнал из реального аналогового мира. «Фильтровать» — значит удалять из сигнала высокочастотные составляющие. Поскольку этот процесс происходит в аналоговом мире, то требует реального аналогового оборудования: цепей из резисторов, конденсаторов и усилителей. Создание такой цепи может стать утомительным и трудоёмким процессом, например, если на электронных микросхемах не хватает места. Научная группа Шепарда рассмотрела это ограничение в контексте устройства для записи сигналов от нервных клеток.

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

Наверное, каждому программисту приходилось сталкиваться с задачами вида «прочитать что-то в формате А и произвести с ним некие манипуляции». Будь то json, логи nginx, cfg, sql, yaml, csv или что-то еще. Хорошо, когда можно воспользоваться библиотекой, однако, по разным причинам, это удается не всегда. Тогда и встает вопрос создания собственного парсера для заданного формата. И это, как говорят англичане, часто оказывается PITA (болью в ...). В этой статье я постараюсь облегчить эту боль. Кому интересно, добро пожаловать.

За последние пару лет я потратил много времени на дебаггинг чужих тестов. Это была интересная работа, иногда расстраивающая, но всегда поучительная. Кто-то может подумать, что в тестах нет багов, но конечно баги есть везде, и тесты не исключение.

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

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

Иногда при разработке программного обеспечения требуется встроить дополнительную функциональность в уже существующие приложения без модификации исходного текста приложений. Более того, зачастую сами приложения существуют только в скомпилированном бинарном виде без наличия исходного текста. Широко известным способом решения указанной задачи является т.н. “сплайсинг” – метод перехвата функций путем изменения кода целевой функции. Обычно при сплайсинге первые байты целевой функции перемещаются по другим адресам, а на их исходное место записывается команда безусловного перехода (jmp) на замещающую функцию. Поскольку сплайсинг требует низкоуровневых операций с памятью, то он осуществляется с использованием языка ассемблера и С/C++, что также накладывает определенные ограничения на реализацию замещающих функций – они обычно также реализованы на С/C++ (реже на ассемблере).

Метод сплайсинга для перехвата API-функций в Windows широко описан в Интернете и в различных литературных источниках. Простота указанного перехвата определяется следующими факторами:

1. целевая функция является статической – она сразу присутствует в памяти загруженного модуля;
   
2. адрес целевой функции легко определить (через таблицу экспорта модуля или функцию GetProcAddress).
   

Реализация замещающих функций на C/C++ при перехвате API-функций является оптимальным вариантом, поскольку Windows API реализовано, как известно, на языке C, и замещающие функции могут оперировать теми же понятиями, что и заменяемые.

Скриншот экрана игры

Эта статья посвящена тому, как я смог написать 3D-движок только на формулах Excel. Я реализовал следующий функционал:

• бесконечная процедурно генерируемая карта лабиринта
• рендеринг трассировкой лучей в реальном времени
• вычисление окклюзии
• рендеринг простейшего освещения
• шейдер освещения и вычислений
• движок естественного движения
• в 3D-движке не используются макросы

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

Можете скачать файл и протестировать его самостоятельно!

О существовании SVG знают все, кто занимается фронтендом. Этой технологии уже не один год, про нее уже не раз писали на хабре. Но есть один момент. Частенько на разных ресурсах, в том числе и на тостере, начинающие задают вопросы о создании определенного семейства анимаций на сайте и получают довольно странные ответы от “бывалых” разработчиков. Возникает ощущение, что в такие моменты все думают в контексте HTML+CSS+JS и просто забывают о существовании SVG, предлагая все рисовать на canvas и попутно давая обещания дать тому, кто это придумал, клавиатурой по голове. Но этот путь (рисование на canvas) зачастую слишком сложен относительно решаемой задачи. В предыдущей статье мы обсуждали идеи создания частичных вау-эффектов, а в этой поговорим о масках и посмотрим пару анимаций, которые с их помощью можно сделать.

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

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

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

Три года назад мне попалась интересная научная статья сотрудника Microsoft Кента Салливана о процессе и результатах проектирования нового пользовательского интерфейса для Windows 95. С тех пор веб-страница исчезла — одна из причин, почему я такой цифровой Плюшкин.

Статья описывает некоторые общие проблемы оболочки Менеджера программ в Windows 3.1 и рассматривает варианты разработки отдельной оболочки для «новичков». Я склоняюсь к мнению, что она предположительно создавалась в духе программы At Ease от Apple, довольно популярной во времена System 7. Я хорошо помню, как мы запускали At Ease в начальной школе, так что детишкам не приходилось возиться с жёстким диском в Finder.

Итак, вот что Кент дословно написал в своей статье под названием «Пользовательский интерфейс Windows 95: конкретный пример проектирования функциональности» (The Windows 95 User Interface: A Case Study in Usability Engineering). Публикуем её, чтобы документ никогда не потерялся.

«Как часто вы ощущаете синдром самозванца?
Ежедневно / Каждую неделю / Раз в месяц / Никогда»

В апреле 2016 года Джессика Баркер провела в Твиттере опрос на тему, часто ли специалисты по информационной безопасности сталкиваются с «синдромом самозванца». Результаты этого опроса легли в основу доклада Джессики на SteelCon 2016.

Вряд ли один этот твит можно квалифицировать как полноценное исследование, однако в качестве беглого анализа он сгодится. Так вот, опрос показал, что 84% безопасников ощущают данный синдром не реже раза в месяц. Одно это позволяет классифицировать его как одну из наиболее актуальных психологических проблем, с которыми можно столкнуться в IT.

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

Попробуем разобраться в проблематике под катом.

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



Дисклеймер: Яндекс очень большой и разный, и я описываю здесь только принципы, принятые в разработке Яндекс.Здоровья. Уверен, что коллеги из других подразделений могут не разделять мои (довольно радикальные) убеждения и не видят ничего зазорного в том, чтобы удержать хорошего человека, сделав ему контроффер.

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