100% гарантии нет, но практика показывает, что при 100% покрытии модульными тестами + 100% мутационное тестирование + использование статических анализаторов вероятность появления багов сильно снижается, так как в процессе описанных выше процессов они обнаруживаются и исправляются.
Автору спасибо за интересный пост. Ранее мы тоже использовали вариант группировки от Devaka. Но так как фронт работы требовал большего, был разработан свой. Инструмент тоже является бесплатным и относится к разработкам студии “Семантика”. Работает как веб-приложение за счет обработки на стороне БД позволяет намного ускорить группировку огромных семантических ядер. Также можно группировать слова как с одним маркером, так и с несколькими. Еще один плюс — инструмент не требует никаких профессиональных знаний или настроек макросов. Вот небольшой справочный пост к инструменту http://semantica.in/blog/instrument-marker-ot-semantica.html , а вот ссылка на сам инструмент http://marker.semantica.in/
Тоже требовался подобный функционал. Необходимо было находить пересечения в списках и уникальные строки из списка (уникальными должны быть среди всех списков). Сделали в гуглдокс, но тормозило на 20000 строк. В итоге написали на JS: arcticlab.ru/tools/overlist/. Обрабатывается гораздо быстрее.
Несколько лет уже верстаю с некоторыми идеями БЭМ. Имхо тот БЭМ, которые предлагается сейчас, оправдан только для больших проектов, в которых производятся постоянные изменения. Яндекс например =) У них же практически все сервисы на одинаковых блоках — для них это реально ускорение разработки и поддержки. Для мелких и средних проектов разработка в строгом в соответствии с БЭМ — только увеличение сроков, а пользы гораздо меньше. В таких проектах нет смысла везде использовать, например, абсолютно независимые блоки.
В своей верстке использую следующие правила:
1) именование только классами.
2) блоки, задающие структуру страницы, именовать с префиксом l- (деление на колонки к примеру)
3) логически выделенные блоки (например, меню, список новостей, пагинация и тп) именовать классом с префиксом b-, а внутри этих блоков именовать как угодно
4) блоки, которые могут использоваться внутри других блоков, делать абсолютно независимыми (к примеру вывод какой-н. информации, который используется в различных блоках)
5) Модификаторы класса указываю через дефис (поэтому для названия блока использую стиль camelCase).
В таком случае не теряется скорость верстки из-за оч. длинных классов и их увелечения, но при этом мы получаем лёгкую поддержку верстки и безпроблемное написание новых блоков.
Ммм… ну может тогда обозвать их надо по другому. Но такой функционал иногда требуется. Вот например открыта фотография в модальном окне и нужно показать ещё одно окно для выбора человека из списка друзей, который есть на фото.
Но это же ещё и пересчитывать надо на ресайз основного окна и на ресайз модального окна. Плюс ещё надо учитывать момент, когда модальное окно не влазит в экран. Я не вижу смысла отказываться от таблиц в данном случае и писать вместо этого JS, пусть уж лучше браузер сам занимается центрированием — у него это хорошо получается :)
Таблицы сделаны для того, чтобы корректно работало позиционирование по горизонтали и вертикали. Как я не старался, но дивами у меня это не получилось реализовать кроссбраузерно.
100% гарантии нет, но практика показывает, что при 100% покрытии модульными тестами + 100% мутационное тестирование + использование статических анализаторов вероятность появления багов сильно снижается, так как в процессе описанных выше процессов они обнаруживаются и исправляются.
В целом рабочее решение, позволяет работать с Cycle ORM в Yii 2.
Это же важная фишка диаграммы.
В своей верстке использую следующие правила:
1) именование только классами.
2) блоки, задающие структуру страницы, именовать с префиксом l- (деление на колонки к примеру)
3) логически выделенные блоки (например, меню, список новостей, пагинация и тп) именовать классом с префиксом b-, а внутри этих блоков именовать как угодно
4) блоки, которые могут использоваться внутри других блоков, делать абсолютно независимыми (к примеру вывод какой-н. информации, который используется в различных блоках)
5) Модификаторы класса указываю через дефис (поэтому для названия блока использую стиль camelCase).
В таком случае не теряется скорость верстки из-за оч. длинных классов и их увелечения, но при этом мы получаем лёгкую поддержку верстки и безпроблемное написание новых блоков.
Если будет время можно будет попробовать сделать разную верстку для современных и для устаревших браузеров.
В общем, когда уйдут от нас старые браузеры, тогда будет смысл отказываться от таблиц :)