Категорически согласен. Хотя многие вещи, там описанные, уже реализованы в современных языках, в SICP очень круто рассказано, как проектировать софт.
А от меня — Дейкстра, «Дисциплина программирования». Формальный подход к верификации и проектированию программы — то, что, кажется, невозвратно утеряно поколением разрабов-макак.
Охренеть, это теперь продвинутые возможности. Видимо, шутка про рекурсию теперь не только про php-шников?
Давайте в следующий раз про оптимизацию хвостовой рекурсии? А, и ещё можно линзы описать в статье «Ультра-фичи js, для понимания которых нужно три докторских степени»
В «меньше килобайта» с трудом влезут конфиги вебпака и тайпскрипта. Скорее, тут почти мегабайт. И да, в такой ситуации 90 секунд — это «всего», я видел проект вдвое меньше, который собирался вдвое дольше.
Есть уязвимости десериализации, позволяющие выполнять произвольный код (например, при десериализации в объект процесса можно запустить код; видел эту тему сто лет назад, точно не скажу, где, скорее всего на dotnext). Другое дело, что на кой чёрт в системе может понадобиться такая сущность…
1. Версионирование, конвеншнл, семвер
Честно — не слышал. Да, так, конечно, правильнее будет.
2.
> Докер, переносимость, не, не слышали?
Непонел. Для минимального проекта образа от MS вполне хватает; если есть зависимость на тулы кроме дотнета — да, надо собирать свой образ со всем необходимым тулингом, но для обычного пет-проекта в большинстве случаев должно хватать и стандартного образа.
3. Срок хранения артефактов
Тут в артефакты вынесены результаты сборки не для того, чтобы их потом скачивать пользователям — для них есть пакеты в фиде. Если появляется необходимость публиковать что-то через артефакты, то 1) можно им настроить срок хранения, да, 2) можно их скопировать поближе к корню, чтобы юзерам не продираться через 100500 папок. Но опять же, в статье — о том, как собрать либу в пакет и отправить в фид.
4. Защищенные шаги
Буду признателен ссылке на документацию. Хранить токен в переменной — такое себе решение, на azure это, на мой взгляд, лучше настраивается
5.
> Ну и не хватает отдельных проверок
Да, согласен, можно настроить пре-коммит, и вообще можно много интересного сделать для процесса. Только код-стайл и многие другие проверки, я считаю, должны выполняться до коммита, чтобы не было возможности даже пушнуть что-то не то.
Согласен, повторяющиеся задачи по созданию инфраструктуры руками делать — фу. Но один личный фид создать уж можно.
В конце статьи написал, что в будущем собираюсь написать, как к этому делу прикрутить авторазвёртывание и, соответственно, обеспечение инфраструктуры с Pulumi.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
А от меня — Дейкстра, «Дисциплина программирования». Формальный подход к верификации и проектированию программы — то, что, кажется, невозвратно утеряно поколением разрабов-макак.
Давайте в следующий раз про оптимизацию хвостовой рекурсии? А, и ещё можно линзы описать в статье «Ультра-фичи js, для понимания которых нужно три докторских степени»
Спасибо!
1. Версионирование, конвеншнл, семвер
Честно — не слышал. Да, так, конечно, правильнее будет.
2.
> Докер, переносимость, не, не слышали?
Непонел. Для минимального проекта образа от MS вполне хватает; если есть зависимость на тулы кроме дотнета — да, надо собирать свой образ со всем необходимым тулингом, но для обычного пет-проекта в большинстве случаев должно хватать и стандартного образа.
3. Срок хранения артефактов
Тут в артефакты вынесены результаты сборки не для того, чтобы их потом скачивать пользователям — для них есть пакеты в фиде. Если появляется необходимость публиковать что-то через артефакты, то 1) можно им настроить срок хранения, да, 2) можно их скопировать поближе к корню, чтобы юзерам не продираться через 100500 папок. Но опять же, в статье — о том, как собрать либу в пакет и отправить в фид.
4. Защищенные шаги
Буду признателен ссылке на документацию. Хранить токен в переменной — такое себе решение, на azure это, на мой взгляд, лучше настраивается
5.
> Ну и не хватает отдельных проверок
Да, согласен, можно настроить пре-коммит, и вообще можно много интересного сделать для процесса. Только код-стайл и многие другие проверки, я считаю, должны выполняться до коммита, чтобы не было возможности даже пушнуть что-то не то.
В конце статьи написал, что в будущем собираюсь написать, как к этому делу прикрутить авторазвёртывание и, соответственно, обеспечение инфраструктуры с Pulumi.