Особенно весело, когда каждый разработчик генерирует 100500 изменений, потому что его стиль кодирования ему больше нравится. Т.е. вместо правки 1 строки трогает либо сам либо своим IDE весь файл, что конечно же не облегчит code review и будет загрязнять проект лишними данными
Здесь стоит помнить о том, что любые операции по модификации структуры БД в MySQL приводят к автокомиту транзакций. Так что и тесты необходимо будет проектировать соответственно.
Мое имхо — не стоит заливать/перезаливать всю базу данных из нескольких десятков таблиц перед каждым тестом. Возможно есть смысл не вносить ключи в дамп вообще, и в каждом тесте вливать не всю базу, а только ту таблицу, которая относится к тестируемой сущьности. В таком случае и тесты быстрее отработают и целосность вы тестировать не будете(т.к. задача проверки корректности работы ключей — это задача mysql команды).
Я бы запрограммировал отдельно «муравьиного бога» — он бы осуществлял контроль карты и координировал действия муравьёв в общем, и дал бы отдельным муравьям некую автономность (отклониться от курса за едой, скооперироваться с ближайшим союзником для битвы)
Вот мой прошлый профайл — ai-contest.com/profile.php?user_id=9430. Обошелся простым алгоритмом по позиционированию своих войск в правильных, как я думал, местах. Оказалось есть как минимум 156 более правильных…
Очень хотелось написать сразу же хоть простого, но совего бота. Подумав, решил выждать пару дней, все хорошо обдумать и только тогда начинать. При чем начинать похоже прийдется с переписывагия стратового пакета от разработчиков.
Как по мне, здесь достаточно 4 классов: Работник, Ребенок и две колекции для работы с двумя предыдущими классами. Список детей тут будет узнать проще простого: если ребенок есть в базе (он не сирота ведь) — значит родители работают на предприятии. Просто выбираем коллекцией детей всех детей до 14 лет, берем у них свойство родитель и даем родителю подарок для соответствующего пола. Т.е. плящем именно от ребенка. Конкретная реализация всего этого зависит от языка и фреймворка на котором вы будете это писать.
Меня слегка смутила пропажа левого меню при просмотре странички пользователя. Получается пользователю добавляете лишний клик, если он хочет после просмотра пользователя сразу же на расписание перейти.
Есть предложение уменьшить вложеность конструкций в методе Polling::listen, потому что читаемость кода страшно падает. Сделать это можно добавив дополнительную точку выхода к первому условию и поменяв на обарное второе, чтобы получилось нечто подобное:
if ($shmid) {
return $result;
}
while (time() < $endTime) {
if ($storage['_updated'] < $lastQueryTime) {
continue;
}
.......
break;
}
Если магазин хранит, обрабатывает или передает номера кредитных карточек — PCI-DSS сертификация обязательна.
На сколько я знаю, сам совет его просто рекомендует, а обязательным его могут сделать либо законы страны, где расположен продавец, либо сам процессинговый центр, с которым продавец так или иначе имеет дело. И даже в последнем случае иногда возможна работа без сертификации с определенным штрафами, либо объемами.
У шлюзов так и есть, но в магазине — это совсем необязательно. Кпримеру: вы используете PayPal Direct — значит вы должны забрать у пользователя кредитку и вручную передать ее на АПИ пейпала. Т.е. ваше приложение работает с кредитками и в некоторых странах должно подлежать сертификации. Вот именно тут поможет Payflow Link. Ваше приложение просто напросто не будет знать ничего о кредитках (т.е. его не нужно сертифицировать и платить за это деньги), но в тоже время поля для ввода платежной информации будут располагаться в вашем дизайне.
Кроме этих методов есть еще несколько из семейства Payflow Edition. Там имеются методы с поддержкой оплаты на своем сайте, но, в тоже время, с соблюдением PCI стандартов.
Кроме этого, держать директорию .git доступную через веб сервер тоже как то не хорошо.
На сколько я знаю, сам совет его просто рекомендует, а обязательным его могут сделать либо законы страны, где расположен продавец, либо сам процессинговый центр, с которым продавец так или иначе имеет дело. И даже в последнем случае иногда возможна работа без сертификации с определенным штрафами, либо объемами.