Возможно, я не точно задал вопрос. Интересно было тестируют боты эксплойты или нет. Понятно, что сервер должен проверять, понятно, что есть юнит-тестирование, однако MMO — достаточно сложный механизм. Баги вполне могут быть.
А что произойдет если злоумышленник поковыряется в вашем протоколе и начнет мечом рубить монстров на другом конце карты? Ну или по крайней мере, я могу «открыть» себе всю карту. Вы как-то боритесь с этим / тестируете такое поведение или подобные выкрутасы запрещены соглашением и преследуются по понятиям закону?
В Европе больше соц. гарантий: уволить сотрудника из штата затруднительно, особенно в ряде стран ЕС. При увольнении выплачивается солидная сумма. В Бельгии существует определенная точка невозврата, когда независимо от эффективности, дешевле держать работника до пенсии, чем увольнять. В Штатах ты можешь придти на работу и узнать, что тебя уволили по скручиваемой с твоего кабинета табличке. Там другая деловая этика.
Что-ж, здорово, что есть позитивный пример такого сетапа. Мне больше нравится подход, когда команда комитит в свой бренч, дальше тимлид/другое ответственное за ревью лицо ревьюирует код только потом идет мерж.
Со временем стал приходить к мысли, что никакие технические ограничения не смогут сделать команду лучше. Если разработчики заливают битый код и уходят домой, то это должно решаться не техническими средствами, а увольнением таких «специалистов».
А можете поделиться, на каком стеке вы работаете, сколько проектов в солюшне, сколько тестов, сколько агентов, сколько разработчиков, одна ветка разработки или бренч на фичу/команду?
Идете в TeamCity или в другое CI-решение, которое используете. Находите билд, соответствующий вашей сборке. Для того, чтобы иметь какое-то соответствие, TeamCity предлагает BuildNumberFormat. Вы можете настроить его в соответствие с версионированием вашего приложения.
Здорово, что разворачивается дискуссия в комментах.
Про публикацию служб. Для доставки бинарников на сервер подходит тот же MSDeploy. Если в проекте уже используется MSDeploy для публикации web-приложений, то одной командой sync в MSDeploy можно скопировать все бинарники сервиса на целевой сервер. Шаред-папка и FTP это уже не модно :)
На целевой машине может не быть IIS
— Параметры в TeamCity. Учите людей плохому. Кучу аргументов через /P указывать в TeamCity не надо — работать будет, но будут warnings. Специально для этого есть Build Parameters, они прозрачно транслируются в MSBuild скрипт
Может у нас разные настройки TeamCity, я не видел ворнингов, хотя последние большие сборки у меня публиковались с помощью кастомного мсбилда, в который передается только конфигурация и никаких параметров нет.
Я больше склоняюсь к использованию PowerShell и конкретно psake. Это императивные скрипты, а не декларативный XML как в MSBuild, их не надо компилировать, можно легко править и можно отдать поддержку этих скриптов админам (от них сейчас знание PowerShell стали требовать).
Никто же не мешает использовать и то и другое или что-то одно по вкусу. Главное, чтобы работало и было просто поддерживать. например, поэтому я чаще всего не пишу отдельные таски, чтобы не тащить за собой бинарники.
Достаточно много разработчиков, к сожалению, никогда не заглядывает в файл проекта. Я думаю, что важно научиться пользоваться msbuild и редактировать проект не только из студии, но и «ручками», потому что многих вещей из студии просто не сделать.
Да, я тоже против создания лишних веток. Где-то на хабре была статья, объясняющая почему Github не использует git workflow: как раз из-за оверхеда с бренчами. Принудительное создание веток хорошо работает, когда разграничены права на публикацию разных окружений или когда разработчиков очень много.
Да все правильно. TDD не позволяет тащить сильные зависимости, это в больших системах и является проблемой. Если же мозгов вообще нет, то тут ни TDD ни DI не помогут.
О безопасности и приватности своей информации каждый должен заботиться сам. В жизни, в интернете — без разницы.
Хочется добавить, что Гугл — коммерческая организация. Деятельность коммерческой организации направлена на (о боже, нет) зарабатывание денег. Гугл не принуждает вас пользоваться поиском, почтой и другими услугами, кстати, бесплатно. Если вас не устраивает пользовательское соглашение Гугла, используйте Яндекс, Мейл, Бинг или напишите свой поисковик, свой почтовый сервер, разверните на VPS в далекой банановой республике и пользуйтесь этим только через TOR. Какие проблемы то?
Проблема не в памяти. Проблемы следующие:
1) Вызовы статических методов намертво привязывают вас к реализации. В каноническом GetInstance нет возможности сконструировать другой тип, вы тащите за собой синглтон и все его зависимости
2) Тестируемость приложения. Не дай бог синглтон завязан на внешние зависимости (конексты, сервисы, бд). Все, что использует такой контекст становится не тестируемым
3) Нарушение области видимости: все имеют доступ к синглтону, что заставляет вас делать инстанс immutable
Лучшее решение — отделить логику создания от контракта. Для этого нужно использовать IOC-контейнер и внедрение зависимостей. Вы получите тот-же результат, но в качестве обычного не-статического поля вашего класса.
Все бы хорошо, только вот заставить всех писать такую разметку очень сложно.
Можно пойти с другой стороны и парсить label'ы и placeholder'ы. А дальше по набору эвристик определять тип поля. Дополнительно можно попробовать парсить .error, .validate — поля. Взять наиболее популярные фреймворки, посмотреть, какого вида валидацию они используют и при неправильном вводе смотреть, что вернула валидация. Вот тут масса простора для самообучения робота, хотя и возникает необходимость работы с естественными языкам.
понятиямзакону?Со временем стал приходить к мысли, что никакие технические ограничения не смогут сделать команду лучше. Если разработчики заливают битый код и уходят домой, то это должно решаться не техническими средствами, а увольнением таких «специалистов».
На целевой машине может не быть IIS
Может у нас разные настройки TeamCity, я не видел ворнингов, хотя последние большие сборки у меня публиковались с помощью кастомного мсбилда, в который передается только конфигурация и никаких параметров нет.
Никто же не мешает использовать и то и другое или что-то одно по вкусу. Главное, чтобы работало и было просто поддерживать. например, поэтому я чаще всего не пишу отдельные таски, чтобы не тащить за собой бинарники.
Достаточно много разработчиков, к сожалению, никогда не заглядывает в файл проекта. Я думаю, что важно научиться пользоваться msbuild и редактировать проект не только из студии, но и «ручками», потому что многих вещей из студии просто не сделать.
Хочется добавить, что Гугл — коммерческая организация. Деятельность коммерческой организации направлена на (о боже, нет) зарабатывание денег. Гугл не принуждает вас пользоваться поиском, почтой и другими услугами, кстати, бесплатно. Если вас не устраивает пользовательское соглашение Гугла, используйте Яндекс, Мейл, Бинг или напишите свой поисковик, свой почтовый сервер, разверните на VPS в далекой банановой республике и пользуйтесь этим только через TOR. Какие проблемы то?
Ready to work, extensible
and developer friendly build server — out of the box.
Не достаточно? Все там нормально написано, просто по каким-то не понятным для меня причинам слово билд-сервер знают еще не все разработчики.
1) Вызовы статических методов намертво привязывают вас к реализации. В каноническом GetInstance нет возможности сконструировать другой тип, вы тащите за собой синглтон и все его зависимости
2) Тестируемость приложения. Не дай бог синглтон завязан на внешние зависимости (конексты, сервисы, бд). Все, что использует такой контекст становится не тестируемым
3) Нарушение области видимости: все имеют доступ к синглтону, что заставляет вас делать инстанс immutable
Лучшее решение — отделить логику создания от контракта. Для этого нужно использовать IOC-контейнер и внедрение зависимостей. Вы получите тот-же результат, но в качестве обычного не-статического поля вашего класса.
Можно пойти с другой стороны и парсить label'ы и placeholder'ы. А дальше по набору эвристик определять тип поля. Дополнительно можно попробовать парсить .error, .validate — поля. Взять наиболее популярные фреймворки, посмотреть, какого вида валидацию они используют и при неправильном вводе смотреть, что вернула валидация. Вот тут масса простора для самообучения робота, хотя и возникает необходимость работы с естественными языкам.