Недавно на Хабре была опубликована статья Разбираем самый маленький PNG в мире. Интересно, а какой самый маленький файл JPEG? В ответах на StackOverflow и Reddit можно встретить размеры 107, 119, 125, 134, 141, 160 байтов. Все они представляют серый прямоугольник 1 на 1. И кто прав? Все правы, просто такая разница объясняется различными режимами кодирования и степенью строгости соответствия стандарту. Описание всех нюансов разрослось до целой статьи cо всеми необходимыми подробностями для более-менее хорошего знакомства с самыми маленькими jpeg-ами. После краткой теории разберем 159-байтный файл на КДПВ, а затем рассмотрим способы его уменьшения.

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

Многое изменилось за 20 лет. В 2003 году главный вопрос звучал так: «Что это за кодировка?». В 2023 году такой вопрос больше не стоит: с вероятностью в 98% это — UTF-8. Наконец то! Можно снова спрятать голову в песок!

В этом месяце я решил узнать, как создать шрифт, который буду использовать в своём комиксе hakum. Раньше я рисовал текст в цифре на своём планшете. Результат оказывался хорошим, но иногда трудночитаемым (размер текста часто скакал на одной странице). Мне не хотелось использовать готовый шрифт, поэтому я решил создать собственный на основе своего рукописного текста. Шрифт повысит читаемость текста и сделает его однородным.

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

Почему буквы на клавиатуре расположены в определённом порядке и какой порядок букв позволяет печатать быстрее всего

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

Алгоритмы важны. Но реализовать их можно очень по-разному.

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

Любите оптимизации, специализированные структуры данных и трюки с битами? Тогда скорее под кат!

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

Коротко обо мне. Меня зовут Макс, и так получилось, что я вот уже 10 лет, почти с самого начала своей карьеры, занимаюсь оптимизирующими компиляторами. Я начинал в Intel, потом перешёл в Azul Systems, год провёл в Cadence и вернулся обратно, всё это время занимаясь компиляторными оптимизациями для Java, C++ и нейросетевых моделей. На момент написания статьи у меня чуть за 900 патчей в LLVM, большинство из них посвящено цикловым оптимизациям.

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

Итак, поехали.

Всем здравствуйте, меня зовут Антон, и этой статьей я открываю новый цикл публикаций про Unicode. Сразу может возникнуть вопрос — зачем? Их же и так море?

На Хабре, как и вообще в русскоязычном сегменте Интернета, в‑основном можно найти обзорные статьи, дающие лишь общее представление о Юникоде, но о том, как с ним работать — информации крайне мало. Сами же его разработчики, Unicode Consortium, предоставляют довольно подробную… но очень объемную документацию, которую при этом мало просто прочитать — для полного понимания много чего в ней стоит прокодить.

Про когнитивные искажения много пишут и много говорят.

Однако всегда не хватало более чёткого понимания, как именно это влияет на профессиональную деятельность, мою и моих коллег. Какие решения я как тимлид и программист принимаю неправильно. Что мне подправить, на что обратить внимание.

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

Если вам интересно, добро пожаловать под кат.

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

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

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

Словарный запас еще небольшой, а тут встречается слово, которое сильно похоже на знакомое. К примеру, accurate. Человек сразу думает, что это «аккуратный». Ведь не может же настолько похожее слово означать что-то иное.

Увы, может. Accurate — это «точный». Поначалу это взрывает мозг, появляется чувство диссонанса, потому что ну какого черта! А потом остается только смириться и изучать ложных друзей переводчика. Расскажем о тех словах, в которых студенты с уровнем Pre-Intermediate и Intermediate допускают ошибки чаще всего.

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

И вот спустя несколько часов (а то и дней) работы, когда вы разобрались и подписали сотни, а то и тысячи процедур и переменных, OllyDbg внезапно зависает или вылетает, унося в небытие все ваши наработки (в которые могут входить не только labels и comments в большом числе, но и расставленные в нужных местах брекпоинты и модификации). Это потеря времени и чудовищно демотивирующий фактор, от которого опускаются руки и бледнеет лицо.

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

1. Если я переведу строку в uppercase или lowercase, число Unicode-символов не изменится.

2. Лигатуры — изврат, ими никто не пользуется. Если их не учитывать, то я прав.

3. Ну хорошо, но давайте считать комбинированный символ (с участием modifying или combining code points) одним символом. Тогда длина всё же сохранится.