Контекст иногда сложно определить однозначно. Особенно имея возможность его менять динамически. Об этом, кстати, постоянно пишет Крокфорд. В том числе в последней его книге.
Есть система типов языка и система типов библиотеки. Это несколько разные вещи. Ко второй, например, относится сама схема. Т.е. это типы, используемые в библиотеке и поставляемые ей. Такие типы и их взаимодействие — система типов библиотеки. Это здесь и имелось ввиду.
Библиотека не была реализована в полной мере. Были задекларированы типы. В части типов и минимально готового функционала были произведены проверки. Конечно, промежуточный результат меня не мог устраивать.
Пропущено действительно очень много, а многое упрощено.
Говоря аналогиями, то это такой "mongoose для API". По факту задача тривиальна в рамках имплементации на js, но без качественной системы типов это бессмысленно. Много умных слов — издержки формы постановки задачи.
На самом деле это и был не линейный руководитель. Понимание назначении библиотеки было у всех, но не было понимания по системе типов. Здесь я допустил ошибку и не донес представление о сложностях реализации системы типов с ts.
Внедрения не было, я до него не добрался. Проверка идей проводилась как в рамках бизнес-приложений, так и в изолированной среде (проверка системы типов). Функциональная часть в большей степени была задекларирована перед разработкой, в период анализа и декомпозиции задачи. Изменения были минимальны. А вот в отношении системы типов пришлось исследовать возможности ts, вырабатывать практики. То есть мы делали ровно то, что требовалось, но с типизацией компайл-тайм. И эта типизация сожрала нам весь бюджет.
Может быть. Но я считаю, что сначала должна быть выражена главная идея инструмента, а для этого должна существовать возможность использования этого инструмента. Сейчас это может зайти как учебное пособие по тс, так как много практик по использованию системы типов тс. Но, конечно, мое мнение не догма и я рассматриваю вариант более скорой публикации репозитория
Сама задача концептуально понималась одинаково с обеих сторон. Кроме того, она была декомпозирована, согласована и прочее. Здесь была моя ошибка в неверной оценке, так как я изначально не думал делать сильную систему типов
Здесь важно то, что огромные инфраструктуры построены на JS и эти инфраструктуры поддерживаются разработчиками без знаний других языков. В связи с чем, процесс миграции на TS наименее болезненный, хотя даже здесь встречаются ярые противники добавления типизации. То есть по сути выбирать и не приходится (разве что рассматривать flow vs ts)
Верно. Но json-schema — это стандарт. Стандартам никогда не следуют, если нет жестких рамок инструментария. В случае с json-schema поддержка ts библиотеками практически отсутствует. Мы бы могли поддержать только этот стандарт, но мы решили дать возможность пользователю определять самостоятельно тот формат, который он хочет, либо воспользоваться теми, что мы поддерживаем.
Конечно в перфомансе здесь выигрыша нет.
Тем не менее, библиотека не занимает большого объема в рантайме и не сжирает кучу памяти. Что касается оптимизаций, то вполне можно использовать стандартные практики и результат будет такой же.
В системах старого типа — да. Но есть системы, в которых не только бек определяет формат обмена.
И тут манипуляции с данными нужны на фронте. Ведь сервисов, используемых фронтом — не один, и с разными рода апи.
Идея в том. что нужно сделать фронтенд приложение, которое сравнительно дешево сможет супортить огромное количество принципиально разных API
Тоже не совсем верно. Не в теории, а в законе. Понятно, что кидалово знатное, недаром введены баллы. Тем не менее, не стоит забывать что это все же капитал, хоть и в виде обязательства. Его могут получить по наследству, обменять (если таковое будет возможно), погасить им кредит (точно будет что-то такое) и т.д. Конечно, все может быстро поменяться и пенсий не будет вовсе (де-факто), но приходится ориентироваться по текущей ситуации.
Неверно. Такие отчисления — это не налог, а собственный капитал. Пенсия берется из него, если не учитывать дополнительные соц. части. Мол, чтобы до пенсии не прожрал все заработанное. В противном случае, нельзя было бы рассчитать/прогнозировать свою пенсию сейчас, ведь пенсию платит тот, кто работает — как работает, так и получаю.
А ещё ссылка на подкаст, ага. И даже чатик в телеге https://t.me/myobrecheny. Ух
Маразм крепчал (простите)
Контекст иногда сложно определить однозначно. Особенно имея возможность его менять динамически. Об этом, кстати, постоянно пишет Крокфорд. В том числе в последней его книге.
Пропущено действительно очень много, а многое упрощено.
Может быть. Но я считаю, что сначала должна быть выражена главная идея инструмента, а для этого должна существовать возможность использования этого инструмента. Сейчас это может зайти как учебное пособие по тс, так как много практик по использованию системы типов тс. Но, конечно, мое мнение не догма и я рассматриваю вариант более скорой публикации репозитория
Да, мы все еще хотим ее доделать и заопенсорсить. В ней еще довольно много работы и скорей всего придется переосмыслить дизайн в некоторой части.
Сама задача концептуально понималась одинаково с обеих сторон. Кроме того, она была декомпозирована, согласована и прочее. Здесь была моя ошибка в неверной оценке, так как я изначально не думал делать сильную систему типов
Здесь важно то, что огромные инфраструктуры построены на JS и эти инфраструктуры поддерживаются разработчиками без знаний других языков. В связи с чем, процесс миграции на TS наименее болезненный, хотя даже здесь встречаются ярые противники добавления типизации. То есть по сути выбирать и не приходится (разве что рассматривать flow vs ts)
Дополнительные абстракции действительно есть. Но в них нет сложных алгоритмических преобразований в рантайме. Это такая минимальная плата за дизайн.
Верно. Но json-schema — это стандарт. Стандартам никогда не следуют, если нет жестких рамок инструментария. В случае с json-schema поддержка ts библиотеками практически отсутствует. Мы бы могли поддержать только этот стандарт, но мы решили дать возможность пользователю определять самостоятельно тот формат, который он хочет, либо воспользоваться теми, что мы поддерживаем.
Конечно в перфомансе здесь выигрыша нет.
Тем не менее, библиотека не занимает большого объема в рантайме и не сжирает кучу памяти. Что касается оптимизаций, то вполне можно использовать стандартные практики и результат будет такой же.
В системах старого типа — да. Но есть системы, в которых не только бек определяет формат обмена.
И тут манипуляции с данными нужны на фронте. Ведь сервисов, используемых фронтом — не один, и с разными рода апи.
Идея в том. что нужно сделать фронтенд приложение, которое сравнительно дешево сможет супортить огромное количество принципиально разных API
Тоже не совсем верно. Не в теории, а в законе. Понятно, что кидалово знатное, недаром введены баллы. Тем не менее, не стоит забывать что это все же капитал, хоть и в виде обязательства. Его могут получить по наследству, обменять (если таковое будет возможно), погасить им кредит (точно будет что-то такое) и т.д. Конечно, все может быстро поменяться и пенсий не будет вовсе (де-факто), но приходится ориентироваться по текущей ситуации.
Неверно. Такие отчисления — это не налог, а собственный капитал. Пенсия берется из него, если не учитывать дополнительные соц. части. Мол, чтобы до пенсии не прожрал все заработанное. В противном случае, нельзя было бы рассчитать/прогнозировать свою пенсию сейчас, ведь пенсию платит тот, кто работает — как работает, так и получаю.
360-ФЗ. Статья 7, О порядке финансирования выплат за счет средств пенсионных накоплений
Значит, мне придется это выложить в опенсорс, оформив, как полагается в npm. И все же, где мне посмотреть твой лучший код?
У тебя есть доступ в приватный репо. Твой выход
Да
У меня нет инстаграма!