Спасибо за фидбек. К сожалению не было возможности (да и необходимости) запускать на вин платформах и про подобные проблемы я не знал. Посмотрю в ближайшие дни и свяжусь с вами.
Если я правильно понял ваш вопрос, то там после выделения выполняется несколько действий:
выделили
перешли в конец и выделили числа (почему не сразу выделили числа, я не знаю)
преобразовали их в последовательность
подготовили константы, добавив "Example." и перенесли их в IntDef
Чем плоха обычная автозамена текста в выделенном блоке?
Ничем, в большинстве случаев они взаимозаменяемы. Но как по мне, то работа с мультиселектом более быстрая и удобная (не нужно переходить в специальное поле и там что-то писать). Вы просто продолжаете писать код. До того, как в идею добавили мультиселект, я тоже не понимал в чем разница, а потом распробовал.
К тому же некоторые вещи через замену делать ну очень не с руки. Например вы использовали названия myCat и myDog, но затем решили что cat и dog выглядят лучше:
С помощью мультиселекта выделяем все " my",
удаляем my
выделяем следующую букву через шифт
делаем lowercase.
Хотя по большей части разница использовать мультиселект или нет — не такая большая. На "полностью изменивший принцип моей работы" явно не тянет. Но попробовать я бы точно советовал.
Статья не совсем про хоткий, а скорее про саму идею мультиселекта. Из коллег-разработчиков, я замечал что от силы 20% используют эту "фичу", и ещё меньше делают это наполную.
Важное отличие приведенных примеров от мультикурсора по альту это именно выделение шаблонов. Из своего опыта, в 90% использовании мультиселекта одним альтом не обойдешься.
Вимеры могут хихикать, но тут вопрос не холивара, а повышения производительности тех, кто уже выбрал темную сторону IDE. Вимеры могут игнорировать посты про Android studio.
пс я работаю с основном с идеей, и там хоткий другой по умолчанию (alt+j). И мне кажется в студии вряд ли он ctrl+g (ибо это стандартный переход на строку).
Кстати, если вдруг кто будет читать, альтернатива для alt+select на клавиатуре (без мыши) ctrl+ctrl и стрелки. По крайней мере в идее именно так
Спасибо. Про expect я знаю. С помощью него можно заменить практически всё на пакетный режим.
Но интерактивность это не всегда зло. К тому же expect обертки тоже нужно поддерживать (если скрипты меняются).
Я даже подумывал прикрутить вынос некоторых интерактивных параметров через expect в стартовые параметра скрипта. Но по причинам выше не особо приоритезировал эту задачу.
главное знать инструменты
Согласен, но в данном случае из имеющихся инструментов мне больше по душе пришелся rundeck. Для конкретно моей задачи.
Посмотрел rundeck подробнее, ещё раз спасибо. Появились идеи как его можно использовать. Однако несколько для других задач — он более расширенный и сложный из-за этого, поэтому попробуем его для разработчиков. И вполне возможно заменим когда-нибудь мою поделку на rundeck.
Пока же для нетехнических коллег продолжим использовать мой сервер, т.к. для конкретных наших задач он получается гораздо проще в использовании пользователями.
Практически все скрипты можно переписать в пакетный режим.
Не могу не согласится, особенно в моем случае, когда не так много взаимодействия с пользователями. Однако:
В ряде случаев интерактив более удобен (т.к. в рантайме можно предоставить выбор исходя из состояния выполнения скрипта или других часто изменяющихся значений)
Не всегда ты отвечаешь за эти скрипты (если исполняемое нечто это вообще скрипт) и можешь их изменять.
Что-то совсем вроде и совсем lite-версии ansible. Прям как из пушки по воробьям.
paramiko — до этого с ним не сталкивался, но не совсем понятно как вы предлагаете его здесь использовать. Можете пожалуйста пояснить?
> Хотя есть плюс, сделано симпатично, но функционал урезан
Спасибо за комплимент интерфейсу.
По функционалу вопрос потребностей, если честно. Из того, что на мой взгляд критично не хватает, это авторизация. Но опять же в моем случае не так много пользователей и всем им я доверяю.
Спасибо за совет, выглядит почти как то, что и хотелось получить изначально. Изучу инструмент подробнее.
Честно говоря, прежде чем делать, посмотрел какие уже есть инструменты, но:
1. Плохо знал по каким названиям эти инструменты искать
2. Особо не старался, т.к. было желание опробовать свои силы и сделать именно то, что виделось.
Насколько я знаю в Jenkins нельзя настроить интерактивное выполнение. Т.е. любой скрипт с запросом информации у пользователя обречен.
А в моих скриптах таковой присутствует.
Ну и честно говоря CI не рассматривал из-за их тяжеловесности. Т.е. для простой задачи слишком много действий потребуется в данном случае
Спасибо за фидбек. К сожалению не было возможности (да и необходимости) запускать на вин платформах и про подобные проблемы я не знал. Посмотрю в ближайшие дни и свяжусь с вами.
Постараюсь ответить за автора:
Если я правильно понял ваш вопрос, то там после выделения выполняется несколько действий:
Ничем, в большинстве случаев они взаимозаменяемы. Но как по мне, то работа с мультиселектом более быстрая и удобная (не нужно переходить в специальное поле и там что-то писать). Вы просто продолжаете писать код. До того, как в идею добавили мультиселект, я тоже не понимал в чем разница, а потом распробовал.
К тому же некоторые вещи через замену делать ну очень не с руки. Например вы использовали названия myCat и myDog, но затем решили что cat и dog выглядят лучше:
Хотя по большей части разница использовать мультиселект или нет — не такая большая. На "полностью изменивший принцип моей работы" явно не тянет. Но попробовать я бы точно советовал.
пс у идеи была неплохая гифка по юз кейзу этой фичи, когда она вышла: https://d3nmt5vlzunoa1.cloudfront.net/idea/files/2014/03/multiple_selections.gif
Статья не совсем про хоткий, а скорее про саму идею мультиселекта. Из коллег-разработчиков, я замечал что от силы 20% используют эту "фичу", и ещё меньше делают это наполную.
Важное отличие приведенных примеров от мультикурсора по альту это именно выделение шаблонов. Из своего опыта, в 90% использовании мультиселекта одним альтом не обойдешься.
Вимеры могут хихикать, но тут вопрос не холивара, а повышения производительности тех, кто уже выбрал темную сторону IDE. Вимеры могут игнорировать посты про Android studio.
пс я работаю с основном с идеей, и там хоткий другой по умолчанию (alt+j). И мне кажется в студии вряд ли он ctrl+g (ибо это стандартный переход на строку).
Кстати, если вдруг кто будет читать, альтернатива для alt+select на клавиатуре (без мыши) ctrl+ctrl и стрелки. По крайней мере в идее именно так
Спасибо. Про expect я знаю. С помощью него можно заменить практически всё на пакетный режим.
Но интерактивность это не всегда зло. К тому же expect обертки тоже нужно поддерживать (если скрипты меняются).
Я даже подумывал прикрутить вынос некоторых интерактивных параметров через expect в стартовые параметра скрипта. Но по причинам выше не особо приоритезировал эту задачу.
Посмотрел rundeck подробнее, ещё раз спасибо. Появились идеи как его можно использовать. Однако несколько для других задач — он более расширенный и сложный из-за этого, поэтому попробуем его для разработчиков. И вполне возможно заменим когда-нибудь мою поделку на rundeck.
Пока же для нетехнических коллег продолжим использовать мой сервер, т.к. для конкретных наших задач он получается гораздо проще в использовании пользователями.
Не могу не согласится, особенно в моем случае, когда не так много взаимодействия с пользователями. Однако:
paramiko — до этого с ним не сталкивался, но не совсем понятно как вы предлагаете его здесь использовать. Можете пожалуйста пояснить?
> Хотя есть плюс, сделано симпатично, но функционал урезан
Спасибо за комплимент интерфейсу.
По функционалу вопрос потребностей, если честно. Из того, что на мой взгляд критично не хватает, это авторизация. Но опять же в моем случае не так много пользователей и всем им я доверяю.
Честно говоря, прежде чем делать, посмотрел какие уже есть инструменты, но:
1. Плохо знал по каким названиям эти инструменты искать
2. Особо не старался, т.к. было желание опробовать свои силы и сделать именно то, что виделось.
А в моих скриптах таковой присутствует.
Ну и честно говоря CI не рассматривал из-за их тяжеловесности. Т.е. для простой задачи слишком много действий потребуется в данном случае