Один раз пишем ансибл плейбук который все под вас делает и разворачивается в одну в одну команду на подавляющем большинстве OS. Голый баш, как мне кажется, оправданно держать только на продакшн серверах.
Существенное увеличение бинарника из-за 256-битных типов действительно странно, надо глядеть почему так получилось
Есть подозрение что там все внутри на генериках и добавление типов вызвало "комбинаторный взрыв" тк понадобилось синтезировать код для всех новых зависимых типов (конверторы, сериализаторы, проверки итд).
Спасибо. Я читал оригинал на английском и там ровно также не понятно как в этой статье (перевод прям почти один-в-один). А вот в видео стало понятно о чем разговор.
Тем кому лень смотреть - там время начинает считаться с момента запуска установки и посмотрев всего на 1 измерение можно сказать сколько времени прошло с начала работы.
Это вы наверное не сталкивались с подходом когда большая часть проверок отдается компилятору и системе типов. Как пример - scala zio (ну или Haskell). Там компилятор по рукам бьёт если забыть, к примеру, обработать ошибку. Ну и также там можно создавать dsl которые не позволяют в неправильном порядке пользоваться операциям.
Те в итоге при правильном подходе и дисциплине при код ревью тесты остаются только 3х типов.
1 - тесты которые написаны для сравнения концепций или скорости работы разных подходов
2 - интеграционные тесты по конкретным сценариям использования
Так берем тот-же логстеш или грейлог и настраиваем обработчики. Те логсервер уже обладает возможностью сам структурировать любой неструктурированный текс через, к примеру, горк
Да. Только если это компилятор решает - это хорошо он ещё способен отследить все зависимости. А человек - не способен. Человек, в среднем, не способен отследить взаимодействия между 4-5 микросервисами "своей" кодовой базы. Пусть это делают машины
Ага. А ещё прям бесит что из-за того что на подстановку так "затрачиваются" - забыли все остальное что аж выразили это в DRY. (Это я не буду тут ещё рассуждать почему ооп - недоказуемая концепция)
Это лид написал? А звучит как нытье мидла - "все сложно, и учится сложно", а вот ещё тут, "не поверите" оказывается что паттерны управления прямо не копируются межу командами. И да процессы "надо строить", даже если ты один кто это видит
Почему-то никто не вспомнил квест "Следствие ведут Колобки", хотя он был тех-же времен что и Петька.
А ещё была игра от создателей вангеров - там было поле над которым летали шарики нескольких цветов и сталкивались. И можно было задать что происходит при столкновениях (уничтожаются, размножаться итд) и надо было все шарики один цвет перекрасить. Вот вообще забыл как называлась.
Я тут как разработчик софта скажу. Чем выше параллельность схемы взаимодействия тем проще такие ошибки допустить и не заметить при тестировании.
Я помню как мой код сам себя убивал при попытке восстановления на кластере из всего 50 машин. И там были строгие ревью итд. И нашли мы этот баг через несколько месяцев. Ну как нашли. Первый раз выхватили. Потом ещё пару месяцев учились воспроизводить.
Так что я больше верю что это просто ошибка в сложной системе.
Простите, а откуда на военной технике гражданские микросхемы? Особенно в ракетах?
Я вот вообще не сторонник теории что есть смысл в аппаратных закладках в процессоре, но ваш аргумент про гражданский кремний в ракете выглядит совсем слабо (
Это просто инструмент. Пневмо-молоток и электро-лобзик не уничтожили столяров.
Один раз пишем ансибл плейбук который все под вас делает и разворачивается в одну в одну команду на подавляющем большинстве OS. Голый баш, как мне кажется, оправданно держать только на продакшн серверах.
Ну в SpaceX у него сработало-же, и в Tesla. Так что он и сюда это тащит. Будем посмотреть.
Будьте осторожны с поиском документации на ss. Ходил по этим граблям)))))
Есть подозрение что там все внутри на генериках и добавление типов вызвало "комбинаторный взрыв" тк понадобилось синтезировать код для всех новых зависимых типов (конверторы, сериализаторы, проверки итд).
Спасибо. Я читал оригинал на английском и там ровно также не понятно как в этой статье (перевод прям почти один-в-один). А вот в видео стало понятно о чем разговор.
Тем кому лень смотреть - там время начинает считаться с момента запуска установки и посмотрев всего на 1 измерение можно сказать сколько времени прошло с начала работы.
Это вы наверное не сталкивались с подходом когда большая часть проверок отдается компилятору и системе типов. Как пример - scala zio (ну или Haskell). Там компилятор по рукам бьёт если забыть, к примеру, обработать ошибку. Ну и также там можно создавать dsl которые не позволяют в неправильном порядке пользоваться операциям.
Те в итоге при правильном подходе и дисциплине при код ревью тесты остаются только 3х типов.
1 - тесты которые написаны для сравнения концепций или скорости работы разных подходов
2 - интеграционные тесты по конкретным сценариям использования
3 - тесты на закрытие багов
Нагрузочные тесты оставим за скобками.
Так берем тот-же логстеш или грейлог и настраиваем обработчики. Те логсервер уже обладает возможностью сам структурировать любой неструктурированный текс через, к примеру, горк
А какие есть гарантии что вашу бумажку не потеряли?
Вы не поверите, но GIT это блокчейн (тогда правда слова такого не было). Каждая репа Гита сама по себе полная нода. Согласование "блоков" тоже есть.
Может вы технологии блокчейна с его внешними утилитами путаете?
Кстати гит даже решил вопрос как хранить бинарные блоки большие (1GB+) увязывая их с историей изменений текстовых данных
Да. Только если это компилятор решает - это хорошо он ещё способен отследить все зависимости. А человек - не способен. Человек, в среднем, не способен отследить взаимодействия между 4-5 микросервисами "своей" кодовой базы. Пусть это делают машины
"На практике любой, имеющий доступ к данным и компьютеру, может сегодня обучить модель машинного обучения."
Ай. Больно стало. Дальше читать не смог.
А почему это нельзя выразить типами? Отвратительный опыт когда твой код после компилятора ломается в проде
Тут вся школа ФП-на-эффектах икнула. ZIO/CATS на скале к примеру.
Причем фоннейман - это лямбда-счисление которые доказывается. А тьюринг - недоказуемая модель
Ага. А ещё прям бесит что из-за того что на подстановку так "затрачиваются" - забыли все остальное что аж выразили это в DRY. (Это я не буду тут ещё рассуждать почему ооп - недоказуемая концепция)
Это лид написал? А звучит как нытье мидла - "все сложно, и учится сложно", а вот ещё тут, "не поверите" оказывается что паттерны управления прямо не копируются межу командами. И да процессы "надо строить", даже если ты один кто это видит
Почему-то никто не вспомнил квест "Следствие ведут Колобки", хотя он был тех-же времен что и Петька.
А ещё была игра от создателей вангеров - там было поле над которым летали шарики нескольких цветов и сталкивались. И можно было задать что происходит при столкновениях (уничтожаются, размножаться итд) и надо было все шарики один цвет перекрасить. Вот вообще забыл как называлась.
А это, простите, для какого процесса? Оно хотя-бы для 12нм ещё работает? (Я просто пока не успел статью прочитать)
Я тут как разработчик софта скажу. Чем выше параллельность схемы взаимодействия тем проще такие ошибки допустить и не заметить при тестировании.
Я помню как мой код сам себя убивал при попытке восстановления на кластере из всего 50 машин. И там были строгие ревью итд. И нашли мы этот баг через несколько месяцев. Ну как нашли. Первый раз выхватили. Потом ещё пару месяцев учились воспроизводить.
Так что я больше верю что это просто ошибка в сложной системе.
Простите, а откуда на военной технике гражданские микросхемы? Особенно в ракетах?
Я вот вообще не сторонник теории что есть смысл в аппаратных закладках в процессоре, но ваш аргумент про гражданский кремний в ракете выглядит совсем слабо (