проще всего maintenance mode

при alter table лочится вся таблица, так что тоже ничего не сможешь сделать

вылили с багом, льют хотфикс

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

ну и можно еще нормальную СУБД юзать типа постгри

у любой субд есть проблемы, тут скорее в культуре разработке

если у тебя в релизе меняется хранение данных и раньше хранил в одном месте теперь в другом

то это одна история и там просто не делаются деструктивные действия

и все довольны)

и разницы в том сегодня ты делаешь эту выкладку или через месяц особо нет

то это одна история и там просто не делаются деструктивные действия

скинь плз счылку на канал

просто если релизы каждый день, то все это становится отточенным до автоматизма

скинь плз счылку на канал

на канал чего ?)

твой

ютубе

https://www.youtube.com/channel/UCDNCv34bnSqQwPHrPlb5Q7w?

но там все для новичков и о наболевшем в пхп

а я кто?)

подписался

у любой субд есть проблемы, тут скорее в культуре разработке

Только в постгри альтер с добавлением новой колонки с дефолтным значением занимает понты. Вот и профит. Как говорил @fesor делаешь обратно совместимые изменения (только вперед!) когда с новой схемой работает и старый код и новый, а потом переключаешь. Если нужно будет почистить, то это раз в годы, и с maintance mod. Так делают все взрослые дяди. Только тут да, и культура разработчиков должна быть, и тестирование качественное. Но для ситуации что ты описал (здоровый магазин) это не должно быть проблемой

1 000 000 товаров это маленький магазин

по сравнению с данными с которыми на прошлой работе работали

и там никто тебя в бд не пустит, там для работы с бд есть свои люди dba

професия спорная конечно dba

1 000 000 товаров это маленький магазин

это достаточно большой магазин что бы там был не студент а матерый чел в свиторе

професия спорная конечно dba

много спорных профессий, но если база данных это мега критическая штука удобнее когда есть чел который именно на этом специализируется.

маленький в сравнение с тем что было на прошлой работе

много спорных профессий, но если база данных это мега критическая штука удобнее когда есть чел который именно на этом специализируется.

и отвечает за это, целый отдел

существует ли сочетание бесплатный хостинг + хороший + без рекламы? Кто-то владеет вопросом?

Хороший нахуй из этого контекста выбрось

Но есть heroku

Amazon

это все уже называли, почитай дискуссию.

челу и гитхаб пэйджис сошел бы

челу и гитхаб пэйджис сошел бы

+

Лел

Сорян

еще не уверен, нужен ли постоянный php

шта

Ну, типа инсталл скрипт генерит хтмл-ки, потом пых не нужен)

там текста в .md файлах

что мы все обо мне, да обо мне…?

как правильно стянуть через регулярку title

https://regex101.com/r/HX2Wpk/1/

как правильно стянуть через регулярку title

А почему именно регулярка?

если у тебя есть проблема и ты решаешь ее регуляркой

теперь у тебя 2 проблемы

Какой-нибудь phpQuery чекни мб тебе поможет

Simple html dom

Но регулярки шустрее

если задача из категории "спарсить", то регулярками её лучше не решать. иначе рано или поздно в поиске по title=".*" напорешься на title="foo\"bar" и всё равно вернёшься к DOM-классам, phpQuery, парсерам, токенам/лексемам и конечным автоматам. лучше уж сразу начать с них.

подскажите пжлст чатик по ноде или, может, кто-то знает как запустить протрактор с ноды (експрес) и там же получить результат работы

если задача из категории "спарсить", то регулярками её лучше не решать. иначе рано или поздно в поиске по title=".*" напорешься на title="foo\"bar" и всё равно вернёшься к DOM-классам, phpQuery, парсерам, токенам/лексемам и конечным автоматам. лучше уж сразу начать с них.

<зануд мод>Регулярки == конечные автоматы</зануд мод>

https://stackoverflow.com/a/1732454/3783300

Может кто знает, почему симфони контейнер не поддерживает анотации. Сейчас мне симфони контейнер нравится больше чем phpdi, thephpleague/container по фукнционалу и продуманности (если включить autowiring). Но для аргументов без аутовайринга, придется юзать сторонний файл (xml,yml,php) что реально мне не понятно. Почему нету аннотаций? Вот этот кейс http://symfony.com/doc/current/service_container.html#manually-wiring-arguments

Может кто знает, почему симфони контейнер не поддерживает анотации. Сейчас мне симфони контейнер нравится больше чем phpdi, thephpleague/container по фукнционалу и продуманности (если включить autowiring). Но для аргументов без аутовайринга, придется юзать сторонний файл (xml,yml,php) что реально мне не понятно. Почему нету аннотаций? Вот этот кейс http://symfony.com/doc/current/service_container.html#manually-wiring-arguments

производительность очень пострадает из-за этого

поэтому выбрали регистрацию по psr

чет ты не с этой оперы. 1. Производительность. Это не компилируемые языки, тут рефлексия чуть медленнее но не такая разница как в компилируемых. Темболее для autowiring она один хер юзается уже. Даже бог с ней с рефлейкией, контейнер симфонивский умеет в кеш. А это разовая операция. пхплига и пхпди же сделали это и много кто пользуется. Короче производительность нет. 2. Причем тут PSR? Я тебе про момент описания инджекта зависимостей, а не момент получения сервиса через контейнер. Отвечу сам на свой вопрос. Пришлось погуглить https://github.com/symfony/symfony/issues/21103 вот и https://github.com/symfony/symfony/pull/21376 Просто пока-что реализации не нравятся, но обещали подумать как избавится от лишнего файла.

Серафима на вас нет

Он бы сейчас рассказал какое симфоневский контейнер говно

А @fes0r бы начал спорить

и диалог на пару ночей)

чет ты не с этой оперы. 1. Производительность. Это не компилируемые языки, тут рефлексия чуть медленнее но не такая разница как в компилируемых. Темболее для autowiring она один хер юзается уже. Даже бог с ней с рефлейкией, контейнер симфонивский умеет в кеш. А это разовая операция. пхплига и пхпди же сделали это и много кто пользуется. Короче производительность нет. 2. Причем тут PSR? Я тебе про момент описания инджекта зависимостей, а не момент получения сервиса через контейнер. Отвечу сам на свой вопрос. Пришлось погуглить https://github.com/symfony/symfony/issues/21103 вот и https://github.com/symfony/symfony/pull/21376 Просто пока-что реализации не нравятся, но обещали подумать как избавится от лишнего файла.

1. Если ты хоть немного читал то что ты скинул, то за производительность там написано сразу. И в слаке довольно бурные обсуждения были. При любом изменении кода нужно пересобирать весь контейнер это раз, во-вторых нужно еще обойти все исходники в поиске новых аннотаций с сервисами. Были неоднократные попытки у core разрабов затащить аннотации как в спринге, но тесты показывали очень печальные результаты 2. Вместо этого приняли другой пакет фичей. один из них это psr регистрация https://github.com/symfony/symfony/pull/21289, autoconfigure, named arguments, defaults и class alias. Ну и собственно еще пока не испытывал нужды в аннотациях, были б еще нормальные аннотации в пхп и да, текущий контейнер с автовайрингом собирается на порядок дольше чем без него. у нас доходит до 2-3 минут на пересборку

Серафима на вас нет

не захотел он сюда с гиттера переходить. и он особо не видел контейнер 3.2+) там в 3.4 еще dsl для пхп добавли, теперь можно вообще без yml жить

не захотел он сюда с гиттера переходить. и он особо не видел контейнер 3.2+) там в 3.4 еще dsl для пхп добавли, теперь можно вообще без yml жить

dsn - имеешь ввиду новый вариант конфигов?

(это я уточняю суть, а не понятие dsn)

dsn - имеешь ввиду новый вариант конфигов?

https://github.com/symfony/symfony/pull/23834

да, его и имел ввиду, спасибо

по симфони вообще лучше сразу в https://t.me/symfony_php писать

я там давно уже есть) просто тут зашел топик такой

1. Если ты хоть немного читал то что ты скинул, то за производительность там написано сразу. И в слаке довольно бурные обсуждения были. При любом изменении кода нужно пересобирать весь контейнер это раз, во-вторых нужно еще обойти все исходники в поиске новых аннотаций с сервисами. Были неоднократные попытки у core разрабов затащить аннотации как в спринге, но тесты показывали очень печальные результаты 2. Вместо этого приняли другой пакет фичей. один из них это psr регистрация https://github.com/symfony/symfony/pull/21289, autoconfigure, named arguments, defaults и class alias. Ну и собственно еще пока не испытывал нужды в аннотациях, были б еще нормальные аннотации в пхп и да, текущий контейнер с автовайрингом собирается на порядок дольше чем без него. у нас доходит до 2-3 минут на пересборку

Обожди, давай разбираться. 1. Читал, про производительность там было одно упоминание, и то про тот случай, если всю конфигурацию запихнуть в анатации. Плюс autowiring и так есть, и в первую очередь замедляет именно он. Кейс что я скинул ссылку, это когда DI уже определился какой класс ему инициировать (через autowiring) и даже знает почти все аргументы (через тайп хинтинг, ему не хватает лишь некоторых аргументов конструктора, у которых нету тайпхинтинга). И вот именно для этого кейса да, добавить аннотацию. Дальше, как-то ж доктрина живет с поддержкой аннотаций, и ничего. Дефолтный проект это n контроллеров n сервисов и n<<Entities (ну в маей практике, может выборка и не очень). Раз доктрина справляется с большим кол-вом энтитиес, справились бы и с некоторыми сервисами. 2. PSR. Ты про то, что дополнительно к автовайрингу прикрутили, чтобы автовайринг был только в некоторых директориях и только по ПСР, ну ок, я тоже про это, как-раз в этом случае мне не хватает чуть-чуть анатаций в редких кейсах. Если у меня одна папка src я бы один раз настроил искать по PSR в src/ (в любом формате) а затем такие вот "нюансы" с одним-двумя аргументами без тайпхинта зарешал анотациями. Про скорость автовайринга это отдельная тема, ясен хрен автовайринг медленнее, чем явные конфиги. Аннотации тут мало зарешают. Ну и в конце-концов- демократия, дайте мне возможность аннотаций, даже если это медленнее, может меня это устраивает. Как-бы когда в ядре почти для всего есть аннотации а для этого нету.... я все

Обожди, давай разбираться. 1. Читал, про производительность там было одно упоминание, и то про тот случай, если всю конфигурацию запихнуть в анатации. Плюс autowiring и так есть, и в первую очередь замедляет именно он. Кейс что я скинул ссылку, это когда DI уже определился какой класс ему инициировать (через autowiring) и даже знает почти все аргументы (через тайп хинтинг, ему не хватает лишь некоторых аргументов конструктора, у которых нету тайпхинтинга). И вот именно для этого кейса да, добавить аннотацию. Дальше, как-то ж доктрина живет с поддержкой аннотаций, и ничего. Дефолтный проект это n контроллеров n сервисов и n<<Entities (ну в маей практике, может выборка и не очень). Раз доктрина справляется с большим кол-вом энтитиес, справились бы и с некоторыми сервисами. 2. PSR. Ты про то, что дополнительно к автовайрингу прикрутили, чтобы автовайринг был только в некоторых директориях и только по ПСР, ну ок, я тоже про это, как-раз в этом случае мне не хватает чуть-чуть анатаций в редких кейсах. Если у меня одна папка src я бы один раз настроил искать по PSR в src/ (в любом формате) а затем такие вот "нюансы" с одним-двумя аргументами без тайпхинта зарешал анотациями. Про скорость автовайринга это отдельная тема, ясен хрен автовайринг медленнее, чем явные конфиги. Аннотации тут мало зарешают. Ну и в конце-концов- демократия, дайте мне возможность аннотаций, даже если это медленнее, может меня это устраивает. Как-бы когда в ядре почти для всего есть аннотации а для этого нету.... я все

доктрина сносно живет с аннотациями потому что там жестко прописано где искать классы с аннотациями и по этому сканить ей не так много. В случае же контейнеров зависимостей - сканить там сииильно больше. Ну и у @Enleur здоровенный контейнер и он будет агриться на что угодно что замедлит компиляцию контейнера даже на 5%

Ну так я ж говорю - демократия - не подходит не юзай, делов то. А про сканить дохера... это почему? вот сам же @Enleur скинул ПР с новой фичей в DI 3.3 https://github.com/symfony/symfony/pull/21289 Теперь ты можешь указать, сканить толкьо src/Services и все.

Опять же, я тебе не про автовайринг, берем что он включен и он УЖЕ сканится, не важно сколько. Но будут классы где будет непонятно что автоподставлять, как тут в примере с adminEmail http://symfony.com/doc/current/service_container.html#manually-wiring-arguments

я не понимаю, что именно требуется от аннотаций?

указать @Component ?

или в аргументы указать какие проперти тащить?

в доктрине с метаданными мягко говоря проблемы

про "почисти кеш" уже шутить устали

я пишу много на спринге, с аннотациями, бинами и java config'ами. но мне вполне хватает того что завезли в симфони

я не понимаю, что именно требуется от аннотаций?

Вот я скинул ссылку, пример с $adminEmail Хочу в аннотации чисто для него, для $adminEmail указать что-то вроде @argument $adminEmail 'manager@example.com' или @argument $adminEmail '%email_param%' вместо того чтобы идти хуй знает в какой файл, ради одного этого параметра, и найти вот это. # explicitly configure the service AppBundle\Updates\SiteUpdateManager: arguments: $adminEmail: 'manager@example.com'

ну не в "хуй какой файл", а возле класса есть ссылочка от плагина

хм... ссылочка это уже лучше. Она будет работать если у тебя только DI от симфони?

Самой симфони нету.

Уверен что врядли.

вряд ли

хотя, там она в кеш смотрит тот что генерит симфони

путь к нему настраивается

но я не проверял как оно будет работать

@argument $adminEmail 'manager@example.com' или @argument $adminEmail '%email_param%' я люблю аннотации, но это через чур как по мне)

ну и поповоду права выбора

JMSDIBundle уже сколько лет?

аннотации для DI, бери юзай

хошь свои пиши на любой вкус

Уверен что врядли.

вообще стоит прочекать, ибо плагину симфони нужен только путь к скомпиленному файлу с дефинишенами

во всяком случае с релизом 3.3 меня полностью все устраивает

мне даже не особо нужен php-dsl который в 4-ке будет (хотя хз надо попробовать)

а я жду dsl)

регать будет быстрее и проще

хотя плагин уже умеет автокомплит по названию делать вроде