Это в идеале. На практике все сложнее. Наш продукт редко просто приходят и покупают. Обычно получается так.
1) Потенциальный клиент пишет вопрос.
2) Мы не используем фильтры и видим его письмо.
3) Мы отвечаем на письмо.
4) Письмо на его стороне попадает в спам.
5) Мы начинаем писать другие письма и использовать другие ящики, чтобы он все-таки прочитал наш ответ. :)
По поводу белого списка тоже не все так просто. Этот сотрудник может сидеть за корпоротивным файерволом. А следовательно ему сложнее что-то изменить.
Подход «Если он меня знает, то сможет найти другие мои контакты (телефон, ICQ, Skype)» приемлем только в случае, когда круг общения мал и практически не расширяется.
Я и не говорил, что разбираюсь в данной тематике. Я высказал некоторые свои мысли. Буду рад, если Вы напишите свою статьи на данную тему. Мне действительно будут интересно.
Я уверен, что можно придумать гораздо более интересную и удобную форму. Но это задача серьезного исследования. Рисунок приведен просто в качестве примера навигации по фракталу.
Вышла. И мы перевели на нее разработку PVS-Studio, так как нам это нужно для целей тестирования кода на языке C++0x. В принципе жить можно. Но ряд неприятных моментов есть. На вскидку: Глючит InlelliSence. Временами внутри что-то падает и выдается страшное окно об ошибке, хотя потом можно продолжать работать. Сломано создание собственных тулов в External Tools.
Ждем с надежной апдейтов.
Техническая вид воплощения не важен. Возможно будет сеточка на голове, как описано у Станислава Лема (Последнее путешествие Ийона Тихого). Это только пока все глупо и неудобно.
Не так стоит мыслить. Дальше будет не еще больший монитор. Дальше будет монитор «кругом». Будет виртуальная реальность. И вот она потребность в колоссальных ресурсах.
А если серьезнее, то ошибку всегда следует обнаруживать как можно раньше.
Выгоднее найти ошибку сразу при запуске юнит-тестов, чем при ручном тестирование или тем более использовании заказчиком. Выгоднее найти ошибку сразу на этапе компиляции, чем на этапе исполнения (запуске юнит-тестов).
C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
Но, как я понимаю, это не связано с C++0x. Выдержка из Msdn:
C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications.
The following code sample generates C4290:
// C4290.cpp
// compile with: /EHs /W3 /c
void f1(void) throw(int) {} // C4290
// OK
void f2(void) throw() {}
void f3(void) throw(...) {}
1) Потенциальный клиент пишет вопрос.
2) Мы не используем фильтры и видим его письмо.
3) Мы отвечаем на письмо.
4) Письмо на его стороне попадает в спам.
5) Мы начинаем писать другие письма и использовать другие ящики, чтобы он все-таки прочитал наш ответ. :)
По поводу белого списка тоже не все так просто. Этот сотрудник может сидеть за корпоротивным файерволом. А следовательно ему сложнее что-то изменить.
Подход «Если он меня знает, то сможет найти другие мои контакты (телефон, ICQ, Skype)» приемлем только в случае, когда круг общения мал и практически не расширяется.
Ждем с надежной апдейтов.
2) А что смущает в высоком разрешении маленьких экранов?
А если серьезнее, то ошибку всегда следует обнаруживать как можно раньше.
Выгоднее найти ошибку сразу при запуске юнит-тестов, чем при ручном тестирование или тем более использовании заказчиком. Выгоднее найти ошибку сразу на этапе компиляции, чем на этапе исполнения (запуске юнит-тестов).
Пример:
void A(int *x) {}
…
A(0); — OK
A((void*)0); — error C2664: 'A': cannot convert parameter 1 from 'void *' to 'int *'
p.s. [] — квадратные :)
P.S.
Провел эксперимент. При компиляции кода
Visual C++ выдает предупреждение:
C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
Но, как я понимаю, это не связано с C++0x. Выдержка из Msdn:
C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications.