String example = "<....>";
Validator v = new Validator(example);
v.useXMLSchema(true);
v.setJAXP12SchemaSource(new File("xml/example.xsd"));
assertTrue(v.toString(), v.isValid());
Если говорить строго о валидности XML.
XMLUnit умеет проверять DTD при помощи класса Validator
Долго колебался, включать ли пример его использования в статью или нет. Потом подумал, что это совсем отдельная тема, которую парой примеров не раскрыть.
К тому же, в моих проектах XML-данные не ограниченны DTD.
Поэтому для себя решил, что про это как-нибудь в следующий раз, в другой статье.
Можно. см. 3-й ответ в 4-ой ссылке из списка литературы статьи.
1. Мне такой вариант тоже показался излишне громоздким.
2. Реализуя такой вариант мы фактически пишем свой XmlUnit. Это изобретение велосипеда, чего не хотелось бы.
3. Что такого страшного в ещё одной зависимости maven? Я же не в ручную её качаю и ставлю при каждой сборке…
фактически мои тесты в проекте свелись к
Diff diff = new Diff(..);
assertTrue("XML результат не совпал", diff.similar());
Зачетный комментарий. По делу парень говорит.
Не понятно за что его минуснули.
Добавлю ещё пару строк от себя:
тесты — это лакмусовая бумажка гибкой и правильной архитектуры приложения. Если ты не можешь свой код протестировать, значит у тебя плохо продумана структура классов и интерфейсов и есть нужна рефакторить, пока не поздно.
Даже есть такой прием, пишешь код и продумываешь, как бы ты его протестировал, при этом сам тест уже не пишешь, но твой код лучше. Хотя ИХМО 100% покрытие логики очень спасает в сложных ситуациях.
Если вы все-таки натянули тест на свой код, и он у вас при каждом изменении ломается, то это тоже сигнал про то, что у вас в коде не всё в порядке. Это так называемые хрупкие тесты. Они написаны с учетом костылей, причем каждый новый костыль ломает предыдущие.
У меня был проект, где все тесты были написаны таким образом, чинить их — тихий ужас, 2 месяца мы продержались, а потом забили на них, и начали переписывать их с нуля на новый функционал, а старый просто не трогали, чтобы не сломать.
В итоге, я осознал простую истину, код без тестов ничего не стоит, потому что ты не можешь в любой момент проверить, работает ли он или нет, а значит будешь опасаться рефакторинга. Писать без рефакторинга старого функционала — самоубийство и изобретение всё новых и новых костылей…
Помогать сообществу, это естественно. Мы же сделали эту работу, как правильно говорили выше, не пропадать же добру.
Мы используем open source продукты, и только мы можем сделать их лучше.
Предлагаю не останавливаться только на баг-репортах, мы знаем некоторую open source систему.
мы много чего знаем о том, как должно строиться приложение.
что нам мешает предлагать(добавлять) новый функционал, новые идеи, если они реально нужны?
А если есть время, то можно и самому по участвовать.
PS: хорошая идея в нужное время тоже дорого стоит. За нее тоже скажут спасибо.
Спасибо за статью, она будет полезна каждому абитуриенту.
добавлю от себя несколько советов по выбору кафедры:
кроме того, чтобы читать программу специальности, узнайте как она реализуется. Кафедра может добавлять до 30% региональных предметов. Будет замечательно, если они будут все технические.
Каждый преподаватель тоже может к общей программе добавлять до 20% своего. Реально, никто не следит что он там добавляет или убавляет. Хорошо бы узнать, что читали, как читали, каков итог. Желательно поискать выпускников(студентов) исследуемой кафедры среди знакомых.
на практике бывает так, что если кафедра молодая(не прошло хотя бы одного полного круга выпускников), то некоторые дисциплины читать некому, некоторые читаются не так глубоко и часто людьми, которые в это ничего не смыслят.
По мере взросления кафедры идет обкатка учебного процесса. Находятся нужные люди, преподаватели въезжают в тему предмета и в то, как лучше его преподавать студентам и т.д.
Смотрите, чтобы на кафедре было 4-5 выпусков. Тогда учебный процесс обкатается 4-5 раз и получается уже что-то похожее на обучение.
Никогда не поступайте на специальности, которые вновь открываемые, т.е. где идет первый набор. Скорее всего все 5 лет вы там будете страдать фигней, а учить вас будет некому.
Узнайте какая кафедра популярна у работодателей. В моем городе заранее известно, какие кафедры «круты», а какие по хуже, т.к. сказать у каждой кафедры своя слава, нужно только добраться до круга людей, которые владеют этой информацией. Это лучший критерий оценки качества знаний, т.к. позволяет посмотреть, как знания полученные в процессе обучения помогли.
Наш тестер нашел баг, в ff5 не работает Notice with Callbacks.
Он думает, что это реклама, и предлагает забанить. Причем постоянно…
в хроме та же история на этот же пример.
И после каждой задачи, особенно если начальный этап, время давать привести в порядок.
Если же все время гнать и не давать рефакторить — к хуям такое управление проектом, которое приведет потом к тому, что нужно будет с нуля все переделывать.
спасибо за подсказку. переделал свой скрипт на использование festival
простые слова он говорит шикарно
например: echo "8 часов" | festival --tts --language russian
echo "18 часов" | festival --tts --language russian
Эту фразу говорит так, что со стороны не поймешь человек ли сказал или компьютер.
Вот такой вариант тоже вполне сносен: echo 'москооовское время 8 часов' | festival --tts --language russian
У меня стоит EDITOR=mcedit
Для локальной работы вполне хватает. Но я стараюсь не приучать себя к такому, т.к. 90% crontab-ов я изменяю на серверах.
Когда заходишь на сервер и открываешь crontab, то каждый раз открывается что-нибудь новое. Этакая рулетка. Каждый разработчик считает своим долгом поставить в переменную EDITOR свой любимый редактор. Поэтому считаю наиболее приемлемым для себя сценарий вида:
crontab -l > ctfile
cp ctfile file.backup
mcedit ctfile # аккуратно редактирую, подписываю коммент, что и зачем и когда менял, сохраняю
crontab ctfile
по мотивам этого сценария родился и скрипт, указанный в статье.
Главное в нем — это бекап того, что было, и контроль того, что есть.
Отписался выше.
Если есть необходимость, то на соответствие схеме XSD тоже можно проверять.
Например, так:
XMLUnit умеет проверять DTD при помощи класса Validator
Долго колебался, включать ли пример его использования в статью или нет. Потом подумал, что это совсем отдельная тема, которую парой примеров не раскрыть.
К тому же, в моих проектах XML-данные не ограниченны DTD.
Поэтому для себя решил, что про это как-нибудь в следующий раз, в другой статье.
1. Мне такой вариант тоже показался излишне громоздким.
2. Реализуя такой вариант мы фактически пишем свой XmlUnit. Это изобретение велосипеда, чего не хотелось бы.
3. Что такого страшного в ещё одной зависимости maven? Я же не в ручную её качаю и ставлю при каждой сборке…
фактически мои тесты в проекте свелись к
По-моему достаточно быстро и компактно.
Не понятно за что его минуснули.
Добавлю ещё пару строк от себя:
тесты — это лакмусовая бумажка гибкой и правильной архитектуры приложения. Если ты не можешь свой код протестировать, значит у тебя плохо продумана структура классов и интерфейсов и есть нужна рефакторить, пока не поздно.
Даже есть такой прием, пишешь код и продумываешь, как бы ты его протестировал, при этом сам тест уже не пишешь, но твой код лучше. Хотя ИХМО 100% покрытие логики очень спасает в сложных ситуациях.
Если вы все-таки натянули тест на свой код, и он у вас при каждом изменении ломается, то это тоже сигнал про то, что у вас в коде не всё в порядке. Это так называемые хрупкие тесты. Они написаны с учетом костылей, причем каждый новый костыль ломает предыдущие.
У меня был проект, где все тесты были написаны таким образом, чинить их — тихий ужас, 2 месяца мы продержались, а потом забили на них, и начали переписывать их с нуля на новый функционал, а старый просто не трогали, чтобы не сломать.
В итоге, я осознал простую истину, код без тестов ничего не стоит, потому что ты не можешь в любой момент проверить, работает ли он или нет, а значит будешь опасаться рефакторинга. Писать без рефакторинга старого функционала — самоубийство и изобретение всё новых и новых костылей…
Красивое решение.
Для себя я делал подобную автоматизацию. Как писалось в статье, путем скрипта.
Решение с DNS ну очень порадовало.
Автору спасибо.
Для меня статья была полезна. Большое спасибо автору. Пиши ещё.
Мы используем open source продукты, и только мы можем сделать их лучше.
Предлагаю не останавливаться только на баг-репортах, мы знаем некоторую open source систему.
мы много чего знаем о том, как должно строиться приложение.
что нам мешает предлагать(добавлять) новый функционал, новые идеи, если они реально нужны?
А если есть время, то можно и самому по участвовать.
PS: хорошая идея в нужное время тоже дорого стоит. За нее тоже скажут спасибо.
добавлю от себя несколько советов по выбору кафедры:
кроме того, чтобы читать программу специальности, узнайте как она реализуется. Кафедра может добавлять до 30% региональных предметов. Будет замечательно, если они будут все технические.
Каждый преподаватель тоже может к общей программе добавлять до 20% своего. Реально, никто не следит что он там добавляет или убавляет. Хорошо бы узнать, что читали, как читали, каков итог. Желательно поискать выпускников(студентов) исследуемой кафедры среди знакомых.
на практике бывает так, что если кафедра молодая(не прошло хотя бы одного полного круга выпускников), то некоторые дисциплины читать некому, некоторые читаются не так глубоко и часто людьми, которые в это ничего не смыслят.
По мере взросления кафедры идет обкатка учебного процесса. Находятся нужные люди, преподаватели въезжают в тему предмета и в то, как лучше его преподавать студентам и т.д.
Смотрите, чтобы на кафедре было 4-5 выпусков. Тогда учебный процесс обкатается 4-5 раз и получается уже что-то похожее на обучение.
Никогда не поступайте на специальности, которые вновь открываемые, т.е. где идет первый набор. Скорее всего все 5 лет вы там будете страдать фигней, а учить вас будет некому.
Узнайте какая кафедра популярна у работодателей. В моем городе заранее известно, какие кафедры «круты», а какие по хуже, т.к. сказать у каждой кафедры своя слава, нужно только добраться до круга людей, которые владеют этой информацией. Это лучший критерий оценки качества знаний, т.к. позволяет посмотреть, как знания полученные в процессе обучения помогли.
Наш тестер нашел баг, в ff5 не работает Notice with Callbacks.
Он думает, что это реклама, и предлагает забанить. Причем постоянно…
в хроме та же история на этот же пример.
другой функционал нормально работает.
задело за живое. спасибо большое.
Этот тоже ничего, симпатичный, вроде все что нужно — умеет.
Так что все-равно спасибо.
Это же просто тайм-трекер. А мне уведомления нужны были.
Так что извините, это — не то.
простые слова он говорит шикарно
например:
echo "8 часов" | festival --tts --language russianecho "18 часов" | festival --tts --language russian
Эту фразу говорит так, что со стороны не поймешь человек ли сказал или компьютер.
Вот такой вариант тоже вполне сносен:
echo 'москооовское время 8 часов' | festival --tts --language russianДля локальной работы вполне хватает. Но я стараюсь не приучать себя к такому, т.к. 90% crontab-ов я изменяю на серверах.
Когда заходишь на сервер и открываешь crontab, то каждый раз открывается что-нибудь новое. Этакая рулетка. Каждый разработчик считает своим долгом поставить в переменную EDITOR свой любимый редактор. Поэтому считаю наиболее приемлемым для себя сценарий вида:
по мотивам этого сценария родился и скрипт, указанный в статье.
Главное в нем — это бекап того, что было, и контроль того, что есть.