Да нет, я знаю как сделать установщик. Батник я сделал потому что:
1) Так было проще
2) Хотел показать(может кто не знает), как пользоваться sc.
А вопрос был про то, как мне уже существующие сервисы, как админу, удалить с компа.
Потому что незачем, если коротко. Установить сервис — задача того, кто его поставляет.
Ну во-первых раз у меня возник этот вопрос, значит case есть. Во-вторых, если «задача того, кто его поставляет», чего же тогда в sc у меня есть возможность снести или добавить любой сервис, который мне не нравится? По сути я говорю об отсутствии UI к команде sc(вернее к тому API, который она дергает).
В .net есть специальный компонент для этого, который автоматически создается в проекте при создании проекта сервиса
Вы не правильно поняли вопрос. Я спрашиваю почему в консоли services.msc я не могу создать или удалить сервис, хотя могу сделать это через командную строку.
Плюс сервиса в автозагрузке и подъеме системой в случае падения. Ну и к сессии пользователя они не привязаны. Я конечно еще тот знаток никсов, но мне казалось, что если проводить аналогию, это должен быть демон, прописанный в /etc/rc.local и кроновская таска, которая будем за ним следить, поднимая когда он упадет, разве нет? Ну и с точке зрения использования, мне было бы удобнее прописать пути в одном конфиге, чем запускать скрипт из нескольких папок.
Опять же, возможно я не прав, но разве эта команда — unp * — не будет каждый раз, когда мы скачаем новый архив, перераспаковывать заново все уже существующие архивы в папке?
Ну я об этом и написал «Ну или отказаться от автораспаковки вложенных архивов.». Но опять же, в нормальной работе(где мы не скачиваем рекурсивные архивы), это может считаться недостатком.
После распаковки в альтернативный поток добавлять метку о том что файл распакован автоматом и больше не распаковывать
Хм. Так я же и написал про «запрещать повторную распаковку». Это может быть плохой вариант — например, я скачал архив, он распаковался, все хорошо. Прошло полгода, я обо всем забыл, заново качаю архив, но в другую папку(которая тоже мониторится). У меня ничего не распаковалось — я пишу разработчику багу. Можно, конечно, ограничить время жизнь хранения хэша архива — например один час. Но все равно, потенциально проблема есть.
Боюсь, что защиты нет. Я думал над этим — можно считать хэш-архива и запрещать повторную распаковку, но в некоторых случаях это будет багом для пользователя. Еще можно проанализировать структуру архива на предмет наличия таких бомб, но это уже совсем другой уровень сложности, может позже, когда будет время и желание покопаться в разных форматах архивов. Ну или отказаться от автораспаковки вложенных архивов.
Надо еще сделать так, чтобы он удалял архив после распаковки.
Я думал над этим, но с другой стороны кому-то может понадобиться сохранить архив. Например я скачал архив с исходниками, поковырялся с ними и грохнул папку, а архив остался на всякий случай, если снова к ним вернусь. Думаю, может вынести это опцией, но по умолчанию лучше оставлять — удаление операция опасная ввиду нетранзакционности файловой системы на большинстве десктопов.
Там бы еще неплохо многопоточную обработку вотчера прикрутить, чтобы не подвисало в ожидании закачки, но пока пользователей(а пока пользователь только я=)) все и так устраивает.
Хороший вопрос. Я это предусмотрел — в обработчике FileSystemWatcher файл пытается открыться на чтение. Если он еще загружается — получаем эксепшен(виндовая ошибка ERROR_SHARING_VIOLATION). Прога уходить в слип на секунду, после чего пытается еще раз открыть ну и т.д. Если за установленое количество попыток ничего не получилось — оставляем архив в покое, пусть кто-нибудь другой разбирается. Для себя количество попыток я установил до дури(int.MaxValue), вы можете поставить другое значение.
Собственно код вы можете найти в функции WatcherHandler
IOUtils.WrapSharingViolations(() => { using (File.OpenRead(file));}, null, int.MaxValue, 1000);
И в утилитном класс IOUtils, там, правда, немного мутно из-за необходимости отличать ERROR_SHARING_VIOLATION в IOException от остальных ошибок доступа.
Извиняюсь, промахнулся с кнопкой. Еще раз с нормальным форматированием.
но если такая необходимость встанет, то только Coded UI Test.
Ну если со стоимостью проблем нет, то выбор действительно неплохой.
не нужно объяснять каждому разработчику, зачем писать полотенце тестов в дополнение к программе.
Не очень понял этот момент. А проблем с объяснением зачем писать модульные тесты не возникает?
вы рассмотрели простейший случай, а гуя могут быть достаточно сложным, да как правило так оно и есть
Ну простой пример был выбран для удобства демонстрации тестов. В реальной жизни я занимался автоматизацией тестирования UI достаточно сложной системы(что-то типа CADa) и могу сказать, что главное проблемы начинается на тестировании граничных условий. Например вам нужно проверить попап, который возникает при отсутствии свободного места на диске. Как вы будет делать на это автоматический тест силами только Code UI?
это действительно не надо писать. Экономим время.
Безусловно, поэтому я и отметил рекорде как плюс.
каждый программист делает 1 ошибку в 10 строках кода и это нормально.
Вообще вы как-то утрировали. Ошибки часто делают при описании логики. Делать уровня выполнения при написании 10 ассертов — ну это надо быть талантом. А от опечаток и прочего хорошо защищает статический анализ того же решашрпера. Вообще же речь шла о командах, которые уже используют TDD, пишут регрешен тесты и т.д. Для такие команд написание еще и тестов для UI не стане шоустопером.
при вариации тестов — переписывание заново.
Ну изменение продакшен кода конечно может привести к необходимости поменять тесты. Но это абсолютно логично для всего автоматического регрешен тестирования вообще. И code ui вас тут не спасет — я удалил часть кнопок, поменять часть контролов, значит надо перезаписать тесты.
Если нужно потратить день, чтобы написать тест к окну, то лучше оттестировать вручную
Нет не лучше, т.к. потом после каждой итерации надо будет снова потратить день на ручное тестирования этого окна. Не знаю какой опыт у вас, а я не однократно встречался с ситуацией, когда на одной итерации ломали функционал, сделанный на предыдущих.
тыкают куда не попадя и пишут что не попадя, так что есть шанс отловить ошибку ввода данных
Автоматизированное тестирование не противопоставляется ручному, а дополняет его. Чтобы те же тестеры не проходили одни и теже тесткейсы по 100 раз.
но если такая необходимость встанет, то только Coded UI Test.
Ну если со стоимостью проблем нет, то выбор действительно неплохой.
не нужно объяснять каждому разработчику, зачем писать полотенце тестов в дополнение к программе.
Не очень понял этот момент. А проблем с объяснением зачем писать модульные тесты не возникает?
вы рассмотрели простейший случай, а гуя могут быть достаточно сложным, да как правило так оно и есть
Ну простой пример был выбран для удобства демонстрации тестов. В реальной жизни я занимался автоматизацией тестирования UI достаточно сложной системы(что-то типа CADa) и могу сказать, что главное проблемы начинается на тестировании граничных условий. Например вам нужно проверить попап, который возникает при отсутствии свободного места на диске. Как вы будет делать на это автоматический тест силами только Code UI?
это действительно не надо писать. Экономим время.
Безусловно, поэтому я и отметил рекорде как плюс.
каждый программист делает 1 ошибку в 10 строках кода и это нормально.
Вообще вы как-то утрировали. Ошибки часто делают при описании логики. Делать уровня выполнения при написании 10 ассертов — ну это надо быть талантом. А от опечаток и прочего хорошо защищает статический анализ того же решашрпера. Вообще же речь шла о командах, которые уже используют TDD, пишут регрешен тесты и т.д. Для такие команд написание еще и тестов для UI не стане шоустопером.
при вариации тестов — переписывание заново.
Ну изменение продакшен кода конечно может привести к необходимости поменять тесты. Но это абсолютно логично для все автоматического регрешен тестирования вообще. И code ui вас тут не спасет — я удалил часть кнопок, поменять часть контролов, значит надо перезаписать тесты.
Если нужно потратить день, чтобы написать тест к окну, то лучше оттестировать вручную
Нет не лучше, т.к. потом после каждой итерации надо будет снова потратить день на ручное тестирования этого окна. Не знаю какой опыт у вас, а я не однократно встречался с ситуацией, когда на одной итерации ломали функционал, сделанный на предыдущих.
тыкают куда не попадя и пишут что не попадя, так что есть шанс отловить ошибку ввода данных
Автоматизированное тестирование не противопоставляется ручному, а дополняет его. Чтобы те же тестеры не проходили одни и теже тесткейсы по 100 раз.
На самом деле да, несмотря на неудачный пример(правильней сравнить, например, разбор списка). Ибо в первом варианте вы просто описывает поток выполнения с операторами перехода. Неймон в полный рост. А во втором случает вы по сути задаете набор «предикат — значение функции». По сути описываете какая ваша функция.
Ну так про идею алгоритма я ничего и не говорил. Речь идет об отсутствии управляющих конструкций типа if в шаблоном коде статье, т.е. об элементах декларативности. Впрочем, не сомневаюсь, что и пример на Scheme можно переписать соответствующим образом.
1) Так было проще
2) Хотел показать(может кто не знает), как пользоваться sc.
А вопрос был про то, как мне уже существующие сервисы, как админу, удалить с компа.
Ну во-первых раз у меня возник этот вопрос, значит case есть. Во-вторых, если «задача того, кто его поставляет», чего же тогда в sc у меня есть возможность снести или добавить любой сервис, который мне не нравится? По сути я говорю об отсутствии UI к команде sc(вернее к тому API, который она дергает).
Вы не правильно поняли вопрос. Я спрашиваю почему в консоли services.msc я не могу создать или удалить сервис, хотя могу сделать это через командную строку.
Опять же, возможно я не прав, но разве эта команда — unp * — не будет каждый раз, когда мы скачаем новый архив, перераспаковывать заново все уже существующие архивы в папке?
Ну я об этом и написал «Ну или отказаться от автораспаковки вложенных архивов.». Но опять же, в нормальной работе(где мы не скачиваем рекурсивные архивы), это может считаться недостатком.
Хм. Так я же и написал про «запрещать повторную распаковку». Это может быть плохой вариант — например, я скачал архив, он распаковался, все хорошо. Прошло полгода, я обо всем забыл, заново качаю архив, но в другую папку(которая тоже мониторится). У меня ничего не распаковалось — я пишу разработчику багу. Можно, конечно, ограничить время жизнь хранения хэша архива — например один час. Но все равно, потенциально проблема есть.
Я думал над этим, но с другой стороны кому-то может понадобиться сохранить архив. Например я скачал архив с исходниками, поковырялся с ними и грохнул папку, а архив остался на всякий случай, если снова к ним вернусь. Думаю, может вынести это опцией, но по умолчанию лучше оставлять — удаление операция опасная ввиду нетранзакционности файловой системы на большинстве десктопов.
Ну если в архиве лежит папка, то будет в результате папка с подпапкой — имя_архива/имя_подпапки. Так же, как если через контекстное меню распаковать.
Собственно код вы можете найти в функции WatcherHandler
И в утилитном класс IOUtils, там, правда, немного мутно из-за необходимости отличать ERROR_SHARING_VIOLATION в IOException от остальных ошибок доступа.
Ну если со стоимостью проблем нет, то выбор действительно неплохой.
Не очень понял этот момент. А проблем с объяснением зачем писать модульные тесты не возникает?
Ну простой пример был выбран для удобства демонстрации тестов. В реальной жизни я занимался автоматизацией тестирования UI достаточно сложной системы(что-то типа CADa) и могу сказать, что главное проблемы начинается на тестировании граничных условий. Например вам нужно проверить попап, который возникает при отсутствии свободного места на диске. Как вы будет делать на это автоматический тест силами только Code UI?
Безусловно, поэтому я и отметил рекорде как плюс.
Вообще вы как-то утрировали. Ошибки часто делают при описании логики. Делать уровня выполнения при написании 10 ассертов — ну это надо быть талантом. А от опечаток и прочего хорошо защищает статический анализ того же решашрпера. Вообще же речь шла о командах, которые уже используют TDD, пишут регрешен тесты и т.д. Для такие команд написание еще и тестов для UI не стане шоустопером.
Ну изменение продакшен кода конечно может привести к необходимости поменять тесты. Но это абсолютно логично для всего автоматического регрешен тестирования вообще. И code ui вас тут не спасет — я удалил часть кнопок, поменять часть контролов, значит надо перезаписать тесты.
Нет не лучше, т.к. потом после каждой итерации надо будет снова потратить день на ручное тестирования этого окна. Не знаю какой опыт у вас, а я не однократно встречался с ситуацией, когда на одной итерации ломали функционал, сделанный на предыдущих.
Автоматизированное тестирование не противопоставляется ручному, а дополняет его. Чтобы те же тестеры не проходили одни и теже тесткейсы по 100 раз.
Ну если со стоимостью проблем нет, то выбор действительно неплохой.
Можно шагнуть чуть дальше и писать что-то типа
declarative(1) = "one"
declarative(2) = "two"
declarative(_) = "many"
Вы отвечаете — «Тот факт, что нет явных if не делает код декларативным.»
Вам не кажется, что наши утверждения не вступают в противоречие и таким образом нет предмета спора?