Три года назад мне попалась интересная научная статья сотрудника 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). Публикуем её, чтобы документ никогда не потерялся.

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

Рассмотрим условный пресс-релиз:

Компания AirTrain Inc. с гордостью представляет новый самолёт AirTrain-8000. Революционный новый самолёт летит из Лондона в Нью-Йорк на средней скорости 7700 км/ч — гигантский прогресс по сравнению с 770 км/ч у других самолётов. Это уменьшает скорость перелёта с десяти часов всего до одного часа, что делает AirTrain-8000 на 90% быстрее, чем наши конкуренты.

Такой пресс-релиз никогда не будет опубликован. Новый самолёт в десять раз быстрее, чем другие (7700 км/ч разделить на 770 км/ч) и никакой отдел маркетинга не позволит называть это «на 90% быстрее», что звучит словно «почти вдвое быстрее». И всё же, когда речь идёт о компьютерах — где десятикратное увеличение скорости случается довольно часто — люди нередко делают такую ошибку.

Подобное злоупотребление процентами сделало их практически бесполезными для описания оптимизаций. Нужно прекратить использовать проценты. Самолёт AirTrain-8000 в десять раз быстрее, точка.

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

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

— Двигать пиксели в CSS и так было трудно! А теперь мне говорят, насколько круто использовать несемантические названия классов, встроенные стили в HTML и даже писать стили CSS на JavaScript!
[Вставь тут гифку из «Гриффинов»] — Ха!
Иллюстрации из Dinosaur Comics Райана Норта

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

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

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

«Просто размести это где-нибудь на сервере».

«Просто добавь кнопку “Избранного” справа от элемента».

«Просто добавь [вставьте здесь сложную опцию] в экране настроек».

Использование слова «просто» указывает на множество сделанных допущений. Несколько месяцев назад Брэд Фрост поделился некоторыми мыслями, какое отношение к знанию имеет это слово.

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

См. также: «Что действительно случилось с Vista: инсайдерская ретроспектива»

Я обычно пищу о вещах, которыми непосредственно занимался — или писал код, или управлял проектом. В этой статье я выбрал другой подход, чтобы написать о своём взгляде на глубинные причины фиаско Windows Vista (кодовое название Longhorn). Хотя это случилось более десяти лет назад, то был ключевой период по переходу на мобильные устройства — и те события вызвали долговременные последствия внутри Microsoft. Я нашёл, что многие попытки описать проблемы Microsoft, особенно в связи с переходом на мобильную платформу, неубедительны и не совпадают с моим пониманием того, что случилось. Статья в Vanity Fair «Потерянное десятилетие Microsoft» описывает бюрократическую гниль и подковёрную борьбу («жизнь… стала непрерывно жестокой») или культурную гниль из-за негативных последствий системы оценки рейтинга конкурентных стеков. Последующая статья в The Atlantic описывает ситуацию как классическую «дилемму инноватора».

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

Этот конкретный твит от Сафьи Абдалла сподвиг меня на некоторые размышления:

Пожалуй, непопулярное мнение (и тут немного иронии от меня).

Чтобы быть способным и отличным инженером, вам не нужно писать статьи в блоге, участвовать в проектах open source, выступать с техническими лекциями или делать что-нибудь ещё.

Можете оставить свой код в офисе — и это вполне нормально.

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

Традиционно группа разработчиков Windows подписывает постер (в данном случае изображение DVD) с выпуском новой версии Windows. Ко времени окончания вечеринки по поводу релиза на нём будут сотни или тысячи подписей

«Опыт — это то, что ты получаешь только после того, как он тебе понадобится» — Стивен Райт

Мне понравился содержательный блог Терри Кроули («Что действительно случилось с Vista»). Терри работал в группе Office и проделал фантастическую работу, описывая сложные козни вокруг Windows Vista и связаного, но заброшенного проекта Longhorn — с точки зрения внешнего наблюдателя.

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

Об авторе: Дэниель Лемир — профессор компьютерных наук в Университете Квебека (Канада). Его исследования затрагивают производительность программного обеспечения и инженерию данных

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

Однако мы часто используем текстовые форматы; например, веб-страницы и электронные письма должны быть в текстовом формате. Как же мы отправляем изображения по электронной почте? Как внедряем картинки на веб-страницы? Один из вариантов — поставить ссылку на реальный бинарный файл. Другой типичный подход — встроить бинарный файл непосредственно в тело письма или веб-страницы с помощью base64. Base64 — это просто стандартный текстовый формат, который можно использовать для кодирования любых бинарных данных. Если быть точным, то код base64 — всегда валидный текст ASCII (и поэтому также валидный UTF-8). Каждый байт кода base64 содержит 6 бит данных. То есть мы «теряем» примерно 2 бита на байт. Поэтому эквивалент base64 бинарного файла будет примерно на 33% больше. На практике такое увеличение размера редко становится проблемой. Насколько я знаю, приложения к электронным письмам почти всегда кодируются в base64.

При написании HTML я нашёл удобным внедрять изображения напрямую в HTML-код с помощью схемы data URI. Например, в недавней статье я таким образом закодировал файл PNG. Крупнейшие веб-сайты вроде Google постоянно используют эту схему. Небольшим недостатком становится то, что веб-страницы чуть увеличиваются в размере (что очевидно) и нельзя воспользоваться преимуществами кэширования изображений. Но зато браузер экономит один сетевой запрос.

Оба авторе: Лин Кларк — разработчик в группе Mozilla Developer Relations. Занимается JavaScript, WebAssembly, Rust и Servo, а также рисует комиксы о коде.

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

Одна из техник — потоковая компиляция, когда браузер компилирует код во время его загрузки. До настоящего времени эта технология рассматривалась лишь как потенциальный вариант ускорения. Но с выпуском Firefox 58 она станет реальностью.

Firefox 58 также включает в себя двухуровневый компилятор. Новый базовый компилятор компилирует код в 10–15 раз быстрее, чем оптимизирующий компилятор.

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



На десктопе мы компилируем 30-60 МБ кода WebAssembly в секунду. Это быстрее, чем сеть доставляет пакеты.

Предупреждение: эта статья и проект имеют исключительно образовательные цели.

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

Цель этой статьи — объяснить, как провести атаку MITM (человек посередине) для внедрения определённого JavaScript-кода в страницы HTML, чтобы заставить все устройства, подключённые к WiFi, майнить криптовалюту для злоумышленника.

Задача состоит в создании скрипта, который проводит автономную атаку в сети WiFi. Это то, что мы назвали CoffeeMiner, поскольку атаки такого типа можно проводить в кафе.

Математика — это «язык, который ни читать, ни понять невозможно без инициации» (Эдвард Ротштейн, «Эмблемы ума»)

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

Для математики существует особый протокол чтения. Как мы учимся читать литературу, так и математику мы должны научиться читать. Школьникам следует изучать протокол чтения для математики так же, как они учатся правилам чтения романа или стихотворения, учатся понимать музыку и живопись. Замечательная книга «Эмблемы ума» Эдварда Ротштейна выявляет взаимосвязь между математикой и музыкой, неявно затрагивая протоколы чтения для математики.

Часть первая. Классификация/локализация, обнаружение объектов и слежение за объектом

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

Введение

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

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

Об авторе. Джеймс Рутли — бэкенд-разработчик в компании Monzo.

В этой статье мы изучим двочиный формат сообщений Domain Name Service (DNS) и напишем вручную одно сообщение. Это больше, чем вам нужно для использования DNS, но я подумал, что для развлечения и в образовательных целях интересно посмотреть, что находится под капотом.

Мы узнаем, как:

• Написать запросы DNS в двоичном формате
• Отправить сообщение в теле датаграммы UDP с помощью Python
• Прочитать ответ от DNS-сервера

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

Есть хорошее демо MSR от 2012 года, которое показывает эффект времени отклика при работе на планшете. Если не хотите смотреть три минуты видео, они по сути создали устройство, которое симулирует произвольные задержки вплоть до доли миллисекунды. Задержка 100 мс (0,1 секунды), типичная для современных планшетов, выглядит ужасно. На 10 мс (0,01 секунды) задержка заметна, но уже можно нормально работать, а при задержке менее 1 мс всё просто идеально — как будто вы пишете карандашом по бумаге. Если хотите проверить это самостоятельно, возьмите любой Android-планшет со стилусом и сравните с нынешним поколением iPad Pro со стилусом Apple. У устройства Apple время отклика намного больше 10 мс, но разница всё равно кардинальная — она такая, что я реально использую новые iPad Pro для записи заметок и рисования диаграмм, в то время как Android-планшеты считаю совершенно неприемлемыми в качестве замены карандашу и бумаге.

Что-то похожее вы увидите в шлемах VR с разными задержками. 20 мс выглядит нормально, 50 мс лагает, а 150 мс уже непереносимо.

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

Если вы посмотрите на «игровые» клавиатуры, то многие из них продаются по цене $100 или выше на заявлениях об их быстроте. В рекламных объявлениях можно встретить такие заявления:

• Специально разработанные клавиши, которые сокращают время регистрации нажатия
• В 8 РАЗ БЫСТРЕЕ — скорость опроса 1000 Гц: время отклика 0,1 миллисекунды
• Получи абсолютное преимущество над своими противниками со сверхбыстрой работой клавишных переключателей 45g и срабатыванием на 40% быстрее, чем у стандартных переключателей Cherry MX Red
• Самая высокая в мире частота опроса 1000 Гц
• Самая быстрая в мире игровая клавиатура, частота опроса 1000 Гц, время отклика 0,001 секунды

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

Ситуация с игровыми клавиатурами во многом напоминает разговор с продавцом машин:

Продавец: Эта машина супербезопасна! У неё двенадцать подушек безопасности!
Я: Это хорошо, но как она выглядит в краш-тестах?
Продавец: Двенадцать подушек безопасности!

Конечно, у игровых клавиатур частота опроса 1000 Гц, и что из этого?

С тех пор, как я посмотрел легендарное видео Wat Гэри Бернхардта, меня завораживает странное поведение некоторых языков программирования. Некоторые из них таят больше сюрпризов, чем другие. Например, для Java написана целая книга с описанием пограничных ситуаций и странной специфики. Для C++ вы просто можете почитать сами спецификации всего за $200.

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

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

Компьютер	Отклик (мс)	Год	Тактовая частота	Кол-во транзисторов
Apple 2e	30	1983	1 МГц	3,5 тыс.
TI 99/4A	40	1981	3 МГц	8 тыс.
Haswell-E 165 Гц	50	2014	3,5 ГГц	2 млрд
Commodore Pet 4016	60	1977	1 МГц	3,5 тыс.
SGI Indy	60	1993	0,1 ГГц	1,2 млн
Haswell-E 120 Гц	60	2014	3,5 ГГц	2 млрд
ThinkPad 13 ChromeOS	70	2017	2,3 ГГц	1 млрд
iMac G4 OS 9	70	2002	0,8 ГГц	11 млн
Haswell-E 60 Гц	80	2014	3,5 ГГц	2 млрд
Mac Color Classic	90	1993	16 МГц	273 тыс.
PowerSpec G405 Linux 60 Гц	90	2017	4,2 ГГц	2 млрд
MacBook Pro 2014	100	2014	2,6 ГГц	700 млн
ThinkPad 13 Linux chroot	100	2017	2,3 ГГц	1 млрд
Lenovo X1 Carbon 4G Linux	110	2016	2,6 ГГц	1 млрд
iMac G4 OS X	120	2002	0,8 ГГц	11 млн
Haswell-E 24 Гц	140	2014	3,5 ГГц	2 млрд
Lenovo X1 Carbon 4G Win	150	2016	2,6 ГГц	1 млрд
Next Cube	150	1988	25 МГц	1,2 млн
PowerSpec G405 Linux	170	2017	4,2 ГГц	2 млрд
Пакет вокруг света	190
PowerSpec G405 Win	200	2017	4,2 ГГц	2 млрд
Symbolics 3620	300	1986	5 МГц	390 тыс.

Автор — Марк Ноттингем, член Internet Architecture Board и сопредседатель рабочих групп IETF по HTTP и QUIC


Когда Интернет стал популярным в 90-е годы, то основному трафику хватало всего нескольких протоколов: IPv4 маршрутизировал пакеты, TCP превращал их в соединения, SSL (позже TLS) шифровал эти соединения, DNS именовал хосты для подключения, а HTTP как прикладной протокол часто использовал их все.

За многие годы эти ключевые интернет-протоколы изменились совсем незначительно: в HTTP добавилось несколько новых заголовков и методов, TLS медленно сменил пару минорных версий, TCP приспособился к управлению заторами, а в DNS появились функции вроде DNSSEC. Сами протоколы в работе оставались практически неизменными очень долгое время (кроме IPv6, который уже получает достаточное внимание в сообществе операторов связи).

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

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

Автор статьи — Патрик "tyil" Спек

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

Перечислим платформы с поддержкой повторяющихся пожертвований. Это самый удобный способ обеспечить стабильный доход.