Джулия Эванс дает советы по отладке программ:

1. Помнить, что у бага есть логичная причина. Иногда хочется решить, что какие-то вещи происходят просто сами по себе. Но это не так: у всего, что делает компьютер, есть причина (как бы он ни пытался убедить в обратном).
2. Быть уверенным в своей способности поправить ошибку. Некоторые баги требуют недель на то, чтобы докопаться до их причины. Будет тяжело пережить это время, если не верить, что ошибку получится исправить.
3. Знать больше. Знание подробностей о работе технологий (например, протокола TCP или сборщика мусора в JVM) часто помогает определить источник ошибки.
4. Обсуждать проблемы с другими. Иногда это помогает просто как утиная отладка, иногда другие люди могут даже дать полезный совет. Особенное если они имеют отношение к системе, которая содержит баг.
5. Использовать strace.

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

Сборник жестов, появившихся под влиянием современных устройств и технологий.

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

Использование смартфона в диалоге.

Видеозапись доклада Владимира Бородина о бэкапах в PostgreSQL.

• Проблема частичной записи страницы (partial page write): в результате какой-либо ошибки или падения системы на диск может быть сброшена только часть страницы с данными. В результате страница будет содержать смесь старых и новых данных. Для защиты от этого постгрес сохраняет в WAL каждую измененную страницу с данными полностью (хотя это и увеличивает размер лога). Настраивается через переменную full_page_writes (по умолчанию on).
• Бэкапы могут быть поврежденными. Нужно постоянно проверять, что из бэкапа можно восстановиться. Для этого можно использовать pg_dump, он пройдет по всем строкам и свалится с ошибкой, если обнаружит повреждение.
• Восстановление нужно заранее автоматизировать. Скрипт восстановления может пригодиться всего один раз, но это будет такая ситуация (ночь, нервы, спешка), что наличие скрипта окупит себя.
• Для бэкапов и восстановления в Яндексе используют barman.

Дайджест «Лаборатории Касперского» рассказывает о способе взлома сканеров штрих-кодов, который продемонстрировали китайские исследователи:

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

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

One of the demos of our talk "BadBarcode: How to hack a starship with a piece of paper". See you in PacSec 2015. pic.twitter.com/tu8XZjegHP

— Yang Yu (@tombkeeper) November 9, 2015

Хонли Лай, один из двух основателей Phusion, рассказывает, как они строили компанию вокруг опенсорсного проекта.

Phusion разработали веб-сервер Passenger и стали пробовать различные способы заработать на нем.

Ранние бизнес-модели:

1. Консалтинг и аутсорсинговая разработка. Passenger выполнял только маркетинговую функцию: привлекал заказчиков и показывал компетентность разработчиков. Эта модель давала доход, но имела много недостатков. Нестабильный и непредсказуемый поток заказов. Сложности работы с клиентами (дедлайны, меняющиеся требования). Неприятнее всего было то, что консалтинг не оставлял времени на дальнейшую разработку Passenger.
2. Контракты на поддержку. Passenger оказался «слишком хорош»: у пользователей не возникало проблем, которые заставили бы обращаться за поддержкой. Да и пользователи в основном были достаточно технически продвинуты, и им не требовалась регулярная поддержка. Максимум — одноразовая консультация по решению какого-то вопроса. Со временем во Phusion поняли, что контракты на поддержку работают скорее как страховка. Их покупают те, кому нужна безопасность и гарантии. Поэтому пользуются этой услугой не-айти-компании: банки, госорганы. И, как и со страховкой, для продажи поддержки нужны менеджеры по продажам.
3. Пожертвования. Донат просто не работает.

Поздние бизнес-модели:

1. Премиум-версия с дополнительными возможностями. Это распространенный в опенсорсе подход. Phusion боялись, что сообщество плохо отнесется к появлению премиум-версии, но оно, наоборот, поддержало разработчиков. Благодаря прямой оплате, появилась возможность добавить в Passenger возможности, которые до этого приходилось откладывать на будущее.
2. Платные сервисы. Идея в том, что если у продукта достаточно много пользователей, то появится достаточный спрос на связанные сервисы (хостинг, мониторинг, аналитика). Так был разработан Union Station — программа для анализа производительности, интегрируемая с Passenger.

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

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