Если ссылок много в одном месте, например, облако тегов, или меню, то подчёркивание только усложняет восприятие. Подчёркивание появилось для того, чтобы выделить ссылку на фоне остального текста.
Культура приходящее, а профессионал должен сомневаться всегда и во всем, на то он и профессионал. И выбирать методики, технологии и подходы тщательно взвесив все плюсы и минусы.
И если не писать "лапшу", то удобнее опускать ?> , т.к. пустые строки не ломают вывод. В случае же перемешивания разметки и кода тэг действительно необходим. Просто "лапшой" пишет меньшинство(я надеюсь), поэтому не стоит тыкать в технологию не дающую для большинства никаких плюсов, но порождающую минусы. А уж тем более возводить ее в ранг культуры.
У вас нет пустых строк в файлах? Вы бы проверили, а то частенько всплывают. Причем у всех. Никого же не коробит писать, и что некультурного в незакрывании?
Извинюсь от лица всей команды.
Как обычно все произошло по стечению мелких обстоятельств:
1. В классе-мейлере не было метода setRecipient, а был addRecepient
2. На CIS не поднялся fakemail
3. Тест был хрупким, и не учитывал данной ситуации.
Мы готовы!
Эх, вспомнились лабораторные работы на 5-м курсе, по параллельным вычислениям на 4-хпроцессорном кластере. А мы считали, что это бред. Ан нет - будующее.
Алгоритм, ИМХО, следуюший: создается временная конференция на их сервере, со случайным именем, чтобы неприглашенные не пролезли, а потом туда приглашают пользователи.
В предложенном вами запросе тоже нет конкретных цифр, кроме багов в начале 5-ой ветки.
И если не писать "лапшу", то удобнее опускать ?> , т.к. пустые строки не ломают вывод. В случае же перемешивания разметки и кода тэг действительно необходим. Просто "лапшой" пишет меньшинство(я надеюсь), поэтому не стоит тыкать в технологию не дающую для большинства никаких плюсов, но порождающую минусы. А уж тем более возводить ее в ранг культуры.
Тот кто верит непроверенным предупреждениям, вооружен не тем, чем надо :)
Apache/2.2.3 (Ubuntu) PHP/5.2.1 Server. Вывод:
0.753756999969
0.00010085105896
Маленькая ошибочка - include выдает E_WARNING, а не E_NOTICE.
Как обычно все произошло по стечению мелких обстоятельств:
1. В классе-мейлере не было метода setRecipient, а был addRecepient
2. На CIS не поднялся fakemail
3. Тест был хрупким, и не учитывал данной ситуации.
Эх, вспомнились лабораторные работы на 5-м курсе, по параллельным вычислениям на 4-хпроцессорном кластере. А мы считали, что это бред. Ан нет - будующее.
Алгоритм, ИМХО, следуюший: создается временная конференция на их сервере, со случайным именем, чтобы неприглашенные не пролезли, а потом туда приглашают пользователи.