Alexander

https://github.com/parse-community/parse-php-sdk/b...
Content-type не text/html, только и всего.

Столько комментов и добавить то нечего)
БЭМ это модульность. Каждая верстка это словно создание фреймворка наподобие бутстрап. Если лендинг секций на 10 к примеру верстаешь, то сверстал по БЭМ секции 2-3 а дальше только классы расставляй готовые и иногда модификаторы добавляй. Или многостраничник, основные элементы сверстал и так же только классы расставляй, стили уже готовы.

А если смотреть HTML код с правильным БЭМ, то получается как самодокументируемый код в программировании. Все ясно из названий классов и видно где частью вёрстки независимый блок с элементами внутри. Видно состояние элементов, типа

menu__link_active
card_shadow
button_red
section__title_blue

В вашем примере результат идиотизма верстальщика, ему можно смело руки оторвать.

А Sass это просто более удобая работа со стилями. Препроцессоры не дают модульности в работе над проектом. Неоспоримые удобства - однозначно, сам сасс использую и написал свою адаптивную сетку, когда вся адаптивка происходит в стилях, а не как в бутстрап расставлением кучи классов и созданием большой вложенности а результат это каша в разметке.
Но БЭМ это другое. Между прочим он идеально сочетается с возможностями препроцессоров!

У сожалению у вас получилось как в анекдоте.
- Гоги, тебе нравиться Шакира?
- Нет
- А где ты ее слышал?
- Мне Моги напел

Вам доказывали какую-то чушь, выдавая ее а БЭМ. А потом удивляешься, почему люди БЭМ не любят. Да вот такие умники своим бредом пугают людей, а те в свою очередь думают что это на самом деле БЭМ.

Сожалею о вашем таком неудачном знакомстве с очень хорошим и мудрым изобретением.

БЭМ вносит порядок в код, что уже отлично, позволяет переиспользовать различные части кода. Что касается вашего примера, это конечно перебор, я думаю от бэма здесь только наименование, хотя у меня тоже бывает встречаются блоки, у которых может быть несколько модификаторов, и соотвественно простыня классов, но это удобно на самом деле. Вам как back-end - щику должно быть до лампочки 2 класса у кнопки или 4, скопировать и вставить, фронт частью должен заниматься другой человек, что касается движков, то это скорее проблема движка, если на него нельзя натянуть любой HTML код, имхо.

От БЭМ-а тут только двойные подчеркивания. Тут вообще всё неправильно.

1) Тебе как back-end'еру какое дело до классов ?
2) Ты знаешь в чем различие БЭМ и SASS ?
БЭМ - это методология написание классов.
SASS - это препроцессор.

БЭМ - Это больше масштабируемость а уже потом лаконичность. Забудьте про селекторы (только если они действительно нужны).

А когда просматривал код через панель разработчика то увидел настоящие MMO RPG PVP битву, зуб за зуб, стиль за стиль, по 3 раза все перебивается

Это криворукость разработчика. БЭМ тут ни при чем.

Так по мне БЭМ это вообще огромный костыль а не методология

Ты просто не познал дзен БЭМа.

А вообще в вопросе у тебя говнобём а не БЭМ.

class="custom__button black__button login__forgot reg__button right__part mob-full__width"

На вопрос верстальщику что это такое: "Это бэм"

Вам нагло соврали. Это говнокод.

Понять BEM

Мне как back-end - щику трудно ужиться с этим БЭМ - ом.

Вам это совершенно не обязательно делать.

Зачем БЭМ когда есть SASS/SCSS/LESS.

Что-то из серии "Зачем мне холодильник, если я не курю", ну вы понимаете... :)

Шесть классов для простого button в регистрации.

Такого эффекта можно добиться и без БЭМ.

У меня код в IDE от JetBrains уходит далеко за белую полосу.

Обычно это решается с помощью комбинации Ctrl+Alt+L в IDE от JetBrains.

"Это бэм, я использую один стиль несколько раз и т.д".

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

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

Не знаю :)

Так по мне БЭМ это вообще огромный костыль а не методология.

Отчасти Вы правы, но лишь от части. От "насколько большой части" - сказать трудно. Всё зависит от Вашего восприятия и субъективной реальности происходящего. Колоть монитором орехи - "большой костыль", но не от того, что монитор плохой, монитор хороший, но он создан для решения несколько других задач. Так же и БЭМ создавался для решения задач, с которыми он более ли менее успешно справляется. Проблема тут не в самом БЭМе, а в том, что толпы верстальщиков (сомнительного качества) кинулись "за новомодной соской"... как в басне Крылова - "Мартышка и очки", применять этот самый БЭМ там где надо и не надо. Препроцессор, например, SASS - это круто. Но это не значит, что для стиля "в 3 селектора" нужно за собой тащить целый препроцессор, нужно понимать, когда он действительно нужен, а когда CSS < 1Кб и можно обойтись "руками" (без препроцессоров).

БЭМ - это не только методология, но и ряд других инструментов, без которых он как по мне (*исключительно личное умозаключение, на истину не претендует), примерно настолько же полезен, насколько полезен SASS без своего "компилятора". Есть масса способов написать код лучше не хуже чем с применением БЭМ, которые вполне себе успешно работают в своём контексте.

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

Лучшее объяснение Redux что я видел.
getinstance.info/articles/react/learning-react-redux

Системные настройки-->Пользователи и группы-->Параметры входа-->Автоматический вход

ну тк ты вешаешь blur на before - он у тебя и блюрится. вешай на img, либо на сам блок

Видео по yii2 на русском, сам готовил для экстремальных новичков:
https://www.youtube.com/channel/UC3jTSXXgSvQI2WJ5f...

<form action="/about" method="POST">
    {{ csrf_field() }}
    ...
</form>

Добрый вечер!

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

Если пройтись по конкретике:

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

2) После оглашения оценки по задаче всегда можно ждать справедливого вопроса "Почему так много?". Для таких случаев надо уметь (а лучше уже иметь готовую) декомпозировать задачу на составляющие, оценку для которых легче аргументировать или обосновать на основании исторических данных. Всегда можно попробовать убрать неопределенность в требованиях, если это поможет снизить оценку. Если оценка даже после уточняющей беседы (к примеру заказчик может более четко описать задачу) не изменилась, то можно попробовать предоставить варианты в духе "Если мы откажемся от фишки X, то я сделаю эту задачу на два дня быстрее", чтобы дать понять, что оценку можно менять, согласившись на урезание требований.

3) Как было замечено выше, хорошим решением будет начать пользоваться трекером, который будет показывать текущую загруженность и планы на ближайшее время. Также по нему можно будет отслеживать историю выполнения задач и использовать её в качестве подкрепления для оценок.
В идеале, трекером должны начать пользоваться и пиэмы, чтобы можно было в рамках него проставить приоритет по проектам и задачам. Но в крайнем случае можно начать пользоваться им единолично и даже это поможет улучшить ситуацию. Часть времени будет уходить на управление своими задачами, а не их реализацию, но даже несмотря на это, структурирование задач очень поможет. Даже если трекером начнете пользоваться только Вы, всегда можно направлять менеджеров в него для мониторинга ваших текущих задач.

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

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

6) Однозначно надо описать сложившуюся проблему (она же риск нереализации проектов в срок) вышестоящему руководству. Не надо думать, что им всё равно. Речь об их деньгах и им предлагают митигировать риски.

7) Неадекватность может встретиться всегда. Главное не отвечать на отсутствие логики или хамство тем же. Конктетизируйте и структурируйте свою позицию. В случае, если диалог заходит в тупик, говорите, что вы в данный момент не видите решения сложившегося конфликта. Можно предложить менеджеру два варианта: первый - сформулировать свой вариант решения проблемы. Если не поможет - идем ко второму варианту. Второй вариант - эскалировать решение вопроса на руководство или на любого другого сотрудника, имеющего право решать подобные вопросы.

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

Вы пишете всё в основном о своих проблемах и как вам некомфортно.
Начальству на ваши проблемы и комфорт - пох совершенно.
Либо они в курсе, что текучка ПМов и борятся с этим/не могут побороть это, либо не в курсе, а это значит им пох, на прибыль это не влияет, либо они считают что не влияет.

Если хотите изменить ситуацию, то надо идти к начальству с решением ЕГО, начальства, проблемы, а не вашей. А какие у начальства проблемы - вы не в курсе судя по вопросу.

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

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

Для начала выясните, почему текучка ПМов.

ЗЫ: Лайфхак. Сухие факты и доводы воздействуют гораздо хуже, чем эмоции. Если придёте и поскандалите, то это будет эффективнее. Но скандалить нужно уметь.