Мы знаем, что нужно опираться на твёрдое — т.е. устойчивая (крепкая) система должна основываться на устойчивых (крепких), независимых элементах.
Чтобы обеспечить отказоустойчивость, нужно применять принцип разделения ответственности. При этом, каждый модуль системы решает свою конкретную задачу.
Где применяется:
Люди сегодня полагаются на вещи, которые им не принадлежат по-настоящему. Например, многие продукты в технологической сфере построены на технологиях, которые могут легко быть отключены в один прекрасный день. Например, Figma. Если вся работа над продуктом происходит только в фигме, есть риск потерять всё.
В медиа тоже самое. Если вы полагаетесь на Instagram, X (Twitter) или Threads, вас могут отключить специально или случайно.
В продукте должна быть предусмотрена возможность экспорта данных и очень желательно, чтобы это были ключевые данные. Например, в отличии от Instagram или других популярных соц. сетей, Substack позволяет экспортировать не только контент, но и свою аудиторию — в любой момент можно легко скачать базу подписчиков.
Чтобы минимизировать риск, нужно выбирать простые технологии.
Решил добавить свой подкаст ещё на несколько площадок.
Написал письмо, «Звуку». Думаю, это же типа «Сбер» — всё серьёзно. Спросил где технически размещается аудио у них или они каждый раз обращаются к моему серверу.
Вот весь текст моего письма:
Здравствуйте! Подскажите, пожалуйста, как именно работает размещение подкаста через внешний RSS (без переноса на ваш хостинг).
Интересуют технические детали.
При добавлении RSS-ленты: вы воспроизводите аудио напрямую с оригинальных mp3-файлов из RSS или копируете / кэшируете выпуски на своей стороне (например, на CDN или серверах)?
Если используется кэширование: загружается ли полный файл эпизода к вам и как часто он обновляется при изменениях в RSS?
Как в этом случае учитываются прослушивания: считаются ли они как обращения к оригинальному mp3 (и попадают ли в статистику хостинга) или учитываются только внутри «Звука»?
Также подскажите, предоставляется ли доступ к студии для подкастеров и аналитике, если подкаст добавлен только через внешний RSS, без переноса на ваш хостинг.
Важно понять, будут ли прослушивания из «Звука» учитываться в статистике моего текущего хостинга.
Спасибо! Антон
…
Прошло всего две (!!!) недели. Получаю вот такой куцый ответ:
Сообщаем, что техническая обвязка размещения подкастов соответствует передовым методам используемым в индустрии. Аналитику по прослушиваниям и стримам вы можете получить по запросу, указав соответствующий период.
Обвязка? Соответствует передовым? Аналитика по запросу? Вы серьёзно? Не уточнили только запрашивать заказным или обычным письмом.
Вычёркиваю.
«Протокол сборки» — это краткое описание того, как был собран текст, идея или проект в работе с ИИ. Не лог чата и не технический отчёт, а сжатая карта сборки: из чего всё началось, что в процессе изменилось, что было отброшено, что удержал автор и как материал в итоге сложился в цельную вещь. Он нужен не для того, чтобы показать «как много было работы», а для того, чтобы сделать видимой архитектуру процесса.
В рамках «игрового руководства» протокол сборки важен потому, что он показывает не только результат, но и способ ведения игры. Он помогает не растворить автора в машине, а, наоборот, проявить его выбор, вкус, рамку и роль в сборке. Поэтому протокол сборки это не приложение к работе, а одна из практик самой работы.
Ну как же так можно, Apple? Я понимаю желание оставаться в рамках красного цвета Apple Music, но это же глупость. И ведь это сайт огромной корпорации.
Хороший повод задуматься, как оформлять сообщения об успехах и ошибках в интерфейсе, не разрушая визуальный образ с одной стороны и не допуская таких промахов с другой.
Игровое руководство — это авторское управление работой с ИИ через игру, вкус, рамки и отбор, а не через жёсткий контроль или пассивное потребление результата.
Это способность направлять работу в медиуме, не владея им ремесленно до конца, но понимая его достаточно, чтобы вести процесс осмысленно и с удовольствием.
Важная часть игрового руководства — «Протокол сборки». Это краткое описание того, как был собран текст, идея или проект в работе с ИИ. Не лог чата и не технический отчёт, а сжатая карта сборки: из чего всё началось, что в процессе изменилось, что было отброшено, что удержал автор и как материал в итоге сложился в цельную вещь.
Шум, свет, влажный асфальт, ночной город, который не собирается останавливаться. И всё же именно в этом потоке начинает проступать что-то едва заметное. Так открывается первый вход в «Лабиринт».
Читать: Лабиринт. След
В последнее время всё больше замечаю, что люди имеют мнение по любому вопросу. И вроде это неплохо, но очень редко мнение действительно своё: пережитое, основанное на широком сценарном взгляде. Обычно это что-то до скуки банальное, «избитое», безопасное и социально-одобряемое. Такое мнение легко принимается большинством и маркирует автора как знающего, а иногда и как эксперта. Это касается любых тем: от взаимоотношений полов до политики, технологий и будущего.
У меня есть знакомые, которые будут слушать, кивать в такт моей речи и иногда даже пытаться ехидно подколоть, но так и не расскажут, что сами думают на самом деле. Думать опасно. В том смысле, что мысли выдают твои промахи и обнажают слабые места.
Все спрятались по своим безопасным норам. Именно поэтому сегодня почти никто не ведёт блоги. Не потому что не интересно, а потому что опасно сделать ставку, опасно встретиться со своим отражением.
