Да, я сказал именно то, что собирался. Непомерно. Переплачивают. Во всем мире.
По вашим словам получается, что работодатели глупые и щедрые. Но это же бизнес. А бизнес всегда пытается уменьшить издержки. И если бы можно было платить меньше, то конечно же платили бы меньше. Зарплаты разработчиков определяются самым обычным балансом спроса и предложения.
Но такой, знаете, обычный разработчик, пишущий куски банковского программного обеспечения, и получающий за это по меньшей мере вдвое больше водителя автобуса, — это нонсенс.
А если из-за ошибки разработчика «обычного банковского обеспечения» украдут все деньги с вашего счета, что вы на это скажете? Ничего страшного, это ж не ракета на марсе упала, пусть банковское ПО пишет кто попало по объявлениям.
Давайте поговорим о водителях автобусов. У них рваный график, неудобный стул, крутящееся колесо вместо стола, и они должны быть предельно внимательны всю рабочую смену. В противном случае может произойти трагедия
Дело не в ответственности, а в том, что водитель, как ни крути, является низкоквалифицированной профессией. Водить автобус может научиться практически любой человек за относительно короткий срок, в этом нет ничего сложного. Поэтому на рынке труда будет всегда много предложений от людей, умеющих водить автобусы.
Случайные люди, которые не очень-то и любят программировать, приходят в профессию за длинным рублем. И это ужасно. Можете ли вы представить себе хирурга, который боится крови, но прошел семь кругов ординатуры, чтобы резать тела скальпелем просто потому, что тут больше платят?
Ну вообще в некоторых странах как раз таки врачи и адвокаты являются одними из самых высокооплачиваемых профессий. И в этом нет ничего плохого.
А чтобы стать хорошо оплачиваемым программистом, требуется три недели в буткемпе и немного удачи с первой работой. За три месяца можно претендовать на средний уровень и некоторый опыт. Это убивает индустрию.
Вы неправы насчет трех недель и трех месяцев. За этот срок можно научиться только кое-как писать код, который должен попадать в проект только после тщательного ревью более опытных коллег. И этот код поначалу будет обычно иметь 100500 ошибок и замечаний. Если сравнивать с водителем автобуса, то это не «средний уровень», а стажер, которого еще нельзя одного выпускать на дорогу, и за которым должен присматривать инструктор, чтобы перехватить управление в случае чего.
отрасль страдает
Вы высказываете это утверждение, но ничем его не подкрепляете. Кто страдает, где страдает? Можете привести какие-то примеры?
Потому что не считаю обсуждаемую систему инструментом для репрессий.
Я не отрицаю, что этой системой могут и будут злоупотреблять. Однако основное её назначение — борьба с преступностью. И я думаю, что плюсы от использования в полезных целях перевесят минусы от злоупотреблений.
Не достаточно вдавался в подробности кто это такие, чтобы сформировать отношение.
Поиск дал ссылки на новости о том, что их решения используют для блокировки телеграма.
К блокировке телеграма, как и к любым другим попыткам ввести интернет цензуру отношусь отрицательно.
Попробую придумать пример для наглядности.
Допустим у меня есть веб-сайт, где пользователь должен задать свой пароль.
Обычно пароли должны соответствовать каким-то требованиям: минимальная длина, наличие каких-то символов и т.д. Если пользователь придумал неправильный пароль, то сайт должен отказать с сообщением что не так.
Разумеется, код проверки пароля несложно запрограммировать внутри системы, но предположим, что хочется дать возможность администратору сайта самому задавать требования к пользовательским паролям. Один из вариантов решений: сделать в адмике сайта формочку, где администратор на котлине может написать такую функцию:
fun checkPassword(password: String, locale: Locale): CheckPasswordResult
Эта функция проверяет пароль, а в случае неудачи формирует сообщение об ошибке на языке пользователя.
Можно конечно сказать: зачем так делать, ведь можно же описать требования для пароля регуляркой, шаблонами, etc. Но в конце концов это же всего лишь простой пример для иллюстрации, в жизни бывают и более сложные случаи конфигурации, которые просто так регуляркой не опишешь, нужен скрипт.
Что я имею в виду под взаимодействием с кодом?
А то, что код, который вводит админ, это не просто замкнутый сам на себя пример, который отработал, напечатал рядом результат и на этом все, нет. В пользовательский скрипт надо передать из системы контекст (в нашем примере это сигнатура требуемой функции и выбранная на сайте локаль пользователя), некое api, через которое скрипт может получать информацию о системе или управлять ею.
А можно ли как-то взаимодействовать с кодом, введённым пользователем, чтобы, например, использовать это в качестве пользовательских скриптовых сценариев?
Ну например, есть веб-админка, и хочется чтобы через неё налету что-то сконфигурировать через описание на котлине.
Охх…
Статью следовало бы назвать "Типичные ошибки бывшего программиста, ставшего начинающим руководителем".
Конечно, это неплохо, если менеджер умеет программировать и говорит с программистами на одном языке. Также, неплохо если он понимает в дизайне и может поговорить на одном языке с дизайнером. Ну и понимание маркетинга — куда ж без этого, ведь продукт мало разработать, его ещё надо продать. А если руководитель окончил консерваторию по классу гитары и может душевно спеть на вечеринке, сплотив коллектив в одну дружную семью — это вообще отлично.
Но в целом основные задачи у руководителя всё-таки другие. А задачи по большому счету две: продукт и команда.
Менеджер должен уметь редактировать файлы при помощи Vim??? :/ Да вы наверное шутите.
Статья смешная, но производит впечатление, что ее писал джуниор, начитавшийся книжек по ООП.
Просто автор видимо не дебажил часами падающие на C++ программы, в которых такой же студент сваял ажурные конструкции из множественного/виртуального наследования, потом запутался в выборе нужного cast при проведении типов и получил UB по лбу.
К слову, в большинстве проектах на C++, на которых я работал, множественное наследование было тупо запрещено. Это к вопросу о том, насколько «успешно» решили эту задачу в C++
У меня от стиля изложения сложилось впечатление, что автор просто хочет выпендриться.
Накрутить слова так, чтобы с одной стороны было плохо понятно, а с другой выглядело по «философски», и читатели пытались выловить смысл из глубины её глубин. Ну и как водится, винегрет из терминов, жаргонизмов и отсылок ко всему попало.
> «Будет больно. Потому что будет правда.»
Вот она, попытка сорвать покровы.
Принято.
Да, встроенный JavaScript убирает все инфраструктурные издержки.
Но увеличение сложности конфигов при использовании JavaScript все равно остается, а плюсов от дополнительных языковых возможностей в применении к конфигам я особо не вижу.
Впрочем, никто не мешает попробовать так сделать и потом рассказать о своем опыте. Я имею в виду не просто попробовать сделать в качестве эксперимента — понятно что так можно. Скорее интересен опыт долгосрочного использования, когда эти js конфиги отдаются на откуп админам, которые занимаются поддержкой системы, и они там на них что-то программируют.
Ну сначала о чисто бытовых неудобствах, которые мне видятся на пути подключения полноценных скриптов:
1. Они предустановленны, но не везде. Например мы в процессе разработки запускаем свои сервера на чем попало, в том числе и windows. Придется бегать и ставить скрипты там.
2. Предустановленная версия скриптов может не совпасть с требуемой. Или нестыковки в каких-то требуемых библиотеках, в путях, в переменных окружения.
3. Надо еще как то передать данные из скрипта в свою программу, а как? Первое что приходит в голову, скрипт печатает их в stdout, а программа парсит. Но тогда нужны какие-то соглашения о формате этих данных, чем-то печатать, чем-то парсить. То есть скрипт ещё не является готовым решением, надо еще строить мост между скриптом и родительской программой.
Если же сравнить эти телодвидения с HOCON, то нам надо всего лишь
1. Поключить библиотеку (с помощью maven или gradle это делается одной строчкой)
2. Вызвать функцию parseFile.
3. Profit. После этого мы получаем готовый объект из которого можно читать значения.
Теперь насчет сложности как языка. HOCON — это все-таки небольшая надстройка над JSON, с весьма ограниченными возможностями, которые решают вполне конкретную задачу. По сути это всё те же текстовые данные, но с возможностью прототипирования.
Когда делаешь конфиги на обычном JSON или XML, то основная проблема с которой сталкиваешься: дублирование данных. И хочется эти дубликаты как-то выносить в общее место и потом на них ссылаться. Собственно, HOCON с помощью прототипирования как раз и помогает это сделать.
А когда я говорю о сложности скриптов, то имею в виду, что скрипты — это все-таки вполне себе полноценные языки программирования: с условными переходами, с циклами, с библиотеками, с лямбдами и т.д. и т.п. И если дать все это богатство сисадмину, то есть опасение потом вместо конфигов увидеть целые программы, которые живут полноценной и насыщенной жизнью. И что в случае каких-то проблем придется сидеть и разбираться в этом богатстве, вплоть до отладки принтами.
HOCON же имеет те именно возможности, которые нужны для конфигов, не больше и не меньше. Он очень простой. Его изучение сводится к получасовому изучению мануала, после чего все более менее понятно и сразу можно работать.
Конечно, возможно в будущем опять окажется что чего-то не хватает, но пока что хватает. Одно из сильных достоинств HOCON — это его легковесность.
Парсер HOCON — это маленькая библиотечка на Java, которая к тому же не тянет никаких зависимостей.
А если JavaScript — то в нашем случае это надо внутрь JVM, на которой наш сервер работает, целый JavaScript интерпретатор затаскивать.
Кроме того, описывать конфиги на JavaScript языке на мой взгляд все-таки не совсем удобно. Слишком широкие возможности, которые предоставляет полноценный скриптовый язык, могут привести к злоупотреблениям и чрезмерному усложнению конфигов.
Ну то есть при желании так сделать конечно можно, но я бы так делать не стал :)
Можно и так. Просто примеры купированные, в них опущено что в s1 помимо ip есть и другие параметры. В исходном варианте было как-то так
s1:
{
ip = “192.168.10.1”
port = 123
database = "goodwin"
username = "root666"
password = "nobodyknows"
threadpool_size = 10
// и так далее
}
Кстати да, вместо двоеточия можно писать =, это как кому нравится.
Насчет того что include игнорирует пропуски, да я согласен что было бы неплохо иметь директиву с обязательным включением.
Семантика игнорирования missing files была задумана видимо как раз под описанный мной пример: когда в основном конфиге задаются все нужные параметры по умолчанию, а в опциональном дополнительном можно что-то если надо перекрыть.
Подскажите, в какой-нибудь из этих книг описаны принципы организации каталогов в linux?
Ну типа что такое \etc, \var, \opt и так далее.
Просто что что меня всегда бесило в linux — это то, что каждая уважающая себя программа считает своим долгом разбросать свои кровавые ошметки по всей файловой системе. И хочется наконец понять логику по которой это делается.
По вашим словам получается, что работодатели глупые и щедрые. Но это же бизнес. А бизнес всегда пытается уменьшить издержки. И если бы можно было платить меньше, то конечно же платили бы меньше. Зарплаты разработчиков определяются самым обычным балансом спроса и предложения.
А если из-за ошибки разработчика «обычного банковского обеспечения» украдут все деньги с вашего счета, что вы на это скажете? Ничего страшного, это ж не ракета на марсе упала, пусть банковское ПО пишет кто попало по объявлениям.
Дело не в ответственности, а в том, что водитель, как ни крути, является низкоквалифицированной профессией. Водить автобус может научиться практически любой человек за относительно короткий срок, в этом нет ничего сложного. Поэтому на рынке труда будет всегда много предложений от людей, умеющих водить автобусы.
Ну вообще в некоторых странах как раз таки врачи и адвокаты являются одними из самых высокооплачиваемых профессий. И в этом нет ничего плохого.
Вы неправы насчет трех недель и трех месяцев. За этот срок можно научиться только кое-как писать код, который должен попадать в проект только после тщательного ревью более опытных коллег. И этот код поначалу будет обычно иметь 100500 ошибок и замечаний. Если сравнивать с водителем автобуса, то это не «средний уровень», а стажер, которого еще нельзя одного выпускать на дорогу, и за которым должен присматривать инструктор, чтобы перехватить управление в случае чего.
Вы высказываете это утверждение, но ничем его не подкрепляете. Кто страдает, где страдает? Можете привести какие-то примеры?
Я не отрицаю, что этой системой могут и будут злоупотреблять. Однако основное её назначение — борьба с преступностью. И я думаю, что плюсы от использования в полезных целях перевесят минусы от злоупотреблений.
Поиск дал ссылки на новости о том, что их решения используют для блокировки телеграма.
К блокировке телеграма, как и к любым другим попыткам ввести интернет цензуру отношусь отрицательно.
А в этой стране надо только выкачивать нефть и выращивать бананы. Впрочем, для бананов климат не совсем подходящий, так что…
Допустим у меня есть веб-сайт, где пользователь должен задать свой пароль.
Обычно пароли должны соответствовать каким-то требованиям: минимальная длина, наличие каких-то символов и т.д. Если пользователь придумал неправильный пароль, то сайт должен отказать с сообщением что не так.
Разумеется, код проверки пароля несложно запрограммировать внутри системы, но предположим, что хочется дать возможность администратору сайта самому задавать требования к пользовательским паролям. Один из вариантов решений: сделать в адмике сайта формочку, где администратор на котлине может написать такую функцию:
Эта функция проверяет пароль, а в случае неудачи формирует сообщение об ошибке на языке пользователя.
Можно конечно сказать: зачем так делать, ведь можно же описать требования для пароля регуляркой, шаблонами, etc. Но в конце концов это же всего лишь простой пример для иллюстрации, в жизни бывают и более сложные случаи конфигурации, которые просто так регуляркой не опишешь, нужен скрипт.
Что я имею в виду под взаимодействием с кодом?
А то, что код, который вводит админ, это не просто замкнутый сам на себя пример, который отработал, напечатал рядом результат и на этом все, нет. В пользовательский скрипт надо передать из системы контекст (в нашем примере это сигнатура требуемой функции и выбранная на сайте локаль пользователя), некое api, через которое скрипт может получать информацию о системе или управлять ею.
А можно ли как-то взаимодействовать с кодом, введённым пользователем, чтобы, например, использовать это в качестве пользовательских скриптовых сценариев?
Ну например, есть веб-админка, и хочется чтобы через неё налету что-то сконфигурировать через описание на котлине.
Охх…
Статью следовало бы назвать "Типичные ошибки бывшего программиста, ставшего начинающим руководителем".
Конечно, это неплохо, если менеджер умеет программировать и говорит с программистами на одном языке. Также, неплохо если он понимает в дизайне и может поговорить на одном языке с дизайнером. Ну и понимание маркетинга — куда ж без этого, ведь продукт мало разработать, его ещё надо продать. А если руководитель окончил консерваторию по классу гитары и может душевно спеть на вечеринке, сплотив коллектив в одну дружную семью — это вообще отлично.
Но в целом основные задачи у руководителя всё-таки другие. А задачи по большому счету две: продукт и команда.
Менеджер должен уметь редактировать файлы при помощи Vim??? :/ Да вы наверное шутите.
Просто автор видимо не дебажил часами падающие на C++ программы, в которых такой же студент сваял ажурные конструкции из множественного/виртуального наследования, потом запутался в выборе нужного cast при проведении типов и получил UB по лбу.
К слову, в большинстве проектах на C++, на которых я работал, множественное наследование было тупо запрещено. Это к вопросу о том, насколько «успешно» решили эту задачу в C++
Накрутить слова так, чтобы с одной стороны было плохо понятно, а с другой выглядело по «философски», и читатели пытались выловить смысл из глубины её глубин. Ну и как водится, винегрет из терминов, жаргонизмов и отсылок ко всему попало.
> «Будет больно. Потому что будет правда.»
Вот она, попытка сорвать покровы.
Из тех же источников что и вы или каких-то других?
Я понимаю, что вопрос не совсем к вам, но наверняка вы в своих поисках пытались провентилировать этот вопрос.
Неужели это оправдано? Не проще ли было при создании объекта сразу проинициализировать его адресом или каким-то псевдослучайным числом?
Это выглядит как очень дешевое действие, которое отработает за пару тактов и ни на что особо не повлияет.
Да, встроенный JavaScript убирает все инфраструктурные издержки.
Но увеличение сложности конфигов при использовании JavaScript все равно остается, а плюсов от дополнительных языковых возможностей в применении к конфигам я особо не вижу.
Впрочем, никто не мешает попробовать так сделать и потом рассказать о своем опыте. Я имею в виду не просто попробовать сделать в качестве эксперимента — понятно что так можно. Скорее интересен опыт долгосрочного использования, когда эти js конфиги отдаются на откуп админам, которые занимаются поддержкой системы, и они там на них что-то программируют.
1. Они предустановленны, но не везде. Например мы в процессе разработки запускаем свои сервера на чем попало, в том числе и windows. Придется бегать и ставить скрипты там.
2. Предустановленная версия скриптов может не совпасть с требуемой. Или нестыковки в каких-то требуемых библиотеках, в путях, в переменных окружения.
3. Надо еще как то передать данные из скрипта в свою программу, а как? Первое что приходит в голову, скрипт печатает их в stdout, а программа парсит. Но тогда нужны какие-то соглашения о формате этих данных, чем-то печатать, чем-то парсить. То есть скрипт ещё не является готовым решением, надо еще строить мост между скриптом и родительской программой.
Если же сравнить эти телодвидения с HOCON, то нам надо всего лишь
1. Поключить библиотеку (с помощью maven или gradle это делается одной строчкой)
2. Вызвать функцию parseFile.
3. Profit. После этого мы получаем готовый объект из которого можно читать значения.
Теперь насчет сложности как языка. HOCON — это все-таки небольшая надстройка над JSON, с весьма ограниченными возможностями, которые решают вполне конкретную задачу. По сути это всё те же текстовые данные, но с возможностью прототипирования.
Когда делаешь конфиги на обычном JSON или XML, то основная проблема с которой сталкиваешься: дублирование данных. И хочется эти дубликаты как-то выносить в общее место и потом на них ссылаться. Собственно, HOCON с помощью прототипирования как раз и помогает это сделать.
А когда я говорю о сложности скриптов, то имею в виду, что скрипты — это все-таки вполне себе полноценные языки программирования: с условными переходами, с циклами, с библиотеками, с лямбдами и т.д. и т.п. И если дать все это богатство сисадмину, то есть опасение потом вместо конфигов увидеть целые программы, которые живут полноценной и насыщенной жизнью. И что в случае каких-то проблем придется сидеть и разбираться в этом богатстве, вплоть до отладки принтами.
HOCON же имеет те именно возможности, которые нужны для конфигов, не больше и не меньше. Он очень простой. Его изучение сводится к получасовому изучению мануала, после чего все более менее понятно и сразу можно работать.
Конечно, возможно в будущем опять окажется что чего-то не хватает, но пока что хватает. Одно из сильных достоинств HOCON — это его легковесность.
А если JavaScript — то в нашем случае это надо внутрь JVM, на которой наш сервер работает, целый JavaScript интерпретатор затаскивать.
Кроме того, описывать конфиги на JavaScript языке на мой взгляд все-таки не совсем удобно. Слишком широкие возможности, которые предоставляет полноценный скриптовый язык, могут привести к злоупотреблениям и чрезмерному усложнению конфигов.
Ну то есть при желании так сделать конечно можно, но я бы так делать не стал :)
Кстати да, вместо двоеточия можно писать =, это как кому нравится.
Насчет того что include игнорирует пропуски, да я согласен что было бы неплохо иметь директиву с обязательным включением.
Семантика игнорирования missing files была задумана видимо как раз под описанный мной пример: когда в основном конфиге задаются все нужные параметры по умолчанию, а в опциональном дополнительном можно что-то если надо перекрыть.
Ну типа что такое \etc, \var, \opt и так далее.
Просто что что меня всегда бесило в linux — это то, что каждая уважающая себя программа считает своим долгом разбросать свои кровавые ошметки по всей файловой системе. И хочется наконец понять логику по которой это делается.