Подключение автономного робота к зарядке: поиск света лампочки, модулированного специальным кодом/частотой, чтобы знать, что это именно кормушка. Описано в советской книге 1978 года, да

На какой носитель можно записать приличный объем данных (сотни гигабайт), чтобы гарантированное время "холодного" (оффлайнового) хранения составляло хотя бы 20-30 лет?

Последним постом в этом канале был задан вопрос, что делать тому, кто хотел бы сохранить данные надолго и надежно. Давайте немного порассуждаем.

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

Большинство прислали мне ссылок на M-DISC (https://ru.wikipedia.org/wiki/M-DISC, диск для миллениалов). Утверждается, что они хранят данные очень долго. Возможно, все это так, но есть нюансы:
* Milleniata, Inc, разработчик диска, обанкротилась в 2016 (наверное, очень хорошие диски были!)
* тесты французской военщины (http://www.lne.fr/publications/guides-documents-techniques/syylex-glass-dvd-accelerated-aging-report.pdf) показывают, что этих диски не сильно стабильнее обычных BR-DVD. А это 5-10 лет, а то и меньше, если не контролировать влажность.

То есть мимо. Хм, ладно, давайте попробуем другие варианты. Кажется, в какой-то момент времени мы продолбали технологии, которые могли бы обеспечивать нам cold storage данных на время хотя бы еще столько же, сколько прошло от начала ИТ-эпохи (1950) до текущего момента.

То, что пришло мне в голову — это ленточные (червчерв) библиотеки, типа тех, что делает HP или IBM. Завораживающее зрелище внутри — по ссылке (https://www.youtube.com/watch?v=xImqdws0_wo). По сути, это робот-рука, которая переставляет ленты-кассеты в хранилище. Библиотека умеет в самодиагностику, а так же периодически переписывает данные с кассеты на кассету во избежание их потери от размагничивания ленты и других способов потери ею свойств.

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

“Хранение это, блин, процесс!”, подумал я. И на этой мысли перейдем далее.

Знаете, как была устроена RAM на линиях задержки в первых ЭВМ и калькуляторах? В некоторый PHY-носитель (ртутную трубку или металлическую струну) с одного конца генерировался импульс, который через некоторое время достигал другого ее конца. Там этот импульс улавливали, усиливали и заново запускали. В итоге биты бегали по кругу, и таким способом могло храниться несколько килобайт, а то и десятки килобайт информации (https://ru.wikipedia.org/wiki/Память_на_линиях_задержки#/media/Файл:Torsion_wire_delay_line.jpg). Минус — не мгновенное извлечение, надо подождать пока автобус с нужными данными по кругу приедет к тебе.

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

Хранение это процесс.

Наконец, самое интересное, что прислали — проект Github Archive. Там, в вечной мерзлоте, глубоко в шахте, Github планирует сохранять весь накопленный материал: исходные коды, содержимое интернет-архива (wayback machine), github pages,

По забавному совпадению, первый полный архив будет сделан и загружен 02.02.2020 PST.  Сегодня!

Как же устроено хранение там? GHA предлагает “слоистую” архитектуру:

Слой 1. Прежде всего, они будут регулярно записывать все архивы на массивы жестких дисков. Эти диски стоят в ДЦ на поверхности, и имеют достаточно маленькое время доступа. Интервал между перезаписью новыми данными меньше, чем время, которое эти диски могут хранить информацию, так что они точно не повреждены.

Слой 2. Пленка. На специальные бобины фирмы Pilq (да, как в дедовских магнитофонах), на специальную полиэфирную пленку с включениями серебра, гарантированный срок хранения которой не менее 500 лет. Эта запись будет происходить примерно раз в несколько месяцев, после чего магнитоматериалы в термостабилизированном контейнере будут загружаться в шахту.
Если я правильно понял, сюда будут попадать ТОЛЬКО исходные коды репозиториев, но не интернет-архив.

Слой 3. Каждые несколько лет данные с бобин будут записываться на специальные кварцевые пластины. Эта технология была представлена проектом MS Silica (https://www.microsoft.com/en-us/research/project/project-silica/). По заверениям исследователей, этот формат позволит хранить данные несколько десятков тысяч лет. Когда произойдет первая запись — пока неизвестно.

Хранение это процесс!

P.S.

Какое-то время назад в Рунете бегали проекты “вечной” (облачной) флешки. Ни один из них не смог поднять каких-то значимых денег, как и организовать устойчивых продаж. Устроены они были по-разному: кто-то предлагал автомонтирование шифрованного диска, а кто-то требовал вставить сим-карту, и реально через свой интернет заливал куда-то данные. Возможно, дело в том, что людям не нужно облачное хранилище; им нужно хранение, которое не исчезнет.

В этом смысле сеть Starlink Илона Маска может тоже стать такой библиотекой, есть все составляющие, включая p2p-связь между узлами, для того, чтобы поддерживать процесс хранения — независимо от происходящего на Земле в это время.

Мой знакомый интересуется, нет ли среди читателей канала опытных разработчиков php, кто хотел бы неплохо поработать удаленно на фирму в UK? Разговорный английский предполагается, остальные детали — в личку

Я собрал немного информации по тому, кто и как читает курсы в рунете для менеджеров (ИТ)-продуктов. По моим оценкам и с учетом ее, можно прикинуть количество активных менеджеров продукта в 700 человек.

Допустим, все они приняли близко к сердцу историю про то, что надо идти от гипотез, и тратят время на проверки гипотез, успешные гипотезы развивают в продукт. Возьмем стандартную венчурную прикидку “каждый десятый выстреливает”. Это значит, что каждый год у нас должно громко взлетать 70 продуктов (условно). Но что-то не слыхать.

Дело или в курсах, или в менеджерах продуктов.

Читатели, наверное, знают, что я работаю техническим директором в финтех-компании. Техническим директором, который не оставляет попыток стать предпринимателем, чему работа в стартапе должна в теории способствовать -- тут можно узнать много нового, правда, сильно пожертвовав доходом. Одна из сложных задач, с которой я столкнулся, это то, как совмещать несколько ролей, это стандартная история в любой небольшой компании. Сейчас я совмещаю роли:
* архитектора
* технического директора
* руководителя проектов (на одном проекте, но крупном).

В принципе, удается делать это как-то с поправкой на то, что времени в сутках всего 24 часа. Что мне помогло больше всего на этом пути? Видеоматериалы по управлению бизнесом, литература по регулярному менеджменту, и общее понимание, как устроен организм компании. Точного ответа, как это делать, наверное, не существует, но можно рассказать о проблемах, с которыми сталкиваешься.

1. Задач много. Даже МНОГО. И поневоле приходится жертвовать качеством исполнения задач. Я пожертвовал качеством проработки архитектуры разрабатываемых систем, потому что риск потонуть, не получив достаточное финансирование, сильно выше, чем риск потонуть из-за плохого кода. Будут деньги -- перепишем. Как с этим борюсь -- железной дисциплиной тайм-менеджмента (несколько месяцев я жил, воображая себя автоматом по созданию и решению задач из Jira), жертвуя много личного времени в пользу работы.

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

3. Очень тяжело себя унижать за несделанное, потому что всегда считаешь себя лучше, чем ты есть. Это прям серьезная проблема, которая мешает работать результативно. Что помогает? Явно отдавать себе отчет, в шапочке какой роли ты играешь в данный момент. Предъявлять надо именно той роли себя, которая недовыполнила, помня, что у нее всего 0.5 дня, а не 1.

4. Не очень хорошо понимаешь, что делать с обязанностями совладельца компании. Да, такие тоже есть. От них я принял решение пока держаться подальше, переложив на плечи более опытных коллег-партнеров.

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

Из Авито пишут:

"..История успеха.

У нас много микросервисов, и их становилось всё больше и больше. В этой ситуации количество RPC-вызовов превращается в проблему. Например, на карточке объявления — а это одна из самых частотных страниц в Авито — для отрисовки страницы задействовано порядка 30 микросервисов. Причём это всё сделано не очень явно: вроде как вызываешь какую-то абстракцию, а под ней последовательно выполняются пять RPC-вызовов в другие сервисы.

С годами карточка объявления сильно деградировала. Один сильный разработчик целый квартал бился, оптимизировал, выводил все RPC-вызовы наружу. Когда он смог это сделать, он их запараллелил через Guzzle multi request — и получил вместо 30 последовательных синхронных запросов те же самые 30 запросов, но параллельных, что очень сильно ускорило работу. После этого рефакторинга время ответа карточки равняется максимальному времени ответа любого из сервисов. Но ему понадобился целый квартал, чтобы оптимизировать/переписать код отображения карточки объявления."

По мнению Авито, это -- история УСПЕХА.

Господа, в качестве эксперимента пробую подключить чат для обсуждений постов из этого канала. Ссылка на него: https://t.me/joinchat/AbWMbkUyIGyK8kriuMYviQ В чате работает бот-модератор, лучше не  кидаться с порога ссылками и пр.

ЦИАН рассказывает про эволюцию разработки (слева направо). Обратите внимание, что результат (в виде флажка) был только в той самой простой и "наивной" структуре

(pm - project manager, po - product owner, pmo - офис управления проектами)

Всегда удивлялся, как Илон Маск не теряет бодрости и бьется до смерти, выцарапывая на развитие компании (почитайте про взлеты и падения) те деньги, которые государство могло бы как пару чихов достать из кармана и "сделать" весь его план по Марсу на 50 лет вперед. Мне кажется, это должно быть ужасно демотивирующе

Пересидели React; надо найти еще немного сил пересидеть горячку с Go

Никак

Есть одна контора в SF, делают приложение Notion, нужное для того, чтобы организовать работу распределенных команд. Что характерно, все сидят в одном офисе рядом, потому что распределенно работать не выходит

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

Я нередко слышу, что многие не в восторге от времени, потраченного в ВУЗе, и от себя, потратившего это время.

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

Слушаю и удивляюсь. Я учился в ТРТУ (ныне часть ЮФУ), на не самом "крутом" радиотехническом факультете. Оглядываюсь и понимаю, что за время учебы удалось потрогать и разобраться:
- с полупроводниками и техпроцессами на них: диоды, транзисторы, ключи и разновидности. Да, техпроцессы на подшефном производстве были "смешные", 3000нм, но для промэлектроники их вполне хватает;
- расчетам токов и напряжений; анализам различных электронных схем;
- с ПЛИС/FPGA и CPLD, несколькими языками описания аппаратуры (VHDL, ahdl, systemC), причем нескольких вендоров: Altera, Xilinx
- силовыми машинами (теория и практика электропривода);
- изготовление печатных плат на производстве, от макетов до корпусирования плат в готовые изделия;
- с процессорами и микроконтроллерами, причем достаточно современными (диплом бакалавра у меня был ОСРВ для AVR с супербыстрым свитчем контекста и связанное с этим портирование подмножества с++ stdlib туда; магистрская работа была посвящена разработке java-подобной среды для маломощных микроконтроллеров-узлов IoT). Большие микропроцессоры -- да, не проходили; у соседней кафедры было и это;
- аннтеннам, радио, в т.ч. СВЧ и волноводам/микрополосковым топологиям. Оптоволокно не застали, да.

Разные сети, компиляторы и другая софтверная магия была немного не по нашему профилю, но многие факультативно смотрели и туда.

Может, не в ВУЗе дело?

В итоге на работе все напрограммированное нами богатство мы переводим в инсталляцию cloud foundry. Подозреваю, но не уверен до конца, что мы рискуем стать самым опытным оператором Cloud Foundry поверх OpenStack в России. Сами компоненты OpenStack управляется не напрямую, а релиз-менеджером bosh, который умеет и установку новых VM с необходимым ПО (релизами), и восстановление упавших вещей, и масштабирование — независимо, это часть CF, или что-то снаружи него стоит (гейт, БД, прочее).

Сам CF по своей сути это опен-сорсная версия облака типа Heroku, которая позволяет единообразно управлять и инфраструктурой исполнения, и загруженным в него ПО. Приложения для запуска можно обернуть в докер-контейнер или собирать билд-паками, специфичными для стека. Все это в итоге пакуется в контейнер -- не докер-образы, а дроплет для CRI-O.

Есть внутренний DNS, внутренняя оверлейная сеть на базе Silk, внутри все нарезается на изолированные "организации" и "пространства", есть SSO, поддерживается Open Service Broker API для подключения туда внешних сервисов типа DBaaS или чего-то другого - например, роутера для A/B деления траффика и т.п. Встроенные инструменты для мониторинга, логгирования, управления доступами, ротирования сертификатов и прочего тоже есть, есть и адаптеры к ELK, prometheus-стеку и т.д.

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

Учитывая, что лежащий внизу IaaS размазан по нескольких зонам доступности, в общем случае нам даже пожар в ДЦ не очень страшен - при условии, что будет организована доступность БД, которые стоят вне CF.

Очень хорошо получилось.