жаль, но спасибо

Если в контейнере, то есть такая штука http://symfony.com/doc/current/service_container/expression_language.html

можно Extension написать в котором: foreach ($array as $section => $values) { foreach ($values as $key => $value) { $container->setParameter($section . '.' . $key, $value); } } это простейший пример (если тебе не нужна рекурсия) p.s. только не юзай ЭТОТ говнокод

Could not determine access type for property "price" in class "ShopBundle\Entity\Product". Помогите) Что это значит?

может хватит задавать тут глупые вопросы?

Не знаю где их еще задать(

Для начала надо всегда впастить в гугл, отрезав специфичное для проекта В данном случае - Could not determine access type for property https://stackoverflow.com/questions/42729607/could-not-determine-access-type-for-property-id-handlerequest-failing-unless - вторым пунктом в результатах, видимо твой случай

Could not determine access type for property "price" in class "ShopBundle\Entity\Product". Помогите) Что это значит?

дословно "не могу определить способ доступа к свойству "price" в классе таком-то таком-то"

твоя реакция должна быть - посмотреть что там за свойство такое и почему оно не может определить уровень доступа.

скорее всего у тебя там тупо приватное поле и ты юзаешь геттеры/сеттеры.

скорее всего у тебя там тупо приватное поле и ты юзаешь геттеры/сеттеры.

Да, я забыл сеттер добавить) Просто не понятна была ошибка. Спасибо)

Для начала надо всегда впастить в гугл, отрезав специфичное для проекта В данном случае - Could not determine access type for property https://stackoverflow.com/questions/42729607/could-not-determine-access-type-for-property-id-handlerequest-failing-unless - вторым пунктом в результатах, видимо твой случай

Похоже у меня гугл по другому работает) Спасибо)

Похоже у меня гугл по другому работает) Спасибо)

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

И нам будет лишний повод поумничать

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

в симфони два способа научиться его готовить - читать доку и сорцы

GDD/SODD (google-driven development, stackoverflow-drivern development) позволят решать текущие ошибки, но это помогает только на самых начальных этапах

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

вообще в идеале отключить интернет

мне помогает еще закрывать нафик все вкладки кроме вкладки с проектом, чатики и всякие thunderbird — остается два окна - phpstorm && ff, все остальное отключить. Ну в крайнем случае zeal еще если нужно доку читнуть.

так уходит минимум времени на переключение контекста

а еще не пользоваться jira

запоминать сразу

кстати у пхпшторма вроде есть клиент для джиры

наверное имелось ввиду не копипастить с гугла? а то порой находишь issue с какой нибудь проблемой в бандле) не хотелось бы запускать тесты чужих либ и искать проблемы самому)

нет, я именно имел в виду (как и бобук) — максимально без интернета. Естественно совсем без интернета не получится — таск трекер и пулл\пуш хотя бы должны быть доступны))

сейчас попробую найти доклад

я вот не помню порядок аргументов в некоторых пхпшных функциях

я вот не помню порядок аргументов в некоторых пхпшных функциях

ctrl+P в шторме )

или ctrl+click. Опять же, zeal

https://www.youtube.com/watch?v=h10qZGq36DE - вот

доклад полчаса и полчаса на вопросы

Дык мы когда то так и программировали - без Интернета. Справочник по языку под рукой и в дорогу

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

Эээ ... А доку по симфони?

Ты, судя по всему, должен ее помнить. А так же знать какая куда конфига пишется для любого бандла

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

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

+

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

Удваиваю Владимира Порядок аргументов тебе, ясное дело, IDE подскажет А вот какой там тег надо было написать у сервиса, чтобы его подхватил бандл, или как там вообще интерфейс назывался – надо гуглить

Копипастой с SO можно пользоваться сколько угодно, главное помнить, что люди там спрашивают не "как мне решить вот такую задачу", а "как сделать X в языке Y"

Ты, судя по всему, должен ее помнить. А так же знать какая куда конфига пишется для любого бандла

php bin/console dump:config any_extension_key 90% бандлов идет с докой или в readme или в resources/docs причем там дока самая актуальная, потому что она именно для твоей версии бандла. для удобства можно поставить https://packagist.org/packages/knplabs/mega-man я вообще не согласен, потому что

*не дописалось комментарий из серии "не читал но осуждаю"

проектирование и стековерфлоу - вообще бред

при проектировании нужен листочек, ручка и тишина

а то и прогулка по лесу иной раз

Проектирование – это отдельная история А когда хочешь вспомнить, как там в питоне содержимое json-файла распарсить – последовательность действий очевидная: google "python open file", паста с SO / мана с модификацией

СО никто не отменяет, если ты бьешься над какой-то ошибкой больше 15 минут, однозначно нужно идти в гугл

но не на каждый чих

(хотя 15 минут это зависит от, можно и больше, если есть время)

при проектировании нужен листочек, ручка и тишина

У каждого свои методы проектирования. Для меня язык программирования - удобен для записей своих мыслей. Как средство максимально формального изложения. Листочек нужен когда ты работаешь с кем-то и нужно образно что-то расписать. Но и в этом случае можно работать с вайрфреймами/флоу чартами и прочим-прочим. При чем в онлайн сервисах.

Потом все написанное сразу может идти в документацию, дабы не делать работу дважды, трижды или сколько там кто умудряется. Раз сделанное не должно требовать повторения DRY

я не хочу холиварить, потому что во-первых DRY совсем не об этом, а во-вторых изначально речь шла немного не об этом. Речь шла о том, что программировать можно научиться только в случае непрерываного чтения документации и кода. А изучить такой фреймворк как симфони, а особенно принципы работы симфони и доктрины можно только читая код. А эффективнее всего работать с кодом можно только в случае когда все посторонние раздражители закрыты, такие как: чатики, фейсбучики и смешные вкладочки. (Я еще выключаю телефон (или ставлю в режим без вибрации). ). А тут конкретно в этом чате задаются такие вопросы, которые по стектрейсу можно решить за 5 минут без особых напрягов. И люди, которые задают такие вопросы, в первую очередь вредят себе - в чате ответят на конкретную проблему в большинстве случаев, но не научат программировать за тебя.

Вот как вы так умеете излагать, что в общем-то с вами и можно согласиться. Но возникает столько всяких "Но". Где вы видели, что программист изолирован от отвлекающих факторов? Огромное количество рабочих мест требуют от программиста вовлечение в офисное "бурление" - общение с клиентами, младшими разработчиками, ПМ-ами, сисадминами и т.д. Много каналов связи, которых игнорировать нельзя проходят как раз через соц сети или какие-то внутренние системы коммуникации, которые не так то просто отфильтровать от паразитного отвлекающего фактора. DRY - всеобъемлющий принцип явно/неявно применяемый как в документации, так и в программировании и в дизайне и во много чем - если в результате вашего интеллектуального труда появляются артифакты, то лучше их делать в том виде, в котором их легче всего сделать общедоступным для всех, кого он касается и быть в понятном для них виде. Таким образом избегаем повторения работы и создания частично или полностью дулирующих себя артефактов. Бумажка - явно не такой формат. Хотя и с таким имели дело - работает до определенного момента. Симфони и доктрину можно действительно изучить читая код и доку, но нужно этот процесс оптимизировать читая хабрахабр и стек оверфлоу. В таком случае внимание сконцентрируется на ключевых моментах, понимании узких мест. Здесь люди, отвечая на вопросы, стараются обратить внимание на принцип получения информации. Не видел ни одного разработчика, который сразу бы научился читать код, даже если он самодокументируемый, аж блестит. В первую очередь разработчики учатся этому наблюдая за процессом познания других людей. Иначе путь обучения слишком долог. PS: часто наблюдал, что люди не привыкшие ко сторонним раздражителям становятся нежнее. А остальным сторонние раздражители часто идут даже на пользу. Кто-то черпает в них вдохновение, кому-то просто эмоциональная разрядка нужна

на удаленке если работаешь всегда можно уйти в оффлайн на любое время и тебя никто не будет дергать

я не хочу холиварить, потому что во-первых DRY совсем не об этом, а во-вторых изначально речь шла немного не об этом. Речь шла о том, что программировать можно научиться только в случае непрерываного чтения документации и кода. А изучить такой фреймворк как симфони, а особенно принципы работы симфони и доктрины можно только читая код. А эффективнее всего работать с кодом можно только в случае когда все посторонние раздражители закрыты, такие как: чатики, фейсбучики и смешные вкладочки. (Я еще выключаю телефон (или ставлю в режим без вибрации). ). А тут конкретно в этом чате задаются такие вопросы, которые по стектрейсу можно решить за 5 минут без особых напрягов. И люди, которые задают такие вопросы, в первую очередь вредят себе - в чате ответят на конкретную проблему в большинстве случаев, но не научат программировать за тебя.

Основной посыл, я так понимаю, самостоятельно разбираться в проблеме и как можно больше практиковать и экспериментировать) ... Полностью за)

Меня так брат прогать учил)) ... Хочешь, грит, скажу где косяк, но за это получишь фофан)) ... А фофаны у него тяжёлые были) ... Приходилось думать своей головой

дебаг не всегда спасает еще

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

Основной посыл, я так понимаю, самостоятельно разбираться в проблеме и как можно больше практиковать и экспериментировать) ... Полностью за)

Во! Такая формулировка идиальна ))! ??

ctrl+P в шторме )

Ну давай, расскажи мне какие аргументы у коллбека ( !! ) , передаваемого в функцию array_reduce используя только шторм

забей)

я лохонулся

:)

ERROR: S client not available

А че удалил то? Прочитал внимательно? :D

ну

Вот как вы так умеете излагать, что в общем-то с вами и можно согласиться. Но возникает столько всяких "Но". Где вы видели, что программист изолирован от отвлекающих факторов? Огромное количество рабочих мест требуют от программиста вовлечение в офисное "бурление" - общение с клиентами, младшими разработчиками, ПМ-ами, сисадминами и т.д. Много каналов связи, которых игнорировать нельзя проходят как раз через соц сети или какие-то внутренние системы коммуникации, которые не так то просто отфильтровать от паразитного отвлекающего фактора. DRY - всеобъемлющий принцип явно/неявно применяемый как в документации, так и в программировании и в дизайне и во много чем - если в результате вашего интеллектуального труда появляются артифакты, то лучше их делать в том виде, в котором их легче всего сделать общедоступным для всех, кого он касается и быть в понятном для них виде. Таким образом избегаем повторения работы и создания частично или полностью дулирующих себя артефактов. Бумажка - явно не такой формат. Хотя и с таким имели дело - работает до определенного момента. Симфони и доктрину можно действительно изучить читая код и доку, но нужно этот процесс оптимизировать читая хабрахабр и стек оверфлоу. В таком случае внимание сконцентрируется на ключевых моментах, понимании узких мест. Здесь люди, отвечая на вопросы, стараются обратить внимание на принцип получения информации. Не видел ни одного разработчика, который сразу бы научился читать код, даже если он самодокументируемый, аж блестит. В первую очередь разработчики учатся этому наблюдая за процессом познания других людей. Иначе путь обучения слишком долог. PS: часто наблюдал, что люди не привыкшие ко сторонним раздражителям становятся нежнее. А остальным сторонние раздражители часто идут даже на пользу. Кто-то черпает в них вдохновение, кому-то просто эмоциональная разрядка нужна

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

Ну давай, расскажи мне какие аргументы у коллбека ( !! ) , передаваемого в функцию array_reduce используя только шторм

да я тебе по памяти расскажу

давай ;) только если ты подсмотрел в гугле то лох-пидр. И поверь, когда я тебя встречу я спрошу - и по лицу пойму спиздел или нет :D

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

давай ;) только если ты подсмотрел в гугле то лох-пидр. И поверь, когда я тебя встречу я спрошу - и по лицу пойму спиздел или нет :D

function ($result, $element) {} если мне память не изменяет. В JS точно есть третий аргумент (ключ или номер итерации) а вот в php вроде бы нет

а вот сейчас полезу смотреть

таки да, а я надеялся на подвох

ну вроде бы прав.

я слииишком часто юзаю map/reduce/filter

ну я просто взял с головы то, что сегодня сам смотрел в гугле. Это просто подтверждение тому, что так себе идея отключать гугл на 45 минут в час. Нужна просто самодисциплина.

я уже говорил про zeal? :)

ну я просто взял с головы то, что сегодня сам смотрел в гугле. Это просто подтверждение тому, что так себе идея отключать гугл на 45 минут в час. Нужна просто самодисциплина.

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

а кто скажет почему у map первый аргумент калбек?)

а кто скажет почему у map первый аргумент калбек?)

блин как-то на реддите обсудали и вроде приводили объяснение... но я уже не найду

там можно просто несколько массивов передавать)

да ладно!?

никогда не нужно было

а оно уже умеет iterable?

не, unpack сделать

ну короч несколько массивов это круто но суппорт iterable было бы полезнее

там можно просто несколько массивов передавать)

ВОУ ... это реально новость :) правда, я не хочу видеть это в своем проекте, но примеры по скрещиванию массивов это что-то. Это прям кандидат в "вопросы по PHP для собеса" :D

ну там не совсем так как ожидается работает

одновременно map по всем массивам

и оно все идет в аргументы

а что если я вам скажу что array_keys принимает не 1 аргумент?)

угу, а еще вместо коллбека null это "интересный эффект" в русской документации.... лоло метод наименьшего удивления в ранних версиях ПХП был отбит намертво

а что если я вам скажу что array_keys принимает не 1 аргумент?)

вот этим я пользовался но чет как-то не особо

угу, а еще вместо коллбека null это "интересный эффект" в русской документации.... лоло метод наименьшего удивления в ранних версиях ПХП был отбит намертво

сделаем свою стандартную библиотеку, с блэкджеком и все такое

ну короч несколько массивов это круто но суппорт iterable было бы полезнее

array_map('intval', array_merge(...iterator_to_array($iterable))) бгг