Честно говоря, первое впечатление - "Вау!". Затем попытка на пару минут погрузиться в эту атмосферу... и понимаешь, что работать на вокзале не слишком приятно...
Хотя, вполне возможно, что ньюсрум покажется выпускающим редакторам и эргономичным, и уютным. Всё познаётся в сравнении:-).
Поправьте меня, пожалуйста, если я неправ, но по логике при таком поиске результаты упорядочиваются лишь по мере убывания релевантности.
Для блогов же актуально упорядочивание результатов как по мере убывания релевантности, так и по мере убывания даты публикации. То есть интеграция поиска от Гугла на Хабре всё-таки нужна.
В настоящий момент Гугл не выводит рекламу в случае поиска по блогам.
Вопрос в том, как этот механизм реализован: считается ли Хабр блог-сайтом с точки зрения Гугла?
Существует компромиссный вариант, предполагающий две альтернативные возможности поиска по сайту:
с использованием собственного движка Хабра
с использованием движка Гугл
Разработчикам Хабра нужно будет всего лишь проинтегрировать Google AJAX Search API на страницу поиска, плюс доработать саму страницу поиска, сделав переключатель "хабрапоиск-гуглопоиск".
Я сегодня с утра работал у Заказчика и умудрился сделать, казалось бы, невозможное в последний рабочий день уходящего года: согласовать разработанное мной ТЗ (между прочим, 8 подписей!), у которого дедлайн истекает как раз сегодня.
И вот буквально пару минут назад с чувством выполненного долга залез на Хабр. И вновь приятно удивился: кому-то понравился мой пост про Новый Год:)
Спасибо вам, хабрадрузья! С наступающим!
Регулярка - это всего лишь просторечное сокращение термина "регулярное выражение". Пишутся регулярные выражения на специализированном языке регулярных выражений.
Этот язык был реализован ещё в древних Unix-машинах, но дожил до наших дней и с незначительными вариациями входит практически во все современные фреймворки в качестве библиотеки-модуля-сборки (нужное подчеркнуть).
Небольшая поправка к примеру с %username%.
У Вас так: ^Привет,%([a-z])%!$
а, хотели, Вы, видимо, всё же так: ^Привет,%([a-z]+)%!$
Вот, правда, не совсем понимаю, в чём смысл этого примера? В качестве обучающего примера для юноши он просто из рук вон, ибо абсолютно бесполезен на практике, да ещё и сложен для восприятия. Вообразите только: эта ваша "регулярка" (которая сама по себе шаблон) должна вылавливать где-то строки-шаблоны приветствий в форме "Привет, %бла-бла-бла%!".
А чтобы сделать из этой регулярки что-нибудь полезное, её придётся сильно усложнить.
IMHO, автор поста хочет отбить интерес к регуляркам у "чайников"!:-)
Ознакомился подробно, несмотря на обилие букв даже во 2-й редакции. Есть одно небольшое пожелание к автору.
Дополните, пожалуйста, ваше блистательное обличение дилетанта Сатина фразой Карету мне, карету! — не для одного лишь придания законченности изложению, но дабы соблюсти все необходимые условности, налагаемые законами жанра эмоциональной критики.
С этим полностью согласен, просто речь шла о первой встрече. Тут бы с предметной областью разобраться и попросту зафиксировать понятия, не вдаваясь в детали, об атрибуте или взаимосвязанной сущности идет речь.
Как правило, после первой встречи я обязательно подготавливаю диаграмму сущность-связь, где фиксирую свое видение предметной области. Эту диаграмму можно обсудить со специалистом со стороны Заказчика.
Как показывает практика, лицо, принимающее решение, обычно слабо разбирается в предметной области. Приходится самому анализировать, докапываться, додумывать, а потом предварительный артефакт - составленную диаграмму - выкатывать Заказчику для обсуждения. В этом случае Заказчик гораздо охотнее организует вторую встречу (с участием специалистов предметной области), а там уже и до проекта недалеко:-)
Ваш подход к спецификации требований тоже работает, но, на мой взгляд, на первой встрече малоприменим. В том числе и потому, что если Вы зададите Заказчику слишком много вопросов по предметной области, на которые он не сможет ответить, то тем самым можете выявить его некомпетентность и оставить в итоге у него неприятный осадок. Чисто психологически неприятный. Никаких объективных преград для обсуждения сущностей "с места в карьер" не существует.
Вероятность того, что я не смогу взять свой крошечный VAIO на встречу с заказчиком, пренебрежимо мала:-)
Как правило, Заказчик искренне заинтересован в проекте, но т.к. вы этот проект ещё не получили, он скорее примеривается к Вам, как к потенциальному исполнителю, нежели горит желанием рассказать о сущностях, взаимосвязях, атрибутах, версионности, графическом интерфейсе пользователя и т.п.
По собственному опыту, в первую очередь Заказчика интересует, насколько точно и полно вы с ним описали требования и пожелания к системе, предложили ли вы ему своё видение бизнес-сценариев работы пользователя с приложением и т.п.
Для этого идеально подходят карты памяти; каким образом их использовать - описано в первом комментарии.
В большинстве случаев Заказчик попросту не готов к проведению длительной и содержательной встречи до начала проекта. Поэтому в своей практике я использую интеллектуальные карты памяти (Mind Maps) для фиксации основных обсуждавшихся моментов.
Исходные вопросы к Заказчику и все интересующие меня моменты предварительно фиксируются в карте памяти. Во время встречи (в идеале) достаточно лишь добавлять информацию к существующему, заранее подготовленному шаблону карты памяти.
На моей памяти не было ещё ни одного случая, когда в ходе предварительной встречи с Заказчиком у меня было бы достаточно времени для рисования полноценных диаграмм UML, хотя бы на уровне вариантов использования, не говоря уже о диаграммах классов.
Идею персональных черных списков поддерживаю. Также мне нравится идея "тёмной стороны" Хабра, на которую ссылаются пользователи с кармой <50. Предлагаю эти идеи объединить следующим образом:
Сделать кнопку "убрать хабратролля" рядом с плюсованием/минусованием за комментарии.
В Хабрацентре создать раздел "Управление хабратроллями", чтобы иметь возможность удалить из чёрного списка пользователя, признанного хабратроллем по ошибке
Позволить хабратроллям видеть твои комментарии и отвечать на них, но поскольку ты их комментарии видеть не будешь, сработает простое эмпирическое правило и в результате все общепризнанные хабратролли, желающие общаться друг с другом, образуют собственный кластер внутри Хабра. Это и будет DarkSide - "тёмная сторона" Хабра.
Мне кажется, что автор данной статьи вместо того, чтобы предложить краткое и продуманное решение проблемы невежливого оператора и "тормозного" софта, написал много букв о "теоретическом юзабилити". Предлагаю свой вариант статьи.
Проблема
97% звонков операторов нашего call-центра заканчиваются отрицательным результатом - в базе данных отражен факт звонка, но отсутствуют результаты опроса респондента
[Здесь размещается стенограмма типичного звонка]
Задача
Повысить процент положительных звонков хотя бы до 10%
Для оперативного решения проблемы тупых операторов и медленного софта нужно организовать регистрацию звонков в 2 этапа:
на первом этапе оператор call-центра задает вопросы респонденту и получает от него ответы, возможно, задает уточняющие вопросы, благодарит респондента
на втором этапе запись разговора с респондентом обрабатывается (возможно, другим оператором), при этом в базу данных CRM заносятся результаты общения оператора с респондентом
Сформировать запрос к БД нашей CRM, выводящий статистику по звонкам, сгруппированную по операторам и отсортированную в порядке убывания результативности их работы.
По результатам запроса:
Наиболее тупых операторов уволить
Проанализировать записи разговоров с клиентами наиболее успешных операторов, совместно с психологом выявить типичные ошибки в общении операторов с клиентами, разработать соответствующий мануал
Проводить такой анализ результативности еженедельно. Это позволит непрерывно отслеживать результаты работы операторов call-центра. В перспективе можно разработать более сложную систему мотивации операторов, включающую элементы как наказания, так и поощрения
Непонятно, зачем нужно было так много букв для того, чтобы описать такое простое (если не сказать, тривиальное) решение проблемы?
Обычно я сталкиваюсь с подобными статьями (пространность, бессодержательность, красивые картинки, НО при этом четко поставленная проблема или задача), когда речь идет о маркетинговых материалах.
Такие материалы, как правило, готовятся с одной целью: заинтересовать заказчика интересной проблемой, чтобы затем запудрить ему мозг и подороже продать свой продукт или услугу.
О программном сбое подумал в связи с дефейсом 22 января
Хотя, вполне возможно, что ньюсрум покажется выпускающим редакторам и эргономичным, и уютным. Всё познаётся в сравнении:-).
Для блогов же актуально упорядочивание результатов как по мере убывания релевантности, так и по мере убывания даты публикации. То есть интеграция поиска от Гугла на Хабре всё-таки нужна.
Вопрос в том, как этот механизм реализован: считается ли Хабр блог-сайтом с точки зрения Гугла?
- с использованием собственного движка Хабра
- с использованием движка Гугл
Разработчикам Хабра нужно будет всего лишь проинтегрировать Google AJAX Search API на страницу поиска, плюс доработать саму страницу поиска, сделав переключатель "хабрапоиск-гуглопоиск".И вот буквально пару минут назад с чувством выполненного долга залез на Хабр. И вновь приятно удивился: кому-то понравился мой пост про Новый Год:)
Спасибо вам, хабрадрузья! С наступающим!
Этот язык был реализован ещё в древних Unix-машинах, но дожил до наших дней и с незначительными вариациями входит практически во все современные фреймворки в качестве библиотеки-модуля-сборки (нужное подчеркнуть).
У Вас так:
^Привет,%([a-z])%!$а, хотели, Вы, видимо, всё же так:
^Привет,%([a-z]+)%!$Вот, правда, не совсем понимаю, в чём смысл этого примера? В качестве обучающего примера для юноши он просто из рук вон, ибо абсолютно бесполезен на практике, да ещё и сложен для восприятия. Вообразите только: эта ваша "регулярка" (которая сама по себе шаблон) должна вылавливать где-то строки-шаблоны приветствий в форме "Привет, %бла-бла-бла%!".
А чтобы сделать из этой регулярки что-нибудь полезное, её придётся сильно усложнить.
IMHO, автор поста хочет отбить интерес к регуляркам у "чайников"!:-)
Дополните, пожалуйста, ваше блистательное обличение дилетанта Сатина фразой Карету мне, карету! — не для одного лишь придания законченности изложению, но дабы соблюсти все необходимые условности, налагаемые законами жанра эмоциональной критики.
Как правило, после первой встречи я обязательно подготавливаю диаграмму сущность-связь, где фиксирую свое видение предметной области. Эту диаграмму можно обсудить со специалистом со стороны Заказчика.
Как показывает практика, лицо, принимающее решение, обычно слабо разбирается в предметной области. Приходится самому анализировать, докапываться, додумывать, а потом предварительный артефакт - составленную диаграмму - выкатывать Заказчику для обсуждения. В этом случае Заказчик гораздо охотнее организует вторую встречу (с участием специалистов предметной области), а там уже и до проекта недалеко:-)
Ваш подход к спецификации требований тоже работает, но, на мой взгляд, на первой встрече малоприменим. В том числе и потому, что если Вы зададите Заказчику слишком много вопросов по предметной области, на которые он не сможет ответить, то тем самым можете выявить его некомпетентность и оставить в итоге у него неприятный осадок. Чисто психологически неприятный. Никаких объективных преград для обсуждения сущностей "с места в карьер" не существует.
Как правило, Заказчик искренне заинтересован в проекте, но т.к. вы этот проект ещё не получили, он скорее примеривается к Вам, как к потенциальному исполнителю, нежели горит желанием рассказать о сущностях, взаимосвязях, атрибутах, версионности, графическом интерфейсе пользователя и т.п.
По собственному опыту, в первую очередь Заказчика интересует, насколько точно и полно вы с ним описали требования и пожелания к системе, предложили ли вы ему своё видение бизнес-сценариев работы пользователя с приложением и т.п.
Для этого идеально подходят карты памяти; каким образом их использовать - описано в первом комментарии.
Исходные вопросы к Заказчику и все интересующие меня моменты предварительно фиксируются в карте памяти. Во время встречи (в идеале) достаточно лишь добавлять информацию к существующему, заранее подготовленному шаблону карты памяти.
На моей памяти не было ещё ни одного случая, когда в ходе предварительной встречи с Заказчиком у меня было бы достаточно времени для рисования полноценных диаграмм UML, хотя бы на уровне вариантов использования, не говоря уже о диаграммах классов.