• Чем заменить jQuery?

    dhat: а теперь давайте конструктивно.
  • Знания Junior php разработчика?

    и на какие ошибки вообще нужно тестировать?


    Ну вот подумайте... на какие ошибки мы пишем тесты?

    Есть неплохая статья "Testing vs Checking". Мол мы не тестируем, мы "проверяем" что то что работало раньше не сломалось. А тестирование это процесс нахождения новых проблем, более творческий процесс. Его автоматизировать полностью нельзя.

    В целом можно начать хотя бы со следующих топиков:

    - виды тестов
    - виды багов, причины регрессий
    - как проверить что все работает? Это больше к вам вопрос. Можем ли мы это автоматизировать что бы не проверять все руками?
    - пирамида тестирования, почему скорость выполнения тестов важна? На эту тему есть неплохая лекция (что большинство пирамиду переварачивают потому что не умеют): https://www.youtube.com/watch?v=VDfX44fZoMc

    Ну короч гугл и практика.
  • По какой причине при сохранении сущности с отношением one to many, не записывается id на связь?

    nepster09:

    1. Производительность. Юнит оф ворк доктрины их недолюбливает, потому лучше стараться обходиться без них. Но да, нередко они нужны. Просто далеко не всегда.
    2. Сложности в плане работы с объектами. Одно дело когда есть какая-то маленькая фигня, инстанс которой мы можем прямо в сущности склепать. И другое дело когда нам надо связать две сущности. В итоге это порождает излишнюю связанность. А это в свою очередь способствует формированию каши в коде, нарушению инкапсуляции и все такое.

    Двусторонние связи - это исключение из правил. Они есть, но перед тем как их фигачить, нужно попробовать без них. Если на бизнес логику лучше ложится двусторонняя связь - окей. Но это где-то 10% всех связей а то и меньше.
  • Angular2 - присваивание в конструкторе в TypeScript как это работает?

    AVIL13: повторюсь. Почитайте про Inversion Of Control и зачем был придуман dependency injection, какие проблемы решает и все такое.

    Сейчас мне кажется что вы хотите этот принцип слегка "поломать" просто так.
  • Знания Junior php разработчика?

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

    То есть этот навык нужен не только потому что "автотесты", а просто он нужен. С Автотестами это просто не так скучно.

    atis //: без собеседования не отвечу.
  • По какой причине при сохранении сущности с отношением one to many, не записывается id на связь?

    nepster09:

    вам потребуется писать скрипты, которые будут следить за целостностью этого json.


    Соблюдение целостности - задача класса ProductPhoto.

    А что если в один прекрасный день добавится еще 1 конфиг, например изображение в шапке товара или еще что-то. Это все весьма неудобно станет поддерживать.


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

    Я удаляю товар и все что к нему относится, по ключу красиво удаляется.


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

    Вы НЕ обязаны так делать, это выбор разработчика. Далеко не все можно удобно денормализовать и далеко не все нужно нормализовать. Вместо того что бы загоняться по паттернам, подходам, базам данных и прочее, лучше старайтесь разбираться в бизнес логике того что вы делаете и выражать это в коде. И тогда все станет проще.
  • Как изолировать active record в laravel5?

    nepster09: это просто выражение которое мне показалось более приятнее чем "иди загугли".
  • По какой причине при сохранении сущности с отношением one to many, не записывается id на связь?

    nepster09:

    похожее в MySQL 5.5.


    Обновитесь до 5.7. Ну или хотя бы до 5.6. Помимо json (5.7) там merge index-ы появились (5.6) и много чего другого вкусного.

    Скоро чихать буду от active record.


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

    вы пренебрегаете заповедью "реляционная бд"


    Ну тип того. Сейчас не 70-ые, место на диске стоит копейки. Просто давайте порассуждаем. Допустим у нас есть сущность Product у которой есть картинки (ProductPhoto). Какой профит нам даст нормализация этого в отдельные таблицы?

    По сути единственный профит от нормализации в этом случае - дает возможность работы с картинками без участия продукта. Когда нам такое надо? В контексте каталога продуктов - никогда. А когда нам продукты нужны вместе с картинками? Практически всегда. Вот и получается что хранить все картинки в JSON поле у продукта выходит довольно удобно.

    Конечно так стоит делать когда вы на 100% уверены в том что делаете. Ну и нужно еще подождать пока выйдет Doctrine 2.6 где работа с json будет поудобнее.
  • По какой причине при сохранении сущности с отношением one to many, не записывается id на связь?

    nepster09:

    Во вторых, я вспомнил, как когда-то давно в детстве хранил картинки в json и это весьма не очень хорошая практика.


    вы же пути картинок хранить должны, а не сами картинки. Хранить картинки в базе плохая практика, согласен.

    Тянет на парочку отдельных сервисов.


    Скорее тянет тупо объекты в которые вы все это будете хранить, но это не обязательно должны быть сущности.

    Поэтому я бы не пологался только на доктирину в плане целостности данных.


    Вы и не должны полагаться на доктрину. Ваша объектная модель (просто PHP код) ничего знать о доктрине не должны и сама по себе должна описывать все бизнес правила и логику сохранения целостности данных.

    Повторюсь - если вы не планируете ТАК использовать доктрину, то для вас нет разницы использовать ее или какую-либо библиотеку для active record. Результат будет примерно одинаковый.
  • Как правильно организовать API?

    Вам нужно организовать взаимодействие нескольких процессов? Ну то есть это будут независимые процессы или "модули" будут тупо подключаться?
  • Как плюсы и минусы от размещения БД на удаленном сервере?

    Антон: не забудьте подтюнить настройки postgres что бы тот все доступные ресурсы юзал. Особенно в плане памяти. И возможно вам стоит взять сервачки чуть дешевле и вынести фоновые задачи на третий сервер чтобы не мешать базе.
  • Есть ли подобие global из php в js?

    отучайтесь использовать глобальные переменные.
  • Как правильно работать с объектами выборки doctrine в Symfony?

    Юрий: да все можно решить бандлами и библиотеками, раз уж на то пошло. У меня есть жирный список вещей, которые я хочу сделать что бы сделать мою работу с симфони приятнее (от надстройки над symfony/dependency injection для ленивых вродеменя, до полноценного мэппера данных запроса на объекты). Но это все чисто под меня и мою команду.
  • Зачем Ruby нужен fiber?

    Александр Гришин: файберы - это примитивы потока управления, на которых можно построить что-то типа потоков. Корутины если хотите. Далее уже на основе их возможностей можно пилить свои абстракции и в них использовать какой-нибудь select/epoll чтобы выбирать сокеты с доступными для чтения данными.
  • По какой причине при сохранении сущности с отношением one to many, не записывается id на связь?

    nepster09:

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


    У этого подхода минусов значительно больше чем плюсов. Потому надо очень хорошо понимать зачем вы это делаете. В вашем случае можно просто об этом забить и воспринимать SQL как замечательный DSL агрегации данных.

    Поэтому я не могу свыкнуться с мыслью, что можно запить на базу, на ключи и тп. Как минимум ключи проставляют индексы. что способствует ускорению работы бд.


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

    что они делают так-же.


    Это дока. она описывает что можно делать а не то что нужно так делать всегда. А еще есть в той же доке лучшие практики, и там то о чем я говорю.


    Но тогда, для изображений не проставляется id автоматически, для этого я добавляю:


    Я говорил о том, что вам не нужно их проставлять. От слова совсем. Не нужно картинке знать о продуктах. Возможно потом у вас даже промелькнет мысль что "хм.. картинки продукта нам нужны практически всегда... зачем я вообще в отдельную таблицу это ложу? Можно ж воспользоваться jsonb и не париться".
  • Зачем Ruby нужен fiber?

    Александр Гришин: если коротко - это как многопоточность но без жестких ограничений на переключение контекста. То есть можно поднять хоть тысячу файберов и будет это работать лучше чем тысяча полноценных потоков.
  • Зачем Ruby нужен fiber?

    Александр Гришин: то есть вы не знаете зачем нужны легковесные потоки?
  • По какой причине при сохранении сущности с отношением one to many, не записывается id на связь?

    nepster09:

    ну не знаю, вроде в доках написано, что можно не беспокоиться о связанности в пределах бандла.


    1. Не весь код приложения должен жить в бандлах. Это даже в доках написано. В целом "бандлы" должны быть самодостаточны. То есть если у вас появляется некий CoreBundle то вы уже неправильно что-то разделили.

    2. Могу сказать вам то, что говорю своим разработчикам когда те начинают разговоры о разделении на бандлы. На бандлы дробить приложение можно, разнося разные контексты (bounded contexts) по разным бандлам. Условие для этого должно быть одно - каждый бандл представляет собой независимую часть приложения. Между бандлами не должно быть прямой зависимости. Сущности в пределах бандла ничего не должны знать о сущностях в других бандлах. По сути критерий качества разделения - у вас должна быть возможность взять бандл, вынести его в отедльный проект с отдельной базой данных и с минимальными усилиями заставить работать этот отдельный компонент как отдельную подсистему, независимую. Такой подход вполне себе норм особенно если проект большой и вы хотите в будущем разделить его на микросервисы но еще не доросли до того, что бы делать микросервисы сразу.

    То есть опять же этот подход нужен где-то для 1% проектов.

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


    1. У вас были такие случаи? Как вы думаете насколько вероятен такой исход?
    2. лучше не делать так, что бы в одну базу писали несколько программ. Для небольших вспомогательных задач это норм, но что-то сложнее - реально проблема. Лучше уж пусть php пишет в одну базу, а "другая технология" в другую. Вам же другая технология не просто так понадобилась. Скорее всего вы смогли выделить какой-то вспомогательный контекст который собираетесь решать своими силами.
    3. Доктрина отлично работает в ситуациях, когда вы сначала на основе объектной модели генерируете схему базы, а потом уже оптимизируете ее.

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


    База данных - тупое хранилище которому не положено ничего кроме как хранить данные. Можно иметь хоть 10 разных СУБД на одном проекте, чтобы пользоваться преимуществами каждого для конкретных задач. Нужны графы - neo4j. Нужны реляции - postgresql. нужен поиск - elasticsearch.

    Дальше 3-ей нормальной формы например идти сегодня смысла нет. И если речь о больших нагрузках вообще приходится прибегать к денормализации. Это лет 30 назад место на диске было дорогим, сейчас это копейки.

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


    Что до консистентности - при нормальных подходах консистентность данных должна обеспечиваться вашим кодом. База данных может выступать лишь дополнительным гарантом что все будет хорошо.

    То есть главное это не "ключи внешние" а почему у вас они появляются. Это скорее всего диктуется бизнес логикой. Сейчас не так уж и редко разработчики не парясь хранят какие-то связанные данные тупо в jsonb. Просто потому что можно и это часто удобно.
  • Организация доступа к API?

    DarkByte2015: для json rpc возможно кто-то что-то подобное уже наваял, не в том виде как у вас конечно (потому что это можно только через прокси а оно еще не так распространено).

    Ну и повторюсь - это покрывает только json rpc но далеко не полностью покрывает restful api. Как минимум потому что в нормальных апишках помимо "урла" есть еще http verb, заголовки, query string и т.д. Ну то есть вам либо придется ограничивать возможности разработчиков в плане того, как они будут это все хэндлить, либо забить. Ибо разработчикам API намного проще сделать шаблон для кодогенератора и генерировать клиенты из доки по api.