Виктор Выскребенцев: да, все зависит от клиента и от тестов. Скажем на типичном аутсорсинговом проекте юнит тестами код покрывать особо смысла нет (то есть он есть но не всегда и не для всего), можно обходиться хотя бы интеграционными и acceptance тестами. Есть есть QA тогда можно заставлять их писать acceptance сценарии на том же cucumber. И сохранится какая-то документация по проекту и польза будет если вы имплементить сценарии будете. QA всеравно себе где-то acceptance criteria пишут, правда хреново частенько и думаю что не все.
А если заказчик решит по BDD вести разработку вообще ништяк. Вообще плюс Ruby и RoR в том, что придамано масса инструментария для покрытия кода тестами с целью минимизировать время оного.
Дима: поправка - в директиве можно работать с DOM но не стоит вылазить за пределы элемента на который навешана директива. Мне что-то подсказывает что вы свою задачу можете спокойно решить с простым дата байндингм.
Любопытное мнение. Вы только не учитываете того что рано или поздно человеку придется разобраться с написанием тестов. Более того, чем раньше тем лучше ибо писать тесты для уже существующего проекта, пост фактум, это боль и скучно.
Имхо TDD должны осваивать в самом начале. Можно не писать потом тестов или покрывать только критически важные участки, но человека намного сложнее заставить писать тесты когда у него уже есть опыт написания проектов без оных. Многие просто не видят в этом профита так как первое время почувствуют серьезное замедление в скорости разработки и забьют.
Dimazsever: реклама эффективнее поисковой оптимизации. Просто ссылка не интересно, а вот статья которая в каком блоге которая будет привлекать трафик определенно дадут больший эффект.
eandr_67: для этого и нужен clear: left. Ну или display: inline-block - он справится замечательно разве что придется удалить пробелы между блоками или поиграться с letter-spacing.
В целом же на данный момент идеальным вариантом решения этой задачи будут flexbox-ы или в случае необходимости поддерживвать старые браузеры (типа IE9 или 2.3 андроид) dislpay: table.
Медленная загрузка обусловленно реализацией протокола FTP. Он хорошо работает на небольшом количестве жирных файлов. Много мелких файлов он будет грузить вечность даже если у вас канал в один гигабит.
bogolt: эти функции проверяют один символ строки. Ими удобно пользоваться когда пишешь лексер или что-то в этом духе но это не то же самое как те функции которые хочет автор.
я просто не считаю что кеширование/логирование это работа для АОП. Ну как, мне просто не нравится реализация Go AOP а лучше ничего нету. Это мое личное мнение. Допускаю использование этой библиотеки только в контексте контрактного програмирования ибо в этом случае реально удобно.
ivanesi: А так вы намерено хотите усложнить (и причем не слабо так) реализацию просто потому что вам того хочется. Я лично профита в этом не вижу. Кеширование работать будет хуже, есть другие более эффективные варианты.
ivanesi: ну мол количество соединений с сервером. В целом же страничка быстрее не загрузится как как темплейт и данные всеравно запрашиваются в два отдельных потока, и если данные придут раньше чем шаблон то и ждать пользователь не будет.
