При локализации сервиса важно внимательно отнестись к согласованию переводов между собой. Руководитель группы клиентской Android-разработки Яндекс.Такси Александр Бонель рассказал, какие практики и инструменты упрощают локализацию. Во второй части доклада Саша поделился опытом поддержки языка RTL в приложении: что хорошо, а что не совсем работает у Андроида из коробки, какие проблемы возникают из-за поддержки RTL и как их минимизировать в будущем.


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

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



Здесь не будет никаких плагинов, библиотек и прочего, речь пойдет только о чистом SVG.
Единственный инструмент, который я буду использовать, это Adobe Illustrator.

Наверняка все видели по телевизору и в интернете фотографии людей, специально размытые, чтобы скрыть их лица. Например, Билл Гейтс:



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

Недавно меня пригласили выступить с вечерней лекцией в Типографском обществе Австрии. Для меня стало большой честью последовать по стопам таких светил, как Мэтью Картер, Вим Краувел, Маргарет Калверт, Эрик Шпикерман и покойная Фреда Сэк.

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

Знаете, когда я почти нечаянно обнаружил, читая прекрасную книгу Дмитрия Кетова «Внутреннее устройство Linux» (и это не реклама), что каждый скачанный нами файл из Интернета с легкой руки браузера оставляет в расширенных атрибутах файла (в inode файла, не в самом файле) как минимум полную ссылку на то откуда он был скачан, я пришел в легкое возбуждение и хотел тут же броситься спасать мир. Позже, немного изучив этот вопрос, почитав «коммиты» и «комменты», говорившие, что этой возможности, встроенной в ядро GNU/Linux, как минимум уже около 10 лет, что ею пользуется не только браузеры, но и, к примеру, популярная утилита wget (curl нет), и что эта вещь считается чуть ли не нормой в Linux (и, как выяснилось позже, в MacOS), то я немного подуспокоился. Одно не давало мне покоя: поиск ключевого слова getfattr в google по сайту «Хабра»: site:https://habr.com getfattr, равно как и по ЛОРУ: site:https://linux.org.ru getfattr ничего толком не дал. «Значит» — подумал я — «эта тема еще особенно не обсуждалась». — Что же, тогда пришло время ее обсудить, но для начала пришлось немного по-исследовать. И вот что я обнаружил:

Предисловие для читателей Хабра — статья о поиске работы на рынке разработки в Украине (который в основном об аутсорсе на иностранных заказчиков), поэтому некоторые вещи могут показаться странными (LinkedIn, собеседования с заказчиками, обязательное требование разговорного английского, обсуждение ЗП в долларах) или нерелевантными для РФ. Тем не менее, статья имела большой успех на локальных ресурсах, и читатели попросили меня перевести её на русский.

Этой статьей я хочу начать цикл рассказов о том, как я на протяжении нескольких месяцев проходил собеседования в примерно 20-и разных компаниях на разные должности. Тут будут мои мысли о рынке труда, процессе найма, советы а так же несколько самых интересных историй. Цикл будет состоять из нескольких частей — HR собеседования, технические собеседования, финальные собеседования. Итак, первая часть.

Немного о себе. Программирую со школьного возраста, за деньги работаю 10 с хвостиком лет. Работал админом, программистом, тимлидом, РМ-ом, линейным менеджером. Выполнял обязанности SRE/DevOps, архитекта, HR, офис-менеджера, эникейщика.

Работал в кровавом энтерпрайзе, в стартапе, в аутсорсе. В основном занимался формошлёпством и крудами, имел дело с Java и бэкендом. За последние несколько лет пересел на фуллстек микс из Java, Ruby/RoR, Python, Node.js.

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

Всего я прошел примерно 20 собеседований с рекрутерами: половина из которых были из агенств и половина — штатные рекрутеры/HR компаний. Так что, могу сказать что некоторая статистика у меня есть.

— Как правильно, творог или творог?
— Творог
— Спасибо!

Привет, Хабр! Обычно мы не выгружаемся в пятницу, но сегодня особый случий: во-первых, зима уже не так близко, во-вторых — начало весны и день котов, в-третьих — сколько можно тянуть-то с этой долгожданной фичей?!



TL;DR

Заходите под кат, выделяйте кусок публикации и ждите CTRL/CMD+Enter — дальше сами всё поймёте.

Изжила ли себя электронная почта? Каким мессенджером стоит пользоваться, чтобы не попасть в затруднительную ситуацию и не потерять связь с друзьями? Можно ли использовать старые технологии на новый лад?

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

Представляю вашему вниманию проект DeltaChat

Delta Chat — свободный децентрализованный мессенджер для Android, iOS, Linux, Mac, функционирующий поверх древнейшего стека протоколов E-mail. Версия для Windows находится в разработке.

Классический DNS, который специфицирован в rfc1034 не пинает только ленивый. При весьма высокой эффективности работы, он действительно никак не защищён, что позволяет злоумышленникам переводить трафик на подставные сайты, путём подмены DNS-ответов для промежуточных кеширующий серверов (отравление кэша). Как-то с этой напастью борется https с его SSL-сертфикатами, которые позволяют обнаружить подмену сайта. Но пользователи обычно ничего не понимают в SSL, и на предупреждения о несоответствии сертификата автоматически кликают «продолжить», вследствие чего время от времени страдают материально.

Предисловие

Как оказалось, не так много людей знают что такое DNSSec, для чего он нужен, для чего нет и стоит ли его внедрять у себя. Так как на русском языке информации на этот счет мало, я постараюсь пролить свет на эти вопросы.

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

Целая глава моей книги Game Engine Black Book: DOOM посвящена консольным портам DOOM и сложностям, с которыми сталкивались их разработчики. Можно долго рассказывать о полном провале на 3DO, о сложностях на Saturn из-за аффинного наложения текстур и о потрясающем «реверс-инжиниринге с нуля», выполненном Рэнди Линденом для Super Nintendo.

Изначально двинувшись в направлении, ведущем к катастрофе^[1], разработчики порта под Playstation 1 (PSX) в дальнейшем смогли сменить курс и создать порт, завоевавший успех у критиков и рынка. Final DOOM был первым истинным портом, сравнимым с PC-версией. Цветовые сектора с альфа-смешением не только усовершенствовали визуальное качество, но и улучшили геймплей благодаря индикации ключа нужного цвета. Также благодаря эффектам реверберации Audio Processing Unit консоли PSX был улучшен звук.

Команда разработчиков выполнила настолько качественную работу, что у неё осталось ещё немного свободных циклов ЦП, которые они решили использовать для генерации анимированного огня в интро и геймплее. Меня это настолько привело в благоговейный трепет, что я решил разобраться, как был реализован эффект. Когда первые поиски не дали ответа, я приготовился уже сдувать пыль с книги по MIPS для взлома исполняемого файла, но Сэмюэль Вильяреал вовремя ответил в Twitter, что он уже выполнил обратную разработку версии для Nintendo 64^[2]. Мне достаточно было просто немного её подчистить, упростить и оптимизировать.

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

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

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

Примеры реконструкции фрагмента видео, сжатого разными кодеками с примерно одинаковым значением BPP (бит на пиксель). Сравнительные результаты тестирования см. под катом

Исследователи из компании WaveOne утверждают, что близки к революции в области видеокомпрессии. При обработке видео высокого разрешения 1080p их новый кодек на машинном обучении сжимает видео примерно на 20%лучше, чем самые современные традиционные видеокодеки, такие как H.265 и VP9. А на видео «стандартной чёткости» (SD/VGA, 640×480) разница достигает 60%.

Иногда может захотеться странного. Вот вроде бы лежит себе видеокамера стандарта MiniDV и лежит. Есть не просит. А что если взять и записать на её кассеты вовсе даже не видео, а, скажем, файлы. Запись-то всё равно цифровая. Пусть объём кассеты всего лишь около 13 ГБ (под данные получилось занять около 9.5 ГБ), пусть скорость чтения 3.5 МБ в секунду, но ведь получится простой домашний стример. Так сказать, “стример для бедных”. Почему бы не отправить на несколько кассет, скажем, какие-либо важные файлы. Просто так, на всякий случай. Попробуем!

Этот доклад руководителя группы разработки ClickHouse Алексея Миловидова представляет собой обзор мало кому известных СУБД. Некоторые из них устарели, некоторые прекратили свое развитие и заброшены. Алексей обращает внимание на интересные архитектурные решения в перечисленных примерах, разбирается в их судьбе и объясняет, каким требованиям должен отвечать ваш опенсорс-проект.


— Мой доклад будет про базы данных. Позвольте сразу спросить, схема метрополитена какого города изображена на этом слайде? Все линии идут в одну сторону.

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

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

Для начала надо представить, какой флоу в разработке у нас принят:

В JS API Яндекс.Карт существует возможность создавать различные объекты на карте. Один из их них – многоугольник, с помощью которого можно улучшить интерактивность пользовательской карты: выделить отдельные области или отобразить местоположение неточечного объекта. К примеру, так можно показать план строительства нового квартала или зоны доставки пиццы.

У пользователей API Яндекс.Карт давно появился вопрос о добавлении подписей поверх многоугольников. Люди предлагали хитрые решения, чтобы добавить подпись на объект в нужном месте, скрыть ее, перекрасить и т.п., но такие решения получались сложными и негибкими.

К примеру, к нам пришел отдел исследований Яндекса с просьбой написать удобный инструмент для подписи многоугольников после того, как они сделали несколько исследований на карте мира.


Отображения региональных слов из словаря Даля, т.е слова которые ищут значительно чаще, чем в среднем по России

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

Большинство массовых краж паролей с социальных сетей реализуются при помощи вирусов, которые лезут в hosts и подменяют страничку авторизации, но я недавно открыл для себя ещё более изощрённый метод обмана пользователей:
yandex.ru@%68%61%62%72%61%68%61%62%72%2E%72%75 (сам «трюк» работает не везде, и не везде работает одинаково).

Например, я не всегда бы увидел, что это не адрес поисковой системы, а ссылка на хабр. Фактически мы просто использовали абсолютно правильный формат URL'а (который определён в RFC 1728, см. раздел 3.1):
//<user>:<password>@<host>:<port>/<url-path>
(те. надпись «yandex.ru» выступила в виде логина).

Сам же адрес настоящего логина легко поддаётся кодировке и когда он закодирован в шестнадцатеричном формате, то типичный пользователь вряд-ли будет переводить его в канонический вид. Ещё можно вместо адреса указать IP сервера в нетипичном для глаз виде (уже обсуждалось на хабре) и получить что-то в духе этого:
vkontakte.ru*id@1297618184
И, почему-то, я уверен, что можно подобрать какой-нибудь символ, который внешне будет похожий на знак вопроса…

UPD.: придумать красивый заголовок так и не получилось, писал ночью… =).

Не хотите читать? Посмотрите демо.

Символы нулевой ширины — это непечатаемые управляющие символы, которые не отображаются большинством приложений. Н​апример, в э​то пред​ложение я вст​авил де​сять про​​белов н​улевой ширины, вы эт​о замет​или? (Подсказка: вставьте предложение в Diff Checker, чтобы увидеть местоположение символов!). Эти символы можно использовать как уникальные «отпечатки» текста для идентификации пользователей.


Безусловно, он может здесь быть. И вы никогда не догадаетесь

Зачем?

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