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

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

Я по-прежнему работаю вместе с «дата-саентистами» и немного продолжаю заниматься этой сферой, но вся моя работа по «data science» заключается в руководстве и консультировании по чужой работе. Я в большей степени занимаюсь реализацией data science (MLOps) и дата-инжинирингом.

Основная причина разочарования в data science заключалась в том, что работа казалась несущественной, во многих смыслах этого слова «неважной»:

• Работа — это непрекращающийся поток разработки, продукта и офисной политики, поэтому часто так бывает, что работа хороша настолько, насколько хорошо самое слабое звено в цепи.
• Никто не знал, в чём заключается разница между плохой и хорошей работой в data science, да никого это и не волновало. Это значит, что вы можете быть абсолютным неудачником или гением в ней, но в любом случае получите примерно одинаковое признание.
• Работа часто приносила очень малую пользу бизнесу (часто компенсируя некомпетентность выше по цепочке управления).
• Когда польза от работы превышала затраты на оплату труда, часто это не давало внутренней отдачи (например, настройка параметра, чтобы бизнес зарабатывал больше денег).

В конце прошлого года, на пике ажиотажа вокруг невзаимозаменяемых токенов (non-fungible token, NFT), я приобрёл на Amazon с дюжину книг по NFT с самым высоким рейтингом:


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

Вскоре я выяснил, что все книги склоняются к одному центральному аргументу: ценность — неотъемлемое следствие дефицита.

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

«Эй ты, функция. Да, я к тебе обращаюсь. При очистке не забудь, пожалуйста, восстановить все мои регистры. Да, и этот тоже, ты что, думаешь, в Linux попала?»

Вот краткое описание проблемы, с которой я столкнулся. ABI (Application Binary Interface) платформы требует от функций, чтобы они сохраняли значения определённых регистров и восстанавливали их в случае использования, однако набор восстанавливаемых регистров зависит от платформы, и правила в Linux отличаются от правил в Windows. Возможно, поэтому я столкнулся с повреждением регистров Chrome в Windows. Но давайте начнём с самого начала.

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

Один из моих уточняющих вопросов такой: «Что является узким местом производительности вашей программы?» Многие отвечают что-то типа «считывание из входящего файла».

На самом деле, написать эту статью меня вдохновил ответ на чей-то вопрос в Gopher Slack: «Я заметил, что много дополнительной работы приходится на разделение строки и тому подобное, но обычно всё это намного быстрее ввода-вывода, поэтому нас это не волнует».

Я не стал спорить… и пока не проанализировал производительность задачи с подсчётом слов, думал так же. Ведь всех нас этому учили, правда? «Ввод-вывод — это медленно».

Но это больше не так! Дисковый ввод-вывод мог быть медленным 10-20 лет назад, но 2022 году последовательное считывание файла с диска выполняется очень быстро.

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


Примерно год назад наша команда разработчиков Wix внезапно осознала, что мы слишком часто не даём пользователям ответы на эти вопросы. Когда мы это поняли, то начали действовать быстро и решать проблему не только с тем сообщением, которое заставило нас задуматься.

Так начался Errorgate 2021.

Всего за месяц мы изменили тысячи сообщений об ошибках в Wix.

Чтобы выполнить этот проект, нам сначала нужно было определиться с тем, что же считать плохим сообщением об ошибке, а что хорошим.

По некоторым оценкам, Twitter потерял примерно 80% сотрудников. Каким бы ни было реальное число, в компании есть команды, в которых полностью пропали разработчики. Тем не менее, веб-сайт продолжает работать, а твиты продолжают публиковаться. Из-за этого многие задаются вопросом, что происходит со всеми этими разработчиками, и не был ли штат компании попросту раздут. Я бы хотел рассказать о собственном маленьком уголке в Twitter (впрочем, он был не таким уж и маленьким), а также о работе, которая выполнялась для того, чтобы система продолжала функционировать.

Проект curl основан на фундаменте, заложенном в конце 1996 года инструментом под названием httpget.

ANSI C, ставший известным как C89

В 1996 году было не так много хороших альтернатив для создания небольшого и эффективного инструмента командной строки для передачи данных через Интернет. Я не хочу сказать, что C был единственным имевшимся языком, но для меня выбор был прост, и, честно говоря, когда начался этот путь, я даже не думал о каких-то других языках. Мы называли версию этого языка ANSI C, чтобы отличать его от «старорежимного» C K&R. Версию ANSI C позже переименовали в C89 (иногда её называют C90, и это сбивает с толку).

В 2000 году мы выпустили libcurl — библиотеку, предоставляющую всем желающим суперсилы передачи данных через Интернет. Это ещё сильнее оправдывало выбор C. Благодаря C мы могли без проблем предоставить стабильный API/ABI, чего в то время не мог обеспечить даже C++. К тому же это был достаточно портируемый язык, поэтому мы смогли перенести curl и libcurl практически на все современные операционные системы.

Поскольку я хотел, чтобы curl и libcurl предоставляли возможности системного уровня, и нацеливался на максимально широкое распространение, их нельзя было написать ни на одном из высокоуровневых языков наподобие Perl, Python или им подобных. Из-за этого они стали бы слишком большими и тащили за собой слишком много «лишнего багажа».

Я убеждён, что использование (консервативного) C для разработки curl — ключевой фактор его успеха и возможности использования его «где угодно».

Меня зовут Дэниел Рид. Я пишу код уже более двадцати лет. Я сооснователь и ведущий разработчик SaaS-компании, предоставляющей ПО для управления фитнес-студиям, например студиям йоги.

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

Недавно Google Play сообщил нам, что нам нужно обновить версию целевого SDK, в противном случае наши приложения больше не будут отображаться в Google Play Store.

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

В этом посте я расскажу о двух неделях общения мелкого разработчика с Google Play Team.

Если вы прочитали заголовок и подумали «ну, ты, наверно, сделал сначала что-то глупое», то вы правы! Но что такое программирование, как не упражнения в глупых ошибках? Поиск глупых ошибок — это и есть самое большое удовольствие!

Также стоит заранее сделать оговорку о бенчмаркинге: ускорение на 42% было замерено при выполнении программы с моими данными и на моём компьютере, поэтому относитесь к этому результату с долей скепсиса.

Что делает программа?

codeowners — это программа на Go, выводящая владельцев каждого из файлов в репозитории согласно набору правил, указанному в файле GitHub CODEOWNERS. Правило может гласить, что всеми файлами с расширением .go владеет команда @gophers, или что всеми файлами в папке docs/ владеет команда @docs.

Я обнаружил уязвимость, похоже, затронувшую все телефоны Google Pixel: вы можете дать мне любое заблокированное устройство Pixel, и я верну его вам разблокированным. Баг устранили в обновлении безопасности 5 ноября 2022 года.

Проблема позволяла атакующему с физическим доступом к телефону обойти меры защиты экрана блокировки (отпечаток пальца, PIN и так далее), получив полный доступ к устройству пользователя. Уязвимость зафиксирована как CVE-2022-20465; она может затронуть и устройства Android других производителей. Мои рекомендации по патчу и сырой баг-репорт, отправленные Google, можно найти здесь: feed.bugs.xdavidhu.me.

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

Значение в string не лучший тип для записи адреса электронной почты или страны проживания пользователя. Эти значения заслуживают гораздо более богатых и специализированных типов. Мне нужно, чтобы существовал тип данных EmailAddress, который не может быть null. Мне нужна единая точка входа для создания нового объекта этого типа. Он должен валидироваться и нормализироваться перед возвратом нового значения. Мне нужно, чтобы этот тип данных имел полезные методы наподобие .Domain() или .NonAliasValue(), которые бы возвращали для введённого foo+bar@gmail.com значения gmail.com и foo@gmail.com. Эта полезная функциональность должна быть встроена в эти типы. Это обеспечивает безопасность, помогает предотвращать баги и существенно повышает удобство поддержки.

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

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

Как вы хорошо знаете, в Unix-системах мы измеряем время как количество секунд, прошедших с «эпохи»: 00:00:00 UTC 1 января 1970 года. Немало людей сильно разозлилось из-за этого, да и вообще, общественное мнение сочло это ошибкой.

Во-первых, это определение основано не на чём-то разумном, например, на объективной частоте колебаний атома цезия-133, а на удобной доле времени полного оборота одного большого камня вокруг собственной оси.

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

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

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

За годы работы я совершил переход от фронтенд-разработчика к full-stack и даже попробовал профессионально создавать игры! В это время я руководил и выполнял функции ментора разработчиков с разным уровнем опыта.

Ваш основной язык программирования

Существуют десятки языков программирования. В большинстве случаев мы, программисты, профессионально осваиваем только один. Зачастую это первый язык, которому нас научили в вузе или на буткемпе. Иногда случается, что свой любимый язык порекомендовал нам более опытный друг. А может быть, мы мечтали о создании конкретного типа ПО, например, видеоигр, и выбрали самую популярную технологию в этой сфере. После получения первой работы уровень опыта взлетает до небес.

Для меня основным языком был и остаётся JavaScript. Это был не первый мой язык, но он был самым доступным для меня в старшей школе: я мог писать на нём и запускать код, по сути, на любом компьютере без специального компилятора или IDE.

Генерация изображений при помощи ИИ — одна из самых новых возможностей искусственного интеллекта, поражающая людей (в том числе и меня). Способность создания потрясающих изображений на основании текстовых описаний похожа на магию; компьютер стал ближе к тому, как творит искусство человек. Выпуск Stable Diffusion стал важной вехой в этом развитии, поскольку высокопроизводительная модель оказалась доступной широкой публике (производительная с точки зрения качества изображения, скорости и относительно низких требований к ресурсам и памяти).

Поэкспериментировав в генерацией изображений, вы можете задаться вопросом, как же она работает.

В этой статье я вкратце расскажу, как функционирует Stable Diffusion.

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


Я всего лишь хотел записать сорокасекундную озвучку простенького видео, поэтому запустил стандартное приложение Запись голоса (Voice Recorder) операционной системы Windows и нажал на кнопку записи. Казалось, что ничего не произошло.

Позже я проверил и оказалось, что программа выполняет запись. Я немного поэкспериментировал и выяснил, что в первый раз, когда я начинал запись после запуска Записи голоса, её реакции иногда предшествовала долгая задержка. Двадцатисекундная задержка при записи сорокасекундного клипа — довольно низкий КПД. Это расстроило меня настолько, что я захотел разобраться, почему так получается, и запустил трассировку ETW.

190 фунтов [~86 кг]

Я хочу сбросить 20 фунтов [~9 кг]. Какую часть массы Земли нужно «выбросить» в космос, чтобы достичь этой цели?

— Райан Мёрфи, Нью-Джерси

Задача выглядит довольно простой. Вес возникает потому, что гравитация Земли тянет нас вниз. Гравитация Земли возникает из-за её массы. Чем меньше масса, тем меньше гравитация. Убери массу с Земли — и ты сбросишь вес.

И ты решаешь попробовать сделать это.

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

Введение

Когда я познакомилась со своим бойфрендом, я иногда ощущала небольшое сожаление от того, что у нас не было умилительной киношной истории встречи, несмотря на то, что мы пять лет жили в одном и том же городе и учились в одном университете. Наша история не уникальна для многих пар в 2020 году: на спаде между двумя волнами COVID мы начали общаться онлайн, в приложении для знакомств Bumble.

Я подумала, что благодаря истории местоположений Google, втихомолку отслеживающей данные GPS, можно было бы найти ответ на вопрос о том, насколько судьбоносно пересекались наши дорожки до встречи. Насколько близко мы были к тому, чтобы воспроизвести романтическую сцену «среди десятков людей они нашли глазами друг друга»?

Введение

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

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

При создании своего веб-сайта я хотел найти простой и разумный способ сделать его красивым на большинстве дисплеев. Для моих задач подошли следующие 58 байтов:

main {
  max-width: 38rem;
  padding: 2rem;
  margin: auto;
}

Давайте их разберём.