Pull to refresh
28
2.7
Сергей Бережной @veged

Директор по взаимодействию с разработчиками

Send message
Да. Что интересно, практически каждое архитектурное решение обусловлено более чем одной причиной. Это позволяет надеяться, что мы нащупали некие «глубинные принципы» к которым сходятся задачи/проблемы из разных областей.
это не важно, я готов почитать про аналоги в ± любых смыслах
не понимаю, почему такой вывод

полных аналогов БЭМ (в том смысле в каком я его понимаю для себя) мне не известно — отсюда и вопрос (я с интересом бы их изучил)
БЭМ применим не только к организации шаблонов, но статья и так не маленькая и было очень тяжело осветить все темы. Мы будем продолжать улучшать документацию, в том числе и такого рода примерами.
а какие вам известны аналоги БЭМ, которые существовали в момент начала разработки БЭМ?
рекомендую по теме доклад Артема Ерошенко и Ильи Кацева на YaC 2011: yac2011.yandex.ru/archive2011/video2/ (в самом низу)
т.е. все файлы в итоге хранятся в спецформате (каком?) и дифф/патч реализуются «не стандартными» утилитами (собственно вашим редактором)?
а как дела с системами контроля версий? и вообще что является результатом работы в «проекционном редакторе» и как в этом результате решается вопрос конфликта грамматик?
интересно былобы узнать подробней про «проекционный редактор»
а что, cvs-репозиторий яндекса открыт на всеобщее обозрение?
я может вас огорчу, но в мире существуют языки для которых автоматический рефакторинг не настолько хорош, как хотелось бы
когда пишешь на них приходится рефакторить "sed-ом", а иногда... вручную
бывают ситуации, когда переименование файла и изменения в нём же — это одно логическое изменение
алиас тем плох — что ломает рефлексы по набиранию svn di
лучше конфигурить старые команды, чем учить новые
в файле ~/.subversion/config можно определить diff-cmd = colordiff
По поводу хранения кусков кода в закоментированном состоянии есть контр пример. Часто бывает, что какая-то функциональность не вынесена в отдельную структурную единицу (функцию или т.п.), а исключить её из основного кода надо. При этом точно известно, что она понадобится в будующем (ну или возможно понадобится). Если эту часть кода удалить, считая что в репозитории она всёравно есть, то возникнут две проблемы, когда её надо будет вернуть:
1. никто не вспомнит в какой ревизии оно отсюда исчезло (по diff-ам и blame-ам можно очдолго ползать, если уже много накоммитили)
2. даже если удастся достать этот кусок из репозитория, он может быть уже протухшим (изменились имена глобальных переменных и прочие последствия глобальных рефакторингов)

Поэтому в своей практике я вполне допускаю закоментированные куски кода, при условии, что "глобальные рефакторинги" на них распространяются. Да, это не гарантирует работоспособность (всётаки код не исполняется и никак проверить нельзя), но при достаточной аккуратности даёт больше чем удаление и надежда на репозиторий.
с помощью этого xss Я.Кошелёк конечно же нельзя украсть. Платёжный пароль нигде никак не хранится.

Information

Rating
1,284-th
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity