руководители отделов могут сколько угодно приходить в ужас от того, что очень важные для них расчёты в большой и страшной erp не реализованы вообще никак.
в экселе, мол, пусть считают, а в сап уже результаты сдают. но это не сап плохой, просто удобство этих товарищей гораздо менее приоритетно, чем другие задачи, в том числе надувание щёк...
решение о внедрении того же sap слишком масштабно и дорого для того, чтобы удобство или неудобство конечных пользователей как-то серьёзно повлияло на общий показатель "успешности".
Точно так. Странно ждать адекватной реакции от собеседника, которого вы в ответ на вопрос даже не потрудились уведомить, что не хотите с ним говорить. Он и интересуется — вдруг у вас в ушах бананы, или у него что-то не то с голосом...
А насчёт реферера — поведение конечно спорное, но люди делают точно так же — после невнятных сбоев при попытке кому-то позвонить пытаются набрать номер в другом формате, а то и позвонить с другого аппарата ))
Тут кроме вкусовщины есть ещё как минимум две на мой взгляд важных детали.
1) При объединении реализаций нескольких интерфейсов в один класс сложнее понять, какая часть хранимого состояния объекта используется для реализации каждого интерфейса. Проще говоря — то, что при реализации через замыкание (через анонимный класс) могло быть локализовано в полях анонимного класса или в переменных порождающей его процедуры, в Вашем случае придётся вытаскивать в поля основного класса, замусоривая его.
2) Аннотации никак не уберегут Вас от конфликта имён, когда Вам придётся реализовывать два интерфейса с одноимёнными методами ) Даже получив нормальную диагностику об ошибке, придётся пересматривать именование методов.
IMHO, в Java реализация объектом дополнительных интерфейсов, не определяющих его (объекта) основную функцию, является спорной практикой и сама по себе усложняет понимание структуры. Лучше действительно вынести реализации этих интерфейсов в функции-геттеры, пусть это и добавит пару строк кода.
А в тех случаях, когда непосредственная реализация дополнительных интерфейсов оправдана, необходимый контекст лучше добавить в имя метода при описании интерфейса (естественно, речь о случае, когда Вы сами его описываете).
К примеру, если у вас есть некий интерфейс Magic с функцией getValue(), который вы планируете реализовывать как добавочный, то функцию лучше назвать не getValue(), а getMagicValue(), чтобы не путаться при чтении и не бояться конфликта имён.
При аккуратной эксплуатации (в основном — не допускать глубокого разряда) литивые аккумы на RC-моделях ходят гораздо больше сотни циклов. Но да, если ездить/летать до отсечки, тогда могут и на полста сдохнуть.
поправьте меня, если я что-то путаю, но предварительное вычисление длины результата с помощью "snprintf(NULL, ..." — в итоге выполняет одну и ту же работу по форматированию два раза?
Так точно. А заметание под ковер ошибок с неверно посчитанной длиной и недописанными терминаторами с помощью предварительной очистки всё равно рано или поздно вылезет в ещё более труднодиагностируемых местах.
На мой непрофессиональный взгляд, идеальный вариант поведения продавца — "если вас что-то заинтересует, буду рад ответить на любые вопросы". И всё. От покупателя в этом случае не требуется никакого ответа и вообще никакой реакции. А вопросы "что вам показать, как помочь" действительно слегка напрягают.
Про "самое вкусное блюдо" вполне нормальный же вопрос. И вариантов ИНФОРМАТИВНЫХ ответов на него очень много. От названия блюда, которое чаще всего заказывают и хвалят, до короткого опроса о вкусах клиента. Это занимает совсем немного времени же.
Отличие живого магазина от интернетного ровно в этом — в наличии консультанта, к которому можно обратиться, будучи вообще никак не подготовленным к покупке.
Более того, очень большое количество людей (и я в том числе) либо вообще неспособны сформулировать свои желания сразу, без диалога, либо тратят на это массу усилий. И суть вопроса, который изначально кажется тупым, можно выяснить только в диалоге, поняв его контекст, который изначально есть только в голове у покупателя.
если бы эту картинку вставили в изначальный пост, вопросов в комментариях было бы на порядок меньше.
кстати, стало интересно, каким образом в этой схеме они сгружают в squid информацию о том, с какого клиента пришёл запрос. предполагаю, что никак, и с точки зрения сквида все запросы идут c адреса Se. То есть вдобавок к обрезанию понятия "интернет" только до http через прокси, они ещё и потеряли часть возможностей настройки сквида.
защита сети — это некий комплекс мер, каждая из которых предположительно отсекает некий процент потенциальных атак.
именно по этому проценту имеет смысл оценивать эффективность (и целесообразность применения) той или иной конкретной меры. абсолютной защиты не существует, нашивать на фрагменты забора титановые пластины при наличии в других местах дыр, завешенных тряпочкой — не очень целесообразно.
уровень протокола ip, на защиту которого направлено ваше решение, и без того является одним из самых защищённых — реализации протестированы десятилетиями и миллионами установок.
на порядки более уязвимы протоколы более высокого уровня, работающие например поверх http, которые никак описанной защитой не контролируются. для их эксплуатации не нужно инициировать соединение со стороны злоумышленника, на невозможности чего вы так акцентируете внимание.
то есть, на поверку декларируемый "безопасный интернет" закрывает весьма узкий круг проблем, и больше напоминает эксплуатацию невежества покупателей, неспособных настроить nat и сетевой экран на уровне "ну firewire это же не ethernet, его взломать гораздо труднее".
забавно, спасибо.
мелкое замечание, не относящееся к императивности - в случае r2dbc-postgresql попытка написать на Statement-е
приводит к мертвому подвисанию, если в результате больше 255 строк.
Если убрать collectList и сразу фетчить Result - всё нормально.
Загадка ))
да, конечно, и это тоже.
руководители отделов могут сколько угодно приходить в ужас от того, что очень важные для них расчёты в большой и страшной erp не реализованы вообще никак.
в экселе, мол, пусть считают, а в сап уже результаты сдают. но это не сап плохой, просто удобство этих товарищей гораздо менее приоритетно, чем другие задачи, в том числе надувание щёк...
решение о внедрении того же sap слишком масштабно и дорого для того, чтобы удобство или неудобство конечных пользователей как-то серьёзно повлияло на общий показатель "успешности".
Для чего в правилах iptables опция "--ctstate NEW,ESTABLISHED"?
Точно так. Странно ждать адекватной реакции от собеседника, которого вы в ответ на вопрос даже не потрудились уведомить, что не хотите с ним говорить. Он и интересуется — вдруг у вас в ушах бананы, или у него что-то не то с голосом...
А насчёт реферера — поведение конечно спорное, но люди делают точно так же — после невнятных сбоев при попытке кому-то позвонить пытаются набрать номер в другом формате, а то и позвонить с другого аппарата ))
Тут кроме вкусовщины есть ещё как минимум две на мой взгляд важных детали.
1) При объединении реализаций нескольких интерфейсов в один класс сложнее понять, какая часть хранимого состояния объекта используется для реализации каждого интерфейса. Проще говоря — то, что при реализации через замыкание (через анонимный класс) могло быть локализовано в полях анонимного класса или в переменных порождающей его процедуры, в Вашем случае придётся вытаскивать в поля основного класса, замусоривая его.
2) Аннотации никак не уберегут Вас от конфликта имён, когда Вам придётся реализовывать два интерфейса с одноимёнными методами ) Даже получив нормальную диагностику об ошибке, придётся пересматривать именование методов.
IMHO, в Java реализация объектом дополнительных интерфейсов, не определяющих его (объекта) основную функцию, является спорной практикой и сама по себе усложняет понимание структуры. Лучше действительно вынести реализации этих интерфейсов в функции-геттеры, пусть это и добавит пару строк кода.
А в тех случаях, когда непосредственная реализация дополнительных интерфейсов оправдана, необходимый контекст лучше добавить в имя метода при описании интерфейса (естественно, речь о случае, когда Вы сами его описываете).
К примеру, если у вас есть некий интерфейс Magic с функцией getValue(), который вы планируете реализовывать как добавочный, то функцию лучше назвать не getValue(), а getMagicValue(), чтобы не путаться при чтении и не бояться конфликта имён.
При аккуратной эксплуатации (в основном — не допускать глубокого разряда) литивые аккумы на RC-моделях ходят гораздо больше сотни циклов. Но да, если ездить/летать до отсечки, тогда могут и на полста сдохнуть.
open_memstream + fprintf? тоже вариант, да )
поправьте меня, если я что-то путаю, но предварительное вычисление длины результата с помощью "snprintf(NULL, ..." — в итоге выполняет одну и ту же работу по форматированию два раза?
Так точно. А заметание под ковер ошибок с неверно посчитанной длиной и недописанными терминаторами с помощью предварительной очистки всё равно рано или поздно вылезет в ещё более труднодиагностируемых местах.
А как отличить заведение, где диалог "включен в ценник" от того, где за вопросы будут в рожу плевать, ибо за них не уплочено?
Отличная статья, спасибо. Для полного счастья мне в ней не хватило ровно одного — ссылки на исходную статью "как продавать" )
В комментариях уже подсказали
На мой непрофессиональный взгляд, идеальный вариант поведения продавца — "если вас что-то заинтересует, буду рад ответить на любые вопросы". И всё. От покупателя в этом случае не требуется никакого ответа и вообще никакой реакции. А вопросы "что вам показать, как помочь" действительно слегка напрягают.
Про "самое вкусное блюдо" вполне нормальный же вопрос. И вариантов ИНФОРМАТИВНЫХ ответов на него очень много. От названия блюда, которое чаще всего заказывают и хвалят, до короткого опроса о вкусах клиента. Это занимает совсем немного времени же.
Отличие живого магазина от интернетного ровно в этом — в наличии консультанта, к которому можно обратиться, будучи вообще никак не подготовленным к покупке.
Более того, очень большое количество людей (и я в том числе) либо вообще неспособны сформулировать свои желания сразу, без диалога, либо тратят на это массу усилий. И суть вопроса, который изначально кажется тупым, можно выяснить только в диалоге, поняв его контекст, который изначально есть только в голове у покупателя.
если бы эту картинку вставили в изначальный пост, вопросов в комментариях было бы на порядок меньше.
кстати, стало интересно, каким образом в этой схеме они сгружают в squid информацию о том, с какого клиента пришёл запрос. предполагаю, что никак, и с точки зрения сквида все запросы идут c адреса Se. То есть вдобавок к обрезанию понятия "интернет" только до http через прокси, они ещё и потеряли часть возможностей настройки сквида.
защита сети — это некий комплекс мер, каждая из которых предположительно отсекает некий процент потенциальных атак.
именно по этому проценту имеет смысл оценивать эффективность (и целесообразность применения) той или иной конкретной меры. абсолютной защиты не существует, нашивать на фрагменты забора титановые пластины при наличии в других местах дыр, завешенных тряпочкой — не очень целесообразно.
уровень протокола ip, на защиту которого направлено ваше решение, и без того является одним из самых защищённых — реализации протестированы десятилетиями и миллионами установок.
на порядки более уязвимы протоколы более высокого уровня, работающие например поверх http, которые никак описанной защитой не контролируются. для их эксплуатации не нужно инициировать соединение со стороны злоумышленника, на невозможности чего вы так акцентируете внимание.
то есть, на поверку декларируемый "безопасный интернет" закрывает весьма узкий круг проблем, и больше напоминает эксплуатацию невежества покупателей, неспособных настроить nat и сетевой экран на уровне "ну firewire это же не ethernet, его взломать гораздо труднее".
ну да. а ещё можно подрядить электронщиков разработать собственное коммуникационное железо со своими драйверами.
это да. для статьи на техническом ресурсе лучше бы поменьше аналогий с ядерной бомбой, и побольше подробностей реализации )
ну тут остаётся только гадать ) информации в статье недостаточно для подобных выводов.