Всё таки не до конца понял разницу между протоколом, контрактом и интерфейсом В словаре HowProgrammingWorks нашел только определение интерфейса, но и в нем также упоминается контракт Есть какой-то дополнительный материал на эту тему?
Показали как описывать контракты... спасибо) А как это все валидировать? Хотелось бы увидеть код валидирущий все выше написанное + последовательность как это все работает в связке. Или хотябы название либы, которая делает подобную валидацию.
Спасибо. Жду когда будете production-ready, хотелось бы попробовать пописать на вашем стеке. Еще в мире TS есть генерации openapi клиентов с проверкой в compile time. Еще можно строить монорепозиторий и использовать в нескольких проектах одни и те же контракты TS. Еще можно выносить тайпинги в отдельный npm пакет.
@@user-te4bh4pp9f поищи как npm умеет устанавливать зависимости из гитхаба, они прям в package.json прописываются урлами и если закрытый репозиторий то будет использоваться ssh ключи, добавленные на локальную машину как при обычной работе с git
Спасибо за лекцию и ваш труд в целом! Похоже на spec из языка программирования clojure, там тоже можно гинерить тесты на основе spec. Кстати, что думаете о языке clojure и о лиспах в частности?
Я может что-то не понимаю, но декларативная валидация - это какая-то полумера. Вот я, например, хочу в определенном поле получить не просто строку, а строку в заданном формате, пусть это будет один из формат для дат, а сама дата при этом должна быть не меньше заданной даты - без императивщины тут не обойтись, если только не придумать свой dsl(и это не выглядит чем-то лучшим, чем процедурно пройтись по строке)
Конечно нужно везде расширять DSL и не писать императивщины, потому, что DSL вы 1 раз напишите, а императивщину каждый раз будете писать и в ней ошибок проще наделать.
Потому, что все функции в стандарте контрактов Метархии возвращают промисы, т.е. они все асинхронные, т.к. могут быть вызваны с клиента или другого потока.
Лекция не про либы, а про принцип написания декларативных контрактов. Напишите сами или используйте те либы, которым вы доверяетя. Я доверяю вот своим, а тем, что в npm не доверяю. Я и другие контрибьюторы Метархии уж наверняка лучше программируют среднестатистического автора либы из npm )
@@TimurShemsedinov ну, выглядит именно, как реклама метархии. И как по мне тема контрактного программирования не раскрыта именно из-за фокуса на метархии, которая во-первых, использует свою собственную метасхему, во-вторых, построена на едином пространстве имен, и в-третьих, собственно, не рассмотрены альтернативные метархии инструменты.
@@dimitro.cardellini это не обзор и не научное исследование, чтобы быть незаангажированным, для того, чтоб донести идею, не нужно рассматривать альтернативы, лекция показывает принцип
@@TimurShemsedinov может, я конечно, придираюсь, но на мой взгляд, идея-то и не раскрыта. Вот просто давай представим, что студент прослушал эту лекцию и упомянул "контрактное программирование" на собесе. И вот ему зададут вопрос: "а зачем нужно контрактное программирование?" А может не повезти и спросять о трейдоффах КП?
дякую . проте набаго краще було б показати якись простий код який цей контракт вичитує і зним працює. ато виглядає як працювати з віндовс реестром щоб іконку поміняти і типу програмування під віндовс :)
чего только не придумают, лишь бы не использовать тс, декораторы, и нормальный фреймворк с либами из коробки (я про nest). И как с этим фреймворком дружит ide? Или надо каждый раз помнить/подсматривать, что там за поля, у аргументов.
Схемы генерируют тайпинги и во всех иде все подтягивается, так что проверки и в рантайме и при разработке. И интроспекция по схемам и на фронте и на бэке, единый источник правды. Декораторы мертвы вместе, когда их щаменят вы будете переписывать все. А нест - это фрактал оверинженеринга.
@@MrVooDo1203 простые вещи делаются очень сложно, вот сравни, в метархии чтоб api эндпоинт для сложения двух чисел нужно создать файл /api/interfaceName/add с кодом ({ method: ({ a, b }) => a + b });
Всё таки не до конца понял разницу между протоколом, контрактом и интерфейсом
В словаре HowProgrammingWorks нашел только определение интерфейса, но и в нем также упоминается контракт
Есть какой-то дополнительный материал на эту тему?
Жёлтые лекции мои любимые
Показали как описывать контракты... спасибо) А как это все валидировать? Хотелось бы увидеть код валидирущий все выше написанное + последовательность как это все работает в связке. Или хотябы название либы, которая делает подобную валидацию.
Супер, дякую за лекції
Чемпионат по бесконтрактному программированию объявляется открытым!
Спасибо!
Спасибо. Жду когда будете production-ready, хотелось бы попробовать пописать на вашем стеке. Еще в мире TS есть генерации openapi клиентов с проверкой в compile time. Еще можно строить монорепозиторий и использовать в нескольких проектах одни и те же контракты TS. Еще можно выносить тайпинги в отдельный npm пакет.
Не обязательно в npm пакет, можно просто тайпинги в отдельный гитхаб репозиторий
@@TimurShemsedinov А как тогда ими пользоваться?
@@user-te4bh4pp9f поищи как npm умеет устанавливать зависимости из гитхаба, они прям в package.json прописываются урлами и если закрытый репозиторий то будет использоваться ssh ключи, добавленные на локальную машину как при обычной работе с git
Спасибо за лекцию и ваш труд в целом!
Похоже на spec из языка программирования clojure, там тоже можно гинерить тесты на основе spec. Кстати, что думаете о языке clojure и о лиспах в частности?
Лиспы это хорошо, стоит учить, даже если не пригодится, для расширения сознания
Конечно же в JS есть контрактное программирование! Просто напиши его сам!
Я может что-то не понимаю, но декларативная валидация - это какая-то полумера. Вот я, например, хочу в определенном поле получить не просто строку, а строку в заданном формате, пусть это будет один из формат для дат, а сама дата при этом должна быть не меньше заданной даты - без императивщины тут не обойтись, если только не придумать свой dsl(и это не выглядит чем-то лучшим, чем процедурно пройтись по строке)
Конечно нужно везде расширять DSL и не писать императивщины, потому, что DSL вы 1 раз напишите, а императивщину каждый раз будете писать и в ней ошибок проще наделать.
Очень удобно для разных сравниваемых типов делать { min: value1, max: value2 }
Почему не обойтись? Вполне можно обойтись без императивщины.
Не стоит путать проприетарную мета схему и декларативное программирование.
@@dimitro.cardellini метасхема не проприетарная, это mit лицензия
@@TimurShemsedinov о, извиняюсь, да -- это open source.
Почему контракт compare описан так что method вернёт Promise, а вот returns просто boolean?
Потому, что все функции в стандарте контрактов Метархии возвращают промисы, т.е. они все асинхронные, т.к. могут быть вызваны с клиента или другого потока.
а как называется этот файловый менеджер ?
Похоже на Far
В npm полно либ для валидации любых полей, объектов и тд. Не совсем понял какое именно преимущество есть у метахрии в этом плане?
Лекция не про либы, а про принцип написания декларативных контрактов. Напишите сами или используйте те либы, которым вы доверяетя. Я доверяю вот своим, а тем, что в npm не доверяю. Я и другие контрибьюторы Метархии уж наверняка лучше программируют среднестатистического автора либы из npm )
@@TimurShemsedinov но это не точно.
@@TimurShemsedinov ну, выглядит именно, как реклама метархии.
И как по мне тема контрактного программирования не раскрыта именно из-за фокуса на метархии, которая во-первых, использует свою собственную метасхему, во-вторых, построена на едином пространстве имен, и в-третьих, собственно, не рассмотрены альтернативные метархии инструменты.
@@dimitro.cardellini это не обзор и не научное исследование, чтобы быть незаангажированным, для того, чтоб донести идею, не нужно рассматривать альтернативы, лекция показывает принцип
@@TimurShemsedinov может, я конечно, придираюсь, но на мой взгляд, идея-то и не раскрыта.
Вот просто давай представим, что студент прослушал эту лекцию и упомянул "контрактное программирование" на собесе.
И вот ему зададут вопрос: "а зачем нужно контрактное программирование?"
А может не повезти и спросять о трейдоффах КП?
дякую . проте набаго краще було б показати якись простий код який цей контракт вичитує і зним працює. ато виглядає як працювати з віндовс реестром щоб іконку поміняти і типу програмування під віндовс :)
чего только не придумают, лишь бы не использовать тс, декораторы, и нормальный фреймворк с либами из коробки (я про nest). И как с этим фреймворком дружит ide? Или надо каждый раз помнить/подсматривать, что там за поля, у аргументов.
Схемы генерируют тайпинги и во всех иде все подтягивается, так что проверки и в рантайме и при разработке. И интроспекция по схемам и на фронте и на бэке, единый источник правды. Декораторы мертвы вместе, когда их щаменят вы будете переписывать все. А нест - это фрактал оверинженеринга.
а вот поддержку IDE здорово было бы улучшать. но это уже совсем другая история
@@andreysakharov6210 Все баги и запросы на фичи репортай в репозиторий
@@TimurShemsedinov nest.js оверинджерининг? а в чем заключается оверинджениринг? что не так с этим фреймворком?
@@MrVooDo1203 простые вещи делаются очень сложно, вот сравни, в метархии чтоб api эндпоинт для сложения двух чисел нужно создать файл /api/interfaceName/add с кодом ({ method: ({ a, b }) => a + b });