Вы получите навыки для скрейпинга сложных сайтов и решения проблем, которые касаются ограничений частоты запросов, блокировок и генерируемых при помощи JavaScript страниц.Читать полностью »
Я не знаю, как изучал функциональное программирование в целом и Haskell в частности. В 2006-м я следил за проектами why the lucky stiff и читал передовой тамблелог Леа Нойкирхен Anarchaia, и какой-то из этих источников познакомил меня с миром за пределами ООП. В декабре 2006 года Леа опубликовала на Anarchaia ссылку на Pandoc, и тогда я впервые узнал о своём любимом ПО и языке, на котором оно было написано.
Читать полностью »
«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин «объектно-ориентированное программирование»)1
Похоже, многим не нравится объектно-ориентированное программирование. Первое, что приходит в голову, когда слышишь эту трёхбуквенную аббревиатуру — это пример с автомобилем, наследование, геттеры, сеттеры и ObjectFactoryFactorySingleton.
Мне это всегда казалось довольно странным. Мне не только нравится ООП, я ещё и считаю, что часто это лучший/наиболее очевидный способ моделирования задачи. И ниже я расскажу, почему.Читать полностью »
Сложность чёткого определения должностей заключается в том, что люди пытаются обмануть систему (всегда заявляя, что они заслуживают новой должности/повышения зарплаты). Я наблюдал, как для борьбы с этим организации создают всё более длинные определения, позволяющие избегать пограничных случаев. Постепенно определения начинают занимать несколько страниц и перестают умещаться в головах. В процессе сложности системы соблюдение её правил ослабевает, а потом люди просто перестают им следовать. Я считаю, что есть более правильный путь, поэтому предлагаю следующее:
Не платите за то, сколько людей под руководством или сколько строк кода они написали. Платите им за генерируемые результаты.
Эта философия сильна и наделяет свободой. Неважно, если вы сотрудник, вносящий индивидуальный вклад (individual contributor, IC), занимаетесь техническим руководством или управлением командой. Важно то, насколько ваш вклад влияет на прибыль бизнеса.
В этом посте предлагается многоуровневая система, которую можно применять к IC, техническим руководителям и руководителям команд.
Читать полностью »
Выберите двухразрядное число, допустим, 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, языке для гремлинов. На случай, если вы тоже гремлин, под спойлерами я буду объяснять все странные особенности.
Читать полностью »
В истребителях 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, расскажу о выполняемых им расчётах и объясню, как он производил эти расчёты механически.Читать полностью »
В 2001 году аэрокосмический инженер Boeing представил на внутреннем техническом симпозиуме компании информационный документ, вызвавший большой шум. Инженер Джон Харт-Смит предупредил своих коллег о рисках стратегии заключения договоров с субподрядчиками, особенно если Boeing будет отдавать на аутсорс слишком большой объём работ и не обеспечит своим поставщикам достаточной технической поддержки и контроля качества на их мощностях.
«Результаты основного производителя ни за что не смогут компенсировать уровень возможностей наименее успешного из поставщиков. Эти проблемы не пропадут просто из-за того, что сама работа выполняется вдали от наших глаз», — писал Харт-Смит.Читать полностью »
Требуют ли фармацевтические компании от исследователей сообщить им сроки создания лекарства от рака? Исследователи могут сообщить сроки выполнения конкретного исследования (и достаточно точные сроки, потому что планы исследований обычно имеют графики), но результаты наподобие «получения лекарства от рака» зависят от того, что выяснится в процессе экспериментов. Для прогнозирования подобных результатов нам заранее нужно знать результаты экспериментов, но если бы мы их знали, то эксперименты были бы не нужны. На самом деле мы не можем смотреть дальше, чем результаты следующего эксперимента, потому что этот эксперимент определяет дальнейший шаг.
В разработке ПО мы не тратим время на задачи, решения которых знаем. Если решения уже существуют, мы добавляем в качестве зависимости пакет или библиотеку с этим решением, или копируем старый код, или делаем что-то ещё, на что требуются секунды, а затем можем переходить к следующей задаче. Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время.Читать полностью »
Вышеупомянутые посты по этой теме состоят примерно на 80% из справедливой и разумной критики, а на 20% из оторванного от реальности ворчания.
Большинство разработчиков понимает, что глупо спрашивать «это ОС для смартфонов, что в ней может быть сложного?» или «моё приложение для работы с электронными таблицами в 90-х занимало 10 килобайт, тогда почему Factorio весит целый гигабайт?» Если вы не присутствовали при разработке, то не сможете оценить все её проблемы и сложности.
Но это не значит, что для объективной критики нет места. Приложения действительно медленнее, чем были раньше. И экспоненциально больше, хотя степень их полезности не растёт с той же скоростью. По крайней мере, почти в каждом современном приложении есть возможности для оптимизации. Мы можем сделать их быстрее, вероятно, даже на порядки величин. Мы можем удалить код. Мы можем писать крошечные специализированные библиотеки. Мы можем находить новые способы сжимать ресурсы.
Почему же мы этого не делаем?Читать полностью »
Когда Васко да Гама в 1497 году обогнул мыс Доброй надежды, больше половины его экипажа из 160 человек погибли от цинги. Этот показатель был довольно привычным: по статистике, от цинги умерло больше моряков, чем от войн, несчастных случаев и всего остального.
Представьте, что у вас есть новое изобретение, способное предотвратить цингу. Люди наверняка будут умолять поделиться им и вы сразу же станете героем?
Спустя сто с небольшим лет, в 1601 году, у английского мореплавателя Джеймса Ланкастера появилась гипотеза о том, что лимонный сок предотвращает цингу.
Его гипотеза не только была абсолютно верной (как мы знаем сейчас, цинга вызывается дефицитом витамина C), но он ещё и провёл эксперимент, результаты которого оказались вполне убедительными. Он добавил в рацион моряков на одном из его судов лимонный сок, а морякам на других судах не давал его. Ни один моряк на судне, где выдавался лимонный сок, не заболел цингой.
Моряки на всех остальных трёх судах умирали в больших и предсказуемых количествах. Чтобы продолжить маршрут, Ланкастеру пришлось перевести моряков с первого корабля на другие.
Возможно, вы подумаете, что британский флот сразу одобрил или, по крайней мере, проверил эту инновацию, которая была простой, дешёвой и практически на 100% эффективной.
Но лишь в 1795 году, почти двести лет спустя после успешного эксперимента Ланкастера и три сотни лет после времени Васко да Гамы флот наконец-то предписал всем своим морякам употреблять цитрусовые (из-за добавления лаймового сока в еду британцев и прозвали «лайми»). До коммерческого флота это нововведение добиралось ещё дольше.
Нам может показаться непостижимым, почему для принятия такой простой инновации, позволявшей избавиться от цинги и сохранить тысячи жизней, потребовалось так много времени. Кто-то может сказать, что её принятию помешали медленные коммуникации и распространение информации. Но ведь не на три сотни лет?Читать полностью »
