Рубрика «ruvds_переводы» - 6

Становится ли ПО хуже? - 1


Недавно я наткнулся на пост Никиты Прокопова Software disenchantment. Он заставил меня вспомнить пост Мацея Цегловски The Website Obesity Crisis и множество других статей подобного типа. Среди людей, пишущих о разработке ПО, возникает всё более широкий консенсус о том, что приложения становятся больше, медленнее и забагованнее. И это в эпоху, когда оборудование должно позволить нам писать быстрее, меньше и надёжнее. DOOM, вышедший в 1996 году, можно запустить в тесте на беременность и на сотне других неожиданных устройств. Тем временем, современные чат-приложения, работая в фоновом режиме, занимают полгигабайта ОЗУ (или больше), а иногда полностью зависают даже на самом мощном ПО.

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

Большинство разработчиков понимает, что глупо спрашивать «это ОС для смартфонов, что в ней может быть сложного?» или «моё приложение для работы с электронными таблицами в 90-х занимало 10 килобайт, тогда почему Factorio весит целый гигабайт?» Если вы не присутствовали при разработке, то не сможете оценить все её проблемы и сложности.

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

Почему же мы этого не делаем?Читать полностью »

Почему люди не пользуются вашим продуктом (даже если он может спасти тысячи жизней) - 1

«Красный дракон», судно Ланкастера

Когда Васко да Гама в 1497 году обогнул мыс Доброй надежды, больше половины его экипажа из 160 человек погибли от цинги. Этот показатель был довольно привычным: по статистике, от цинги умерло больше моряков, чем от войн, несчастных случаев и всего остального.

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

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

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

Моряки на всех остальных трёх судах умирали в больших и предсказуемых количествах. Чтобы продолжить маршрут, Ланкастеру пришлось перевести моряков с первого корабля на другие.

Возможно, вы подумаете, что британский флот сразу одобрил или, по крайней мере, проверил эту инновацию, которая была простой, дешёвой и практически на 100% эффективной.

Но лишь в 1795 году, почти двести лет спустя после успешного эксперимента Ланкастера и три сотни лет после времени Васко да Гамы флот наконец-то предписал всем своим морякам употреблять цитрусовые (из-за добавления лаймового сока в еду британцев и прозвали «лайми»). До коммерческого флота это нововведение добиралось ещё дольше.

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

Собираем объёмный дисплей на Raspberry Pi - 1


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

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

Вам не нужен для этого JavaScript - 1


Прошу вас не возмущаться названием статьи. Я не ненавижу JavaScript, я люблю его. Ежедневно я пишу на нём кучу кода. Но ещё я люблю CSS и даже люблю JSX HTML. Я люблю все эти три технологии по причине, которая называется…

▍ Правило наименьших полномочий

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

В случае веба это означает, что нужно по возможности выбирать HTML вместо CSS, а затем CSS вместо JS. JS — самый универсальный язык из всех трёх, потому что на нём вы описываете, как должен вести себя браузер; но также он может ломаться, отказываться загружаться, требует дополнительных ресурсов для скачивания, парсинга и исполнения. Кроме того, при его использовании очень легко ограничить доступ пользователей, выполняющих браузинг при помощи клавиатуры или специальных возможностей.

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

Так как функции HTML и CSS обрабатываются браузером, они могут быть более производительными, более нативными, более адаптируемыми к предпочтениям пользователя и в общем случае иметь бОльшую accessibility. Это не значит, что так будет всегда (особенно когда дело касается accessibility), но когда все сложные задачи берёт на себя браузер, от этого обычно выигрывают конечные пользователи.Читать полностью »

Марсоход и моя ошибка на 500 миллионов долларов - 1


Кажется, что некоторые ошибки хуже, чем смерть.

Февральским вечером 2003 года я начал процедуру в Лаборатории реактивного движения НАСА в Пасадене, штат Калифорния. Я натянул костюм для чистой комнаты и прошёл в воздушный шлюз High Bay 1 здания 179, где создавались почти все межпланетные космические аппараты НАСА, начиная с программы «Рейнджер», делавшей снимки Луны в 1960-х. Спустя годы труда тысяч инженеров, техников и учёных оставалось всего две недели до того, как марсоход «Спирит» будет транспортирован на мыс Канаверал во Флориде для запуска перед его братом «Оппортьюнити».

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

Мой опыт собеседования в Google [оффер на L5] - 1


Предупреждение: я не смогу привести в статье конкретные вопросы из-за подписанного соглашения о неразглашении (NDA).

Работая в лондонском офисе Facebook в команде Instagram*, я начал задумываться о возвращении в Индию. В ноябре 2022 года со мной связался рекрутер Google. Он сообщил об открытии в Бангалоре должности уровня L5 и спросил, интересно ли мне это.

Так как я уже раздумывал о переезде в Индию, то ранее собеседовался в Google, но мне предложили более низкую должность (L4), чем я хотел; потом я устроился в META* на уровень E5.

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

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

На этот раз в процессе подготовки возникла уникальная для меня сложность — счастливое пополнение в моей семье, дочка. За моё внимание боролись подгузники и кодинг, было очень сложно выделить время на сосредоточенную подготовку! У меня было примерно 25-30 дней на освоение и искусства ухода за ребёнком, и прохождения собеседования.Читать полностью »

Керниган и Пайк были правы: делай что-то одно и делай это хорошо - 1

Роб Пайк и Брайан Керниган

В октябре 1984 года два идеолога опубликовали радикальный манифест… ну, или что-то вроде того.

Легенды computer science Брайан Керниган и Роб Пайк сформулировали в Program Design in the UNIX Environment паттерн архитектуры ПО, за сохранение которого оба боролись долгие годы.

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

Старые программы покрываются коркой сомнительных фич.

Суть статьи часто сводят к аббревиатуре DOTADIW, или «Do One Thing And Do It Well» («Делайте что-то одно и делайте это хорошо»). В Unix и его потомках есть множество программ, в которых воплощена эта мантра: ls просто создаёт список файлов, cat просто выводит содержимое файлов, grep просто фильтрует данные, wc просто подсчитывает слова и так далее. У каждой программы есть несколько опций, меняющих её поведение, но не слишком сильно. Например: wc можно сконфигурировать для подсчёта строк или слов, но не для подсчёта количества абзацев или вхождений какой-то фразы.

Мощь Unix, защищаемая Керниганом и Пайком, заключалась в возможности соединения этих простых программ в цепочку для создания сложных поведений. Зачем добавлять сопоставление регулярных выражений в wc, если с этим уже способна справиться grep?Читать полностью »

Искусство создания понятных графиков - 1


Эта статья — субъективное эссе о хороших и плохих практиках в визуализации данных, в нём приведены примеры и объяснения.

В папке Scripts/ на Github есть файлы .Rmd, генерирующие показанные ниже графики. Для их работы требуются R, RStudio и пакет rmarkdown.

Читать полностью »

Увядает ли ремесло программиста? - 1


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

Что понимают технологические компании и чего не понимают традиционные компании о разработчиках ПО - 1


Я работал в разнообразных технологических компаниях: от «традиционных» центров программирования и консалтингов до инвестиционных банков и быстрорастущих технологических фирм. Также я общался с разработчиками ПО, работающими в стартапах, банковской сфере, автомобилестроении, big tech и в более «традиционных компаниях». В этой выборке была приличная доля компаний из Кремниевой долины и тех, которые находятся вне её.

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

В этой статье я буду использовать термин «компания в стиле Кремниевой долины», подразумевая современные компании, оптимально использующие каждого разработчика ПО и традиционно находящиеся в Кремниевой долине (хотя многие новые компании этого типа обосновываются уже не там). Такие компании сравнимы по КПД инженера с Meta* или Google. Они используют схожие методологии и часто могут привлекать персонал из других компаний «в стиле Кремниевой долины».
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js