nepster-web

Идея дурацкая, если честно, но сделать можно:

create sequence shared_sequence;
create table production_data(id bigint default nextval('shared_sequence'), value text);
create table demo_data(id bigint default nextval('shared_sequence'), value text);

Примерно как-то так:

class MyCLass {
  static wait(t = 1000) {
    return new Promise(r => setTimeout(r, t))
  }
  
  constructor() {
    this._promise = Promise.resolve()
  }

  then(callback) {
    this._promise = this._promise.then(MyCLass.wait).then(callback)
    return this;
  }
}

Дело в том, что новые промисы создаются не «потом», а сразу, при добавлении очередной задачи. Так они не становятся в очередь друг за другом.

Можно добавить метод, который будет создавать новый промис только, когда его время придёт:

class Q {
  constructor() {
    this.promise = Promise.resolve();
  }

  makePromise(cb) {
    return new Promise(res => setTimeout(
      () => {
        cb();
        res();
      },
      1e3
    ));
  }

  enqueue(cb) {
    this.promise = this.promise
      .then(() => this.makePromise(cb));
    return this;
  }
}


const cell = new Q();
cell.enqueue(() => console.log(1));
cell.enqueue(() => console.log(2));
cell.enqueue(() => console.log(3));

Посмотрите расценки на иллюстрации в Интернете. Условно 1 картинка стоит 1000 рублей. Но это очень ОЧЕНЬ грубая оценка, зависит от размеров и прочее. Скажем, если вы закажете 100 мелких иконок оптом, то за каждую, возможно, будет уже около 100 рублей. А может и меньше, но и шанс получить качество тоже меньше. Или вам очень нравится какой-то крутой художник лично, но цены у него сука в 3 раза выше рыночных.

То есть точной цифры нет и не может быть, всё индивидуально. Можно даже за бесплатно найти, за опыт или за упоминание в титрах, как договоритесь. За деньги проще, конечно. Опытным слава не нужна.

Топорный вариант - напишите задание своими словами на illustrators.ru. Хоть там и не каждый умеет в анимацию, но несколько предложений со своими ценами вам накидают. А дальше уже выбирайте. Особо торговаться не советую, иллюстраторы часто знают себе цену. Не советую демперов, они хотят побыстрее отделаться от вас. Смотрите портфолио. Ну и делайте наценку на то, как долго и глубоко вы хотите общаться, доделывать, переделывать, это как бы тоже не бесплатно, но очень условно. То есть если вы, к примеру, битый час объясняете, что нужно сделать, ну накиньте +500 хотя бы по своей инициативе, будет плюс к мотивации. Короче, как я уже сказал выше, всё индивидуально.

К слову, вам нужен не спрайт, а анимация целиком. То есть нужен художник-аниматор. Потому что это как бы вместе делается. Отдельно можно только концепт заказать, и потом на его основе делать анимацию. Причем, в 2019 обычно делают скелетную анимацию (в вашем примере как раз именно такая в Спрайтере), даже если нужно нарезать на отдельные спрайты в итоге, но можно и по-старинке. Up to you, как говорится.

Как оценить стоимость дизайна спрайтов персонажей?

Даже если здесь кто-то что-то напишет, то на практике можно столкнуться с иной ситуацией.

Эффективней будет сходить на биржу фрилансеров и посмотреть на работы дизайнеров, которые Вас устроят и узнать расценки. Или создать заказ с выше предложенным описанием и собрать отклики с примерами работ и ценами.

Presentaion > Application > Domain > Infrastructure
Всё просто: слева направо вызывать можно даже с пропуском слоя, справа налево - нет.

Ответы:
1. Могут.
2. Если подразумевается несколько реализаций, то да.

я в основном делаю ui тесты и у меня некоторые тесты связаны друг с другом. конечное состояние первого теста является начальным сосотоянием следующего. Например первый тест "зайти в формуляр" а следующий за ним "ввести данные в первую строку" а затем тест "ввести данные во вторую строку" а потом "нажать на отправку данных" а потом "тест сообщения об отправке". Естественно если первый тест завалится, завалятся и все после него, хотя реальная проблема только одна. Единственный серьезный недостаток такого подхода, это возможное перекрытие ошибок. Т.е. в билде может сломаться заход в формуляр, и отображение сообщения об отправке. Вторая проблема будет перекрыта первой.
Но меня устраивает такой подход по следующим соображениям.
- Если что-то сломалось в приложение надо в первую очередь чинить приложение, а не писать тонны дополнительного тестировочного кода.
- Тестировочный код тоже код, чем его больше тем больше вероятность сделать ошибку в нем.
- Лучше потратить время на увеличение покрытие пользовательских сценариев, чем на создание красивой и каноничной автоматизации.
- Зависимые тесты выполняются быстрее, (а у нас время тестирования билда во всех вариациях уже перевалило за 16 часов)
- Чинить по одной ошибке за раз - хорошо, пытаясь починить сразу несколько можно сломать что-то еще.

Для того чтобы такой подход работал более менее чисто, я например стараюсь сдвигать все проверки в конец теста, уменьшая таким образом вероятность того что вылетевшее исключение не доведет приложение до нужного состояния для последующего теста.

Но это все не по вашему вопросу. По вашему вопросу - да, писать тонны моков (не нужно). У меня например есть тесты которые проверяют как данные от железа передаются в api графического клиента. при проверке фунцкионала графического клиента, я опираюсь на корректную работу api графического клиента, поскольку им пользуюсь. Так же я опираюсь на корректную работу виджетов. И если какие-то условия не будут работать многие ui тесты посыплются. Мы найдем причину и устраним ее. Чтобы в таком случае падал только один тест, который специально сделан для нахождения этой ошибки, вам придется отвязать тестируемую компоненту от всех внешних зависимостей. Теоретически написав столько же кода сколько в самом приложении. Вы готовы к этому?

P.S.: стоит добавить: наш тест-фреймворк выполняет тесты в алфавитном порядке и не поддерживает параллельное выполнение в принципе.

Создать тестового наследника класса и в наследнике можно перегрузить методы трейта

https://laravel.com/docs/5.4/middleware
Раздел Before & After Middleware

Ну и основной вопрос, в правильном ли я направлении формирую мысли, и как подобный подход с репозиториями можно реализовать правильно ?

Если хотите по правильному - не используйте ларавелевскую ORM, "воевать" с фреймворком - это дело не благодарное.
Паттерн Repository как правило предполагает еще наличие Entity. Entity - это объект, умеющих хранить в себе данные и проверять их при установке. Репозиторий работает только с Entity и только с БД. Никаких bcrypt, работы с файлами, никаких уведомлений...
Не стоит использовать публичные свойства. В противном случае вы не сможете гарантировать корректность данных в вашем Entity, как следствие всюду их придется проверять. Используйте тайпхинтинг.
Так же рекомендую почитать: Попросили проверить код, на что смотреть нужно?

Тоже столкнулся с таким. Есть мнение, что модели возвращают потому, что в них уже можно прописать все необходимое для вывода данных, равно как и спрятать лишние поля, а также преобразовать/добавить недостающие атрибуты. Но наличие метода save() за пределами репозитория смущает. На данный момент пришел к тому, что репозиторий у меня преобразует модели в сущности (самопальными трансформерами наподобие fractal.thephpleague.com) перед тем, как отдать их, но с логикой сохранения внутри репозитория пока не пришел к конечному варианту - часто в проекте требуется не просто сохранить строку в бд в одну таблицу, а сделать гораздо более сложные вещи и вся эта логика завязана именно на процесс сохранения, поэтому не вижу способа вынести эту логику куда-то из репозитория. Но такие вещи, как return session()->flash() в примере по вашей ссылке, считаю лучше на уровне выше генерировать в зависимости от отданных репозиторием данных, они тут вообще никаким местом.

Вообще сам пока ищу наиболее удобный вариант построения приложений (засматриваюсь на гексагональную архитектуру), но применить что-то глобальное на проекте, которым занимаюсь уже год и который разрабатывался с 2014 года просто не могу. Поэтому рассматривайте мои измышления лишь как рассуждения человека, столкнувшегося с этой же проблемой и находящемся на том же пути.

Рекурсия - это отличное решение для отдельных задач. Такое же, как использование case вместо if, или использование sql вместо массивов данных.

Просто используйте их там, где рекурсия работает лучше других решений и все. Есть множество задач, где рекурсия будет best practice.

Чтоже касается того, что "в каких-то языках это плохо работает", так пока не попробуете - не узнаете.

дополню ответ Юрий

Во первых, это на столько здоровый объект реляции images, что отдебажить его можно только с помощью функции dump.

Все сущности заворачиваются в прокси объекты, что бы работала "магия" вроде ленивой подгрузки и т.д. Именно по этому в сущностях "больше" чем есть на самом деле.

По поводу коллекций, в Doctrine есть такая штука как Collection. Вы должны понимать что в доктрине вы оперируете не табличками в базе, а объектами. Строите именно объектную модель вашей системы. В этом ключе можете почитать что такое "агрегат сущностей". В вашем случае у вас агрегат будет состоять из двух сущностей. Product и его Image. Например если вы захотите сделать добавление картинок, вы можете сделать так:

/**
 * usage: $product->addImage($image);
 */
public function addImage(Image $image)
{
    $this->images->add($image);
}

А коллекция сама выполнит persist новой сущности. Таким образом количество репозиториев уменьшается до количества корней агрегатов сущностей. В вашем примере "корнем", то есть вершиной графа взаимоотношений объектов в контексте продуктов, является сам продукт. А потому репозиторий мы будем делать только для продуктов. Все остальное внутри оного разруливается либо при помощи коллекций.

При работе с доктриной вообще полезно представлять себе, что никакой базы данных у вас нет. Что данные просто живут между запросами где-то там, в памяти. Это должно помочь вам "абстрагироваться" и перестать смешивать "сущности" и "таблицы".

К примеру "новички" в доктрине любят персисть сущность даже для обновления. Они путают `persist` и `save`. Так вот, если вы загрузили сущность из базы через доктрину, то сущность уже попадает в unit of work. И делать persist уже не нужно, этот метод только для того чтобы доктрина узнала о чем-то новом. А так она и так знает про эту сущность. В итоге вы можете просто что-то поменять и вызвать flush. То есть репозиторий - это тупо хранилище. Хранилище умеет хранить. Изменять то, что оно хранит оно не может.

Так же рекомендую на тему репозиториев почитать это:

www.whitewashing.de/2013/03/04/doctrine_repositori...

Ну и в целом.

https://www.youtube.com/watch?v=rzGeNYC3oz0 - доклад о том как готовить доктрину от авторов оной.

От себя лишь добавлю простые правила:

- Не используйте напрямую доктриновские репозитории. Пишите свои, а в них уже юзайте доктриновские. Не стоит размазывать доктрину по всему проекту, потом это будет нереально поддерживать.
- Не наследуйтесь от EntityRepository. Это внутренний механизм доктрины общего назначения. Используйте их в своих репозиториях со своим интерфейсом, повышая специфичность и ужесточая контроль за тем кто что юзает.
- Старайтесь использовать entity manager только в своих репозиториях и каких то небольших сервисах. Не размазывайте все по всюду.

что очень сильно срет память.

Доктрина гарантирует вам что в памяти будет всегда только один инстанс сущности. То есть если у вас есть 10 объектов одного типа и имеющих один объект, это все будут ссылки на одну сущность. В вашем случае у вас просто циклическая ссылка между продуктами и изображениями. dump циклические ссылки не особо умеет.

Это логичное ограничение, дабы не возникало ситуаций что вы обновили что-то в одном экземпляре сущности и что-то в другом, и в базу попадут только часть изменений. За подробностями - читайте документацию к доктрине в отношении UnitOrWork и Identity Map.

PhpStorm умеет открывать phar