Одна городская легенда гласит, что создатель сахарных пакетиков-палочек повесился, узнав, что потребители не разламывают их пополам над чашкой, а аккуратно отрывают кончик. Это, разумеется, не так, но если следовать такой логике, то один британский любитель пива "Гиннесс" по имени Уильям Госсет должен был не просто повеситься, но и своим вращением в гробу уже пробурить Землю до самого центра. А все потому, что его знаковое изобретение, опубликованное под псевдонимом Стьюдент, уже десятки лет используют катастрофически неправильно.

Рисунок выше приведен из книги С. Гланц. Медико-биологическая статистика. Пер. с англ. — М., Практика, 1998. — 459 с. Мне неизвестно, проверял ли кто-нибудь на статистические ошибки расчеты для этой диаграммы. Однако и ряд современных статей по теме, и мой собственный опыт говорят о том, что t-критерий Стьюдента остается самым известным, и оттого — самым популярным в применении, по поводу и без.

На Software Engineering Stack Exchange я увидел такой вопрос: «Что мешает широкому внедрению формальных методов?» Вопрос был закрыт как предвзятый, а большинство ответов представляли собой комментарии типа «Слишком дорого!!!» или «Сайт — это не самолёт!!!» В каком-то смысле это верно, но мало что объясняет. Я написал эту статью, чтобы дать более широкую историческую картину формальных методов (FM), почему они на самом деле не используются и что мы делаем для исправления ситуации.

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

by Niklaus Wirth
Professor (retired)
Swiss Federal Institute of Technology (ETH)
Zurich, Switzerland

В 1988 году мы с Юргом Гуткнехтом завершили и опубликовали язык программирования Оберон [1, 2], который являлся преемником двух других языков, Паскаля и Модулы-2, разработанных мной ранее. Язык Оберон был спроектирован нами изначально как более рациональный и эффективный, чем Модула-2, что облегчило студентам академической системы образования освоение компьютерной науки. Не останавливаясь на достигнутом, в 1990 году мы построили современную операционную систему (ОС) Оберон для рабочих станций, использующую окна и возможности для обработки текстов. Затем мы опубликовали книгу, раскрывающую детали как компилятора Оберона, так и одноимённой ОС. Книга, названная «Проект Оберон», включала в себя исходные тексты системы.

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

Вместо предисловия

Допустим, сидя вечерком в теплом кресле вам вдруг пришла в голову шальная мысль: «Хм, а почему бы мне вместо случайного подбора гиперпараметров модели не узнать, а почему оно всё работает?»

Или: Как переход от публикации P-значений к публикации функций правдоподобия поможет справиться с кризисом воспроизводимости: личное мнение Элиезера Юдковского.



Комментарий переводчика: Юдковский, автор HPMOR, создатель Lesswrong и прочая и прочая, изложил свою позицию по поводу пользы байесовской статистики в естественных науках в форме диалога. Прямо классический такой диалог из античности или эпохи возрождения, с персонажами, излагающими идеи, обменом колкостями вперемешку с запутанными аргументами и неизбежно тупящим Симплицио. Диалог довольно длинный, минут на двадцать чтения, но по-моему, он того стоит.


Модератор: Добрый вечер. Сегодня в нашей студии: Учёный, практикующий специалист в области… химической психологии или чего-то типа того; его оппонент Байесовец, который намерен доказать, что кризис воспроизводимости в науке можно как-то преодолеть с помощью замены P-значений на что-то из Байесовской статистики…
Студент: Извините, как это пишется?
Модератор:… и, наконец, ничего не понимающий Студент справа от меня.

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

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

Далее, я часто занимаюсь анализом трудоемкости алгоритмов. Размеры наборов данных, подвергаемые обработке в наши дни, просто колоссальны. В 2010 году на конференции Techonomy Эрик Шмидт сказал, что объем данных, создаваемых сегодня человечеством всего за два дня, равен объему всех существовавших в мире данных по состоянию на 2003 год. Мне важно уметь обрабатывать большие сегменты этих объемов и извлекать из них пользу. И в этом смысле понимание пространственно-временной сложности операций, применяемых нами к данным есть ключ к определению того, возможны ли те или иные вычисления в принципе. В отличие от более традиционных видов O-анализа или тета-анализа постоянные множители в таких масштабах оказывают существенное влияние: множитель 2 не меняет асимптотическую временную сложность алгоритма, но потребует увеличения количества процессоров с 10 тыс. до 20 тыс., и такая разница в потреблении ресурсов будет ощутима. В результате вычисления становятся более изощренными. Примеры: могу ли я взять некое линейное вычисление и снизить его в силе до логарифмического? Можно ли снизить потребление памяти в три раза? И так далее.

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

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

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

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

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

Статья-конспект по книге Роберта Мартина «Идеальный программист». После прочтения книги у меня поменялось отношение к программистической жизни. В книге рассматривается процесс написания кода, сам код, отношение к задачам, TDD и много других полезностей. Читать нужно разработчикам и менеджерам проектов. Частично применимо к дизайнерам.

Генетически модифицированные организмы (ГМО) — организмы, чей генотип искусственно изменён при помощи методов генной инженерии. Изменения внесены целенаправленно, например, в случае сельскохозяйственных культур — повышение урожайности, улучшение вкуса и питательных ценностей продуктов, устойчивости к вредителям и т.д.

В 2015 году генетически модифицированные культуры составили 99% собранного в США урожая сахарной свеклы, 94% соевых бобов, 94% хлопка и 92% кормовой кукурузы.

В мире 12% всех пахотных земель занято ГМ-культурами.

С 1970-х годов учёные изучают потенциальные риски, связанные с использованием ГМО. Чтобы прояснить этот вопрос, Американские академии наук, техники и медицины организовали самое масштабное на сегодняшний день исследование почти 900 научных статей, опубликованных за последние 30 лет, на тему влияния ГМ-культур на организм человека и окружающую среду. Анализ статей продолжался два года комитетом из 50 учёных, исследователей и специалистов от сельского хозяйства и биотехнологий. Документ рецензировали 26 независимых экспертов.

Обо мне

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

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

Во Вселенной работает довольно жестокий вид кармы.

В моем нынешнем положении в качестве старшего директора по развитию программного обеспечения у меня есть 6 менеджеров по развитию, которые отчитываются передо мной. Только в моей организации около 50 разработчиков программного обеспечения. У нас завидно низкая текучесть кадров и очень высокий уровень удовлетворенности клиентов.

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

Глава отдела разработки Ecwid Василий Васильков написал о том, как кандидаты делают тестовые задания и что из этого выходит. Получилось забавно. Публикуем заметку слово в слово.

***

Я расскажу историю одного тестового задания. Немного длинную, но, надеюсь, интересную.

У нас в Ecwid все тестовые задания для инженеров выложены открыто на GitHub вот тут — github.com/Ecwid/new-job. Можно просто начать делать любую понравившуюся задачу, никого не предупреждая, а потом, когда сами будете довольны результатом, поделиться им со мной.

Одно из первых заданий, что я придумал, был консольный качальщик файлов по HTTP. Оно очень простое и придумывал я его именно с такой мыслью. Пусть, рассуждал я, пока такое простое повисит, а потом-то я, конечно, добавлю крутые задания. Потом-то я ого-го что выдумаю! Такие крутые тестовые выложу, что все ахнут и немедленно побегут их делать, а этот примитивный качальщик я куда-нибудь запрячу и никому больше не буду показывать. Как-то так я тогда думал.

Качальщик нужно сделать действительно очень примитивный. Судите сами — ты ему список ссылок в текстовом файле, а он скачивает эти файлы и кладет в указанную папку на локальном диске. Должен уметь качать несколько файлов одновременно (в несколько потоков, например, 3 потока) и выдерживать указанное ограничение на скорость загрузки, например, 500 килобайт в секунду. Всё.

Простите, реформаторы образования – нам всё ещё нужны зубрёжка и повторение

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

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

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

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

Все остальные правила для меня выглядят совершенно, ну просто абсолютно произвольно. Почему у нас есть 12 нот, но для их обозначения применяются только 7 букв? Откуда взялись знаки при ключе? Почему ни одну статью по музыке в Википедии просто невозможно понять, не прочитав сперва все остальные?

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

Идея не нова, да, но успешно реализовать ее до сих пор не удавалось никому. Есть Continuum от Microsoft, старалась изменить ситуацию и компания Canonical со своими Ubuntu-смартфонами и кастомной ОС. Особого распространения все это ПО и аппаратное обеспечение не получило, к сожалению. Может быть, больше повезет MaruOS, это кастомный билд Adnroid. Если подключить к телефону с этой ОС дисплей, клавиатуру, мышь, можно запустить Debian.

Мы — математический лагерь «Слон» — уже давно проводим летние и зимние школы для учеников 8-11 классов. Основной вид деятельности на школе — работа над крупной задачей, проектом. Это может быть что угодно от моделирования сложной физической системы до программы взлома шифров или написания игрушки под Android. Большая часть проектов на школе так или иначе связана с программированием, но редко программирование является самоцелью проекта. Школьники, которые еще не успели стать матерыми программистами, да еще и в условиях вечной нехватки времени пишут код «шоб работало». Так что мы не понаслышке знаем, что такое плохой код и каждый год встречаем всё новые, иногда удивляющие даже нас, способы сделать код нечитаемым — и каждый год решаем, что делать с этой проблемой.

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

Еще одной идеей было использовать git, «чтобы дурь каждого видна была». Тогда ближе к концу проекта можно было бы пересмотреть, с чего все начиналось и куда вывернуло, ужаснуться и делать по-другому. Однако эта идея не прошла проверку временем. По нашему опыту, школьников сложно научить пользоваться системой контроля версий, да еще и регулярно. Им непонятно, для чего СКВ нужны, а потому им скучно. Кроме того, отнимать пару часов только на освоение git — безумное расточительство для проекта длиной в одну неделю. Да и не для того системы контроля версий изначально задумывались.

Решение же, которое мы использовали этой зимой нам самим очень понравилось, поэтому считаем нужным поделиться своим методом. Мы назвали его «Безумное чаепитие».
Итак, задача: научить школьников писать понятный и аккуратный код. При этом надо сделать этот процесс увлекательным…

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

Внимание! В рецепте с отбеливателем обнаружилась опасность коррозии металла! Не рекомендуется в стандартном применении!

Обзор экспериментов год спустя:
DIY порошок для посудомойки: как не растворить посуду и не повторить моих ошибок. Год экспериментов

В прошлой публикации мы создавали дешевый порошок для посудомойки из желудей и спичек кальцинированной соды и стирального порошка. В этой я расскажу о том, как можно его улучшить с помощью кислородного отбеливателя и где можно купить компоненты для более продвинутой версии. Будем делать упор на эффективности мойки, но даже при этом цена не выйдет за 100 рублей/килограмм. А еще будет рецепт ополаскивателя с себестоимостью в районе 1 рубля за литр. Как справедливо заметил amarao, занятие не для всех и многим проще использовать готовые таблетки. Но в подобных экспериментах с бытовой химией есть что-то от детства, первых опытов по смешиванию соды с уксусом и газировки с мятными конфетами. Так что ощутимая экономия здесь все-таки вторична. Будем развлекаться) Если кому-то лень читать весь текст — в конце поста будут подробные рецепты с рекомендациями.

Update
Новый вариант порошка и более подробный разбор во второй части: DIY порошок для посудомойки: разбираем промышленные средства и улучшаем рецепт

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

Есть очень много областей нашей жизни, где наше представление формирует исключительно маркетинговый буллшит. Увы, большинство людей даже не пытаются задумываться о том, что лежит в основе всего этого. Очень часто рыночная ситуация приводит к тому, что себестоимость продукта составляет 0.5% от его цены. Остальное маркетинг, наценки, логистика, упаковка и тому подобное. Почти все в курсе про концепцию продажи чернил для принтера по цене слез гималайских девственниц и настойчивые рекомендации производителей использовать только оригинальные расходные материалы. Например, совсем недавно меня озарило, что 1.5 грамма сухого вещества во флаконе удобрений для растений не могут стоить 200-250 рублей. А ведь именно такое количество может уместиться в относительно стабильном состоянии в виде раствора. Я сразу представил себе гектары полей и грузовики, которые везут тонны порошка. В результате перешел на расфасовки по 1 кг Буйских комплексных сухих удобрений. Можно ванну раствора приготовить.

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

TLDR:

70% прокаленной соды и 30% стирального порошка вместо моющего средства.
Если очень лень возиться с содой, то просто порошок Биолан или его аналоги. Сода удешевляет.
Пищевая соль «Экстра» вместо соли.

Я наткнулся на этот прекрасный текст (под катом) в книге Вернора Винджа "Глубина в небе". Фрагмент меня впечатлил на столько, что я решил поделиться своими мыслями с общественностью. Не часто встретишь подобную проработку вопроса в художественной литературе. Местами, текст кажется слегка… простетским, но возможно это результат не самого хорошего перевода. На самом деле, текст достаточно глубокомысленный.

Еще по ходу чтения мне вспомнился Эдсгер Дейкстра с его знаменитой фразой: «Я денно и нощно молю, чтобы как можно больше моих собратьев-программистов нашли способ освободиться от проклятья совместимости» («I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility») из книги Смиренный программист (1972 sic!!!). А позже и Эрик Реймонд с своим Собором и Базаром (1997 год). Но текст Винджа не только о проклятье совместимости, на трех страничках поднят (и в общем то оставлен без ответов) целый пласт вопросов:

1. Проблема совместимости в широком смысле;
2. Проблема поддержки старого кода;
3. Проблема зависимости человеческой жизни «от бесчувственных роботов» (с), к чему мы стремительно приближаемся;
4. Проблема data mining`а вообще и поиска готового решения в бездонной бочке рецептов в частности (github, stack overflow?);
5. Проблема «переписывания» старого кода (и плохого, и хорошего) — этот момент так и хочется перечитывать :);
6. Проблема необъятности ИТ-технологий. Иногда говорят, что последний универсальный физик жил в середине пошлого века, имея ввиду Льва Ландау. Похоже сейчас наступает (или уже наступило) время, когда найти универсального программиста таки уже невозможно;
7. В тексте нет слова хакер, ни в позитивной, ни в негативной коннотации. Но написано и об исследователях, и о тех преимуществах, которые можно получить зная те или иные backdoor`ы и о том, какую власть это может дать.
8. и наверное это не все… :)

Складывается впечатление, что писал это человек, на своей шкуре прочувствовавший эти самые проблемы.
Хочу отметить, что «Глубина в небе» была написана в 1999 году, когда многое из того, о чем пишет Виндж еще не было проблемой, или вообще только показалось на горизонте.

В качестве критики хочется отметить, что Виндж прошел мимо ИИ (и сильного и слабого, вообще мимо пробежал, даже нейронные сети не затронул) и свел преимущества ИТ к производительности. Так же в тексте не ощущается присутствие мегакорпораций (хотя конечно «Глубина в небе» не относится к киберпанку), если не считать Кенг-Хо таковой. Нет патентных войн, не затронуты вопрос копирайта и проблема закрытых проприетарных разработок, исходные коды к которым так и не были опубликованы.



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