Отправлять искать ссылку по десяткам комментариев - это выглядит хамовато, если честно.
Но я нашел. Хотелось бы понять, как вы себе представляете CSV в этом самом вашем волшебном формате? Не, конечно, так-то туда можно таблицу на 100 столбцов и 10000 строк запихать, но вот от наглядности и человекочитаемости там останется ровно ничего.
P.S. Что касается значащих вайтспейсов - это по определению зло. Отсутствие "экранировки" - тоже. Экранирующие символы используются не только для того, чтобы экранировать что-то, но и дают возможность вставлять символы, которые иным образом вставить либо невозможно, либо сложно, либо не наглядно.
Ну и, да, будем честными. Этот формат не справляется. Просто потому, что его никто не использует.
А давайте спросим у PANTONE, уже они-то в цветах разбираются, есть ли оттенки серого? И внезапно выяснится, что мало того, что есть градации серого (как правильно называть то, что написано в статье), так еще и оттенки типа "теплого серого" и "холодного серого", у которых все компоненты RGB или CMYK в полный рост присутствуют.
Можно привести в пример онлайн песочницу для sharplab.io, которая в URL записывает не только режимы работы и интерфейсные параметры, но и текст программу на C#, разумеется, упакованный и закодированный в BASE64. Образец.
Про сверточные фильтры как-то очень ненаглядно написано, зачем их давать в виде кода, если есть более наглядный способ? Про то, что ядро в принципе не обязано быть квадратом 3х3 и вообще не обязано быть квадратом, а так же про коэффициент, применяющийся к итоговой сумме, ничего не сказано почему-то. Ну и как на краях изображения с ядром работать.
Ссылка на BRIEF ведет на несуществующую страницу Википедии.
JSON, YAML, TOML, HCL - за последние годы человечество успело изобрести десяток языков для конфигурации.
Странно, что забыли в пример SGML/XML поставить, он самый шумный и избыточный. При этом приведены в пример зачем-то краснокнижный HCL и вторичный TOML. Ладно, это мелочи, просто к слову.
Каждый обещал быть "простым", "удобным" и "читаемым человеком".
Гибкость и строгость в большинстве случаев увеличивают сложность.
Но по факту - все они страдают от одних и тех же проблем: шумный синтаксис, хрупкие отступы, бесконечные кавычки и отсутствие элементарных возможностей вроде модульности и слияния конфигов.
Из всех представленных примеров (+XML) на отступы только YAML полагается. Кстати, по этой причине в реальных применениях редко используются все возможности: я встречал какой-то язык конфигурации с синтаксисом XML, но без атрибутов, только теги. Но самое главное: тут же автором предлагается РАСШИРЕННЫЙ вариант JSON5 с шахматами и балеринами.
Пора перестать с этим мириться и сделать конфигурации наконец человеческими.
И сразу вспоминается шутка про N стандартов и новый более лучший N+1-й стандарт.
А давайте все-все инструменты перенесем в браузеры! Компиляторы, нейросети, игры. Пусть все это браузеры будут уметь нативно. И еще патч Бармина не забыть встроить.
Обязательно. Любое время, потраченное на обучение, будет вычтено из рабочего времени. В полчаса в день тут не уложишься. Причем в большинстве случаев приходится постоянно переключаться между текущими задачами и обучением, а переключение контекста очень, очень дорого обходится разработчикам.
Погодите, давайте все-таки учитывать, что помимо яндексов и векторов еще существует огромный диапазон предприятий разного размера и подхода как к работе, так и найму.
И, да, проблема в масштабируемости. Если компании из 10 человек надо увеличится до 20, то им это гораздо сложнее, чем к компании из 1000 добавить еще 100. Хотя 10 < 100, но 100% > 10%. Опять же, для компании из 1000 человек текучка - обычное дело, каждый день кто-то увольняется или приходит.
Ну и по моему опыту учеников можно брать в соотношении 10:1 минимум, а еще лучше не менее 15:1, ну, это если сразу не запланированы расходы времени на их обучение.
Там, где это имеет смысл - конечно. Ну и профессии, которые имеют привязку к физическому рабочему месту, все-таки имеют больший шанс удержать обученного специалиста. Перейти на удаленную работу программистом в Яндекс проще, чем переехать физически в столицу токарю, даже если там условия шоколаднее, чем в его условном Челябинске. Да и вообще в России с ее огромными расстояниями в купе с дикой централизацией все сильно не так, чем в "отдельных странах".
Мне кажется, что вы путаете что-то. Маленькому ООО "Вектор" вообще в принципе не впилось учить своих спецов, хотя бы потому, что они маленькие. Это могут себе позволить только большие компании. Для того, чтобы обучать людей с нуля/околонуля нужно очень много:
Свободное время у высококлассных специалистов
Наличие не просто высококлассных специалистов, а тех, кто умеет и имеет желание учить (а таких среди разработчиков немного)
Сопровождение со стороны кадров
Возможность дальнейшего продвижения обученных людей, причем не только в деньгах
Если подумать, то такой "инфраструктуры" у "Вектора" быть в принципе не может, там 10 человек в разработке и 10 человек остального персонала. В разработке при этом 2-3 человека, которые "зубры" в своем деле, но учить не умеют, поскольку привыкли с компьютерами общаться, а не с людьми, да и времени у них нет, они на себе весь стартап тащат. Ну и, опять же, когда стажер научился не просто кнопочки красить, а более-менее приличный код писать, то его и девать некуда, поскольку его именно на покраску кнопок брали, в этом отделе он уже оверквалифайд, здесь ему другую работу не предложат (кнопки-то должен кто-то красить), а другого-то отдела и нет.
Вот и получается, что только у яндексов-сберов обучение молодняка на постоянные рельсы может быть поставлено, маленькие компании с этим в принципе связываться не будут. Зачем им быть кузницей кадров?
Отправлять искать ссылку по десяткам комментариев - это выглядит хамовато, если честно.
Но я нашел. Хотелось бы понять, как вы себе представляете CSV в этом самом вашем волшебном формате? Не, конечно, так-то туда можно таблицу на 100 столбцов и 10000 строк запихать, но вот от наглядности и человекочитаемости там останется ровно ничего.
P.S. Что касается значащих вайтспейсов - это по определению зло. Отсутствие "экранировки" - тоже. Экранирующие символы используются не только для того, чтобы экранировать что-то, но и дают возможность вставлять символы, которые иным образом вставить либо невозможно, либо сложно, либо не наглядно.
Ну и, да, будем честными. Этот формат не справляется. Просто потому, что его никто не использует.
А давайте спросим у PANTONE, уже они-то в цветах разбираются, есть ли оттенки серого? И внезапно выяснится, что мало того, что есть градации серого (как правильно называть то, что написано в статье), так еще и оттенки типа "теплого серого" и "холодного серого", у которых все компоненты RGB или CMYK в полный рост присутствуют.
Можно привести в пример онлайн песочницу для sharplab.io, которая в URL записывает не только режимы работы и интерфейсные параметры, но и текст программу на C#, разумеется, упакованный и закодированный в BASE64. Образец.
Про сверточные фильтры как-то очень ненаглядно написано, зачем их давать в виде кода, если есть более наглядный способ? Про то, что ядро в принципе не обязано быть квадратом 3х3 и вообще не обязано быть квадратом, а так же про коэффициент, применяющийся к итоговой сумме, ничего не сказано почему-то. Ну и как на краях изображения с ядром работать.
Ссылка на BRIEF ведет на несуществующую страницу Википедии.
А какой лучше справляется?
Странно, что забыли в пример SGML/XML поставить, он самый шумный и избыточный. При этом приведены в пример зачем-то краснокнижный HCL и вторичный TOML. Ладно, это мелочи, просто к слову.
Гибкость и строгость в большинстве случаев увеличивают сложность.
Из всех представленных примеров (+XML) на отступы только YAML полагается. Кстати, по этой причине в реальных применениях редко используются все возможности: я встречал какой-то язык конфигурации с синтаксисом XML, но без атрибутов, только теги. Но самое главное: тут же автором предлагается РАСШИРЕННЫЙ вариант JSON5 с шахматами и балеринами.
И сразу вспоминается шутка про N стандартов и новый более лучший N+1-й стандарт.
Завязывай с наркотой
https://sql-ex.ru/blogs/?/Vremennye_tablicy_v_PostgreSQL.html
Так она тут и не временная (по крайней мере в терминах Postgress). Временные таблицы создаются через CREATE TEMPORARY TABLE.
Ну и не думаю, что автор действительно что-то понял, поскольку это, прямо скажем, довольно нетривиальная штука.
С чего бы это REST синхронный? Кто мешает написать асинхронное взаимодействие на REST с использованием сущностей типа task, ticket или message/queue?
А потеря времени не проблема?
А давайте все-все инструменты перенесем в браузеры! Компиляторы, нейросети, игры. Пусть все это браузеры будут уметь нативно. И еще патч Бармина не забыть встроить.
Обязательно. Любое время, потраченное на обучение, будет вычтено из рабочего времени. В полчаса в день тут не уложишься. Причем в большинстве случаев приходится постоянно переключаться между текущими задачами и обучением, а переключение контекста очень, очень дорого обходится разработчикам.
Так можно на обучение взять двух учеников при двух специалистах. Только вот и с основной работой, и с обучением будут проблемы.
Ну, вот вы как раз и попадаете где-то в серединку. И соотношение обучающих/обучаемых плюс-минус такое, про которое я писал в этом комментарии https://habr.com/ru/companies/grangroup/articles/961560/comments/#comment_29044812
Ну так у вас и не 10 человек в рабочей команде, верно?
Погодите, давайте все-таки учитывать, что помимо яндексов и векторов еще существует огромный диапазон предприятий разного размера и подхода как к работе, так и найму.
И, да, проблема в масштабируемости. Если компании из 10 человек надо увеличится до 20, то им это гораздо сложнее, чем к компании из 1000 добавить еще 100. Хотя 10 < 100, но 100% > 10%. Опять же, для компании из 1000 человек текучка - обычное дело, каждый день кто-то увольняется или приходит.
Ну и по моему опыту учеников можно брать в соотношении 10:1 минимум, а еще лучше не менее 15:1, ну, это если сразу не запланированы расходы времени на их обучение.
Там, где это имеет смысл - конечно. Ну и профессии, которые имеют привязку к физическому рабочему месту, все-таки имеют больший шанс удержать обученного специалиста. Перейти на удаленную работу программистом в Яндекс проще, чем переехать физически в столицу токарю, даже если там условия шоколаднее, чем в его условном Челябинске. Да и вообще в России с ее огромными расстояниями в купе с дикой централизацией все сильно не так, чем в "отдельных странах".
Мне кажется, что вы путаете что-то. Маленькому ООО "Вектор" вообще в принципе не впилось учить своих спецов, хотя бы потому, что они маленькие. Это могут себе позволить только большие компании. Для того, чтобы обучать людей с нуля/околонуля нужно очень много:
Свободное время у высококлассных специалистов
Наличие не просто высококлассных специалистов, а тех, кто умеет и имеет желание учить (а таких среди разработчиков немного)
Сопровождение со стороны кадров
Возможность дальнейшего продвижения обученных людей, причем не только в деньгах
Если подумать, то такой "инфраструктуры" у "Вектора" быть в принципе не может, там 10 человек в разработке и 10 человек остального персонала. В разработке при этом 2-3 человека, которые "зубры" в своем деле, но учить не умеют, поскольку привыкли с компьютерами общаться, а не с людьми, да и времени у них нет, они на себе весь стартап тащат. Ну и, опять же, когда стажер научился не просто кнопочки красить, а более-менее приличный код писать, то его и девать некуда, поскольку его именно на покраску кнопок брали, в этом отделе он уже оверквалифайд, здесь ему другую работу не предложат (кнопки-то должен кто-то красить), а другого-то отдела и нет.
Вот и получается, что только у яндексов-сберов обучение молодняка на постоянные рельсы может быть поставлено, маленькие компании с этим в принципе связываться не будут. Зачем им быть кузницей кадров?
Мне очень нравится, что у вас региональные компании слово "газ" два раза в названии имеют: "Газпром трансгаз Москва", "Газпром трансгаз Казань".