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

Как изучить Haskell всего за 15 лет - 1


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

Я не знаю, как изучал функциональное программирование в целом и Haskell в частности. В 2006-м я следил за проектами why the lucky stiff и читал передовой тамблелог Леа Нойкирхен Anarchaia, и какой-то из этих источников познакомил меня с миром за пределами ООП. В декабре 2006 года Леа опубликовала на Anarchaia ссылку на Pandoc, и тогда я впервые узнал о своём любимом ПО и языке, на котором оно было написано.
Читать полностью »

Люди не понимают ООП - 1

«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин «объектно-ориентированное программирование»)1

Похоже, многим не нравится объектно-ориентированное программирование. Первое, что приходит в голову, когда слышишь эту трёхбуквенную аббревиатуру — это пример с автомобилем, наследование, геттеры, сеттеры и ObjectFactoryFactorySingleton.

Мне это всегда казалось довольно странным. Мне не только нравится ООП, я ещё и считаю, что часто это лучший/наиболее очевидный способ моделирования задачи. И ниже я расскажу, почему.Читать полностью »

Как организовать систему оплаты в компаниях, занимающихся разработкой - 1


Любая программная компания рано или поздно сталкивается с проблемой должностей. Некоторые организации довольствуются «плоской» системой, но в отсутствие системы должностей возникают теневые иерархии, что на самом деле хуже. Должности дают чёткую демаркацию ожиданий от конкретного сотрудника. Например, гораздо проще возложить на ведущего разработчика ответственность за техническое руководство, если эта роль чётко определена. Без определений должностей наверх будут подниматься самые громкие, а тихие и вдумчивые останутся незамеченными.

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

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

Эта философия сильна и наделяет свободой. Неважно, если вы сотрудник, вносящий индивидуальный вклад (individual contributor, IC), занимаетесь техническим руководством или управлением командой. Важно то, насколько ваш вклад влияет на прибыль бизнеса.

В этом посте предлагается многоуровневая система, которую можно применять к IC, техническим руководителям и руководителям команд.
Читать полностью »

Генератор случайных чисел, который можно запустить в голове - 1


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

Выберите двухразрядное число, допустим, 23. Оно будет вашим «порождающим значением» (seed).

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

Пример последовательности: 23 –> (2 + 6 * 3) = 20 –> (2 + 6 * 0) = 02 –> 12 –> 13 –> 19 –> 55 –> 35 –> …

Его период будет порядком множителя (6) в группе остатков, простых относительно модуля, 10 (в данном случае 59).

«Случайными цифрами» будет количество единиц двухразрядных чисел, то есть 3,0,2,2,3,9,5,… то есть члены последовательности mod 10.

Больше всего Марсалья известен своим набором тестов diehard-генераторов случайных чисел (RNG), так что он в этом понимает (здесь и далее под RNG я имею в виду генератор псевдослучайных чисел (PRNG)). Мне стало любопытно, почему это работает и как он выбрал 6.

Мы будем писать на Raku, языке для гремлинов. На случай, если вы тоже гремлин, под спойлерами я буду объяснять все странные особенности.
Читать полностью »

Реверс-инжиниринг электромеханического компьютера с самолёта-истребителя - 1


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

В истребителях F-101 и F-111, в бомбардировщике B-58 ВВС США эту задачу решал Bendix Central Air Data Computer (CADC)1.

[1. Мне не удалось найти полный список самолётов, в которых использовался CADC. Судя по различным источникам, он применялся в F-86, F-101, F-104, F-105, F-106, F-111, а также в бомбардировщике B-58.]

Это электромеханическое чудо техники было реализовано на основе лучших технологий 1955 года: шестерней, кулачков, синхронизаторов и магнитных усилителей. В этом посте я загляну внутрь CADC, расскажу о выполняемых им расчётах и объясню, как он производил эти расчёты механически.Читать полностью »

«Это длилось годами». Внутри производственного бардака Boeing - 1


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

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

«Результаты основного производителя ни за что не смогут компенсировать уровень возможностей наименее успешного из поставщиков. Эти проблемы не пропадут просто из-за того, что сама работа выполняется вдали от наших глаз», — писал Харт-Смит.Читать полностью »

Все оценки сроков разработки ПО — ложь - 1

▍ Разработка ПО — это исследование

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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