Интересно узнать как вы разделяете тестовые данные от обычных и как реализовано ограничение прав доступа QaApi. Автоматизированные тесты запускаемые на реальной базе довольно привлекательны в некотором смысле, но количество тонкостей немного пугает.
Помню как в 5 классе, примерно так же развлекался в logo-world. Не знаю повлияло ли это на мою текущую деятельность, но вспоминается с большим удовольствием!
Вообще, операции это основная суть trailblazer'а… Эта та штука которая объединяет уровни авторизацию, форм-обжекты и репрезентеры (классы отвечающие как за сериализацию данных в различные форматы такие как xml, json и тп), так и десериализацию из тех же форматов). Все это вместе позволяет в кратчайшие сроки реализовать красивый API приложения со всеми необходимыми вещами. К примеру, из коробки можно отдавать данные по стандарту JSON-API.
Да, можно использовать trailblazer по частям (я так и начинал: cells -> reform -> representable -> disposable и тд), к тому же это позволяет довольно быстро понять как все это должно работать.
Потом наступает период когда ты смотришь на свой разросшийся контроллер из-за таких вещей как авторизация и препопуляция данных и понимаешь что в нем этого быть не должно… Вот тут то и понимаешь всю прелесть trailblazer-операций=)
Что особенно приятно, операции не делают за тебя никакой магии, к примеру, для авторизации можно использовать собственные policy-классы не имеющие ничего общего с trailblazer'ом.
Что касается cells, то последние обновления данного гема намекают на то, что в скором времени его можно будет использовать в качестве полноценной замены ActionView.
баг очень сильно раздражает при веб-разработке, где довольно часто отрабатывается такой сценарий:
1. Отправляем post-запрос;
2. Получаем 500 статус от бэкенда;
3. Правим код;
4. Жмем f5;
5. Либо возвращаемся к пункту 2, либо получаем ожидаемый результат.
На текущий момент приходится жать кнопку назад и повторно отправлять форму.
Skype может не работать в linux без видимых причин, например в случае qtwebkit собранном gcc-5 bugs.gentoo.org/show_bug.cgi?id=546746
Насколько я слышал, skype for linux практически не поддерживается и только вопрос времени когда он просто перестанет работать. К примеру, при следующем обновлении протокола.
Я Вам даже верю, честно. Дело в том, что я просто хотел обменяться парой текстовых сообщений с несколькими контактами, наивно предполагая что передо мной старая добрая аська, с более удобным интерфейсом, а оказалось что это такой же комбаин, как и прочие мессенджеры. Понимаю, что я не являюсь целевой аудиторией, но все равно грустно… Аська э.то же целая эпоха.
Не люблю отвечать на отдельные части комментариев (обычно это приводит только к разрастанию холивара), поэтому постараюсь кратко и по существу.
Почти готов согласится с Вами по поводу наличия семантики в классе menu-list__link, если в данном случае действительно имеется ввиду ссылка элемента меню. Снова спишем на неудачное имя класса и предположим что на самом деле имеется ввиду menu-list__menu-item-link. Но хотел бы заметить что далеко не факт что имелось ввиду именно это, к примеру могла бы быть примерно такая структура DOM:
По поводу абстракций… Мне как раз то чего всегда хочется избежать их на итоговой странице, ИМХО, абстракциям место только в исходниках, в своих проектах я с этой задачей справляюсь.
Честно говоря не понимаю о чем мы сейчас спорим, я согласен с тем что БЭМ выполняет свою задачу, я лишь говорю о том, что классический подход к применению данной методологии имеет свою цену, а неклассический подход идентичен по результату тому же smacss (отличие будет только в наличии в стилях " > ." вместо "__" и в количестве классов у элементов).
Крайне неожиданно и любопытно. Идеи smacss и БЭМ конечно пересекаются основными критериями, но я бы не стал однозначно утверждать что одна методология во всем лучше другой.
То, как именованы конкретные переменные — не проблема методологии, а проблема конкретного именующего.
Проблема правильного имени класса есть только в «link», ее я и имел ввиду когда написал что лучше уж пусть будет голый <a>, чем <a> с таким классом.
Для простоты мысленно дадим ему более адекватное имя, full-article-link, к примеру.
В итоге получится:
full-article-link
menu-list__full-article-link
menu-list__full-article-link_size_small
Первый класс семантикой наполнился
Второй по прежнему не имеет семантического смысла, линк как был, так и остается ссылкой на полную статью, нам незачем дополнительно подчеркивать это отдельным классом, а то что данный линк лежит внутри меню мы можем узнать просто посмотрев на DOM
Третий класс по прежнему не говорит нам ничего о ссылке, он говорит только о том, что она маленькая, а не о том почему она такая
Последнее как раз ограничение именно методологии, так работают модификаторы.
Самая семантичная замена size_small, которую я смог сейчас придумать это importance_low, но:
класс смотрится стремно
намекает на то что где-то должен быть importance_high и подобные, вряд ли наличие подобных классов предполагалось в приведенном изначально примере, сомневаюсь что модификатор size там нес какую-либо смысловую нагрузку
в БЭМ'е обычно так не делают
Можно еще попытаться преобразовать модификатор size в некий «булевый» модификатор, к примеру, «secondary» как я написал в предыдущем комментарии, тогда класс будет иметь вид: «menu-list__full-article-link_secondary», семантика появляется. Но при этом должно поменяться и css-правило для данного класса. Грубо говоря вместо:
Из приведенного только link просматривается в качестве семантического элемента, хотя и это лишнее, так как link наверняка является <a href="...">.
Класс menu-list__link не имеет отношения к семантике, вообще…
В классе menu-list__link_size_small к семантике отношение могла бы иметь только часть link_size_small, если бы назвалась не link_size_small, а, к примеру, link_secondary или link_is_secondary (да, я знаю что в данном примере, size это модификатор, а small это его значение, в этом и есть семантическая проблема, этот класс говорит не о смысле элемента, а о его отображении)
Терпеть не могу БЭМ, но, к сожалению, не могу упрекнуть данный подход в том, что от него нет практической пользы. БЭМ инструмент созданный для вполне конкретной цели — независимая стилизация различных компонентов страницы. Иначе говоря, для того, чтобы сверстанный компонент отображался адекватно независимо от того, на какую страницу портала (или какого-либо внешнего ресурса), и в какую их областей этой страницы ты бы его не пихнул. БЭМ справляется с этой задачей.
Ругать или хвалить в БЭМе можно только средства которыми это было достигнуто. В данном случае это уход от классической методологии использования каскада в «каскадных таблицах стилей». С учетом того, что в исходниках css'а (sass, less и тд) каскадность никуда не девается, то проблема не такая уж и серьезная.
Проблемой же в БЭМе я считаю то, что при применении данного подхода, верстка становится делом слишком «машинным», теряется семантика элементов страницы. В случае огромных функционально связанных между собой порталов с разными командами разработчиков данных подход полностью оправдан, это тот случай когда много думать вредно. Другое дело, что редко кому приходится разрабатывать нечто настолько огромное.
В остальных же случаях достаточно более «мягких» методологий. Лично я предпочитаю smacss, так как на мой взгляд он не портит семантику и действительно позволяет масштабировать проект. Да, думать приходится много, но оно того стоит.
ЗЫ: Ну и… мне не нравятся стандартные рекомендации по именованию классов в БЭМ. Все эти "__" и "--" довольно омерзительны=)
Да, можно использовать trailblazer по частям (я так и начинал: cells -> reform -> representable -> disposable и тд), к тому же это позволяет довольно быстро понять как все это должно работать.
Потом наступает период когда ты смотришь на свой разросшийся контроллер из-за таких вещей как авторизация и препопуляция данных и понимаешь что в нем этого быть не должно… Вот тут то и понимаешь всю прелесть trailblazer-операций=)
Что особенно приятно, операции не делают за тебя никакой магии, к примеру, для авторизации можно использовать собственные policy-классы не имеющие ничего общего с trailblazer'ом.
Что касается cells, то последние обновления данного гема намекают на то, что в скором времени его можно будет использовать в качестве полноценной замены ActionView.
1. Отправляем post-запрос;
2. Получаем 500 статус от бэкенда;
3. Правим код;
4. Жмем f5;
5. Либо возвращаемся к пункту 2, либо получаем ожидаемый результат.
На текущий момент приходится жать кнопку назад и повторно отправлять форму.
Насколько я слышал, skype for linux практически не поддерживается и только вопрос времени когда он просто перестанет работать. К примеру, при следующем обновлении протокола.
Почти готов согласится с Вами по поводу наличия семантики в классе menu-list__link, если в данном случае действительно имеется ввиду ссылка элемента меню. Снова спишем на неудачное имя класса и предположим что на самом деле имеется ввиду menu-list__menu-item-link. Но хотел бы заметить что далеко не факт что имелось ввиду именно это, к примеру могла бы быть примерно такая структура DOM:
По поводу абстракций… Мне как раз то чего всегда хочется избежать их на итоговой странице, ИМХО, абстракциям место только в исходниках, в своих проектах я с этой задачей справляюсь.
Честно говоря не понимаю о чем мы сейчас спорим, я согласен с тем что БЭМ выполняет свою задачу, я лишь говорю о том, что классический подход к применению данной методологии имеет свою цену, а неклассический подход идентичен по результату тому же smacss (отличие будет только в наличии в стилях " > ." вместо "__" и в количестве классов у элементов).
Проблема правильного имени класса есть только в «link», ее я и имел ввиду когда написал что лучше уж пусть будет голый <a>, чем <a> с таким классом.
Для простоты мысленно дадим ему более адекватное имя, full-article-link, к примеру.
В итоге получится:
Последнее как раз ограничение именно методологии, так работают модификаторы.
Самая семантичная замена size_small, которую я смог сейчас придумать это importance_low, но:
Можно еще попытаться преобразовать модификатор size в некий «булевый» модификатор, к примеру, «secondary» как я написал в предыдущем комментарии, тогда класс будет иметь вид: «menu-list__full-article-link_secondary», семантика появляется. Но при этом должно поменяться и css-правило для данного класса. Грубо говоря вместо:
должно стать:
А это уже не совсем классический подход к БЭМ-модификаторам
Из приведенного только link просматривается в качестве семантического элемента, хотя и это лишнее, так как link наверняка является <a href="...">.
Класс menu-list__link не имеет отношения к семантике, вообще…
В классе menu-list__link_size_small к семантике отношение могла бы иметь только часть link_size_small, если бы назвалась не link_size_small, а, к примеру, link_secondary или link_is_secondary (да, я знаю что в данном примере, size это модификатор, а small это его значение, в этом и есть семантическая проблема, этот класс говорит не о смысле элемента, а о его отображении)
Ругать или хвалить в БЭМе можно только средства которыми это было достигнуто. В данном случае это уход от классической методологии использования каскада в «каскадных таблицах стилей». С учетом того, что в исходниках css'а (sass, less и тд) каскадность никуда не девается, то проблема не такая уж и серьезная.
Проблемой же в БЭМе я считаю то, что при применении данного подхода, верстка становится делом слишком «машинным», теряется семантика элементов страницы. В случае огромных функционально связанных между собой порталов с разными командами разработчиков данных подход полностью оправдан, это тот случай когда много думать вредно. Другое дело, что редко кому приходится разрабатывать нечто настолько огромное.
В остальных же случаях достаточно более «мягких» методологий. Лично я предпочитаю smacss, так как на мой взгляд он не портит семантику и действительно позволяет масштабировать проект. Да, думать приходится много, но оно того стоит.
ЗЫ: Ну и… мне не нравятся стандартные рекомендации по именованию классов в БЭМ. Все эти "__" и "--" довольно омерзительны=)