Все относительно: за неделю, пока вы будете "покупать кроссовки", вам накапают обзорами и отзывами так, что вы неимпульсивно, не спеша, выберите именно рекламируемую модель.
Но когда будете заказывать *.такси, суши, пиццу с аккумулятором на 5% не удивляйтесь, что стоимость будет выше обычной.
И потом светится у тебя "1", а у тебя десятки групп, которые ты сам отсортировал по значимости, и ползаешь туда-сюда, ищешь, где это одно непрочитанное сообщение.
А без ваших глупостей оно будет на самом верху, сразу под закрепленным чатами.
Проходили уже этот ваш UX в ICQ, &RQ, ранней версии Skype.
Я говорю не об обработке ошибок, а о том, чтобы ваш планировщик не падал из-за критической ошибки в запускаемой задаче, оставаясь независимым предсказуемым участником системы
закладывать их вероятность при разработке это дикость
Это не дикость, а выбор паттерна поведения в случае непредвиденной реакции окружения ("обрушилась" база, подключение, недостаточно памяти, не был получен семафор и т.д.). В том числе выход из процедуры с ошибкой, завершение приложения с кодом ошибки и проч — такое встречается повсеместно, а в некоторых системах "обрушение" и вовсе приветствуется, как гарантированная остановка приложения — все зависит от целей, бизнес-процесса, принятых норм, а также соответствия уровню качества (доверия), который был выбран, исходя из целей по рентабельности кода, а также всей системы, частью которой эта Job является.
"а давайте его веревками к стропилам привяжем, вдруг обрушится"
Холодное и горячее резервирование систем вам чуждо, я так полагаю.
Простейшее решение в виде запуска задачи в независимом/слабозависимом потоке легко решит вопрос и сделает логику планировщика предсказуемой в этой части.
Зона ответственности планировщика — выполнять задания по плану гарантированно и предсказуемо (без неоднозначности).
Вопрос: если одно из заданий "рушится" — а это ожидаемое с некоторой долей вероятности (в зависимости от заявленного качества ПО в соответствии с ISO 9000, раз уж мы тут про "по существу") — планировщик может гарантировать, что не упадет сам и выполнит следующее в очереди задание, независимо от "результатов" предыдущего?
Если все-таки он рушится вместе с заданием, откуда он начнет выполнение заданий со следующим запуском: с начала или с момента аварийной остановки?
Что случится при запуске двух и более копий планировщика?
Правильно понимаю, что любой fatal error тихо положит планировщик со всеми задачами на неопределенном этапе выполнения?
Контроля запуска дубликатов тоже не увидел.
Насколько помню, такой велосипед (раз уж есть доступ до cron-a) реализовывался ранее всегда через демон-подобный вечный скрипт с pid.lock файлом для контроля запуска дублей, полной обработкой всех ошибок, чтобы жить как можно дольше или предсказуемо падать при первой возможности, а также реакцией на принудительное завершение через sig9 — в друпале, джумле, вордпрессе и пр.
Нет четкого разделения ответственности: за дубликаты задач должны отвечать сами задачи, но в то же время ваш планировщик зачем-то хранит в памяти кучу вывода из этих самых задач. В таком вопросе обычно либо все, либо ничего — нужно четко определять границы обслуживания, иначе либо задача пишется, подразумевая использование именного вашего планировщика (отсутствует эффект drop-in replacement), либо допиливать каждый раз через обертки ваш интерфейс, что делает продукт менее интересным.
Ответив на письмо из рассылки "как вам наш продукт?" можно получить авто-ответ, что сотрудник в отпуске (без пересылки дальше). "Thanks for your email. I am out of office until August, 11 and will respond to you once I'm back." — с кем связываться дальше, если хочешь получить адекватный ответ не через неделю, непонятно. Но (как далее выяснилось после пересылки на общий ящик) сотрудников, кто может ответить — толпа.
"Sorry for auto email. It's our way of keeping in contact during the trial. Also during the holiday season sometimes our team take holidays." Вот мне, как потенциальному клиенту, вообще начхать, кто там у вас куда берет holidays, я хочу ответы на свои вопросы и "take my money", а не вот это вот все.
При каждом входе страница перезагружается несколько раз, показывая разный набор задач (пусто, тестовые и только потом те, которые принадлежат учетной записи), а затем перезагружается снова и просит указать свой мобильный номер. Не знаю, какой ад творится после приобретения подписки, но этого достаточно, чтобы даже не думать о покупке. перепроверил: оно все еще себя так ведет, даже после всех ваших митапов.
Работать с двумя и более задач невозможно, так как каждое переключение между ними — долгий Ajax-запрос. Не знаю, кто вам сказал, что Comet-подобный подход — это плохо, но сравните с отзывчивостью интерфейса в той же asana.
Та же ситуация с вложенными задачами: проваливаться в каждую подзадачу — это сплошные унижения и боль. При том, что "задача" — это самый используемый и вообще главный компонент всей вашей системы (к черту графики и отчеты с оповещениями, если основной продукт потребления заставляет страдать).
Боюсь даже представить, чему вы учите на своем митапе по UX.
Приходить на митап по UX к тем, кто не может сделать отзывчивый удобный интерфейс?
У вас каждая кнопка — это долгий Ajax-запрос, о каком UX вы можете разговаривать?
Правильно понимаю, что под "большими данными" здесь понимается не просто любая база данных, превышающая N Петабайт, а объем обезличенных данных, статистически достаточный для того, чтобы считать их персданными?
«Как нужно было сделать» — это личное дело каждой компании. В случае, описанном в посте, явный косяк со стороны сотрудника — в том числе и в выборе компании с такими правилами.
По части рабочих ресурсов: частый фрод(в т.ч. фишинг) и гадости вроде социальной инженерии происходят именно в социальных сетях и персональных почтовых ящиках, так как доверие к получателю с именем друга/родственника, неаккуратно позволившего взломать свою учетную запись, сильно выше, и если почта и каналы корпоративной связи (внутренние мессенджеры, CRM и пр.) защищены, то возможность получения ссылки и прочих вредоносов через неограниченное количество ресурсов (доступ до которых может быть получен в т.ч. в обход корпоративных фильтров) значительно расширяет площадь направленной атаки на компанию.
Ресурсы, которые потребуются на защиту таких масштабов при сохранении работоспособности сотрудника, быстрого доступа в сеть и достаточных свободных мощностей АРМ (после установки всех необходимых фильтров и агентов), могут оказаться несоизмеримыми с пользой, которую приносит такой сотрудник.
Решение ЕСПЧ однобокое, и то, что личка и работа "размазываются" должно делать осторожным и включать мозг не только работодателя, но и сотрудника, что несет ответственность за риски, которые добавляет своим безалаберным отношением к правилам компании (вне зависимости от причины их введения).
Имхо, толкать эту телегу нужно в сторону "если сотрудник хочет личку в рабочем окружении — пусть с собой тащит личный девайс с гостевым/отдельным доступом в сеть", неся полную ответственность за последствия и снижение KPI.
А доступ в соц.сети работодателем дается исключительно по желанию в рамках "пакета с печеньками и бонусов при работе в его компании", при этом административный запрет правилами компании — это такая же мера, что и технические ограничения, сбор данных и проч., и само наличие таких правил, объяснили сотруднику, как будут читать его переписки, или нет, должно трактоваться, как ограничение ответственности работодателя в случае нарушения их сотрудником...
Вы комментарий к топику в стиле "а я использую -ххх- и мне норм" оставили ради пука в воду, и отвечать на него не нужно, выискивая полезный смысл?
Вот, пытаюсь понять, может, какое-то личное исследование/сравнение было скрыто за этим. Не может же просто так быть комментарий про "а я использую вот это" на хабре. Тем более в противовес решению, предложенному автором темы.
Все относительно: за неделю, пока вы будете "покупать кроссовки", вам накапают обзорами и отзывами так, что вы неимпульсивно, не спеша, выберите именно рекламируемую модель.
Но когда будете заказывать *.такси, суши, пиццу с аккумулятором на 5% не удивляйтесь, что стоимость будет выше обычной.
Методом drug&drop создавалась Windows ME, а в вашем случае метод другой :)
Вы точно прочитали текст статьи?
И потом светится у тебя "1", а у тебя десятки групп, которые ты сам отсортировал по значимости, и ползаешь туда-сюда, ищешь, где это одно непрочитанное сообщение.
А без ваших глупостей оно будет на самом верху, сразу под закрепленным чатами.
Проходили уже этот ваш UX в ICQ, &RQ, ранней версии Skype.
Я говорю не об обработке ошибок, а о том, чтобы ваш планировщик не падал из-за критической ошибки в запускаемой задаче, оставаясь независимым предсказуемым участником системы
Это не дикость, а выбор паттерна поведения в случае непредвиденной реакции окружения ("обрушилась" база, подключение, недостаточно памяти, не был получен семафор и т.д.). В том числе выход из процедуры с ошибкой, завершение приложения с кодом ошибки и проч — такое встречается повсеместно, а в некоторых системах "обрушение" и вовсе приветствуется, как гарантированная остановка приложения — все зависит от целей, бизнес-процесса, принятых норм, а также соответствия уровню качества (доверия), который был выбран, исходя из целей по рентабельности кода, а также всей системы, частью которой эта Job является.
Холодное и горячее резервирование систем вам чуждо, я так полагаю.
Простейшее решение в виде запуска задачи в независимом/слабозависимом потоке легко решит вопрос и сделает логику планировщика предсказуемой в этой части.
Зона ответственности планировщика — выполнять задания по плану гарантированно и предсказуемо (без неоднозначности).
Вопрос: если одно из заданий "рушится" — а это ожидаемое с некоторой долей вероятности (в зависимости от заявленного качества ПО в соответствии с ISO 9000, раз уж мы тут про "по существу") — планировщик может гарантировать, что не упадет сам и выполнит следующее в очереди задание, независимо от "результатов" предыдущего?
Если все-таки он рушится вместе с заданием, откуда он начнет выполнение заданий со следующим запуском: с начала или с момента аварийной остановки?
Что случится при запуске двух и более копий планировщика?
Правильно понимаю, что любой fatal error тихо положит планировщик со всеми задачами на неопределенном этапе выполнения?
Контроля запуска дубликатов тоже не увидел.
Насколько помню, такой велосипед (раз уж есть доступ до cron-a) реализовывался ранее всегда через демон-подобный вечный скрипт с pid.lock файлом для контроля запуска дублей, полной обработкой всех ошибок, чтобы жить как можно дольше или предсказуемо падать при первой возможности, а также реакцией на принудительное завершение через sig9 — в друпале, джумле, вордпрессе и пр.
Нет четкого разделения ответственности: за дубликаты задач должны отвечать сами задачи, но в то же время ваш планировщик зачем-то хранит в памяти кучу вывода из этих самых задач. В таком вопросе обычно либо все, либо ничего — нужно четко определять границы обслуживания, иначе либо задача пишется, подразумевая использование именного вашего планировщика (отсутствует эффект drop-in replacement), либо допиливать каждый раз через обертки ваш интерфейс, что делает продукт менее интересным.
www.techspot.com/news/72612-western-digital-cloud-drives-have-built-backdoor.html
Обменялся опытом без траты времени и денег на дорогу до вашего митапа)
UX, говорите...
Ответив на письмо из рассылки "как вам наш продукт?" можно получить авто-ответ, что сотрудник в отпуске (без пересылки дальше). "Thanks for your email. I am out of office until August, 11 and will respond to you once I'm back." — с кем связываться дальше, если хочешь получить адекватный ответ не через неделю, непонятно. Но (как далее выяснилось после пересылки на общий ящик) сотрудников, кто может ответить — толпа.
"Sorry for auto email. It's our way of keeping in contact during the trial. Also during the holiday season sometimes our team take holidays." Вот мне, как потенциальному клиенту, вообще начхать, кто там у вас куда берет holidays, я хочу ответы на свои вопросы и "take my money", а не вот это вот все.
При каждом входе страница перезагружается несколько раз, показывая разный набор задач (пусто, тестовые и только потом те, которые принадлежат учетной записи), а затем перезагружается снова и просит указать свой мобильный номер. Не знаю, какой ад творится после приобретения подписки, но этого достаточно, чтобы даже не думать о покупке. перепроверил: оно все еще себя так ведет, даже после всех ваших митапов.
Работать с двумя и более задач невозможно, так как каждое переключение между ними — долгий Ajax-запрос. Не знаю, кто вам сказал, что Comet-подобный подход — это плохо, но сравните с отзывчивостью интерфейса в той же asana.
Боюсь даже представить, чему вы учите на своем митапе по UX.
Приходить на митап по UX к тем, кто не может сделать отзывчивый удобный интерфейс?
У вас каждая кнопка — это долгий Ajax-запрос, о каком UX вы можете разговаривать?
Слайды презентации такие же, как юзабилити вашего продукта...
Правильно понимаю, что под "большими данными" здесь понимается не просто любая база данных, превышающая N Петабайт, а объем обезличенных данных, статистически достаточный для того, чтобы считать их персданными?
Ихнего
По части рабочих ресурсов: частый фрод(в т.ч. фишинг) и гадости вроде социальной инженерии происходят именно в социальных сетях и персональных почтовых ящиках, так как доверие к получателю с именем друга/родственника, неаккуратно позволившего взломать свою учетную запись, сильно выше, и если почта и каналы корпоративной связи (внутренние мессенджеры, CRM и пр.) защищены, то возможность получения ссылки и прочих вредоносов через неограниченное количество ресурсов (доступ до которых может быть получен в т.ч. в обход корпоративных фильтров) значительно расширяет площадь направленной атаки на компанию.
Ресурсы, которые потребуются на защиту таких масштабов при сохранении работоспособности сотрудника, быстрого доступа в сеть и достаточных свободных мощностей АРМ (после установки всех необходимых фильтров и агентов), могут оказаться несоизмеримыми с пользой, которую приносит такой сотрудник.
Решение ЕСПЧ однобокое, и то, что личка и работа "размазываются" должно делать осторожным и включать мозг не только работодателя, но и сотрудника, что несет ответственность за риски, которые добавляет своим безалаберным отношением к правилам компании (вне зависимости от причины их введения).
Имхо, толкать эту телегу нужно в сторону "если сотрудник хочет личку в рабочем окружении — пусть с собой тащит личный девайс с гостевым/отдельным доступом в сеть", неся полную ответственность за последствия и снижение KPI.
А доступ в соц.сети работодателем дается исключительно по желанию в рамках "пакета с печеньками и бонусов при работе в его компании", при этом административный запрет правилами компании — это такая же мера, что и технические ограничения, сбор данных и проч., и само наличие таких правил, объяснили сотруднику, как будут читать его переписки, или нет, должно трактоваться, как ограничение ответственности работодателя в случае нарушения их сотрудником...
Вы комментарий к топику в стиле "а я использую -ххх- и мне норм" оставили ради пука в воду, и отвечать на него не нужно, выискивая полезный смысл?
Вот, пытаюсь понять, может, какое-то личное исследование/сравнение было скрыто за этим. Не может же просто так быть комментарий про "а я использую вот это" на хабре. Тем более в противовес решению, предложенному автором темы.