> Одним из главных отличий и преимуществ игры является уникальный игровой мир, в котором объединены достижения высоких технологий и привычные всем элементы фэнтези.
Иными словами, более серьёзных отличий от существующих продуктов нет?
К слову, смесь фэнтези и технологий уже давно не является уникальным явлением в геймдеве.
Буду рад увидеть здесь комментарий человека, который не понимает что написано в этих строках (и знает английский):
> result = self.client.get('/products/123/')
> self.assert('title' in result.body)
Человек, который работал в Excel, писал макросы для Word, настраивал что-нибудь в Jira, или ещё чего-нибудь похожее делал хоть раз в своей жизни, поймёт что тут написано. Это не говоря уже о том, что не ясно зачем ПМ-у вообще лезть в эти тесты.
Если же по какой-то неимоверной случайности этот ПМ вообще не сталкивался с программированием, то вот хороший повод узнать таки, чем он управляет.
>«Новый ЯП» это некоторый полу-формальный формат записи спецификаций, не более.
И тем не менее ему надо учить всех людей, которые будут с ним взаимодействовать и большинство из которых точно может обойтись без него. Зачем тогда его вводить? Этот полу-формальный формат — отличный пример лишней сущности.
>Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.
Простой тест и есть спецификация, причём максимально конкретная. Более того, простой тест более гибок, чем правила на специфичном для проекта ЯП, описывающем только часть (причём меньшую) предметной области.
Даже писать простые тесты с подробными комментариями на нормальном языке проще, чем поддерживать отдельный ЯП для описания этих тестов на «почти» нормальном языке.
Глобальная цель у тестирования одна — убедиться что поведение проекта соответствует спецификации (как бы она ни была выражена).
Использование BDD предполагает:
1. Введение в проект нового ЯП со своим синтаксисом и семантикой (а значит обучение им всех специалистов, работающих с тестами).
2. Дублирование части функционала, для возможности его использования в BDD.
3. Поддержка дублированного функционала (как только будет надо сделать какое-то новое действие, его надо замапить в правила).
Человек, который пишет тесты (а значит явно описывает требования спецификации ПО), должен быть в состоянии писать простейшие алгоритмы. Если он не может этого делать, то его нельзя допускать до этой работы. А если он может писать алгоритмы, то разницы между:
— user.create(name='test_name')
— «create user with name 'test_name'»
никакой нет, за тем исключением, что программистам будет проще разобрать 1-ый вариант, так как они его по 20 раз на дню видят.
Наворачивание ещё одного уровня абстракции (которым является BDD) над тестами увеличит сложность поддержки тестов.
Я ни в коем случае не говорил, что сами тесты — плохо, тесты — это хорошо, но только до тех пор, пока над ними не начинают ставить странные опыты.
Еретический метод — внесение абсолютно лишнего уровня абстракции.
Полностью «классические» тесты заменить на него не получится, а значит его использование в проекте только увеличит сложность поддержки (через добавление лишних сущностей и связей), не принося существенной пользы.
Доменная часть почты регистронезависима, но локальная может быть зависимой — в зависимости от конкретного почтового сервера. Т.е. xxx@mail.mail и XXX@mail.mail могут быть как одним адресом так и двумя.
В таких случаях (особенно, когда не хочется тратить время) я стараюсь не рассуждать о том как лучше, а делать по стандарту.
Вышлите пожалуйста вашу почту мне в личку или на support@the-tale.org
Посмотрю, в чём дело.
Восстановление пароля требует точного совпадения почты (включая, заглавные буквы), возможно в этом проблема.
Задача на более «умное» сравнение есть, но до неё пока руки не дошли.
Правда расчёт был на 1 год, потом просто втянулся.
О монетизации конечно думал (куда ж без этого), но образцом была скорее разработка за донат (примерно так живёт Dwarf Fortress). Поэтому в игре в основном ставка на подписку идёт. Править механику в пользу монетизации не хочется.
Ну и разработка игрушки была не единственной целью. Хотел поэкспериментировать с кодом, с генерацией всего чего можно и т.п. Так что эту авантюру можно обозвать творчески отпуском.
Для любопытных есть видео изменений карты мира за 5 месяцев.
В статью не вставлял, так как не сильно эффектное (отображает все состояния карты на конец каждого часа с сентября по январь).
Было бы неплохо, если бы появился профсоюз и занялся хотя бы этим, а заодно следил за различными договорённостями о «не переманивании сотрудников».
Что ж они там 5 лет делали-то… вибраторы по карманам распихивали?
В чём сложность, поясните.
Иными словами, более серьёзных отличий от существующих продуктов нет?
К слову, смесь фэнтези и технологий уже давно не является уникальным явлением в геймдеве.
> result = self.client.get('/products/123/')
> self.assert('title' in result.body)
Человек, который работал в Excel, писал макросы для Word, настраивал что-нибудь в Jira, или ещё чего-нибудь похожее делал хоть раз в своей жизни, поймёт что тут написано. Это не говоря уже о том, что не ясно зачем ПМ-у вообще лезть в эти тесты.
Если же по какой-то неимоверной случайности этот ПМ вообще не сталкивался с программированием, то вот хороший повод узнать таки, чем он управляет.
И тем не менее ему надо учить всех людей, которые будут с ним взаимодействовать и большинство из которых точно может обойтись без него. Зачем тогда его вводить? Этот полу-формальный формат — отличный пример лишней сущности.
>Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.
Простой тест и есть спецификация, причём максимально конкретная. Более того, простой тест более гибок, чем правила на специфичном для проекта ЯП, описывающем только часть (причём меньшую) предметной области.
Даже писать простые тесты с подробными комментариями на нормальном языке проще, чем поддерживать отдельный ЯП для описания этих тестов на «почти» нормальном языке.
Вообще, кто этот мифический «человек со стороны»?
Использование BDD предполагает:
1. Введение в проект нового ЯП со своим синтаксисом и семантикой (а значит обучение им всех специалистов, работающих с тестами).
2. Дублирование части функционала, для возможности его использования в BDD.
3. Поддержка дублированного функционала (как только будет надо сделать какое-то новое действие, его надо замапить в правила).
Человек, который пишет тесты (а значит явно описывает требования спецификации ПО), должен быть в состоянии писать простейшие алгоритмы. Если он не может этого делать, то его нельзя допускать до этой работы. А если он может писать алгоритмы, то разницы между:
— user.create(name='test_name')
— «create user with name 'test_name'»
никакой нет, за тем исключением, что программистам будет проще разобрать 1-ый вариант, так как они его по 20 раз на дню видят.
Я ни в коем случае не говорил, что сами тесты — плохо, тесты — это хорошо, но только до тех пор, пока над ними не начинают ставить странные опыты.
Полностью «классические» тесты заменить на него не получится, а значит его использование в проекте только увеличит сложность поддержки (через добавление лишних сущностей и связей), не принося существенной пользы.
Для своего проекта ищу что-то похожее, пока не нашёл.
Писался для моего проекта, поэтому умеет не много «национальностей», зато может делать имена на кирилице с полным набором склонений.
В таких случаях (особенно, когда не хочется тратить время) я стараюсь не рассуждать о том как лучше, а делать по стандарту.
А на конкретные вопросы могу и в комментариях ответить.
Посмотрю, в чём дело.
Восстановление пароля требует точного совпадения почты (включая, заглавные буквы), возможно в этом проблема.
Задача на более «умное» сравнение есть, но до неё пока руки не дошли.
Была ошибка в конфигурации CDN, статика раздавалась с сервака :-( Сейчас поправил, может полегче станет.
Очень не люблю покупать ненужные вещи, вроде новых телефонов и прочего.
Правда расчёт был на 1 год, потом просто втянулся.
О монетизации конечно думал (куда ж без этого), но образцом была скорее разработка за донат (примерно так живёт Dwarf Fortress). Поэтому в игре в основном ставка на подписку идёт. Править механику в пользу монетизации не хочется.
Ну и разработка игрушки была не единственной целью. Хотел поэкспериментировать с кодом, с генерацией всего чего можно и т.п. Так что эту авантюру можно обозвать творчески отпуском.
В статью не вставлял, так как не сильно эффектное (отображает все состояния карты на конец каждого часа с сентября по январь).