• Как реализовать абстракцию над последовательной цепочкой функций?

    Kozack
    @Kozack Куратор тега JavaScript
    Thinking about a11y
    Примерно как-то так:
    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;
      }
    }
    Ответ написан
  • Как реализовать абстракцию над последовательной цепочкой функций?

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

    Можно добавить метод, который будет создавать новый промис только, когда его время придёт:
    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));
    Ответ написан
  • Как оценить стоимость дизайна спрайтов персонажей?

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

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

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

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

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

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

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

    @younghacker
    А вы уверены что вы программист?
    У меня идеи были раньше навыков программирования и раньше знания языков.
    Что программировать даже вопросов не возникало.
    Придумывал задачу и писал. Сталкивался с проблемой - брал
    дизассемблер, отладчик и смотрел как это решают другие.
    Читал исходники чужих широко известных библиотек.
    Красивый, понятный, изящный код. Это же кайф, как поэзия!

    Практику можно только напрактиковать! :)
    Тренировка во сне - пока что возможна только в кинематографе.
    Ответ написан
  • Протечка или какие зависимости могут быть между слоями в DDD?

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

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

    iiiBird
    @iiiBird Куратор тега CSS
    Пока ты спишь - твой конкурент совершенствуется
    что значит изучить? ты все это должен знать по дефолту.
    когда тебе говорят сделать таблицу - ты же не будешь отвечать "не. я table еще не изучал."
    Ответ написан
  • Как добиться независимости в тестах (phpunit)?

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

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

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

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

    Создать тестового наследника класса и в наследнике можно перегрузить методы трейта
    Ответ написан
  • Хорошая ли идея хранить переводы в JSON?

    ThunderCat
    @ThunderCat
    {PHP, MySql, HTML, JS, CSS} developer
    Значится так, имея множественный опыт мультиязычных сайтов:
    вариант с файлами самый гнилой, причем как для перевода темплейтов, так и для переводов словарных.
    жсон в таблицах - пока фича новая, еще никто нигде не отписался о скорости работы, я регулярно этот вопрос просматриваю - отсюда вывод - хз как оно работает.

    Пока самым верным решением для перевода статей и т.п. является таблица с языками + таблица со значениями, в которой есть:
    id | groupid | languageid | contetnt | e.t.c...
    по группе выбирается нужный объект, по лангвижу - соответствующий язык.
    для перевода темплэйтов - таблица похожая:
    id | alias | languageid | contetnt
    в шаблонах прописывается хелпер, который по алиасу тащит нужную фразу/слово.
    Удобно и гибко, любое количество языков искаропки.
    Ответ написан
  • Репозиторий и ActiveRecord, хорошая ли идея возвращать модели?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Ну и основной вопрос, в правильном ли я направлении формирую мысли, и как подобный подход с репозиториями можно реализовать правильно ?

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

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

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

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

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

    Чтоже касается того, что "в каких-то языках это плохо работает", так пока не попробуете - не узнаете.
    Ответ написан
  • Как правильно работать с объектами выборки doctrine в Symfony?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    дополню ответ Юрий

    Во первых, это на столько здоровый объект реляции 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.
    Ответ написан
  • Где можно увидеть пример применения паттерна Ambient Context для php?

    OnYourLips
    @OnYourLips
    Например в Laravel, его роль там играют фасады.
    Паттерн плохой, лучше его не использовать.
    Ответ написан
  • Как сделать сортировку по разделам, чтобы они сохранялись в куках?

    romy4
    @romy4
    Exception handler
    Лучше не в куки хранить саму сортировку, а хранить лишь идентификатор пользователя, у которого в сессии сохранена сортировка. Либо же в localstorage. Всегда помните про небольшой размер куки
    Ответ написан
  • Как пофиксить белый экран на самописной cms?

    e_kupchak
    @e_kupchak
    Веб-разработчик
    Включение вывода всех ошибок и предупреждений в файле php.ini
    error_reporting = E_ALL
    display_errors = On
    display_startup_errors = On

    Включение вывода всех ошибок и предупреждений в коде PHP-скриптов
    Включить вывод уведомлений и предупреждений можно, добавив в начало нужного .php файла следующие строки:
    ini_set('error_reporting', E_ALL);
    ini_set('display_errors', 1);
    ini_set('display_startup_errors', 1);

    Включение вывода всех ошибок и предупреждений в файле .htaccess
    php_value display_errors 1
    php_value display_startup_errors 1
    php_value error_reporting E_ALL
    Ответ написан