Тогда оповещения (срочные и важные) должны идти отдельно, как вариант настроить фильтрами, или использовать ИМ, если эт основная работа.
Для меня, например, почта основное средство коммуникации, десятки писем в день (не считая спама) При автоматической проверке (как было раньше) постоянно торопился и отвлекался, что бы ответить «срочно» на новые даже на не очень важные письма, из-за чего терял уйму времени.
С точки зрения тайм-менеджмента вы очень неправильно пользуетесь почтой.
Срочность у писем не должна быть большой (срочно — это телефон, например), и соответсвтенно проверять ее нужно:
1. руками (что бы делать это когда вам удобно, а не когда что-то пришло)
2. довольно редко (что бы не отвлекаться на не срочную задачу)
Примечательно что месенждеры на английском называют Instant Messenger (дословно Немелденные/мгновенные сообщения) и их использования стоит избегать т. к. они мгновенно прерывают вашу работу (как минимум на секунду посмотреть оповещение).
«Подобные риски — это тоже вопрос бизнеса»
точно так же как и решение о бойкоте платформы, собственно говоря. Если Аппл своими действиями повышает риски сверх приемлемых границ, то разработчики уходят туда где риски приемлемы, вот и все.
Тут вопрос в репутации, ИМХО, ее подорвали такими действиями.
«Путь увеличения мощности сервера неправильный. Все же оптимизация будет лучше.»
Весьма распространенное заблуждение. Зачастую как раз таки правильное решение — увеличение мощности сервера.
Важно определить критерии «правильности», для меня, например, этот критерий стоимость решения в течении его жизни.
Если оптимизация даст выигрыш в 2 раза, при затратах в 100 000-рублей разово, и код будет использоваться год. А докупка мощностей будет стоить 60 000-рублей за этот же год, то стоит выбирать 2-ое.
Методика сама по себе может быть не плоха, и при этом давать отвратительные результаты.
Использование гибкого графика, ИМХО, возможно только при наличии «хорошего менеджмента», что есть большая редкость на просторах СНГ.
Для того что бы уменьшить объем мусора в предложениях нужно четко указывать:
1. Суть проекта (желательный давать мини-ТЗ на 1-2 страницы).
2. Стоимость/срок.
3. Требований к кандидатам (обязательные/необязательные).
4. Вид связи и формат первого сообщения (что там должно быть в т.ч.).
Не совсем так, вероятность поломки одного лезвия (из-за отказа питания) равна вероятности поломки всех лезвий одновременно.
Просто при одинаковой вероятности будут разные потери (1 сервер или 6). И если эти шансы ничтожны, то лучше иметь 2 БП, т.к. они дешевле в поддержке.
см. UPD.
Абсолютно согласен, ставки в блейде растут если отказоустойчивость БП в сервере и блейде принимать одинаковую (что на самом деле не совсем так). Но даже в этом случае она очень мала.
= думаю нет.
ваши предположения?
= да, предположение.
Или есть, что то подкрепляющее это высказывание?
Есть конечно («предположение» без оснований называется фантазией) — рейтинги статей.
Большинству нравится статья -> за нее голосуют -> она получает +10 рейтинга -> она выходит на главную.
Я не спрашиваю какие основания у вашего предположения.
Если угодно: «Идея хабра в самоорганизации сообщества», которая никуда не пропадает, а вот так вот проявляется.
Возможно ваша мысль созвучна с мыслями части пользователей, возможно, даже от многих, но точно не от большинства.
Для меня, например, почта основное средство коммуникации, десятки писем в день (не считая спама) При автоматической проверке (как было раньше) постоянно торопился и отвлекался, что бы ответить «срочно» на новые даже на не очень важные письма, из-за чего терял уйму времени.
Срочность у писем не должна быть большой (срочно — это телефон, например), и соответсвтенно проверять ее нужно:
1. руками (что бы делать это когда вам удобно, а не когда что-то пришло)
2. довольно редко (что бы не отвлекаться на не срочную задачу)
Примечательно что месенждеры на английском называют Instant Messenger (дословно Немелденные/мгновенные сообщения) и их использования стоит избегать т. к. они мгновенно прерывают вашу работу (как минимум на секунду посмотреть оповещение).
точно так же как и решение о бойкоте платформы, собственно говоря. Если Аппл своими действиями повышает риски сверх приемлемых границ, то разработчики уходят туда где риски приемлемы, вот и все.
Тут вопрос в репутации, ИМХО, ее подорвали такими действиями.
Весьма распространенное заблуждение. Зачастую как раз таки правильное решение — увеличение мощности сервера.
Важно определить критерии «правильности», для меня, например, этот критерий стоимость решения в течении его жизни.
Если оптимизация даст выигрыш в 2 раза, при затратах в 100 000-рублей разово, и код будет использоваться год. А докупка мощностей будет стоить 60 000-рублей за этот же год, то стоит выбирать 2-ое.
Использование гибкого графика, ИМХО, возможно только при наличии «хорошего менеджмента», что есть большая редкость на просторах СНГ.
ЗЫ. Переходить на личности — зло.
1. Суть проекта (желательный давать мини-ТЗ на 1-2 страницы).
2. Стоимость/срок.
3. Требований к кандидатам (обязательные/необязательные).
4. Вид связи и формат первого сообщения (что там должно быть в т.ч.).
Это не панацея, но все же.
Просто при одинаковой вероятности будут разные потери (1 сервер или 6). И если эти шансы ничтожны, то лучше иметь 2 БП, т.к. они дешевле в поддержке.
Абсолютно согласен, ставки в блейде растут если отказоустойчивость БП в сервере и блейде принимать одинаковую (что на самом деле не совсем так). Но даже в этом случае она очень мала.
Про фин. затарты см. выше.