Потому что сквош коммитов уничтожает историю того что когда было сделано и зачем. То что коммиты не несут смысловой нагрузки это скилл ишью, надо подписывать нормально. То что они мешают лог смотреть это тоже скилл ишью, флаг —first-parent для этого существует.
Дело в том, что у рекрутёра нет времени на просмотр всех резюме. Он смотрит на то, что соискатель рассказывает в сопроводительном письме.
Объясните кто-нибудь пожалуйста, почему у рекрутёра нету времени на просмотр резюме?
Это же его работа буквально. Слишком много резюме? Ну так не собирайте столько откликов сколько не можете отсмотреть. Зачем мне в письме писать то, что у меня в резюме уже написано? Это же ну просто невероятная глупость. Или сделайте там себе ИИшку что ли чтобы она TLDR по резюме выдавала рекрутёру раз такие занятые.
синтаксис интерпретатора не имеет отношения к POSIX. POSIX регламентирует только набор утилит и наличие некоторого командного интерфейса, но не синтаксис скриптинга. Bash совместим с синтакисом Shell, который в своё время был частью Unix.
Это неправда. Стандарт IEEE 1003.1-2024 / Shell & Utilities / Shell Command Language определяет синтаксис интерпретатора в точности.
Кстати отдельного упоминания заслуживает powershell, который по умолчанию на Винде и прекрасно ставится на Линукс. Неиронично один из лучших современных шелов, на порядок удобнее POSIX совместимых.
Я реально не понимаю зачем нужны проекты вроде fish/nushell и прочие попытки переизобрести шел. Основное преимущество POSIX совместимых шелов в том что скрипты работают везде из коробки, на любой POSIX системе. Меня тоже страшно корёжит от POSIX шела но в этом плане он практически безальтернативен.
В ином случае, если не нужна POSIX совместимость, то есть если вы можете просто поставить любое нужное рантайм окружение на целевую машину типа fish, то почему бы не использовать нормальный язык программирования вместо всего этого зоопарка?
ИМХО sh прекрасно справляется с однострочниками и ужасно со всем остальным, зато переносимо. Если переносимость не нужна то просто пишите на питоне, там всё уже придумано и не нужно учить очередной чудной синтаксис.
Помимо возни с "нейтральными" названиями main имхо в целом немного лучше семантически подходит чем master для основной ветки. Слово master имеет семантику владения и/или контроля, мастер ветка в гите ничего не контролирует. Все ветки равны, она просто основная или приоритетная, что и отражает слово main куда более явно.
Во первых, как уже подметили выше, тип функции в виде стрелки вовсе не означает что реализация должна быть стрелкой. Это вообще никак не связано и я, если честно, никогда до этого не видел чтобы это так интерпретировали. Поэтому в целом смысла в такой "синхронизации" не нахожу. Стрелки в интерфейсах нужны только чтобы вариантность правильно расставлять. Какая интерфейсу разница как его реализации будут this привязывать?
Во вторых, у тс уже есть способ статически проверять привязку this:
class Foo {
bar(this: this) {}
}
const foo = new Foo()
foo.bar() // Ok
const bar = foo.bar
bar() // Error: The 'this' context of type 'void' is not assignable to method's 'this' of type 'Foo'
Весь смысл притиера в том что он не настаивается, чтобы было поменьше споров о том как его настраивать. И он не один такой, biome и deno например так же делают. Я если честно не очень понимаю какая вообще необходимость в сверхтонкой настройке форматера, как будто высокое искусство какое-то. Парочки предпочтений уровня пробелы/табы и '/" более чем достаточно.
Я использую биом, в петах и на работе. Он конечно не заменяет еслинт полноценно, но мне его более чем хватает в замен на существенно меньший гемор с настройкой.
По вашему мой пример выше это НАРУШЕНИЕ структурной вариантности?
В вашем примере структурная и номинальная вариантности не совпадают, это ошибка. От этого предостерегает документация, потому что поведение тайпчекера в таких случаях не определено. Вы выстраиваете зависимость от нестабильной и незадокументированной детали реализации.
Какое тогда по вашему мнению правильное использование аннотаций, которое не меняет тайпчекер?
Основным применением аннотаций на данный момент считается оптимизация измерения вариантности в тайпчекере для повышения производительности в редакторе. Приходить к выводу что это необходимо следует только после анализа трейсов языкового сервера, выявившего значительную потерю производительности при измерении вариантности.
Так же аннотации могут использоваться в целях документирования вариантности параметров обобщённых типов, но это не совсем удобно потому что их легко можно случайно поставить неправильно.
Ещё у них упоминаются "крайне редкие случаи с рекурсивными типами" когда вариантность измеряется неправильно, но примеров таких случаев я пока лично не видел, это искать надо.
А вот собственно пример почему их не нужно так использовать (такой тоже есть в документации):
type ContravariantMethod<in V> = {
process(v: V): void;
}
declare let a: ContravariantMethod<Cat>
declare let b: ContravariantMethod<Animal>
a = b // Ок
b = a // Ошибка
b = { ...a } // Снова ок
Его можно изменить с помощью явных аннотаций вариантности.
Если вы почитаете документацию которую прикрепили то откроете для себя что так делать крайне не желательно. Там это написано выделенным шрифтом специально 5 раз, потому что аннотации вариантности нужны не для этого.
Пока что единственным инструментом который "продал" мне инъекцию зависимостей в жс стал effect. Почти все подобные инструменты пытались навязать мне запихивание любой сущности в класс и обмазывание декораторами, никогда не понимал почему кто-то считает что это удобно. Не говоря уже о том что никакой статической гарантии того что ты правильно построил зависимости не будет скорее всего, за этим сам следи. Эффект в сравнении со всем этим кажется таким простым и понятным.
Жалко что не написали как gitops делается на vps. По факту это настолько просто что целый специальный хостинг без надобности. Достаточно вместо того чтобы делать docker compose up напрямую на сервере создать удалённый контекст:
docker context create vps --docker "host=ssh://me@example.com"
docker context use vps
И можно деплоить на vps из того же github workflow.
Проверка на лишние свойства не работает везде потому что не должна. Система типов нечего против лишних свойств не имеет, они всегда допустимы. Проверка на лишние свойства существует в тех местах где по мнению разработчиков они провоцируют баги, не смотря на то что типы верны. Это как жаловаться что правила линтера можно обойти.
Потому что сквош коммитов уничтожает историю того что когда было сделано и зачем. То что коммиты не несут смысловой нагрузки это скилл ишью, надо подписывать нормально. То что они мешают лог смотреть это тоже скилл ишью, флаг —first-parent для этого существует.
На ЯП со статической типизацией будет ещё лучше, жалко таких встраиваемых не так много. Кроме TS есть например ещё KTS.
Если нужно что-то сложнее ямла не понимаю в чем проблема какой-нибудь луа использовать
Объясните кто-нибудь пожалуйста, почему у рекрутёра нету времени на просмотр резюме?
Это же его работа буквально. Слишком много резюме? Ну так не собирайте столько откликов сколько не можете отсмотреть. Зачем мне в письме писать то, что у меня в резюме уже написано? Это же ну просто невероятная глупость. Или сделайте там себе ИИшку что ли чтобы она TLDR по резюме выдавала рекрутёру раз такие занятые.
Это неправда. Стандарт IEEE 1003.1-2024 / Shell & Utilities / Shell Command Language определяет синтаксис интерпретатора в точности.
Кстати отдельного упоминания заслуживает powershell, который по умолчанию на Винде и прекрасно ставится на Линукс. Неиронично один из лучших современных шелов, на порядок удобнее POSIX совместимых.
Я реально не понимаю зачем нужны проекты вроде fish/nushell и прочие попытки переизобрести шел. Основное преимущество POSIX совместимых шелов в том что скрипты работают везде из коробки, на любой POSIX системе. Меня тоже страшно корёжит от POSIX шела но в этом плане он практически безальтернативен.
В ином случае, если не нужна POSIX совместимость, то есть если вы можете просто поставить любое нужное рантайм окружение на целевую машину типа fish, то почему бы не использовать нормальный язык программирования вместо всего этого зоопарка?
ИМХО sh прекрасно справляется с однострочниками и ужасно со всем остальным, зато переносимо. Если переносимость не нужна то просто пишите на питоне, там всё уже придумано и не нужно учить очередной чудной синтаксис.
Помимо возни с "нейтральными" названиями main имхо в целом немного лучше семантически подходит чем master для основной ветки. Слово master имеет семантику владения и/или контроля, мастер ветка в гите ничего не контролирует. Все ветки равны, она просто основная или приоритетная, что и отражает слово main куда более явно.
Во первых, как уже подметили выше, тип функции в виде стрелки вовсе не означает что реализация должна быть стрелкой. Это вообще никак не связано и я, если честно, никогда до этого не видел чтобы это так интерпретировали. Поэтому в целом смысла в такой "синхронизации" не нахожу. Стрелки в интерфейсах нужны только чтобы вариантность правильно расставлять. Какая интерфейсу разница как его реализации будут
thisпривязывать?Во вторых, у тс уже есть способ статически проверять привязку
this:Весь смысл притиера в том что он не настаивается, чтобы было поменьше споров о том как его настраивать. И он не один такой, biome и deno например так же делают. Я если честно не очень понимаю какая вообще необходимость в сверхтонкой настройке форматера, как будто высокое искусство какое-то. Парочки предпочтений уровня пробелы/табы и '/" более чем достаточно.
Я использую биом, в петах и на работе. Он конечно не заменяет еслинт полноценно, но мне его более чем хватает в замен на существенно меньший гемор с настройкой.
В вашем примере структурная и номинальная вариантности не совпадают, это ошибка. От этого предостерегает документация, потому что поведение тайпчекера в таких случаях не определено. Вы выстраиваете зависимость от нестабильной и незадокументированной детали реализации.
Основным применением аннотаций на данный момент считается оптимизация измерения вариантности в тайпчекере для повышения производительности в редакторе. Приходить к выводу что это необходимо следует только после анализа трейсов языкового сервера, выявившего значительную потерю производительности при измерении вариантности.
Так же аннотации могут использоваться в целях документирования вариантности параметров обобщённых типов, но это не совсем удобно потому что их легко можно случайно поставить неправильно.
Ещё у них упоминаются "крайне редкие случаи с рекурсивными типами" когда вариантность измеряется неправильно, но примеров таких случаев я пока лично не видел, это искать надо.
Где здесь эта же ситуация? Этот пример не относится к цитате, в примере собственно всё правильно вычисляется и аннотация корректно стоит.
А вот собственно пример почему их не нужно так использовать (такой тоже есть в документации):
Давайте вместе прочитаем и переведём документацию:
Никогда не используйте аннотации вариантности которые не совпадают со структурной вариантностью типа.
Аннотации вариантности не изменяют структурную вариантность и проверяются только в специфических ситуациях.
НЕ ИСПОЛЬЗУЙТЕ аннотации вариантности если только они не совпадают со структурным поведением типа.
Не пытайтесь использовать аннотации вариантности чтобы изменить поведение тайпчекера, они не для этого. (Написано дважды)
Буквально пишут что если аннотации вариантности меняют поведение тайпчекера значит они используются неправильно.
Если вы почитаете документацию которую прикрепили то откроете для себя что так делать крайне не желательно. Там это написано выделенным шрифтом специально 5 раз, потому что аннотации вариантности нужны не для этого.
Пока что единственным инструментом который "продал" мне инъекцию зависимостей в жс стал effect. Почти все подобные инструменты пытались навязать мне запихивание любой сущности в класс и обмазывание декораторами, никогда не понимал почему кто-то считает что это удобно. Не говоря уже о том что никакой статической гарантии того что ты правильно построил зависимости не будет скорее всего, за этим сам следи. Эффект в сравнении со всем этим кажется таким простым и понятным.
Жалко что не написали как gitops делается на vps. По факту это настолько просто что целый специальный хостинг без надобности. Достаточно вместо того чтобы делать
docker compose upнапрямую на сервере создать удалённый контекст:И можно деплоить на vps из того же github workflow.
Проверка на лишние свойства не работает везде потому что не должна. Система типов нечего против лишних свойств не имеет, они всегда допустимы. Проверка на лишние свойства существует в тех местах где по мнению разработчиков они провоцируют баги, не смотря на то что типы верны. Это как жаловаться что правила линтера можно обойти.
А в чем противоречие? В фп кто-то мешает нормально именовать сущности? Не требует != противоречит же.