Люто плюсую. Far никогда не обманет, не запустит случайно никакого кода, просто покажет что внутри файла. А с Проводником на чужие флешки ходить как-то стрёмно. И даже если речь не идёт о малвари - куда быстрее глянуть Far-ом, что там за файл и что от него ожидать.
С ним вообще вся файловая система как на ладони. Адекватные дефолты "для ойтишнека" - не нужно настраивать показ расширений файлов, скрытых файлов и вот это вот всё что делается каждый раз на свежем профиле в Винде. Впрочем, это наверное актуально для любого приличного файлового менеджера, а вот "консльность" и быстрый просмотр - кмк, киллер-фичи.
Кажется никто не упомянул в комментариях интересный и важный юзкейс для Far - работа по SSH на виндовых машинах. С учётом того, что OpenSSH теперь есть в поставке Винды, то консольность файлового менеджера выглядит как киллер-фича.
Ну и второй огромный плюс, лично для меня - быстрый просмотр/редакторование по F3/F4. РЕАЛЬНО быстрый, никакой, даже самый лёгкий редактор так быстро не запустится. А для меня часто очень важно знать, что "внутри" файлов, и быстро по ним переходить. Не встречал HEX-редакторов, где это было бы так же удобно и быстро (потому что по сути нужен файловый менеджер и HEX-просмотровщик/редактор в одном флаконе).
а вот для винды сама концепция такого доступа к сожалению не прижилась
А вот я обнадёжу вас, очень даже прижилась, с тех пор как в Винде появился OpenSSH (что клиент, что сервер). Теперь на виндовые билд-машины в 97% случаю захожу по SSH, только если какая-то странная авария - тогда уже через SPICE или ещё какой гуёвый протокол.
Ну а если по SSH - то что, если не FAR, не так ли?
А теперь давайте порассуждаем как ответственные разработчики библиотеки или инструмента.
Согласно semver, если мажорная версия остаётся неизменной, новая версия библиотеки в идеале должна быть в состоянии заменить старую версию без значительных ухудшений. Как минимум - должен сохраниться API/ABI (в зависимости от ЯП и соглашений), как максимум - должны сохраниться гарантии относительно сложности алгоритмов, потребления памяти и т.д. Конкретно в экосистеме Node.js принято не ломать совместимость с поддерживаемой версией Ноды/NPM. Иными словами, если версия 7.2.5 поддерживала Node.js 18.x, то и версия 7.3.1 должна поддерживать Node.js 18.x (разве что могут потребовать более свежей минорной или патч-версии). Это правило выполняется не всегда, но чем более влиятельным является инструмент/библиотека, тем оно важнее.
ESLint это дофига влиятельный инструмент, де-факто стандарт линтинга JS-кода. Следовательно, если разработчики, выпустив новую МАЖОРНУЮ версию будут поддерживать в ней Node 18, им следует делать это пока ветка 9.x eslint-а не умрёт. Это может быть довольно долго.
Когда поднимается мажорная версия, самое время поломать интерфейсы - т.к. по сути не гарантируется совместимость ни в чём, можно считать что это "новый" инструмент/библиотека. По этому самое время завязаться на более свежие зависимости, в том числе Ноду.
Я не думаю, что автор использовал понятие "модуль" в том смысле, в каком оно понимается в организации кода (а-ля unit-ы в Паскале или ES-модули в JS/TS). Очевидно, автор говорит о каком-то подходе к декомпозиции сервиса, только непонятно, о каком. Код любого нормального монолита разбит на модули/единицы компиляции/что-там-ещё-придумано-в-конкретном-языке, никто не пишет исходники в файлах длиной по 10 мегабайт. Поэтому непонятно, какой смысл в вашем комментарии, вы описали очевидную вещь.
явно тестирующей построение всей системы новым компилятором перед переходом на него
Так эта команда тоже облажалась, в конце статьи как раз написано) Ну и "монолитная" Винда - довольно тяжеловесная штука, там наверняка переход на новый компилятор идёт медленнее, чем в остальных проектах. И соблазн перевести отдельный продукт побыстрее очень велик. В C++ в последние годы наблюдается взрывной рост фичей в языке и в стандартной библиотеке, и многие хотят себе в проект свежий компилятор (особенно если компилятор немного отстаёт в реализации чего-либо из свежего стандарта).
А зачем вам такой объект? Модуль - уже и есть готовый объект с таким же предназначением. Разве так не проще? strbool.mts:
export const foo = 'foo';
export type Foo = typeof foo;
export const bar = 'bar';
export type Bar = typeof bar;
type StrBool = Foo | Bar | null;
export { type StrBool as default };
export function is(value: unknown): value is StrBool {
return isFoo(value) || isBar(value) || isNull(value);
}
export function isFoo(value: unknown): value is Foo {
return value === foo;
}
export function isBar(value: unknown): value is Bar {
return value === bar;
}
export function isNull(value: unknown): value is null {
return value === null;
}
export function toBoolean(value: StrBool): boolean {
return isFoo(value) || isNull(value);
}
Использование:
import type StrBool from './strbool.mjs';
import { is, isBar, isFoo } from './strbool.mjs';
Кстати, спасибо, первая статья которую встретил с упоминанием winget как настоящего, а не далёкого светлого будущего. Последние года два раз в месяц обязательно удаётся кого-нибудь удивить winget-ом, который в последних сборках работает обычно из коробки. Даже бывалые админы в шоке, что теперь так можно. В очередной раз убеждаюсь, что в последние годы у MS стало плоховато с евангелизмом и пропагандой собственных технических решений.
Ну если и дальше развивать вашу позицию, то сменить специализацию в IT вообще нереально. Я вот последние несколько месяцев на полном серьёзе подумываю на годик уйти в подполье, 3-4 месяца отходнуть, а за оставшееся время подучить совершенно другой стек, и уйти наконец с фронтэнда, в который меня волею судеб занесло (в котором я толком ничему не научился, зато успел знатно выгореть).
А по вашим словам получается, что мне и помыслить нельзя о таком. Только мне что-то кажется, что это преувеличение. Может, нужно просто быть готовым к тому, что вновь станешь миддлом (причём ненадолго, над год-полтора)?
От программиста будет требоваться только боле-менее чётко формулировать описания для этих AI-помощников - всё-таки пока я считаю требования к описаниям должны быть достаточно строгими (условно - математически строгими) - чётко декларирующими требования...
... и в качестве такого чёткого описания требований отлично подойдёт код на C#, ну или на Kotlin.
Возможно есть причины? В офис, может, и нашлось бы что, но я живу на Алтае, у нас тут отрасль IT вообще никакая
Очевидно, причина в этом. Это всё равно что жить в Геленджике и жаловаться, что кроме сферы услуг всё остальное развито достаточно слабо. Я прекрасно понимаю автора, что он не хочет уезжать. Я тоже не могу и не хочу из РнД сейчас никуда уезжать, но я сижу ровно и делаю, что дают (хотя уже ненавижу чертов фронтэнд каждой клеточкой своего организма). Ситуация, что почти вся серьёзная айтишечка находится в дефолт-сити и СПб сложилась не год и не два назад (хотя это печально, конечно).
Вы рассказываете про "ОЧЕНЬ крупные проекты" и одновременно с этим у вас в продакшен вываливается подобное... Где тестовое окружение? Чем занят QA-отдел?
Допустим вы релизитесь каждый день, ну или хотя бы раз в неделю (что считается редким на сегодняшний день для технологичного бизнеса). Вы каждый день будете проверять вручную весь продукт? Где тесты, спросите вы? Ну так TypeScript это и есть в каком-то смысле формат таких тестов, просто очень глубоко встроен в код. Код не нужно запускать даже для базового "тестирования" с помощью TS. По сути где больше компилятора и его строгости, там нужно меньше тестов, и наоборот.
Реально, а чем тогда эти 200 человек заняты, что они понятия не имеют с чем они работают?
А кто говорил, что они понятия не имеют? Эти 200 человек - они же не археологи, и не смотрят на код, написанный на древнем пергаменте, пытаясь расшифровать древний язык программирования. Они меняют этот код каждый день. Пока 10 человек читают код функции f, один человек его меняет, или вообще удаляет эту функцию, заменяя все её вызовы на что-то другое. Если 200 человек будут сообщать друг другу о том, что они делают каждый день, то они только и будут этим заниматься, а не писать код. Рано или поздно проект достигает такого размера, что отдельно взятый разработчик не может читать/знать весь остальной код. Для этого придумали декомпозицию и программные интерфейсы, и 1000 и 1 способ их декларирования и соблюдения. TypeScript - один из них.
Мы каждый рабочий день кроме пятницы релизим примерно по 20 задач, начиная от небольших фиксов и заканчивая бранчами на 2000+ строк изменений. Если в одном таком бранче один разработчик вызовет функцию f, а другой, в ДРУГОМ бранче, удалит её (не подозревая, что она кому-то понадобится), то что будет, если эти задачи попадут друг за другом в мастер? Правильно, ничего хорошего. И с JS мы узнаем об этом только в рантайме. А весь продукт перед релизом каждый день проверять невозможно.
А потом однажды обнаруживается, что в команде уже 200 человек, из которых никто не может ответить
Вот! Вот в том-то и суть, что по мере роста проекта нужно переходить от договорённостей на словах и в тексте (если таковые вообще есть) к договорённостям, проверяемым автоматически. Код - всегда основной источник правды, а то, что у каждого разработчика в голове - это представление о небольшой части кода проекта и его поведении. Поэтому реально полезно лишь то, что записано в коде, автоматизировано скриптами или изложено хотя бы в человекочитаемом тексте. Остальное - воздух, который уйдёт вместе с вами, когда через полгода вам сделают очень выгодное предложение о работе :)
Хорошее замечание про тесты. Строгость типизации - это такая прямая. С одного конца динамические языки, где именно что нужно покрывать код тестами в том числе на адекватность входа и реакцию на него. Посередине - языки вроде TS, где часть проверок корректности уезжает в compile-time. С другого конца - языки вроде Idris, где типизация настолько мощная, что код пишешь по принципу "компилируется - значит корректен". Unit-тестов ещё меньше, важнее становятся всякие e2e и интеграционные.
Ну т.е. вы расписываетесь в том, что в коде у вас полнейший бардак? Который вы красиво именуете "обычное явление"))
Если у вас в проекте 200 человек, как может не быть бардака? Они все разные, у них разный уровень подготовки, разный опыт. Ещё они постоянно увольняются (в айтишечке же если больше двух лет работаешь на одном месте - значит всё, деградируешь. Бред кмк, но люди же так и скачут по компаниям), приходят новые. Бардака не может не быть, если за этим не следить. Вот TS - и есть средство слежения. Никто не говорил, что он очень нужен в проектах, где 5 или даже 15 человек. Только как раз таки все деньги крутятся в тех компаниях, где ПО сложное, и его разрабатывает много людей.
noUncheckedIndexedAccess. Но да, это хороший аргумент. Собственно разработчики TS постоянно ищут подобный баланс в различных вещах - где например, as const появился именно потому, что по-умолчанию типы не остаются литеральными (а могли бы!) и расширяются по ряду интуитивных правил. Например, тип значения 'foobar' мог бы по-умолчанию выводиться как 'foobar', но это было бы непрактично, поэтому он расширяется до string.
Люто плюсую. Far никогда не обманет, не запустит случайно никакого кода, просто покажет что внутри файла. А с Проводником на чужие флешки ходить как-то стрёмно. И даже если речь не идёт о малвари - куда быстрее глянуть Far-ом, что там за файл и что от него ожидать.
С ним вообще вся файловая система как на ладони. Адекватные дефолты "для ойтишнека" - не нужно настраивать показ расширений файлов, скрытых файлов и вот это вот всё что делается каждый раз на свежем профиле в Винде. Впрочем, это наверное актуально для любого приличного файлового менеджера, а вот "консльность" и быстрый просмотр - кмк, киллер-фичи.
Кажется никто не упомянул в комментариях интересный и важный юзкейс для Far - работа по SSH на виндовых машинах. С учётом того, что OpenSSH теперь есть в поставке Винды, то консольность файлового менеджера выглядит как киллер-фича.
Ну и второй огромный плюс, лично для меня - быстрый просмотр/редакторование по F3/F4. РЕАЛЬНО быстрый, никакой, даже самый лёгкий редактор так быстро не запустится. А для меня часто очень важно знать, что "внутри" файлов, и быстро по ним переходить. Не встречал HEX-редакторов, где это было бы так же удобно и быстро (потому что по сути нужен файловый менеджер и HEX-просмотровщик/редактор в одном флаконе).
А вот я обнадёжу вас, очень даже прижилась, с тех пор как в Винде появился OpenSSH (что клиент, что сервер). Теперь на виндовые билд-машины в 97% случаю захожу по SSH, только если какая-то странная авария - тогда уже через SPICE или ещё какой гуёвый протокол.
Ну а если по SSH - то что, если не FAR, не так ли?
А теперь давайте порассуждаем как ответственные разработчики библиотеки или инструмента.
Согласно semver, если мажорная версия остаётся неизменной, новая версия библиотеки в идеале должна быть в состоянии заменить старую версию без значительных ухудшений. Как минимум - должен сохраниться API/ABI (в зависимости от ЯП и соглашений), как максимум - должны сохраниться гарантии относительно сложности алгоритмов, потребления памяти и т.д. Конкретно в экосистеме Node.js принято не ломать совместимость с поддерживаемой версией Ноды/NPM. Иными словами, если версия 7.2.5 поддерживала Node.js 18.x, то и версия 7.3.1 должна поддерживать Node.js 18.x (разве что могут потребовать более свежей минорной или патч-версии). Это правило выполняется не всегда, но чем более влиятельным является инструмент/библиотека, тем оно важнее.
ESLint это дофига влиятельный инструмент, де-факто стандарт линтинга JS-кода. Следовательно, если разработчики, выпустив новую МАЖОРНУЮ версию будут поддерживать в ней Node 18, им следует делать это пока ветка 9.x eslint-а не умрёт. Это может быть довольно долго.
Когда поднимается мажорная версия, самое время поломать интерфейсы - т.к. по сути не гарантируется совместимость ни в чём, можно считать что это "новый" инструмент/библиотека. По этому самое время завязаться на более свежие зависимости, в том числе Ноду.
Я не думаю, что автор использовал понятие "модуль" в том смысле, в каком оно понимается в организации кода (а-ля unit-ы в Паскале или ES-модули в JS/TS). Очевидно, автор говорит о каком-то подходе к декомпозиции сервиса, только непонятно, о каком. Код любого нормального монолита разбит на модули/единицы компиляции/что-там-ещё-придумано-в-конкретном-языке, никто не пишет исходники в файлах длиной по 10 мегабайт. Поэтому непонятно, какой смысл в вашем комментарии, вы описали очевидную вещь.
Так а в чём разница между модульным монолитом и набором микросервисов? Микросервисы - это точно не то же самое, что и "модульный монолит"?
Так эта команда тоже облажалась, в конце статьи как раз написано)
Ну и "монолитная" Винда - довольно тяжеловесная штука, там наверняка переход на новый компилятор идёт медленнее, чем в остальных проектах. И соблазн перевести отдельный продукт побыстрее очень велик. В C++ в последние годы наблюдается взрывной рост фичей в языке и в стандартной библиотеке, и многие хотят себе в проект свежий компилятор (особенно если компилятор немного отстаёт в реализации чего-либо из свежего стандарта).
А как иначе? Windows Terminal - самостоятельное приложение, которое распространяется в том числе через Стор.
А зачем вам такой объект? Модуль - уже и есть готовый объект с таким же предназначением. Разве так не проще?
strbool.mts:Использование:
Кстати, спасибо, первая статья которую встретил с упоминанием winget как настоящего, а не далёкого светлого будущего. Последние года два раз в месяц обязательно удаётся кого-нибудь удивить winget-ом, который в последних сборках работает обычно из коробки. Даже бывалые админы в шоке, что теперь так можно. В очередной раз убеждаюсь, что в последние годы у MS стало плоховато с евангелизмом и пропагандой собственных технических решений.
Ну если и дальше развивать вашу позицию, то сменить специализацию в IT вообще нереально.
Я вот последние несколько месяцев на полном серьёзе подумываю на годик уйти в подполье, 3-4 месяца отходнуть, а за оставшееся время подучить совершенно другой стек, и уйти наконец с фронтэнда, в который меня волею судеб занесло (в котором я толком ничему не научился, зато успел знатно выгореть).
А по вашим словам получается, что мне и помыслить нельзя о таком. Только мне что-то кажется, что это преувеличение. Может, нужно просто быть готовым к тому, что вновь станешь миддлом (причём ненадолго, над год-полтора)?
... и в качестве такого чёткого описания требований отлично подойдёт код на C#, ну или на Kotlin.
Очевидно, причина в этом. Это всё равно что жить в Геленджике и жаловаться, что кроме сферы услуг всё остальное развито достаточно слабо.
Я прекрасно понимаю автора, что он не хочет уезжать. Я тоже не могу и не хочу из РнД сейчас никуда уезжать, но я сижу ровно и делаю, что дают (хотя уже ненавижу чертов фронтэнд каждой клеточкой своего организма). Ситуация, что почти вся серьёзная айтишечка находится в дефолт-сити и СПб сложилась не год и не два назад (хотя это печально, конечно).
Да, первое время он и правда работал не очень. Да и кто вообще хотел с ним связываться)
Допустим вы релизитесь каждый день, ну или хотя бы раз в неделю (что считается редким на сегодняшний день для технологичного бизнеса). Вы каждый день будете проверять вручную весь продукт?
Где тесты, спросите вы? Ну так TypeScript это и есть в каком-то смысле формат таких тестов, просто очень глубоко встроен в код. Код не нужно запускать даже для базового "тестирования" с помощью TS.
По сути где больше компилятора и его строгости, там нужно меньше тестов, и наоборот.
А кто говорил, что они понятия не имеют? Эти 200 человек - они же не археологи, и не смотрят на код, написанный на древнем пергаменте, пытаясь расшифровать древний язык программирования.
Они меняют этот код каждый день. Пока 10 человек читают код функции f, один человек его меняет, или вообще удаляет эту функцию, заменяя все её вызовы на что-то другое.
Если 200 человек будут сообщать друг другу о том, что они делают каждый день, то они только и будут этим заниматься, а не писать код. Рано или поздно проект достигает такого размера, что отдельно взятый разработчик не может читать/знать весь остальной код. Для этого придумали декомпозицию и программные интерфейсы, и 1000 и 1 способ их декларирования и соблюдения. TypeScript - один из них.
Мы каждый рабочий день кроме пятницы релизим примерно по 20 задач, начиная от небольших фиксов и заканчивая бранчами на 2000+ строк изменений. Если в одном таком бранче один разработчик вызовет функцию f, а другой, в ДРУГОМ бранче, удалит её (не подозревая, что она кому-то понадобится), то что будет, если эти задачи попадут друг за другом в мастер? Правильно, ничего хорошего. И с JS мы узнаем об этом только в рантайме. А весь продукт перед релизом каждый день проверять невозможно.
Вот! Вот в том-то и суть, что по мере роста проекта нужно переходить от договорённостей на словах и в тексте (если таковые вообще есть) к договорённостям, проверяемым автоматически. Код - всегда основной источник правды, а то, что у каждого разработчика в голове - это представление о небольшой части кода проекта и его поведении. Поэтому реально полезно лишь то, что записано в коде, автоматизировано скриптами или изложено хотя бы в человекочитаемом тексте. Остальное - воздух, который уйдёт вместе с вами, когда через полгода вам сделают очень выгодное предложение о работе :)
Хорошее замечание про тесты.
Строгость типизации - это такая прямая. С одного конца динамические языки, где именно что нужно покрывать код тестами в том числе на адекватность входа и реакцию на него. Посередине - языки вроде TS, где часть проверок корректности уезжает в compile-time. С другого конца - языки вроде Idris, где типизация настолько мощная, что код пишешь по принципу "компилируется - значит корректен". Unit-тестов ещё меньше, важнее становятся всякие e2e и интеграционные.
Если у вас в проекте 200 человек, как может не быть бардака? Они все разные, у них разный уровень подготовки, разный опыт. Ещё они постоянно увольняются (в айтишечке же если больше двух лет работаешь на одном месте - значит всё, деградируешь. Бред кмк, но люди же так и скачут по компаниям), приходят новые. Бардака не может не быть, если за этим не следить.
Вот TS - и есть средство слежения. Никто не говорил, что он очень нужен в проектах, где 5 или даже 15 человек. Только как раз таки все деньги крутятся в тех компаниях, где ПО сложное, и его разрабатывает много людей.
noUncheckedIndexedAccess.
Но да, это хороший аргумент. Собственно разработчики TS постоянно ищут подобный баланс в различных вещах - где например,
as constпоявился именно потому, что по-умолчанию типы не остаются литеральными (а могли бы!) и расширяются по ряду интуитивных правил. Например, тип значения'foobar'мог бы по-умолчанию выводиться как'foobar', но это было бы непрактично, поэтому он расширяется доstring.