во-первых, какая разница, в каком выпуске? — важно, что было.
во-вторых, «пропаганда» была её личными впечатлениями — впечатлениями человека из зоны боевых действий, то есть собственно то, зачем её и позвали на передачу
в-третьих, ну и я тоже по диктору прошёлся добрым словом, и что? — самого факта «затыка» это никак не отменяет и не изменяет))
не помню на каком канале было интервью той девочки-осетинки, гражданки США, вроде на этом самом CNN, но там диктор приложил _все_ мыслимые и немыслимые усилия, чтобы не дать ей высказаться, как только они стали говорить «не то, что положено». так что может он и считается непатриотичным у них, но по сути — весьма и весьма подцензурен…
Это ярко антирусское, «оранжевое», если так можно выразиться радио. Вряд ли где-нить в США такое бы допустили к существованию (антиамериканское, в смысле).
Пусть есть ASP.NET Web Site, в нём подпапка SomeFolder, в ней — папка Controls, в ней контрол UserPreview.ascx. Имя класса для этого контрола будет иметь вид: SomeFolder_Controls_UserPreview.
И где-нибудь в обработчике события ItemDataBound (у Repeater-a, например) при получении ссылок на эти User-контролы внутри ItemTemplate мы напишем:
var userProfile = (SomeFolder_Controls_UserPreview)e.Item.FindControl(«userProfile»);
Дублировать тут это длинное автогенерируемое имя дважды — явный шум.
Ну а с другой стороны:
int usersCount = 0;
немного предпочтительнее всё же, чем
var usersCount = 0;
ничего подобного, ключевое слово «var» многих смущает, но ничего общего с javascriptoвым «var» оно не имеет. строгая типизация была, есть и будет.
посмотрите проект Nemerle (http://www.rsdn.ru/article/nemerle/NemerleIntro.xml) — на этом языке и не такие фрагменты кода можно увидеть, внешне выглядящие как динамически типизированные, но при этом он остаётся строго статически типизированным языком. Вывод типов — наше всё:)
Хорошо бы, чтобы так. Вопрос в том, будет ли поисковик "разбираться", куда там она ведёт. Интересно бы почитать что-нибудь про то, какие случаи поисковики считают спамом, а какие - нет, и каковы критерии разделения... Вот если я, например, на странице сделаю белым цветом по белому фону текст с кучей ключевых слов, это вроде как спам. Даже если слова и правда релевантны нашей страничке.
А тут мы что-то похожее делаем, выходит... В общем, интересны критерии "спам-не спам")
Народ, вот такой вопрос в контексте этого у меня возник. Вот мы да, делаем семантичный html, у нас в нём ссылка с текстом, как и положено.
Дальше мы CSS-ом настраиваем её вид, а это у нас меню, "гаражная дверь", и никакой там не текст нужен, а картинка. Ну и мы этот текст вот так:
text-indent: -9999px;
выкидываем за пределы видимости, а там ставим фоном нужную картинку. И html семантичный , и выглядит красиво.
А вот как поисковики на это отреагируют? Ведь это по сути можно применить и для поискового спама, вставив на сайт невидимые пользователю (текста-то он не видит) ссылки, видимые при этом роботу. А за попытки поискового спама поисковики, как известно, банят.
Кто-нибудь знает что-то определённое про такого рода способы оформления, может ли это привести к понижению в выдаче?
Вот хотя бы про такое "выкидывание текста" через text-indent?
Давно читаю хабр, хочу писать, для этого надо вылезти из нуля, а вылезти никак не получается — не за что зацепиться. Сам занимаюсь разработкой под Windows и Web, достаточно в широком спектре технологий; развиваем с партнёром софтверную фирму. Обо всём этом есть что написать, интересующая тематика: ASP.NET, .NET вообще, WPF, философия разработки и управления распределёнными командами. Имею личный блог на gotdotnet, но хочется выйти и на Хабр тоже.
В будущем планирую пропиарить пару интересных стартапов, пока развивающихся в недрах нашей фирмы под завесой тайны, так что у меня есть все стимулы к созданию интересного контента.
Соответственно, прошу занять под это дело кармы, чтобы начать писать хотя бы в личный блог :)
увы, такие вещи очень часто на практике требуется поменять существенно позже этапа проектирования базы, особенно «null-not null», когда клиента вдруг осеняет, что он не совсем правильно сформулировал свои потребности)
Или другой вариант: решили вы внедрить слой хранимых процедур, дабы поисследовать, как там с производительностью будет. Когда весь маппинг отделён, такие изменения касаются только его. А если всё вперемешку — перелопачивать код.
Пример из другой сферы:
Вот когда-то очень давно я считал, что отдельный CSS-файл — это страшно неудобно. Ну как, так у меня вся информация о теге прямо в нём же, в атрибуте style, а тут надо куда-то в другое место лезть, там нужные классы искать... Однако, я думаю, ясно, что разделение html и css - это хорошо и полезно, поелику это есть разные аспекты описания, им и быть в разных местах, и меняться независимо.
Вот и пара «код-маппинг» (структура класса => маппинг на хранилище) аналогична в принципе паре «html-css» (структура документа => маппинг на экран). И без особых на то причин, лучше их не смешивать.
во-вторых, «пропаганда» была её личными впечатлениями — впечатлениями человека из зоны боевых действий, то есть собственно то, зачем её и позвали на передачу
в-третьих, ну и я тоже по диктору прошёлся добрым словом, и что? — самого факта «затыка» это никак не отменяет и не изменяет))
Пусть есть ASP.NET Web Site, в нём подпапка SomeFolder, в ней — папка Controls, в ней контрол UserPreview.ascx. Имя класса для этого контрола будет иметь вид: SomeFolder_Controls_UserPreview.
И где-нибудь в обработчике события ItemDataBound (у Repeater-a, например) при получении ссылок на эти User-контролы внутри ItemTemplate мы напишем:
var userProfile = (SomeFolder_Controls_UserPreview)e.Item.FindControl(«userProfile»);
Дублировать тут это длинное автогенерируемое имя дважды — явный шум.
Ну а с другой стороны:
int usersCount = 0;
немного предпочтительнее всё же, чем
var usersCount = 0;
Все остальные случаи — где-то между.
из таких вот мелочей и складывается удобство работы => повышается её эффективность.
однако важным плюсом моего варианта является простота подключения к уже существующему коду.
посмотрите проект Nemerle (http://www.rsdn.ru/article/nemerle/NemerleIntro.xml) — на этом языке и не такие фрагменты кода можно увидеть, внешне выглядящие как динамически типизированные, но при этом он остаётся строго статически типизированным языком. Вывод типов — наше всё:)
digg.com/politics/acts_of_genocide_of_ossetian_people_by_georgia
Digg!
А тут мы что-то похожее делаем, выходит... В общем, интересны критерии "спам-не спам")
Дальше мы CSS-ом настраиваем её вид, а это у нас меню, "гаражная дверь", и никакой там не текст нужен, а картинка. Ну и мы этот текст вот так:
выкидываем за пределы видимости, а там ставим фоном нужную картинку. И html семантичный , и выглядит красиво.
А вот как поисковики на это отреагируют? Ведь это по сути можно применить и для поискового спама, вставив на сайт невидимые пользователю (текста-то он не видит) ссылки, видимые при этом роботу. А за попытки поискового спама поисковики, как известно, банят.
Кто-нибудь знает что-то определённое про такого рода способы оформления, может ли это привести к понижению в выдаче?
Вот хотя бы про такое "выкидывание текста" через text-indent?
В будущем планирую пропиарить пару интересных стартапов, пока развивающихся в недрах нашей фирмы под завесой тайны, так что у меня есть все стимулы к созданию интересного контента.
Соответственно, прошу занять под это дело кармы, чтобы начать писать хотя бы в личный блог :)
Или другой вариант: решили вы внедрить слой хранимых процедур, дабы поисследовать, как там с производительностью будет. Когда весь маппинг отделён, такие изменения касаются только его. А если всё вперемешку — перелопачивать код.
Пример из другой сферы:
Вот когда-то очень давно я считал, что отдельный CSS-файл — это страшно неудобно. Ну как, так у меня вся информация о теге прямо в нём же, в атрибуте style, а тут надо куда-то в другое место лезть, там нужные классы искать... Однако, я думаю, ясно, что разделение html и css - это хорошо и полезно, поелику это есть разные аспекты описания, им и быть в разных местах, и меняться независимо.
Вот и пара «код-маппинг» (структура класса => маппинг на хранилище) аналогична в принципе паре «html-css» (структура документа => маппинг на экран). И без особых на то причин, лучше их не смешивать.