Надо понимать с какими компаниями Игорь сталкивался. Компании работающие только на российский рынок, там и зарплаты ниже и требования, опять же, в силу зарплат ниже. Более квалифицированным специалистам проще пойти в продуктовую компанию на существенно более высокую зарплату или пойти в международные компании, где зарплаты будут соответствовать российскому рынку, но клиентами будут зарубежные компании, для которых найм таких сотрудников выгоден.
Это из моего опыта общения с компаниями-агентами. Есть еще отдельный класс который просто нанимает в свой штат, но собеседования и прочее проходишь с целевой компанией и работаешь ты именно на эту компанию, там зарплаты будут в рынке, но там никаких отличий от работы в продуктовой компании и собственно никаких плюсов от работы в компании-агенте.
Ну да. Потому что, кажется, в случае с «галерами» всё наоборот и ребята там не от хорошей жизни работают.
Вопрос про какие компании идет речь. В крупных международных компаниях типа Luxoft, Epam, Grid Dynamics есть те кто работают много лет и очень доволены, кто-то делает карьеру вырастая в архитектора или продакта, кому-то нравится возможность сменить проект, поработать с разными людьми. А в некоторых случаях - это просто единственная возможность поработать в крупной компании, например, Google или Apple оставаясь дома. Плюс практика английского, возможность видеть как работают и мыслят люди из других стран. Это очень интересно. Опять же возможность поработать над разными проектами.
Крупные консалтинговые компании могут иметь и внутренние продукты, так как держат какой-то процент людей в резерве, чтобы оперативно реагировать на новые заказы. И тут они дают волю фантазии инженерам, на таких проектах можно попробовать освоить новые технологии, попробовать себя в новой роли - продакта, лида, QA или разработчика. По «плюшкам» такие компании не отключаются от продуктовых, а то могут и превосходить в части обучения языкам, в первую очередь английский, прохождение курсов и получение сертификатов - компании сами в этом заинтересованы. Возможность пожить, поработать в другой стране без релокации.
Да, можно попасть на скучный проект, но тоже самое касается и продуктовой компании, где так же может оказаться скучно.
Вообще, идея очень похожа на идеи, встречающиеся в функциональном программировании. В ООП я в чистом виде подобного не видел. Создается DSL для предметной области отвязанный от исполнения, а потом создается слой который исполняет этот DSL, соотвественно можно подменить среду исполнения (БД, фреймворки). В итоге код может разделиться на две части модельные сущности и их взаимодействие описанной в терминах DSL, и слой исполнения этого DSL. Но вопрос цены такой разработки, как много специалистов готовы так делать и есть ли от этого существенные преимущества от такого подхода.
Конечно, можно так писать и в ООП, описывает логику и потом слой который свяжет нашу модель и фреймворк. Но опять же, какая будет цена такой разработки и какие преимущества даст такой подход. Все таки превращение Web приложения в консольное хотя и имеет место быть, точнее не превращение, а проявление дополнительного клиента, но всё же вещь редкая. Замена БД встречается, пожалуй, чаще, но все же достаточно редко и если происходит, то в этот момент, скорей всего, надо переосмыслить всю архитектуру так как поменялись требования.
Можно до какой-то степени достраивать дом, добавлять новые комнаты и даже этаж или два, но группы небольших мастерских превратить в большой мощный завод на фундаменте мастерских - не получится, фундамент надо будет менять.
Есть в Scala не популярный фреймворк Lagom для микросервисов, который в свою очередь построен на баз фреймворка Play, а он базируется на фреймворка Akka. ?
То есть даже линейная последовательность команд или конвейер для вас программированием не является. А собственно почему?
Это просто вызов команд, не важно как его делать в конвейере, объединив команды через &&, или ||, или записать их последовательность в скрипт и выполнить, или каждый раз вручную вводя команду (копируя откуда-то), или кликая мышкой по менюшкам. Запись макроса или последовательный запуск команд в скрипте, на границе, но всё же нет.
В противном случае, любая работа связанная с использование компьютера - программирование. Просто интерпретатором команд является не шелл, а какая-то другая программа. Ну за исключением компьютер когда используется как подставка или его куда-то переносят, ну или еще совершают какое-то действие как с некоторым объектом. :)
Причем процесс программирования - это как раз процесс создания программы. Дальнейшие её запуски уже программированием не являются. И смысл программирования ещё в том, чтобы программа, как результат процесса, использовалась многократно без модификации, а не создавалась для разового выполнения.
С какой стороны посмотреть. Вбиваете-то вы команду скриптового языка.
Необязательно команду языка, это может быть просто имя исполняемого файла, но да, тогда это будет рассматривать как команда на запуск этого файла.
Но таком случае, работа в программе в GUI, где есть возможность записи макроса и/или повтора команды из истории так же является вариантом визуального программирования. Ведь по сути, клик по меню или выбор и применение инструмента - это просто форма описания команды, которая сохранилась в истории. Является ли это программированием (визуальным)?
Все три варианта с точки зрения баша одинаковы. Почему вы считаете, что первый это не программирование, а последний — уже оно?
В моем понимании ни первый ни последний не являются программированием. Для меня грань пролегает при появлении языковых конструкций ветвления, циклов. При этом написать скрипт в котором после каждого вызова программы будет стоять явная проверка на то, что команда завершилась успехом, и в этом случае продолжается исполнение скрипта, а в случае ошибки прерывается с каким-то дополнительным сообщением - становится программированием. Просто прерывание попадает под программирование, но можно заменить set -e или объединением команд в одну через &&. Или дописав || exit 1 к каждой.
А какая разница, объединяю я запуск команд в конвейер или перенаправляю вывод одной команды в файл, а потом этот файл передаю на вход другой команде? Тем самым я сохраняю промежуточное состояние и если ошибся в команде, или мне нужны другие параметры, то не надо выполнять всю цепочку команд. И это мало отличается от того, чтобы открыть файл в одной программе, сделать с ним какие-то манипуляции, результат сохранить и обработать а другой программе. Если я написал скрипт (не важно bash, sh, bat, power shell), то да, это будет программированием, программирование подразумевает, что появляется описание алгоритма которое можно переиспользовать. В случае ручного набора команд и объединения их в конвейер результат в виде скрипта не остаётся, т.е. нет результата процесса программирования. Так же, я могу чертить в автокаде используя его встроенную консоль и даже делать циклы, но это опять же не будет программированием, так есть только результат работы, но нет самой программы. А если я в ворде записал макрос и сохранил его - это программирование, так в результате процесса появилась программа, которую можно повторно запустить. Даже написание файла конфигурации vim/nvim - программирование, потому что в результате появляется программа которую можно выполнить и выполняет её vim/nvim. Ну или emacs.
Если по вашему работа в консоли - это хотя бы объединение команд в конвейер, то как называть просто отдельный запуск CLI программ?
Ну я работаю в консоли - использую различные тулы, но не пишу скрипты. Это преимущественно запуск сборки, тестов (по другому не запустить нужную для проверки версию), просмотр логов, какие-то манипуляции с ними при помощи разных утилит (grep, dsq, jq) или апи дернуть курлом, пакеты обновить/поставить. Это программирование? Вряд ли, иначе - любой запуск программы становится программированием. Работа в консоле - да, все тулы имею CLI, из обладающих псевдографикой только tmux/screen.
WSL дает представление о работе с командной строкой, но не для погружения целиком в дистрибутив. В идеале, в случае с линукс/*BSD показать несколько окружений рабочего стола. По моему опыту люди теряются при виде чего-то непривычного и просто не будут этим пользоваться. А так им GUI будет более привычен. Показать что искать, чтобы поменять какие-то настройки, как минимум управление сетями.
В случае со школьным образованием, мне кажется, важно показать разнообразие интерфейсов, тогда будет проще разобраться с каким-то новым. По удобству, потом каждый выберет для себя сам. Есть организации где на компьютерах стоит линукс их еще не много, лично не видел, но в интернетах читал, что перевели всех пользователей на линукс. Так что пруфов не будет.
"Полное погружение" в линукс актуально, если есть какая-то глобальная цель у государства снизить зависимость от продуктов Windows, если такой цели нет, то и мучать детей этим особо смысла не вижу. Можно просто в виртуалке или с Live носителя с линукс показать, что есть альтернатива Windows. А кому надо, тот потом сам разберется.
А что касается удобства... Ну тут у всех свои предпочтения, мне больше нравится линукс, кто-то предпочитает мак, вы винду. Если бы меня поставили перед выбором для дома или мак, или винда, то выбрал бы винду. К счастью, меня никто не ставит перед таким выбором. А в работе предпочитаю то, чем пользуется большинство, чтобы не собирать уникальных граблей. Да и линукс реже предлагают, в основном выбор между виндой и маком, а то и просто без выбора.
Да, хорошее замечание. Но в эмуляторах не встречал такого. Вкладка закрывается по Ctrl + Shift + W, а на маке по Cmd + W. В Windows Terminal тоже закрывается по Ctrl + Shift + W. Да и момент, что для мака в этих хоткеях именно ctrl, а не cmd как часто бывает, что сочетания ctrl + в маке превращается в cmd +, но не в этом случае.
Отдельное спасибо за спикок хоткеев к терминалу, очень удобно. Я бы еще добавил к ним Ctrl + W - вырезать слово слева от курсора, его потом можно так же вставить. И минутка занудства: Ctrl + U вырезает всё слева от курсора. Т.е. если курсор стоял в конце строки, то да, всю команду, а если в середине, то "хвост" останется. В противовес ему есть Ctrl + K, который вырезает всё справа от курсора.
И главное, что эти хоткеи работают и на маке, да и в большинстве эмуляторов терминала. Где не работают, так это терминалы встроенные в IDE. :)
P.S. Если кому-то зайдет идея использовать хоткеи в терминале, то их можно нагуглить по emacs hotkeys.
Пробовали тайловый оконный менеджер, например i3? Видел у коллег и они были весьма довольны. Я пробовал, мне меньше зашел - мне привычнее gnome. i3 минималистичный и так же управляется хоткеями, мышкой тоже можно.
Например, система управления и мониторинга оборудования РЛС наземного базирования. Там как раз использовался Солярис и в планах, насколько я понял, был переход на что-то типа линукса. Не все задачи требуют жесткого реального времени и соответствующих ОС. Бортовые навигационные системы, которые Транзас делал и они использовались так же и военными. Часть точно работала под управлением линукс, но что конкретно за дистрибутив - не знаю, скорей всего так же Астра. Да и те же данные накапливать и обрабатывать где-то надо, аналитику и тому подобное, да и писарям в штабах тоже за чем-то работать надо. Но там винда скорей всего, не знаю, не видел. В военкоматах, вроде, винду видел.
Базовое - да, как и в случае с Windows и Mac OS, но базовое - это на уровне, вот командная строка, вне можно запускать программы. Справку о команде чаще всего можно получить так и так. Ну и базовый набор команд типа cd, ls, dir, pwd. Вот на такому уровне - да. Глубже смысла нет, так как забудется.
Раньше был МСВС (мобильная система вооруженных сил), сейчас Астра Линукс используется. Для последнего, можно купить лицензию и использовать дома. Раньше ещё Солярис на Эльбрусах использовался для управления разными системами. Но Солярис все таки не опенсорс, покраснел мере не opensolaris использовался.
Для них, таким конфигурировать может быть скрипт запуска, в котором будут зашиты не меняющиеся параметры, а остальные так же передавать через командную строку. Ну или алиасы. Сам так делал и другие делали. Как альтернатива кончинам - вполне себе.
Надо понимать с какими компаниями Игорь сталкивался. Компании работающие только на российский рынок, там и зарплаты ниже и требования, опять же, в силу зарплат ниже. Более квалифицированным специалистам проще пойти в продуктовую компанию на существенно более высокую зарплату или пойти в международные компании, где зарплаты будут соответствовать российскому рынку, но клиентами будут зарубежные компании, для которых найм таких сотрудников выгоден.
Это из моего опыта общения с компаниями-агентами. Есть еще отдельный класс который просто нанимает в свой штат, но собеседования и прочее проходишь с целевой компанией и работаешь ты именно на эту компанию, там зарплаты будут в рынке, но там никаких отличий от работы в продуктовой компании и собственно никаких плюсов от работы в компании-агенте.
Вопрос про какие компании идет речь. В крупных международных компаниях типа Luxoft, Epam, Grid Dynamics есть те кто работают много лет и очень доволены, кто-то делает карьеру вырастая в архитектора или продакта, кому-то нравится возможность сменить проект, поработать с разными людьми. А в некоторых случаях - это просто единственная возможность поработать в крупной компании, например, Google или Apple оставаясь дома. Плюс практика английского, возможность видеть как работают и мыслят люди из других стран. Это очень интересно. Опять же возможность поработать над разными проектами.
Крупные консалтинговые компании могут иметь и внутренние продукты, так как держат какой-то процент людей в резерве, чтобы оперативно реагировать на новые заказы. И тут они дают волю фантазии инженерам, на таких проектах можно попробовать освоить новые технологии, попробовать себя в новой роли - продакта, лида, QA или разработчика. По «плюшкам» такие компании не отключаются от продуктовых, а то могут и превосходить в части обучения языкам, в первую очередь английский, прохождение курсов и получение сертификатов - компании сами в этом заинтересованы. Возможность пожить, поработать в другой стране без релокации.
Да, можно попасть на скучный проект, но тоже самое касается и продуктовой компании, где так же может оказаться скучно.
Вообще, идея очень похожа на идеи, встречающиеся в функциональном программировании. В ООП я в чистом виде подобного не видел. Создается DSL для предметной области отвязанный от исполнения, а потом создается слой который исполняет этот DSL, соотвественно можно подменить среду исполнения (БД, фреймворки).
В итоге код может разделиться на две части модельные сущности и их взаимодействие описанной в терминах DSL, и слой исполнения этого DSL. Но вопрос цены такой разработки, как много специалистов готовы так делать и есть ли от этого существенные преимущества от такого подхода.
Конечно, можно так писать и в ООП, описывает логику и потом слой который свяжет нашу модель и фреймворк. Но опять же, какая будет цена такой разработки и какие преимущества даст такой подход. Все таки превращение Web приложения в консольное хотя и имеет место быть, точнее не превращение, а проявление дополнительного клиента, но всё же вещь редкая. Замена БД встречается, пожалуй, чаще, но все же достаточно редко и если происходит, то в этот момент, скорей всего, надо переосмыслить всю архитектуру так как поменялись требования.
Можно до какой-то степени достраивать дом, добавлять новые комнаты и даже этаж или два, но группы небольших мастерских превратить в большой мощный завод на фундаменте мастерских - не получится, фундамент надо будет менять.
Есть в Scala не популярный фреймворк Lagom для микросервисов, который в свою очередь построен на баз фреймворка Play, а он базируется на фреймворка Akka. ?
Это просто вызов команд, не важно как его делать в конвейере, объединив команды через
&&, или||, или записать их последовательность в скрипт и выполнить, или каждый раз вручную вводя команду (копируя откуда-то), или кликая мышкой по менюшкам. Запись макроса или последовательный запуск команд в скрипте, на границе, но всё же нет.В противном случае, любая работа связанная с использование компьютера - программирование. Просто интерпретатором команд является не шелл, а какая-то другая программа. Ну за исключением компьютер когда используется как подставка или его куда-то переносят, ну или еще совершают какое-то действие как с некоторым объектом. :)
Причем процесс программирования - это как раз процесс создания программы. Дальнейшие её запуски уже программированием не являются. И смысл программирования ещё в том, чтобы программа, как результат процесса, использовалась многократно без модификации, а не создавалась для разового выполнения.
Слышал, использую. Нет потребности любой ценой объединить исполнение команд в конвейер, ради конвейера.
Необязательно команду языка, это может быть просто имя исполняемого файла, но да, тогда это будет рассматривать как команда на запуск этого файла.
Но таком случае, работа в программе в GUI, где есть возможность записи макроса и/или повтора команды из истории так же является вариантом визуального программирования. Ведь по сути, клик по меню или выбор и применение инструмента - это просто форма описания команды, которая сохранилась в истории. Является ли это программированием (визуальным)?
В моем понимании ни первый ни последний не являются программированием. Для меня грань пролегает при появлении языковых конструкций ветвления, циклов. При этом написать скрипт в котором после каждого вызова программы будет стоять явная проверка на то, что команда завершилась успехом, и в этом случае продолжается исполнение скрипта, а в случае ошибки прерывается с каким-то дополнительным сообщением - становится программированием. Просто прерывание попадает под программирование, но можно заменить
set -eили объединением команд в одну через&&. Или дописав|| exit 1к каждой.А какая разница, объединяю я запуск команд в конвейер или перенаправляю вывод одной команды в файл, а потом этот файл передаю на вход другой команде? Тем самым я сохраняю промежуточное состояние и если ошибся в команде, или мне нужны другие параметры, то не надо выполнять всю цепочку команд.
И это мало отличается от того, чтобы открыть файл в одной программе, сделать с ним какие-то манипуляции, результат сохранить и обработать а другой программе.
Если я написал скрипт (не важно bash, sh, bat, power shell), то да, это будет программированием, программирование подразумевает, что появляется описание алгоритма которое можно переиспользовать. В случае ручного набора команд и объединения их в конвейер результат в виде скрипта не остаётся, т.е. нет результата процесса программирования.
Так же, я могу чертить в автокаде используя его встроенную консоль и даже делать циклы, но это опять же не будет программированием, так есть только результат работы, но нет самой программы.
А если я в ворде записал макрос и сохранил его - это программирование, так в результате процесса появилась программа, которую можно повторно запустить.
Даже написание файла конфигурации vim/nvim - программирование, потому что в результате появляется программа которую можно выполнить и выполняет её vim/nvim. Ну или emacs.
Если по вашему работа в консоли - это хотя бы объединение команд в конвейер, то как называть просто отдельный запуск CLI программ?
Ну я работаю в консоли - использую различные тулы, но не пишу скрипты. Это преимущественно запуск сборки, тестов (по другому не запустить нужную для проверки версию), просмотр логов, какие-то манипуляции с ними при помощи разных утилит (grep, dsq, jq) или апи дернуть курлом, пакеты обновить/поставить.
Это программирование? Вряд ли, иначе - любой запуск программы становится программированием. Работа в консоле - да, все тулы имею CLI, из обладающих псевдографикой только tmux/screen.
О, 10 лет понадобилось, чтобы вернуть инсталлер… :) надо будет взглянуть на арч снова.
Спасибо, думал, что это что-то более унифицированное, наподобие vi-like управления.
WSL дает представление о работе с командной строкой, но не для погружения целиком в дистрибутив. В идеале, в случае с линукс/*BSD показать несколько окружений рабочего стола. По моему опыту люди теряются при виде чего-то непривычного и просто не будут этим пользоваться. А так им GUI будет более привычен. Показать что искать, чтобы поменять какие-то настройки, как минимум управление сетями.
В случае со школьным образованием, мне кажется, важно показать разнообразие интерфейсов, тогда будет проще разобраться с каким-то новым. По удобству, потом каждый выберет для себя сам. Есть организации где на компьютерах стоит линукс их еще не много, лично не видел, но в интернетах читал, что перевели всех пользователей на линукс. Так что пруфов не будет.
"Полное погружение" в линукс актуально, если есть какая-то глобальная цель у государства снизить зависимость от продуктов Windows, если такой цели нет, то и мучать детей этим особо смысла не вижу. Можно просто в виртуалке или с Live носителя с линукс показать, что есть альтернатива Windows. А кому надо, тот потом сам разберется.
А что касается удобства... Ну тут у всех свои предпочтения, мне больше нравится линукс, кто-то предпочитает мак, вы винду. Если бы меня поставили перед выбором для дома или мак, или винда, то выбрал бы винду. К счастью, меня никто не ставит перед таким выбором. А в работе предпочитаю то, чем пользуется большинство, чтобы не собирать уникальных граблей. Да и линукс реже предлагают, в основном выбор между виндой и маком, а то и просто без выбора.
Да, хорошее замечание. Но в эмуляторах не встречал такого. Вкладка закрывается по Ctrl + Shift + W, а на маке по Cmd + W. В Windows Terminal тоже закрывается по Ctrl + Shift + W.
Да и момент, что для мака в этих хоткеях именно ctrl, а не cmd как часто бывает, что сочетания
ctrl +в маке превращается вcmd +, но не в этом случае.Отдельное спасибо за спикок хоткеев к терминалу, очень удобно. Я бы еще добавил к ним
Ctrl + W- вырезать слово слева от курсора, его потом можно так же вставить. И минутка занудства: Ctrl + U вырезает всё слева от курсора. Т.е. если курсор стоял в конце строки, то да, всю команду, а если в середине, то "хвост" останется. В противовес ему есть Ctrl + K, который вырезает всё справа от курсора.И главное, что эти хоткеи работают и на маке, да и в большинстве эмуляторов терминала. Где не работают, так это терминалы встроенные в IDE. :)
P.S.
Если кому-то зайдет идея использовать хоткеи в терминале, то их можно нагуглить по emacs hotkeys.
Пробовали тайловый оконный менеджер, например i3? Видел у коллег и они были весьма довольны. Я пробовал, мне меньше зашел - мне привычнее gnome. i3 минималистичный и так же управляется хоткеями, мышкой тоже можно.
Не понимаю откуда споры, если всем уже давно известно, что писать программы надо на Haskell и только на нем, тогда и ошибок никаких не будет. :)
Например, система управления и мониторинга оборудования РЛС наземного базирования. Там как раз использовался Солярис и в планах, насколько я понял, был переход на что-то типа линукса.
Не все задачи требуют жесткого реального времени и соответствующих ОС.
Бортовые навигационные системы, которые Транзас делал и они использовались так же и военными. Часть точно работала под управлением линукс, но что конкретно за дистрибутив - не знаю, скорей всего так же Астра.
Да и те же данные накапливать и обрабатывать где-то надо, аналитику и тому подобное, да и писарям в штабах тоже за чем-то работать надо. Но там винда скорей всего, не знаю, не видел. В военкоматах, вроде, винду видел.
Базовое - да, как и в случае с Windows и Mac OS, но базовое - это на уровне, вот командная строка, вне можно запускать программы. Справку о команде чаще всего можно получить так и так. Ну и базовый набор команд типа cd, ls, dir, pwd. Вот на такому уровне - да. Глубже смысла нет, так как забудется.
Раньше был МСВС (мобильная система вооруженных сил), сейчас Астра Линукс используется.
Для последнего, можно купить лицензию и использовать дома.
Раньше ещё Солярис на Эльбрусах использовался для управления разными системами. Но Солярис все таки не опенсорс, покраснел мере не opensolaris использовался.
Для них, таким конфигурировать может быть скрипт запуска, в котором будут зашиты не меняющиеся параметры, а остальные так же передавать через командную строку. Ну или алиасы.
Сам так делал и другие делали. Как альтернатива кончинам - вполне себе.