> после того, как мы пересели на Hadoop, многие из наших программистов познакомились с Java
Это был обмен опытом между отделами/подразделениями, или массовое переобучение имеющихся специалистов? Если второе — было бы интересно почитать про такой опыт.
Название внутри всё равно сомнительная практика:
Если есть оба — до заполнения выглядит по-дурацки
Беглым взглядом не видны пустые поля — там всегда что-то написано
На практике ещё и реализация, бывает, хромает.
Пример с колл-центром совершенно не впечатлил.
На предыдущей работе был КЦ для себя и сторонних клиентов. И там всё как бы наоборот:
Ответы по памяти не поощряются — т.к. нужно выдавать актуальную информацию — всё по алгоритму, по базе знаний.
Скорость ответа… Время в эфире — это наиболее явный показатель работы оператора. Никому не нужно, чтобы он перебивал, быстро тараторил и т.п. Я уже не говорю про внешних клиентов, которые в итоге за время платят. Оператор в типовом сценарии вообще не может инициировать завершение разговора.
На тематику разговора операторы так же обычно не могут влиять.
Т.е. вся приведённая игровая стимуляция либо работает против, либо просто случайная лотерея.
Есть ещё такая замечательная концепция, как «архивирование».
Часто для домашнего пользователя его вполне достаточно: слил фотки на компьютер, записал на DVD/внешний HDD, убрал на полочку.
Утверждения «не умеет писать код на языке БД» и «не понимает как БД работает» — утверждения практически идентичные — реально одно без другого немыслимо. Писать СУБД должны люди, которые понимают, что такое БД. Иначе настроят чугуниевых велосипедов, которые не ездят.
это октет — всегда восемь бит,
байт — это минимально адресуемая единица памяти
word — в существующих реалиях — вообще непонятно что — наверное, разрядность самых частоиспользуемых регистров :-)
> мы так и не отважились выделять письма по нажатию на Ctrl, поскольку побоялись перебить стандартный браузерный шорткат для открытия ссылки в новой вкладке. Возможно, в скором будущем мы решимся и на это, ведь уже всеми интерфейсными средствами показали, что элементы в списке писем — не ссылки
Не совсем понятно такое стремление. Лично знаю массу пользователей, которые в глаза не видели почтовый клиент (десктопную программу). Вместо того, чтобы учитывать среду, разработчики интерфейсов web-mail стремятся нагородить велосипедов — реализовать в web'е несвойственное ему поведение.
В результате получается «вещь в себе» на которой не работают стандартные эффекктивные приёмы работы, и необходимо изучать/запоминать специфичные для конкретного сайта паттерны поведения.
В моём понимании «обалденная звонилка» должна ещё и адресную книгу нормальную иметь на борту. Подавляющее количество простых телефонов ничего адекватного предложить не могут. Я про синхронизацию, несколько номеров, длинное поле для адреса и т.п.
А как вы определили, что «find вообще не работал»? — сверяли количество файлов до и после?
Я сталкивался с аналогичной ситуацией. find, конечно, основательно загружал систему, некоторые запущенные фоновые службы не отвечали по сети. Но find свою работу делал — файлы удалялись.
Это был обмен опытом между отделами/подразделениями, или массовое переобучение имеющихся специалистов? Если второе — было бы интересно почитать про такой опыт.
Если есть оба — до заполнения выглядит по-дурацки
Беглым взглядом не видны пустые поля — там всегда что-то написано
На практике ещё и реализация, бывает, хромает.
На предыдущей работе был КЦ для себя и сторонних клиентов. И там всё как бы наоборот:
Ответы по памяти не поощряются — т.к. нужно выдавать актуальную информацию — всё по алгоритму, по базе знаний.
Скорость ответа… Время в эфире — это наиболее явный показатель работы оператора. Никому не нужно, чтобы он перебивал, быстро тараторил и т.п. Я уже не говорю про внешних клиентов, которые в итоге за время платят. Оператор в типовом сценарии вообще не может инициировать завершение разговора.
На тематику разговора операторы так же обычно не могут влиять.
Т.е. вся приведённая игровая стимуляция либо работает против, либо просто случайная лотерея.
Часто для домашнего пользователя его вполне достаточно: слил фотки на компьютер, записал на DVD/внешний HDD, убрал на полочку.
> Я знаю язык запросов. Я не умею писать хранимые процедуры.
Выходит, вы не знаете язык запросов.
Точно так же как то, что я когда прочитал Страуструпа, и могу матрицы на C++ перемножить, не говорит, что я знаю C++
байт — это минимально адресуемая единица памяти
word — в существующих реалиях — вообще непонятно что — наверное, разрядность самых частоиспользуемых регистров :-)
Не совсем понятно такое стремление. Лично знаю массу пользователей, которые в глаза не видели почтовый клиент (десктопную программу). Вместо того, чтобы учитывать среду, разработчики интерфейсов web-mail стремятся нагородить велосипедов — реализовать в web'е несвойственное ему поведение.
В результате получается «вещь в себе» на которой не работают стандартные эффекктивные приёмы работы, и необходимо изучать/запоминать специфичные для конкретного сайта паттерны поведения.
Я сталкивался с аналогичной ситуацией. find, конечно, основательно загружал систему, некоторые запущенные фоновые службы не отвечали по сети. Но find свою работу делал — файлы удалялись.