Эта статья содержит всё, что вам нужно знать об alt-text! Когда их использовать и как идеально их подготовить. Подготовил я, Дэниель, веб-разработчик с частичной потерей зрения, который ежедневно использует скринридер.

Мой опыт с картинками в вебе

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

Robots.txt указывает веб-краулерам мира, какие файлы можно или нельзя скачивать с сервера. Он как первый сторож в интернете — не блокирует запросы, а просит не делать их. Интересно, что файлы robots.txt проявляют предположения веб-мастеров, как автоматизированным процессам следует работать с сайтом. Хотя бот легко может их игнорировать, но они указывают идеализированное поведение, как следует действовать краулеру.

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

Я взял список 1 млн крупнейших сайтов от Alexa и написал маленькую программу для скачивания файла robots.txt с каждого домена. После скачивания всех данных я пропустил каждый файл через питоновский пакет urllib.robotparser и начал изучать результаты.


^{Найдено в yangteacher.ru/robots.txt}

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

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


^{Источник: https://github.com/mraible/history-of-web-frameworks-timeline}

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

Но у меня нет сторонних проектов. У меня нет аккаунта на GitHub. У меня нет open-source проектов, которые я строгаю по вечерам. У меня ровно ноль пулл-реквестов в любой из последних модных проектов, в которых участвуют все крутые кодеры. Я не вожусь с упражнениями в Haskel. И я ненавижу хакатоны.

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

Кажется, человеческой изобретательности нет предела, если нужно обойти какое-то ограничение. Например, нужно подключить устройство к розетке в центре надувного бассейна — ничего не получится, правильно? Неправильно!


Или потушить пожар с другой стороны железнодорожных путей. И очень нужно протянуть туда гидрант, но нельзя останавливать поезда — какие есть варианты? Никаких? Опять неправильно!



Заметили тенденцию? Давайте распространим её на цифровой мир и немного поговорим о HTTPS.

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

У меня проблемы с поиском фронтенд-разработчика, в основном, по WP, Foundation, CSS, JS, на низкоуровневую позицию. Не могу понять, в чём дело. Ни у кого из кандидатов нет «базовых знаний» ничего из перечисленного. Но они могут делать сайты на React или других JS-фреймворках, или на базе WP-шаблонов. Но если я говорю, что нужно сделать простые изменения в CSS, смотрят пустыми глазами… Или какую-нибудь мелочь на чистом JS, ничего.

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

Конечно, есть ограничения на то, сколько можно усвоить за 12 недель обучения. Но огромная часть проблемы в том, что наша индустрия восхищается новым, одержима самыми последними и прекрасными SPA-фреймворками, в то же время обесценив CSS и «старые» имплементации.

На Stack Overflow Jobs каждый может опубликовать собственную Developer Story, чтобы поделиться достижениями и поспособствовать карьерному росту. При публикации можно добавить к статье теги, соответствующие языкам и технологиям, с которыми вы бы хотели работать и с которыми бы не хотели:



Это даёт нам возможность изучить мнения сотен тысяч разработчиков. Есть много способов измерить популярность языка. Например, мы часто использовали для изучения трендов статистику визитов на Stack Overflow или просмотров вопросов. Но данные о тегах — уникальная возможность посмотреть, что людям не нравится, когда у них есть возможность сказать об этом в резюме.

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

Как создать приватный блокчейн Ethereum с нуля?

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

Инструкция включает в себя следующее:

• Создание приватного блокчейна Ethereum с помощью geth.
• Создание кошелька MetaMask для работы с приватным блокчейном.
• Перевод средств между несколькими аккаунтами.
• Создание, развёртывание и вызов смарт-контракта в приватном блокчейне с помощью remix.
• Создание обозревателя блоков Ethereum поверх приватного блокчейна.

В последнее время я читал статьи о лучших практиках code review и заметил, что эти статьи фокусируются на поиске багов, практически игнорируя другие компоненты ревью. Конструктивное и профессиональное обсуждение обнаруженных проблем? Неважно! Просто найди все баги, а дальше само сложится.

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

Моя революционная книга обучит вас проверенным техникам по выявлению максимального количества недостатков в своём партнёре. Книга не затрагивает следующие области:

• Обсуждение проблем с сочувствием и пониманием.
• Помощь партнёру в устранении недостатков.

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

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

Недавно довелось прочитать статью под названием «Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы когда-либо делали». [Очень популярная статья, которая получила массу положительных оценок на Medium — прим. пер.]

Давайте присядем, вы и я. Нужно поговорить. Если вы не читали статью по ссылке, то уделите 10–15 минут и прочитайте, впитайте её целиком.

Готовы? Отлично. Теперь разберём этот текст, потому что он значит гораздо больше, чем там написано. Если вы прочитали статью, то понимаете, что автор описывает проблемного сотрудника под вымышленным именем «Рик». Рик — это местный гений с огромным количеством знаний в предметной области, он входит в состав ключевых разработчиков продукта.

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

Статья для подписчиков LWN

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

В сентябре Мишель Уортер анонсировала отказ от текстового формата писем (анонс опубликован в списке рассылки mozilla-governance). Вскоре стало понятно, что сообщество немного скептично настроено по поводу этой идеи, так что Уортер объяснила причину изменений:

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

До релиза Firefox Quantum остаётся всё меньше времени. Он принесёт множество улучшений в производительности, в том числе сверхбыстрый движок CSS, который мы позаимствовали у Servo.

Но есть ещё одна большая часть технологии Servo, которая пока не вошла в состав Firefox Quantum, но скоро войдёт. Это WebRender, часть проекта Quantum Render.



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

При разработке WebRender мы поставили задачу, чтобы все приложения работали на 60 кадрах в секунду (FPS) или лучше, независимо от размера дисплея или от размера анимации. И это сработало. Страницы, которые пыхтят на 15 FPS в Chrome или нынешнем Firefox, летают на 60 FPS при запуске WebRender.

Как WebRender делает это? Он фундаментальным образом меняет принцип работы движка рендеринга, делая его более похожим на движок 3D-игры.

В гольфе выигрывает тот, у кого меньше очков.

Применим этот принцип в Android. Мы собираемся поиграть в APK-гольф и создать приложение минимально возможного размера, которое можно установить на Android 8.0 Oreo.

Базовый уровень

Начнём с дефолтного приложения, который генерирует Android Studio. Создадим хранилище ключей, подпишем приложение и измерим размер файла в байтах командой stat -f%z $filename.

Затем установим APK на смартфон Nexus 5x под Oreo, чтобы убедиться, что всё работает.



Прекрасно. Наш APK весит примерно полтора мегабайта.

Я понимаю, что странно начинать блог с негатива, но за последние несколько дней поднялась волна дискуссий, которая хорошо соотносится с некоторыми темами, над которыми я думал в последнее время. Всё началось с поста Джеффа Лика в блоге Simply Stats с предостережением об использовании глубинного обучения на малом размере выборки. Он утверждает, что при малом размере выборки (что часто наблюдается в биологии), линейные модели с небольшим количеством параметров работают эффективнее, чем нейросети даже с минимумом слоёв и скрытых блоков.

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

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

Начнём с традиционного «Этот материал представлен только в образовательных целях». Если вы используете эту информацию для взлома HBO и выпуска следующего сезона «Игры престолов» бесплатно на YouTube, ну… здорово. В том смысле, что я никак не поощряю подобное поведение.

Если не знаете, что такое «резиновая уточка» (USB Rubber Ducky), это устройство, которое сделал Hak5, на фото. Оно выглядит и ведёт себя как обычная флешка, но её можно запрограммировать на очень быстрый ввод клавиш с клавиатуры. «Уточка» способна взломать любую систему за несколько секунд. Единственный недостаток — вам понадобится физический доступ к компьютеру. И ещё она стоит $50, вот почему я написал эту статью.

Мы используем 5V Adafruit Trinket и кабель microUSB — вот и всё, что нам понадобится.

Мы в компании Triplebyte проводим много собеседований. В реальности за последние два года я собеседовал более 900 инженеров. Насколько это эффективное использование моего времени — здесь можно спорить (иногда я просыпаюсь в холодном поту и сомневаюсь в этом). Но независимо от моих ощущений, главное, что мы стараемся улучшить процедуру собеседований. Для этого мы проводим собеседования без просмотра резюме (background-blind inrterview), определяем навыки программирования, а не оцениваем заслуги и рекомендации. После того, как инженеры прошли наше собеседование, они направляются для финального интервью напрямую в компании, с которыми мы работаем (включая Apple, Facebook, Dropbox и Stripe). Мы собеседуем инженеров, ничего не зная об их биографии, а затем смотрим, как они проявляют себя в разных крупнейших IT-компаниях. На мой взгляд, это самая лучшая проверка эффективности интервью.

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

Статья для подписчиков LWN

Хотя население в целом практически не использует OpenPGP, но это критический элемент безопасности, особенно для дистрибутивов Linux. Например, центральный репозиторий Debian проверяет каждый пакет с помощью OpenPGP-ключей мейнтейнера, а затем подписывает его своим ключом. Если у пакетов, которые включаются в ветку, тоже есть такие подписи, то создаётся полноценная цепочка доверия от изначального разработчика до пользователей. Кроме того, пулл-реквесты в ядро Linux тоже верифицируются цифровыми подписями. Поэтому ставки высоки: если скомпрометирован ключ для подписи релиза или хотя бы ключ единственного мейнтейнера, следствием может стать разрушительная атака на много машин.

Это привело сообщество Debian к лучшему пониманию хороших практик работы с криптографическими подписями (которые обычно создаются в программе GNU Privacy Guard, также известной как GnuPG или GPG). Например, слабые (менее 2048 бит) и уязвимые ключи PGPv3 в 2015 году удалили из связок ключей, а среди разработчиков Debian широко распространена практика взаимной подписи ключей при личной встрече. Но даже у разработчиков Debian, кажется, отсутствуют общепринятые правила хранения критического секретного материала, как видно по дискуссии в списке рассылки debian-project. Эта дискуссия сводится к единственному простому требованию: где взять «руководство по хранению электронных ключей для чайников»? Электронные аппаратные ключи или карты-ключи, как мы их здесь называем — это маленькие устройства, позволяющие хранить ключи в офлайне и представляющие собой один из вариантов защиты секретного материала, то есть ключа. В этой статье я постараюсь поделиться своим опытом в данной области и разъяснить проблему, как хранить эти драгоценные секретные ключи, которые в случае компрометации подвергают опасности миллионы компьютеров по всему миру.

Примечание переводчика: Автор статьи — эксперт по социотехнической безопасности (Sociotechnical Security Researcher) в Национальном центре кибербезопасности Великобритании (NCSC), подразделении Центра правительственной связи (GCHQ), который отвечает за ведение радиоэлектронной разведки и обеспечение защиты информации органов правительства и армии.



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

Так зачем организации это делают? Часто они не дают никаких объяснений, но если всё-таки дают, то говорят о «безопасности». NCSC не думает, что эти опасения обоснованы. Мы считаем, что блокировка вставки паролей (БВП) — это плохая практика, которая ухудшает безопасность. Мы считаем, что пользователям следует разрешить вставлять пароли.

Недавно у меня появилась возможность выполнить отладку буфера обмена в Windows, и я решил, что хорошо бы поделиться информацией, которую удалось узнать. Буфер обмена — это тот компонент Windows, который многие из нас используют десятки (сотни?) раз в день, особо не размышляя об этом. Прежде чем взяться за это дело, я даже никогда не задумывался, как всё устроено. Как выяснилось, там столько интересного, что вы даже не можете себе представить. Сначала опишу, как приложения хранят разные типы данных в буфере обмена и как извлекают их оттуда, а затем — как приложения могут «прицепиться» к буферу и отслеживать изменения в нём. В обоих случае вы увидите отладочные записи, которые показывают, как получить доступ к данным из отладчика.

Начнём с обсуждения форматов буфера обмена. Такие форматы используются для описания, какие типы данные можно поместить в буфер. Там есть некоторое количество предопределённых стандартных форматов, которые может использовать приложение, вроде битового массива, текста ANSI, текста в Юникоде и TIFF. Windows также позволяет приложению установить собственный формат. Например, текстовый процессор может зарегистрировать формат, включающий в себя текст, форматирование и картинки. Конечно, это ведёт к определённой проблеме: что произойдёт, если вы скопируете данные из текстового редактора и вставите их в «Блокнот», который не понимает всего этого форматирования и не отображает картинки?

В последнее время на программистских форумах развернулись неслабые дискуссии (для примера см. здесь, здесь и здесь, и эта сегодняшняя) об Electron и его влиянии на сферу разработки десктопных приложений.

Если вы не знаете Electron, то это по сути веб-браузер (Chromium) в котором работает только ваше веб-приложение… словно настоящая десктопная программа (нет, это не шутка)… это даёт возможность использовать веб-стек и разрабатывать кросс-платформенные десктопные приложения.

Самые новые, хипстерские десктопные приложения в наше время сделаны на Electron, в том числе Slack, VS Code, Atom и GitHub Desktop. Необычайный успех.

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