Новая кнопка по описанию частично пересекается с другим виджетом ВКонтакте, «Share»:
Мне нравится — позволит посетителям Вашего сайта не только выразить своё отношение к статье одним кликом, но также поделиться ссылкой на неё с друзьями, даже если они не считают необходимым оставлять комментарий.
Share позволяет существенно увеличить посещаемость Вашего сайта, предоставляя Вашим читателям возможность удобно делиться ссылкой на Ваши материалы. Каждый раз, когда пользователь делится статьей, ссылка на нее появляется на его странице, а также в новостях у его друзей.
Нужно четко понимать, что значит «поделиться ссылкой» в обоих случаях:
«Share» добавляет ссылку в список «Мои заметки». «Like» этого НЕ делает.
«Share» помещает ссылку на страницу в статус пользователя (т.е. она появится в ленте новостей его друзей). «Like» делает это только в случае, если пользователь выберет галочку «Рекомендовать друзьям».
Зато при нажатии «Like» НЕ появляется диалог, в котором можно поменять описание ссылки и НЕ выводится каптча. Это явный плюс, скорее всего эти два диалога (особенно каптча) уменьшает кол-во людей, добравшихся до финиша в несколько раз.
Главный вопрос: если у вас был Share, стоит ли его заменять на новый Like? (конечно, можно использовать оба, но мне кажется это только запутает пользователя; тем более обычно рядом нужно пристроить кнопки других сетей, т.е. кнопок будет много).
Конечно, отсутствие каптчи стоит многого. Но только в случае, если люди будут выбирать вторую галочку «рекомендовать друзьям». Плюс заменив виджет вам нужно будет опять накапливать счетчик, который выводится рядом (когда он уже большой, людям психологически проще тоже на него нажать).
Новая кнопка сделана в стиле а-ля Facebook, а идеология Facebook мне нравится больше. Лично я — попробую.
Мне кажется, использовать решение, предложенное в статье (выделенная страница для сообщения об ошибке), крайне желательно в любом случае. Даже если бы никакой уязвимости не было.
1. Пользователю абсолютно ничего не говорят сообщения об ошибках, которые он увидит.
2. Мало того, у него появляется ощущение, что сайт ненадежный. Общая фраза «На сайте произошел сбой, дайте нам немного времени, чтобы мы могли его устранить» создает впечатление хоть какого-то контроля над ситуацией.
3. Злоумышленник может получить полезную информацию о внутренностях вашего сайта, чтобы использовать ее для других методов взлома. Я периодически наталкиваюсь на сайты, которые выводят дампы SQL запроса в случае сбоя — выглядит «несколько непрофессионально», как вежливо говорит один наш заказчик :)
Как вариант, можно поставить обработчик Application_Error и гарантированно логировать там все необработанные ошибки + перенаправлять на страницу «Сбой на сайте». Только нужно учитывать, что для ASP.NET 404 ошибка — это то же исключение. Такие ошибки нужно выделять и перебрасывать на другую страницу, которая вернет 404 код (для поисковых серверов), но будет содержать нормальный html код «Страница не найдена» для посетителей.
Очень впечатляет. Правда, после объявления шаха алгоритм почему-то отказывался ходить — наверное ждал, пока я сделаю более подходящий ход.
Кстати дождался. Когда я решил, что он завис и стал кликать мышкой — быстренько походил туда моим ферзем и сразу же его съел.
Валидацию по схеме религия использовать не позволяет?
Если использовать запятую в качестве разделителя или передавать пустое значение — валидация все равно проходит успешно, а данные просто перестают отображаться. Так что дело, к сожалению, не в религии.
Неплохая статья, но вроде и много написано, но как-то очень уж поверхностно.
Каждый старается как-то соблюсти баланс между объемом и читабельностью. Когда я добавлял Pivot в проект — помечал, что я делаю и с чем приходилось разбираться — эти шаги и перечислил в статье + дал ссылки на материалы, которые мне помогли.
Начни я, скажем, подробно описывать, что такое Facets и как их лучше подобрать для конкретного варианта — статья превратилась бы в методичку на десяток страниц, а лучше чем в документации это все равно не сделаешь.
Но со стороны виднее, что по вашему стоило бы включить в описание, чтобы стало полезнее, но не слишком увеличилось в объеме?
Я добавил топик, в котором постарался описать реальное использование Pivot. Во второй части перечислены случаи, когда я «сворачивал с асфальтированной дорожки» и причины этих блужданий :)
Когда я формировал коллекцию, мне хватило описания из хабротопика Создаем за 10 минут PivotViewer контента сайта на примере Хабрахабр. Так что во второй части я собирался описать, что можно использовать и просто на нее сослаться.
Если есть что добавить к «Создаем за 10 минут...» — конечно пишите, интересно.
Соглашаясь или возражая, важно помнить, что любая любой выбор хорош или плох только в конкретном контексте, а не в общем.
Например, это хорошо, если:
а) Вы уверены в человеке и знаете, что он действительно тратит время не зря
б) В любой момент у вас есть текущие оценки по времени, например «еще день занимаюсь анализом, потом нужно принимать решение, стоит ли изучать проблему дальше, менять постановку или план». Иначе проект может завалить все сроки.
в) Есть какое-то управление рисками. Во время планирования вы учли, что вот тут есть N темных пятен, с ними могут возникнуть проблемы, поэтому нужно заложить на 30% больше времени (или провести research, а потом уточнить сроки).
Это плохо, если:
а) У вас есть план итерации, скажем на 2 недели. Вы просто не можете позволить себе ждать неделю, не зная возможных последствий по времени. Часто, только заказчик может оценить, стоит ли какая-то возможность этой недели или нет. Возможно, давно пора:
— изменить постановку и уйти от проблемы, пусть даже ценой уменьшения функциональности;
— вынести задачу в следующую итерацию, чтобы успеть с другими задачами;
— согласовать с заказчиком изменения сроков (ну да, не для всех agile методологий сроки итераций священны :)
б) Программист может не найти простого решения «а» и увлечется способом «б», который как раз и потребует дополнительного анализа, изучения матчасти и пр. При этом ему вообще может не прийти в голову, что есть простой вариант, так что вы узнаете о всем этом только через неделю
в) Программист столкнулся с проблемой, не может ее решить, но отчаянно тратит на это время, не обращаясь за помощью, так как боится, что остальные решат, что он плохой программист (мы же говорим не об идеальной, а реальной команде, верно?).
Правила, которым стараюсь следовать я:
а) Если у кого-то не получается разобраться с проблемой в течении X часов (X зависит от типа проекта и жесткости плана) — ему нужно прерваться и обсудит это с другими. Если ваши итерации 2-3 недели — хорошо подходят утренние stand-up митинги (т.е. X = 1 день).
б) План всегда должен быть актуальный. В него постоянно могут вносится изменения, но:
— «разбираюсь, не трогай меня, я сам приду и спрошу, когда будут проблемы» — неправильный вариант
— «разбираюсь еще X часов, потом по результатам примем решение: разбираться дальше, менять постановку или сдвигать сроки» — правильный вариант
Иначе вписаться в сроки и оставить довольным заказчика будет крайне трудно.
Вряд ли кто-то серьезно рассчитывает создать абсолютный фильтр. Спасает так называемый «барьер» — небольшие усилия помогают отстеять огромную массу любителей-спамеров. Дальше повышать барьер сложнее и процент отсеянных спамеров увеличивается намного медленнее. Главное — решить, где остановиться.
На примере: фильтровал я как-то комментарии на сайте развлекательной тематики. Простой список стоп-слов позволили заблокировать процентов 90 нарушителей. После того как я перед проверкой стал удалять все символы кроме букв и цифр (тем самым отсекая варианты типа «В_И_А_Г_Р_А» или «Виа(гра)»), стало отсеиваться 98%. Остальные проверки были совсем специфическими и добавлялись на конкретные случаи, под настроение. В принципе, это — вариант, на котором можно остановится, все остальное пока проще изредка вычищать вручную.
Отличный пост, ребята хорошо оторвались!
Но все зависит от условий. Есть ситуации, когда такое предложение вполне разумно.
Мы, например, принимаем запросы от тех.отдела, который эксплуатирует наш софт. Т.е. запросы эти намного адекватнее и «ржунимагу» там не встречается :)
Вот среди них добрая половина маякует о том, что что-то можно улучшить.
Только нужно еще не забывать оценивать, что выгодней (по деньгами и репутации): исправить или продолжать отвечать на подобные запросы и потратить время на что-то другое.
Не обязательно то же самое будет у большинства пользователей.
В моем случае: выделенка 2 Mbps, в клиенте штук 50 файлов. Когда торрент клиент открыт, страницы грузятся намного медленее, открываются по 10-15 секунд. Так что когда мне нужно работать, клиента прихдится отключать.
Возможно это как-то регулируется в настройках. Но у меня все стоит по умолчанию, думаю так поступает основная масса пользователей.
Если понадобятся диаграммы посложнее, можно использовать "Microsoft Chart Controls". Появлися в конце прошлого года, бесплатен, работает под ASP.NET и Windows Forms, куча разных диаграмм, локализация, AJAX и еще много чего. Если кто помнит — это бывшие «Dundas Data Visualization controls», которые Microsoft переработало и будет поставлять с .NET Framework 4.0.
Единственное серьезное ограничение — нужен .NET Framework 3.5 SP1. Так что тут — как повезет с проектом.
>>> «Другая распространенная «болезнь» ссылок — ссылки на странице на саму себя.»
Сейчас есть много страниц, работающих через AJAX или просто содержащих большое количество скриптов (особенно для визуальных эффектов). Бывает походишь по такой странице, она что-то свернет, что-то выведет, что-то через AJAX обновит в списке — потом очень хочется сбросить все это к чертовой матери и вернуться к первоначальному виду.
Вот тут и начинаешь кликать по меню или «пути по сайту» — удобно, когда он остался ссылкой, а не стал простым текстом.
Вы написали статью о том, что «плохо, когда начальник реально не понимает преимуществ внедрения» — тут можно только согласиться. Точка. Но статья написана хорошо, так что обсудить хочется :)
Поэтому народ с энтузиазмом стал обсуждать чуть другое: «а может начальник понимает, а не понимает как раз программист» — тут вариантов намного больше, так что и обменяться мнениями интереснее.
Так что спасибо за интересный пост, было бы написано что-то левое или однозначно неправильное — разве его бы так обсуждали?
Все правильно, согласен. Могут оказаться, могут повысить. Главное — чтобы это «могут» кто-то правильно оценил. Вряд ли по такому короткому рассказу без тех. деталей мы сможем понять «могут» или «не могут».
История написана очень «идеально» (возможно просто, чтобы ясно показать проблему), так что я всего лишь хотел напомнить старую как мир истину — если что-то кажется тебе глупым и нелогичным — возможно ты просто чего-то не знаешь (хотя бывает, что это просто глупо и нелогично :).
Когда у программиста «сверкают грани», а начальник — «таджик» — все понятно и обсуждать нечего.
Но бывает и по другому:
1. Пока программист работает на кого-то, его задача — выполнять работу, приносящую прибыль. Он не рискует деньгами и не ему решать, чем важнее заниматься, исправлением ошибки, которая может принести X убытка или созданием новой функциональности, которая может принести Y прибыли. Если он считает, что может оценить это лучше работодателя — чудесно, пусть открывает собственное дело.
2. «Часто программисты, предоставленные самим себе скатываются от разработки полезных вещей к разработке прикольных хреновин. После чего им перестают платить и они умирают с голода» (к сожалению сейчас не вспомню, откуда эта цитата).
Хочется верить, что у герою этого поста, написанного ярко и от души, просто не везло с начальниками…
Про технологии старых 3D рассказать не смогу, но могу сравнить впечатления о просмотре. Когда-то смотрел 3D фильмы «Челюсти» и какой-то триллер о чудовище из озера.
Настоящих 3-х мерных сцен было буквально несколько, причем, как правило, только в центре экрана. Сами фильмы были более «блеклые» (то ли глаза уставали, то ли еще что-то) чем их аналоги на обычной пленке.
В «Монстры против Чужих» — яркое, сочное, очень четкое трехмерное изображение.
Правда стоит учитывать еще пару вещей:
1. Оборудование в IMAX на порядок лучше: сферический экран 22 x 16 метров (у нас в Киеве чуть меньше, высота 12,5), 70 мм пленка (кадры на пленке идут горизонтально, чтобы как-то поместиться), разрешение 10000×7000 пикселей, 2 проектора, которые прокручивают пленки, снятые 2-я камерами, поляризационные очки (а не цветные стекла), 6-ти канальный звук Proportional Point Source, который записан без компресии.
2. Снять 3D мультик все таки легче, чем фильм. Окончательно сравнить впечатления можно будет, когда в прокате пойдет следующий Гарри Поттер. Там обещают минут 30 трехмерных сцен.
Недавно был в IMAX, смотрел «Монстры против Чужих», мультик в 3D. Очень впечатлило, ради таких фильмов опять буду выбираться в кино. Так что если очки будут давать качественную картинку, а цены со временем снизятся до общедоступных — думаю очень даже будет нужно.
LINQ2SQL и Entity Framework — классический пример того, что инструмент облегчает жизнь, только если его использовать по назначению. Попробуешь L2S в сложных проектах — код обрастет костылями и подпорками для недостающей функциональности. Ну и наоборот, EF в простом проекте — сойдешь с ума, разбирая нюансы маппинга, когда тебе всего-то нужно сделать выборку из нескольких таблиц одной хранимой процедурой.
Хороший пример — мои последние проекты. Первое — простое web приложение. В основном отображает данных по разным условиям плюс чуть-чуть редактирования. LINQ2SQL пошел на ура, кода в несколько раз меньше чем при создании классических слоев хранимых процедур и Data access layer. А вот текущий проект уже сложнее, плюс клиентская часть должна работать в отсоединенном режиме. Вот тут EF + ADO.NET Data Services + Astoria Offline должны сэкономить кучу времени.
Правда перед этим прийдется потратить не меньшую кучу, чтобы со всем этим разобраться :)
Да, для запрета индексации лучше использовать robots.txt.
Но и «nofollow» тоже полезны — они не позволяют ссылочному весу утекать на ненужные нам страницы.
Мне нравится — позволит посетителям Вашего сайта не только выразить своё отношение к статье одним кликом, но также поделиться ссылкой на неё с друзьями, даже если они не считают необходимым оставлять комментарий.
Share позволяет существенно увеличить посещаемость Вашего сайта, предоставляя Вашим читателям возможность удобно делиться ссылкой на Ваши материалы. Каждый раз, когда пользователь делится статьей, ссылка на нее появляется на его странице, а также в новостях у его друзей.
Нужно четко понимать, что значит «поделиться ссылкой» в обоих случаях:
Главный вопрос: если у вас был Share, стоит ли его заменять на новый Like? (конечно, можно использовать оба, но мне кажется это только запутает пользователя; тем более обычно рядом нужно пристроить кнопки других сетей, т.е. кнопок будет много).
Конечно, отсутствие каптчи стоит многого. Но только в случае, если люди будут выбирать вторую галочку «рекомендовать друзьям». Плюс заменив виджет вам нужно будет опять накапливать счетчик, который выводится рядом (когда он уже большой, людям психологически проще тоже на него нажать).
Новая кнопка сделана в стиле а-ля Facebook, а идеология Facebook мне нравится больше. Лично я — попробую.
1. Пользователю абсолютно ничего не говорят сообщения об ошибках, которые он увидит.
2. Мало того, у него появляется ощущение, что сайт ненадежный. Общая фраза «На сайте произошел сбой, дайте нам немного времени, чтобы мы могли его устранить» создает впечатление хоть какого-то контроля над ситуацией.
3. Злоумышленник может получить полезную информацию о внутренностях вашего сайта, чтобы использовать ее для других методов взлома. Я периодически наталкиваюсь на сайты, которые выводят дампы SQL запроса в случае сбоя — выглядит «несколько непрофессионально», как вежливо говорит один наш заказчик :)
Как вариант, можно поставить обработчик Application_Error и гарантированно логировать там все необработанные ошибки + перенаправлять на страницу «Сбой на сайте». Только нужно учитывать, что для ASP.NET 404 ошибка — это то же исключение. Такие ошибки нужно выделять и перебрасывать на другую страницу, которая вернет 404 код (для поисковых серверов), но будет содержать нормальный html код «Страница не найдена» для посетителей.
Кстати дождался. Когда я решил, что он завис и стал кликать мышкой — быстренько походил туда моим ферзем и сразу же его съел.
Если использовать запятую в качестве разделителя или передавать пустое значение — валидация все равно проходит успешно, а данные просто перестают отображаться. Так что дело, к сожалению, не в религии.
Каждый старается как-то соблюсти баланс между объемом и читабельностью. Когда я добавлял Pivot в проект — помечал, что я делаю и с чем приходилось разбираться — эти шаги и перечислил в статье + дал ссылки на материалы, которые мне помогли.
Начни я, скажем, подробно описывать, что такое Facets и как их лучше подобрать для конкретного варианта — статья превратилась бы в методичку на десяток страниц, а лучше чем в документации это все равно не сделаешь.
Но со стороны виднее, что по вашему стоило бы включить в описание, чтобы стало полезнее, но не слишком увеличилось в объеме?
Если есть что добавить к «Создаем за 10 минут...» — конечно пишите, интересно.
Например, это хорошо, если:
а) Вы уверены в человеке и знаете, что он действительно тратит время не зря
б) В любой момент у вас есть текущие оценки по времени, например «еще день занимаюсь анализом, потом нужно принимать решение, стоит ли изучать проблему дальше, менять постановку или план». Иначе проект может завалить все сроки.
в) Есть какое-то управление рисками. Во время планирования вы учли, что вот тут есть N темных пятен, с ними могут возникнуть проблемы, поэтому нужно заложить на 30% больше времени (или провести research, а потом уточнить сроки).
Это плохо, если:
а) У вас есть план итерации, скажем на 2 недели. Вы просто не можете позволить себе ждать неделю, не зная возможных последствий по времени. Часто, только заказчик может оценить, стоит ли какая-то возможность этой недели или нет. Возможно, давно пора:
— изменить постановку и уйти от проблемы, пусть даже ценой уменьшения функциональности;
— вынести задачу в следующую итерацию, чтобы успеть с другими задачами;
— согласовать с заказчиком изменения сроков (ну да, не для всех agile методологий сроки итераций священны :)
б) Программист может не найти простого решения «а» и увлечется способом «б», который как раз и потребует дополнительного анализа, изучения матчасти и пр. При этом ему вообще может не прийти в голову, что есть простой вариант, так что вы узнаете о всем этом только через неделю
в) Программист столкнулся с проблемой, не может ее решить, но отчаянно тратит на это время, не обращаясь за помощью, так как боится, что остальные решат, что он плохой программист (мы же говорим не об идеальной, а реальной команде, верно?).
Правила, которым стараюсь следовать я:
а) Если у кого-то не получается разобраться с проблемой в течении X часов (X зависит от типа проекта и жесткости плана) — ему нужно прерваться и обсудит это с другими. Если ваши итерации 2-3 недели — хорошо подходят утренние stand-up митинги (т.е. X = 1 день).
б) План всегда должен быть актуальный. В него постоянно могут вносится изменения, но:
— «разбираюсь, не трогай меня, я сам приду и спрошу, когда будут проблемы» — неправильный вариант
— «разбираюсь еще X часов, потом по результатам примем решение: разбираться дальше, менять постановку или сдвигать сроки» — правильный вариант
Иначе вписаться в сроки и оставить довольным заказчика будет крайне трудно.
На примере: фильтровал я как-то комментарии на сайте развлекательной тематики. Простой список стоп-слов позволили заблокировать процентов 90 нарушителей. После того как я перед проверкой стал удалять все символы кроме букв и цифр (тем самым отсекая варианты типа «В_И_А_Г_Р_А» или «Виа(гра)»), стало отсеиваться 98%. Остальные проверки были совсем специфическими и добавлялись на конкретные случаи, под настроение. В принципе, это — вариант, на котором можно остановится, все остальное пока проще изредка вычищать вручную.
Но все зависит от условий. Есть ситуации, когда такое предложение вполне разумно.
Мы, например, принимаем запросы от тех.отдела, который эксплуатирует наш софт. Т.е. запросы эти намного адекватнее и «ржунимагу» там не встречается :)
Вот среди них добрая половина маякует о том, что что-то можно улучшить.
Только нужно еще не забывать оценивать, что выгодней (по деньгами и репутации): исправить или продолжать отвечать на подобные запросы и потратить время на что-то другое.
В моем случае: выделенка 2 Mbps, в клиенте штук 50 файлов. Когда торрент клиент открыт, страницы грузятся намного медленее, открываются по 10-15 секунд. Так что когда мне нужно работать, клиента прихдится отключать.
Возможно это как-то регулируется в настройках. Но у меня все стоит по умолчанию, думаю так поступает основная масса пользователей.
Единственное серьезное ограничение — нужен .NET Framework 3.5 SP1. Так что тут — как повезет с проектом.
Сейчас есть много страниц, работающих через AJAX или просто содержащих большое количество скриптов (особенно для визуальных эффектов). Бывает походишь по такой странице, она что-то свернет, что-то выведет, что-то через AJAX обновит в списке — потом очень хочется сбросить все это к чертовой матери и вернуться к первоначальному виду.
Вот тут и начинаешь кликать по меню или «пути по сайту» — удобно, когда он остался ссылкой, а не стал простым текстом.
Поэтому народ с энтузиазмом стал обсуждать чуть другое: «а может начальник понимает, а не понимает как раз программист» — тут вариантов намного больше, так что и обменяться мнениями интереснее.
Так что спасибо за интересный пост, было бы написано что-то левое или однозначно неправильное — разве его бы так обсуждали?
История написана очень «идеально» (возможно просто, чтобы ясно показать проблему), так что я всего лишь хотел напомнить старую как мир истину — если что-то кажется тебе глупым и нелогичным — возможно ты просто чего-то не знаешь (хотя бывает, что это просто глупо и нелогично :).
Но бывает и по другому:
1. Пока программист работает на кого-то, его задача — выполнять работу, приносящую прибыль. Он не рискует деньгами и не ему решать, чем важнее заниматься, исправлением ошибки, которая может принести X убытка или созданием новой функциональности, которая может принести Y прибыли. Если он считает, что может оценить это лучше работодателя — чудесно, пусть открывает собственное дело.
2. «Часто программисты, предоставленные самим себе скатываются от разработки полезных вещей к разработке прикольных хреновин. После чего им перестают платить и они умирают с голода» (к сожалению сейчас не вспомню, откуда эта цитата).
Хочется верить, что у герою этого поста, написанного ярко и от души, просто не везло с начальниками…
Настоящих 3-х мерных сцен было буквально несколько, причем, как правило, только в центре экрана. Сами фильмы были более «блеклые» (то ли глаза уставали, то ли еще что-то) чем их аналоги на обычной пленке.
В «Монстры против Чужих» — яркое, сочное, очень четкое трехмерное изображение.
Правда стоит учитывать еще пару вещей:
1. Оборудование в IMAX на порядок лучше: сферический экран 22 x 16 метров (у нас в Киеве чуть меньше, высота 12,5), 70 мм пленка (кадры на пленке идут горизонтально, чтобы как-то поместиться), разрешение 10000×7000 пикселей, 2 проектора, которые прокручивают пленки, снятые 2-я камерами, поляризационные очки (а не цветные стекла), 6-ти канальный звук Proportional Point Source, который записан без компресии.
2. Снять 3D мультик все таки легче, чем фильм. Окончательно сравнить впечатления можно будет, когда в прокате пойдет следующий Гарри Поттер. Там обещают минут 30 трехмерных сцен.
Хороший пример — мои последние проекты. Первое — простое web приложение. В основном отображает данных по разным условиям плюс чуть-чуть редактирования. LINQ2SQL пошел на ура, кода в несколько раз меньше чем при создании классических слоев хранимых процедур и Data access layer. А вот текущий проект уже сложнее, плюс клиентская часть должна работать в отсоединенном режиме. Вот тут EF + ADO.NET Data Services + Astoria Offline должны сэкономить кучу времени.
Правда перед этим прийдется потратить не меньшую кучу, чтобы со всем этим разобраться :)
Но и «nofollow» тоже полезны — они не позволяют ссылочному весу утекать на ненужные нам страницы.