Согласен с Вами, но лишь отчасти. Ситуаций - огромное множество, решений - аналогично. Скрипт я писал для себя, мне не нужен быстрый доступ к бОльшему количеству файлов.
В процессе работы над проектами/рабочими задачами, часто копятся не мои блоки кода/скриншоты и прочий "мусор", который сохранить желательно, но в "общей свалке". К скринам проще получить 1-2 раза за сутки доступ с рабочего стола - после чего они нужны исключительно "на всякий случай". Из-за чего и был написан сам скрипт. Я просто залил его в планировщик задач с определенными настройками и перестал тратить время на перебрасывание файлов по папкам.
Неужели у скрипта настолько сложная логика, которая навечно спрячет ярлыки где-то в сотне папок без возможности глянуть по логам?
Как раз для данных ситуаций, как человек, имеющий подобные ярлыки, добавил функцию тестового запуска с возможностью поглядеть, куда все падает. Плюсом, для чего-то же была добавлена возможность простой смены настроек работы скрипта, включая расширения файлов. Исключите «ярлыки» из поля действий скрипта, почему нет?
Акцентирую внимание, мной был озвучен факт частичной бесполезности скрипта для подавляющего большинства. Применение ему найти можно, но далеко не всегда и не всем, о чем я говорил. Вы же комментируете так, словно я уверяю в важности и гениальности данного решения.
Спасибо за комментарий! Не уверен, что на Хабр сидят исключительно люди с огромным стажем в ИТ. Ниже был комментарий с вопросом: «с чего начать углубление, Bash или Python, если цель админить Linux/DevOps».
Я уверен, что Вы легко определите, какой язык использовать для скрипта под ту или иную задачу, но ведь не все имеют подобные знания. Разве это не так?
Не сочтите, пожалуйста, за грубость, но в действительности в АйТи заходят и молодые специалисты, которые вот-вот выпустились с ВУЗа. Для них многие вещи, которые Вам кажутся очевидными и простейшими, будут тяжелы в восприятии. Опыт приходит со временем.
Плюсом, я сравнивал не языки, а ситуации, когда и что использовать лучше. Когда правильнее и эффективнее использовать одно, а когда другое. На мой взгляд, это все же ≠ сравнению языков.
Практически, важнее начать с Bash, тк он является стандартным интерпретатором командной строки. Без него админить Linux будет весьма проблематично. Затем плавно переходить к Python для сложных процессов.
Плюсом ко всему, админить сервера и работать с инструментами (K8s, Ansible, CI/CD) без знаний Bash крайне затруднительно. Но и Python для сложных процессов отменять сложно. Я бы посоветовал попробовать практиковаться параллельно.
Спасибо аз комментарий! Обратная связь очень помогает делать материалы более качественным.
Ваше замечание полностью справедливо, стоило внести эту информацию в статью. Для Python использоваться timet, для Bash - time. Проходов было 3, файлы же использовались одни и те же.
Момент с созданием репозитория рассмотрю в обязательном порядке, данный пункт действительно был упущен.
Что касательно путаницы в терминологии... Вы правы, фактически я противопоставлял 2 разных подхода. Методологическая ошибка, которая может ввести в заблуждение.
Да, мой пример с регулярками для разбора логов в Pythn - не самый лучший выбор для демонстрации производительности, были примеры более корректные. Но в этом аспекте я сознательно пошёл на компромисс в пользу "универсальности", тк регулярки лучше справятся с "грязными" данными. В статье данный момент действительно стоило оговорить, дабы не вводить в заблуждение.
И, про инициализацию интерпретатора - это наиболее важное замечание, которое мной было вообще упущено из виду. Разница в скорости запуска может быть критичной для каких-то сценариев.
Спасибо! Вы указали на все слабые места в статье, со всем согласен. Критика бесценна. Не сочтите за оправдание. Я действительно небольшой опыт в написании имею, поэтому какие-то аспекты в силу "неопытности" могу упускать. Критика же невероятно помогает в написании следующих статей, стараюсь уделять больше внимания деталям. Очень стараюсь улучшать материал, Вам ещё раз больше спасибо!
Спасибо за комментарий! Если рассматривать с подобной стороны - определенно факт. Я же хотел сравнить использование под те или иные задачи на Linux. Фактически, все задачи можно решить на одном bash, не городить окружения и тд, но ведь с точки зрения удобства подходы будут отличаться.
Попробуйте найти через поисковик статьи, например, «о пользе высшего в IT». Вы будете крайне удивлены их количеству. Это касается в целом большинства тем.
по всей видимости эффект от чатаЖПТ и иже с ними + "эффект ваАйТишников"
Раскройте понятия, пожалуйста. Не понимаю, что за «эффекты».
И, насколько мне известно, есть tmux pipe-pane,но про него подсказать ничего не могу, к сожалению, только наслышан. Вроде он логирует только после подключения.
Спасибо за комментарий! Решения в статье действительно не идеальны. Мой посыл оказался неудачен, бывает. Постараюсь подробнее погружаться в тему в дальнейшем.
Я себе для таких задач EternalTerminal поднимаю, он удерживает контекст практически всегда. Но, к сожалению, он должен устанавливаться в том числе и на сервер, что не всегда возможно.
Изучу, погляжу, спасибо! И прошу прощения за потраченное время на не самую удачную статью. В своих решениях я использую принцип "адаптивности", с чем скрипты справляются отлично. Понадобилось логирование - дописал, необходим мониторинг с уведомлениями - сделал. При написании не подразумевал, что в большинстве ситуаций при обрывах используют mosh\screen\EternalTerminal.
Спасибо за комментарий! Ни screen, ни mosh не отменяли. Моё решение рассчитано на дополнительный функционал, который каждый потенциально может адаптировать под себя. До публикации мне казалось, что тема достаточно интересная. Статья вышла неудачная, признаю. Прошу прощения.
Спасибо за комментарий! Согласен, есть mosh, с данным решением я не спорил, но он не даёт гибкости. Писать скрипты - как хобби. Я выливаю всё, что делаю, в статьи на Хабр, кому-то моё решение может помочь, быть полезным и тд.
Mosh - "монолит", который сложнее адаптировать под специфические задачи.
В плане удобства для большинства пользователей - согласен с Вами, решение идеальное, но это же не подразумевает бесполезность статьи из-за того, что такое решение уже есть на "рынке". Если мы будем зацикливаться на уже существующих - как придумывать новое? Фактически всему есть аналоги.
Спасибо за комментарий! Согласен, есть mosh, с данным решением я не спорил, но он не даёт гибкости. Писать скрипты - как хобби. Я выливаю всё, что делаю, в статьи на Хабр, кому-то моё решение может помочь, быть полезным и тд.
Mosh - "монолит", который сложнее адаптировать под специфические задачи.
В плане удобства для большинства пользователей - согласен с Вами, решение идеальное, но это же не подразумевает бесполезность статьи из-за того, что такое решение уже есть на "рынке". Если мы будем зацикливаться на уже существующих - как придумывать новое? Фактически всему есть аналоги.
Спасибо за комментарий! Это было больше про указанную ниже функцию мониторинга с уведомлением в Telegram. Решил на всякий случай уточнить, так как часто читаю комментарии в стиле: "есть же Zabbix" и "зачем городить, всё давно придумано". Возможно в "уточнении" выразился некорректно, прошу прощения.
У меня слово "автоматизация" в ИТ с начала 21 века (2006 год примерно) ассоциируется с продуктом ИБМ System Automation (SA)
Важная пометка, ассоциируется у Вас. Ваше мнение, как и моё, не может считаться "эталоном".
Вы автор и Вы должны максимально корректно относиться к комментирующим Ваш труд
Что мной было сказано некорректно? Использование "терминов 2000-х"? Или сообщество, которому интересна новая тенденция, должны использовать, как Вы, термин "программное выполнение ручных функций".
Автоматизация — применение технических средств, экономико-математических методов и систем управления, освобождающих человека частично или полностью от непосредственного участия в процессах получения, преобразования, передачи и использования энергии, материалов или информации.
Официальная терминология с википедии. Подчеркнул слово "частично", чтобы Вы не подменяли понятия под Ваши убеждения.
Поэтому никакого "слияния «старой и новой» автоматизации" Вам в будущем не светит. Вы так и будете называть написание скриптов автоматизацией.
Почему Вы противитесь Вашим же вопросам, на которые я отвечал:
но что вы будете делать если дело дойдет до действительно автоматизации? Какое слово будет найдено для этого.
Я рассудил, вывел Вам пример "слова" для автоматизации, а с Вашей стороны началась агрессия? На что? На факт непринятия с моей стороны чужой позиции, с которой я не согласен и на которую я не увидел аргументов? Мне надо преклоняться перед всеми, кто со мной не согласен?
но что вы будете делать если дело дойдет до действительно автоматизации?
Разве это подразумевает, что мы должны сидеть на терминах начала 2000-х и не придумывать какие-то новые ветки IT? Что мешает в будущем произвести слияние «старой и новой» автоматизации и как использование данного термина повлияет на дальнейшее развитие АйТи?
Насколько я помню, когда-то не было и DevOps, но ввели, ввели официально, пользуются повсеместно. Чем термин «автоматизации» хуже?
Просто номер версии через некоторое время мне уже ни о чём не говорит.
Этот пример был использовал скорее для наглядности, но в моей практике есть применение версионирования. Есть небольшой «сдвиг» на структуризации, поэтому любые важные (или полезные) скрипты хранятся в БД, в том числе и их старые версии. Особенно на работе данный принцип применим. Формат: «Версия 1.0» в ситуации с только написанным скриптом, «Версия 2.1» - допиленный (+ 1 версии - глобальные доработки, + 0,1 - небольшие изменения в коде) + обязательное документирование (что, где, когда, куда и откуда).
Неважные или неиспользуемые скрипты маркирую датой, в этом плане действительно удобно, согласен. В них мне не нужен контроль и анализ (что потенциально могло вызвать те или иные ошибки в сравнении с прошлой версией).
version 1.0.2356. build 115 rev 12
Такой формат не вижу смысла использовать в целом, я такое количество версий на скрипте никогда не сделаю. Это уже про грамотный подход и, как мне кажется, цельные приложения. Скриптам будет избыточно, как мне кажется.
Спасибо за комментарий! Очень зависит от подхода. Если гореть/фанатеть и не обращать внимания на остальные сферы жизни, то безусловно - Вы правы. На деле же, все реже встречаю «закрытых» айтишников. Даже наоборот, открытых словно больше (исходя из моей личной выборки, общую массу судить не берусь).
Согласен с Вами, но лишь отчасти. Ситуаций - огромное множество, решений - аналогично. Скрипт я писал для себя, мне не нужен быстрый доступ к бОльшему количеству файлов.
В процессе работы над проектами/рабочими задачами, часто копятся не мои блоки кода/скриншоты и прочий "мусор", который сохранить желательно, но в "общей свалке". К скринам проще получить 1-2 раза за сутки доступ с рабочего стола - после чего они нужны исключительно "на всякий случай". Из-за чего и был написан сам скрипт. Я просто залил его в планировщик задач с определенными настройками и перестал тратить время на перебрасывание файлов по папкам.
Неужели у скрипта настолько сложная логика, которая навечно спрячет ярлыки где-то в сотне папок без возможности глянуть по логам?
Как раз для данных ситуаций, как человек, имеющий подобные ярлыки, добавил функцию тестового запуска с возможностью поглядеть, куда все падает. Плюсом, для чего-то же была добавлена возможность простой смены настроек работы скрипта, включая расширения файлов. Исключите «ярлыки» из поля действий скрипта, почему нет?
Акцентирую внимание, мной был озвучен факт частичной бесполезности скрипта для подавляющего большинства. Применение ему найти можно, но далеко не всегда и не всем, о чем я говорил. Вы же комментируете так, словно я уверяю в важности и гениальности данного решения.
Спасибо за комментарий! Тяжело в эпоху ИИ сделать что-то не похоже на ИИ, сохраняя структуру. Почему же похоже на GPT?
Upd: сразу дополню. Я не считаю, что статьи с техническим разбором должны носить в себе много «отсебятины», не всегда четкая и сухая структура = GPT.
Спасибо за комментарий! Не уверен, что на Хабр сидят исключительно люди с огромным стажем в ИТ. Ниже был комментарий с вопросом: «с чего начать углубление, Bash или Python, если цель админить Linux/DevOps».
Я уверен, что Вы легко определите, какой язык использовать для скрипта под ту или иную задачу, но ведь не все имеют подобные знания. Разве это не так?
Не сочтите, пожалуйста, за грубость, но в действительности в АйТи заходят и молодые специалисты, которые вот-вот выпустились с ВУЗа. Для них многие вещи, которые Вам кажутся очевидными и простейшими, будут тяжелы в восприятии. Опыт приходит со временем.
Плюсом, я сравнивал не языки, а ситуации, когда и что использовать лучше. Когда правильнее и эффективнее использовать одно, а когда другое. На мой взгляд, это все же ≠ сравнению языков.
Спасибо за комментарий!
Практически, важнее начать с Bash, тк он является стандартным интерпретатором командной строки. Без него админить Linux будет весьма проблематично. Затем плавно переходить к Python для сложных процессов.
Плюсом ко всему, админить сервера и работать с инструментами (K8s, Ansible, CI/CD) без знаний Bash крайне затруднительно. Но и Python для сложных процессов отменять сложно. Я бы посоветовал попробовать практиковаться параллельно.
Спасибо аз комментарий! Обратная связь очень помогает делать материалы более качественным.
Ваше замечание полностью справедливо, стоило внести эту информацию в статью. Для Python использоваться timet, для Bash - time. Проходов было 3, файлы же использовались одни и те же.
Момент с созданием репозитория рассмотрю в обязательном порядке, данный пункт действительно был упущен.
Что касательно путаницы в терминологии... Вы правы, фактически я противопоставлял 2 разных подхода. Методологическая ошибка, которая может ввести в заблуждение.
Да, мой пример с регулярками для разбора логов в Pythn - не самый лучший выбор для демонстрации производительности, были примеры более корректные. Но в этом аспекте я сознательно пошёл на компромисс в пользу "универсальности", тк регулярки лучше справятся с "грязными" данными. В статье данный момент действительно стоило оговорить, дабы не вводить в заблуждение.
И, про инициализацию интерпретатора - это наиболее важное замечание, которое мной было вообще упущено из виду. Разница в скорости запуска может быть критичной для каких-то сценариев.
Спасибо! Вы указали на все слабые места в статье, со всем согласен. Критика бесценна. Не сочтите за оправдание. Я действительно небольшой опыт в написании имею, поэтому какие-то аспекты в силу "неопытности" могу упускать. Критика же невероятно помогает в написании следующих статей, стараюсь уделять больше внимания деталям. Очень стараюсь улучшать материал, Вам ещё раз больше спасибо!
Спасибо за комментарий! Если рассматривать с подобной стороны - определенно факт. Я же хотел сравнить использование под те или иные задачи на Linux. Фактически, все задачи можно решить на одном bash, не городить окружения и тд, но ведь с точки зрения удобства подходы будут отличаться.
Спасибо за комментарий!
Попробуйте найти через поисковик статьи, например, «о пользе высшего в IT». Вы будете крайне удивлены их количеству. Это касается в целом большинства тем.
Раскройте понятия, пожалуйста. Не понимаю, что за «эффекты».
Не очень понимаю грубости высказывания с Вашей стороны. Вы спросили - я ответил, а не двигал тезисы, как "надо".
Спасибо за комментарий! Предположу, может попробовать
ansifilter? Что-то в стиле:И, насколько мне известно, есть
tmux pipe-pane,но про него подсказать ничего не могу, к сожалению, только наслышан. Вроде он логирует только после подключения.Спасибо за комментарий! Решения в статье действительно не идеальны. Мой посыл оказался неудачен, бывает. Постараюсь подробнее погружаться в тему в дальнейшем.
Изучу, погляжу, спасибо! И прошу прощения за потраченное время на не самую удачную статью. В своих решениях я использую принцип "адаптивности", с чем скрипты справляются отлично. Понадобилось логирование - дописал, необходим мониторинг с уведомлениями - сделал. При написании не подразумевал, что в большинстве ситуаций при обрывах используют mosh\screen\EternalTerminal.
Спасибо за комментарий! Ни screen, ни mosh не отменяли. Моё решение рассчитано на дополнительный функционал, который каждый потенциально может адаптировать под себя. До публикации мне казалось, что тема достаточно интересная. Статья вышла неудачная, признаю. Прошу прощения.
Спасибо за комментарий! Честно сказать, не тестировал. Вероятнее всего, в этом плане скрипты - не идеальное решение.
Предположу, что можно попробовать настроить вход не по двухфакторной, а для конкретного SSH-ключа, если политика безопасности позволяет.
Спасибо за комментарий! Согласен, есть mosh, с данным решением я не спорил, но он не даёт гибкости. Писать скрипты - как хобби. Я выливаю всё, что делаю, в статьи на Хабр, кому-то моё решение может помочь, быть полезным и тд.
Mosh - "монолит", который сложнее адаптировать под специфические задачи.
В плане удобства для большинства пользователей - согласен с Вами, решение идеальное, но это же не подразумевает бесполезность статьи из-за того, что такое решение уже есть на "рынке". Если мы будем зацикливаться на уже существующих - как придумывать новое? Фактически всему есть аналоги.
Спасибо за комментарий! Согласен, есть mosh, с данным решением я не спорил, но он не даёт гибкости. Писать скрипты - как хобби. Я выливаю всё, что делаю, в статьи на Хабр, кому-то моё решение может помочь, быть полезным и тд.
Mosh - "монолит", который сложнее адаптировать под специфические задачи.
В плане удобства для большинства пользователей - согласен с Вами, решение идеальное, но это же не подразумевает бесполезность статьи из-за того, что такое решение уже есть на "рынке". Если мы будем зацикливаться на уже существующих - как придумывать новое? Фактически всему есть аналоги.
Спасибо за комментарий! Это было больше про указанную ниже функцию мониторинга с уведомлением в Telegram. Решил на всякий случай уточнить, так как часто читаю комментарии в стиле: "есть же Zabbix" и "зачем городить, всё давно придумано". Возможно в "уточнении" выразился некорректно, прошу прощения.
Не очень Вас понял.
Важная пометка, ассоциируется у Вас. Ваше мнение, как и моё, не может считаться "эталоном".
Что мной было сказано некорректно? Использование "терминов 2000-х"? Или сообщество, которому интересна новая тенденция, должны использовать, как Вы, термин "программное выполнение ручных функций".
Официальная терминология с википедии. Подчеркнул слово "частично", чтобы Вы не подменяли понятия под Ваши убеждения.
Почему Вы противитесь Вашим же вопросам, на которые я отвечал:
Я рассудил, вывел Вам пример "слова" для автоматизации, а с Вашей стороны началась агрессия? На что? На факт непринятия с моей стороны чужой позиции, с которой я не согласен и на которую я не увидел аргументов? Мне надо преклоняться перед всеми, кто со мной не согласен?
Спасибо за комментарий!
Разве это подразумевает, что мы должны сидеть на терминах начала 2000-х и не придумывать какие-то новые ветки IT? Что мешает в будущем произвести слияние «старой и новой» автоматизации и как использование данного термина повлияет на дальнейшее развитие АйТи?
Насколько я помню, когда-то не было и DevOps, но ввели, ввели официально, пользуются повсеместно. Чем термин «автоматизации» хуже?
Спасибо за комментарий!
Этот пример был использовал скорее для наглядности, но в моей практике есть применение версионирования. Есть небольшой «сдвиг» на структуризации, поэтому любые важные (или полезные) скрипты хранятся в БД, в том числе и их старые версии. Особенно на работе данный принцип применим. Формат: «Версия 1.0» в ситуации с только написанным скриптом, «Версия 2.1» - допиленный (+ 1 версии - глобальные доработки, + 0,1 - небольшие изменения в коде) + обязательное документирование (что, где, когда, куда и откуда).
Неважные или неиспользуемые скрипты маркирую датой, в этом плане действительно удобно, согласен. В них мне не нужен контроль и анализ (что потенциально могло вызвать те или иные ошибки в сравнении с прошлой версией).
Такой формат не вижу смысла использовать в целом, я такое количество версий на скрипте никогда не сделаю. Это уже про грамотный подход и, как мне кажется, цельные приложения. Скриптам будет избыточно, как мне кажется.
Спасибо за комментарий! Очень зависит от подхода. Если гореть/фанатеть и не обращать внимания на остальные сферы жизни, то безусловно - Вы правы. На деле же, все реже встречаю «закрытых» айтишников. Даже наоборот, открытых словно больше (исходя из моей личной выборки, общую массу судить не берусь).