И плохая, имхо, идея — использовать селектор по-умолчанию mail._domainkey.
Я так подозреваю, очень многие не утруждают себя сменой селектора из копипаста с мануалов, и у многих NS уже будет такой селектор. От недостаточного понимания вопроса, многие просто добавят или перезатрут запись с ключом и у них откажет свой родной DKIM.
Вот ведь, а!
Сижу настраиваю DKIM + exim на всех своих серверах и доменах, обновляю ключи, пробую разную длину, играю с NS записями. Тестирую на yandex, (удобно видеть сразу зеленый значок). Дай думаю отвлекусь, хабр почитаю… А тут опять DKIM o_O ) День DKIM какой-то прям.
А вообще не помню точно, но точно еще год назад озадачился этим вопросом на своих серверах, и у вас уже был зеленый значок в ответ на корректный DKIM.
Вопрос Яндекс
Вот тока интересует вопрос. В одном и том же случае, при некорректном DKIM yandex выдавал dkim=neutral, а гугл и yahoo =fail (bad_format).
Не могли бы вы написать, в каком случае вы ставите письмам =neutral?
пример выше хороший, у меня же в одной из компонент нужно уведомить другой, что данные изменились. Это в случае таблиц myisam очень красиво, быстро и логично выглядит и работает.
В другом месте, примерно тот же случай что VolCh описал, с той разницей, что проверяются части одной «таблицы» разбитой на части приоритетого и временного значения с разной интенсивностью, для опять же проверки и сообщения подсистеме кеширования.
Вы это и правда серьезно?
Вы вот прям серьезно предлагаете, там где нужен ластапдейт неважно каких данных, вмешиваться в структуру, да еще и цеплять это поле каждой записи?
Вы с таблицами больше 10 млн записей работали?
Insert и update в InnoDB? оптимизация запросов? компактное расположение полей, помочь встроенному оптимизатору?
Борешься, блин, за каждый лишний байт в длине полей, количестве и качестве индексов…
Лучше будем mysql оправдывать.
И я не говорил про
все
таблицы. Где вы это увидели?
Пишите какие хотите костыли, а я с этого недоразумения точно ухожу.
Да, вы все верно написали.
Еще можно триггер повесить. Можно перехватывать обращения к сокету наверное и еще кучу вещей… Но это всеравно, что топором гвозди забивать. Вроде и забиваются, но ведь не для того он… Да и полбу можно получить.
Мне же нужно сам факт случившегося апдейта. Точное время. Одним быстрым и правильным запросом.
шчто?
Нет, это не саркэстик мод.
А вы еще предложите мне отдельную табличку создать, куда непрозрачно писать все ластапдейты, дополнительным скрытым вызовом на каждый чих. Ну, или там демоном файлики БД мониторить.
innodb table last update time 27 октября 8 лет исполняется.
Подарю себе в этот день сервер с Percona, и обещание начать забывать mysql.
Ладно бы фигня какая, но такое я уже прощать дальше не в состоянии. Ни в моральном ни в архитектурном.
Пример про microsoft:
область уведомлений в windows 7. При клике на свободном месте, если бабл всплыл при клике на его родительской иконке, он не убирается, и может висеть черте где и черт знает сколько времени, пока я опять не разверну трей, и не кликну именно на эту же иконку. Порой, это выбешивает настолько, что прям вот ну ващщщщщееее!
А я вот всё меньше вижу проблему именно в том, о чем статья (мне последнее время видимо везёт, наши дизайнеры работают над текстами дружно, а даже у нас, разработчиков спрашивают мнение и о содержании и о дизайне).
Я вот всё чаще вижу проблему, когда забывают о так называемых «областях пересекающихся смыслов».
Т.е. всё вроде сделано правильно и в одном месте, и в близлежащем. Но вот наличие пограничных контролов с нечеткой или сбойной логикой поведения (областей, где пользователь делает/может делать выбор), из за ограниченности пространства монитора, и недостаточной проработки вопроса, приводит к более ощутимым баттхёртам, чем всё остальное вместе взятое (не сразу понятный смысл, некрасивая и неудобная форма).
Если люди в своей основной массе (хотелось бы верить) — существа пытливые и любопытные, то они найдут ваш товар, правильно оформят заказ, спросят там где надо и сами все найдут, нарисуй вы какой угодно плохой дизайн, но удовлетворив их основные потребности и предоставив нужный инструментарий работающий как надо в конечном результате . Но вот если по кнопке оформить заказ — меня перебрасывают на форму логина или выскакивает помощник, или по нажатию стрелки вниз я двигаюсь вверх, или в одном месте случайно срабатывают 2 (или какое то одно, но не то) экшна (яркий пример вот прямо тут на хабре: попробуйте нажать на стрелку в левом верхнем углу) — это тушите свет.
И очень правильное в статье замечание, что дизайнер должен быть режиссером! Полностью согласен.
А в погоне за красотой, содержанием и формой — постоянно, блин, забывают о сценариях и поведении…
Скала то отвесная. Рычаг собственного тела к отвесу — 100% хватит силы. Так же определить куда упадет камень, с такой высоты по веревке тоже не проблема.
Вообщем в реальных условиях резать бы не стал. Поэкспериментировал бы с трением, массой, подходящими камнями и в путь! :)
Зачем, к вашей массе добавиться ускорение с которым вы будете дергать.
Вы же способны подтягиваться с гирей? В тоже время держать равновесие с равноценной массой в покое или равномерном движении с небольшим ускорением…
Все реально.
Т.е. как бы стащить вниз камень даже в 2 раза большей массы уже не проблема
Привязав веревку на уступе, вы можете использовать рычаг градуса веревки и собственного тела с отвесом горы. Тогда все еще проще.
Стащите, не бойтесь)
Ищем на горе камень, массой близкой или выше чем вы. (+ сила трения камня о гору)
Привязываем веревку, спускаемся медленно и аккуратно на уступ.
Привязываем нижний конец к уступу.
Посильнее дергаем за веревку. Камень с верхним концом падает на уступ (берегите голову :) или мимо. Пофиг.
Сбрасываем камень вниз, спускаемся.
У нас ведь нету ножа для разрезания, да? Да и тяжело сверху определить полную высоту горы чтобы точно разрезать…
В реальных условиях так бы и было. Тем более если это стальной трос и ножа / кусачек нет полюбому.
Я вроде про буфер уже говорил. Не надо в меня тестами кидаться. Вы суть то не уловили:
в данном примере, происходит инкремент html одного элемента, основанный всего лишь на индексе, не требующий дополнительных вычислений, требующих семантически выделить инкремент (конкатенацию) в блок действий for, а не в блок инициализации.
Смысл моего примера в том, что напрямую связанное с инкрементом единичное действие нефиг выделять в блок выполнения. Ему очень комфортно в итераторе. (проверьте тем же тестом)
Добавьте ваш семантически мусорный буфер в мой код и запустите тот же тест. Теперь мой код быстрее.
На реальной производительности (где на DOM куча вочеров, стилей, событий) наличие буфера никак не сказывается. А вот на «засорение» — да.
И вот пишут мне потом такие «спичечные» оптимизаторы: «посмотри ка мой код, что-то у меня не пойму все зависает после 15 минут работы, хотя везде все оптимизировано». Хотя не привыкать ловить минусы от непонимающих. Уже даже приятно как-то.
Чота да, как то у нас стрёмно с ней всё )
Я так подозреваю, очень многие не утруждают себя сменой селектора из копипаста с мануалов, и у многих NS уже будет такой селектор. От недостаточного понимания вопроса, многие просто добавят или перезатрут запись с ключом и у них откажет свой родной DKIM.
Сижу настраиваю DKIM + exim на всех своих серверах и доменах, обновляю ключи, пробую разную длину, играю с NS записями. Тестирую на yandex, (удобно видеть сразу зеленый значок). Дай думаю отвлекусь, хабр почитаю… А тут опять DKIM o_O ) День DKIM какой-то прям.
А вообще не помню точно, но точно еще год назад озадачился этим вопросом на своих серверах, и у вас уже был зеленый значок в ответ на корректный DKIM.
Вопрос Яндекс
Вот тока интересует вопрос. В одном и том же случае, при некорректном DKIM yandex выдавал dkim=neutral, а гугл и yahoo =fail (bad_format).
Не могли бы вы написать, в каком случае вы ставите письмам =neutral?
В другом месте, примерно тот же случай что VolCh описал, с той разницей, что проверяются части одной «таблицы» разбитой на части приоритетого и временного значения с разной интенсивностью, для опять же проверки и сообщения подсистеме кеширования.
зачем здесь примари кей id с инкрементом?
зачем его вообще бездумно везде лепят?
т.е. получить самый последний апдейт надо так:
, а `t1` count(*) > 10,000,000
неужели не очевидно, что это большой косяк, отсутствие нативного last_update?
Вы это и правда серьезно?
Вы вот прям серьезно предлагаете, там где нужен ластапдейт неважно каких данных, вмешиваться в структуру, да еще и цеплять это поле каждой записи?
Вы с таблицами больше 10 млн записей работали?
Insert и update в InnoDB? оптимизация запросов? компактное расположение полей, помочь встроенному оптимизатору?
Борешься, блин, за каждый лишний байт в длине полей, количестве и качестве индексов…
Лучше будем mysql оправдывать.
И я не говорил про таблицы. Где вы это увидели?
Пишите какие хотите костыли, а я с этого недоразумения точно ухожу.
Еще можно триггер повесить. Можно перехватывать обращения к сокету наверное и еще кучу вещей… Но это всеравно, что топором гвозди забивать. Вроде и забиваются, но ведь не для того он… Да и полбу можно получить.
Мне же нужно сам факт случившегося апдейта. Точное время. Одним быстрым и правильным запросом.
Нет, это не саркэстик мод.
А вы еще предложите мне отдельную табличку создать, куда непрозрачно писать все ластапдейты, дополнительным скрытым вызовом на каждый чих. Ну, или там демоном файлики БД мониторить.
Подарю себе в этот день сервер с Percona, и обещание начать забывать mysql.
Ладно бы фигня какая, но такое я уже прощать дальше не в состоянии. Ни в моральном ни в архитектурном.
область уведомлений в windows 7. При клике на свободном месте, если бабл всплыл при клике на его родительской иконке, он не убирается, и может висеть черте где и черт знает сколько времени, пока я опять не разверну трей, и не кликну именно на эту же иконку. Порой, это выбешивает настолько, что прям вот ну ващщщщщееее!
Я вот всё чаще вижу проблему, когда забывают о так называемых «областях пересекающихся смыслов».
Т.е. всё вроде сделано правильно и в одном месте, и в близлежащем. Но вот наличие пограничных контролов с нечеткой или сбойной логикой поведения (областей, где пользователь делает/может делать выбор), из за ограниченности пространства монитора, и недостаточной проработки вопроса, приводит к более ощутимым баттхёртам, чем всё остальное вместе взятое (не сразу понятный смысл, некрасивая и неудобная форма).
Если люди в своей основной массе (хотелось бы верить) — существа пытливые и любопытные, то они найдут ваш товар, правильно оформят заказ, спросят там где надо и сами все найдут, нарисуй вы какой угодно плохой дизайн, но удовлетворив их основные потребности и предоставив нужный инструментарий работающий как надо в конечном результате . Но вот если по кнопке оформить заказ — меня перебрасывают на форму логина или выскакивает помощник, или по нажатию стрелки вниз я двигаюсь вверх, или в одном месте случайно срабатывают 2 (или какое то одно, но не то) экшна (яркий пример вот прямо тут на хабре: попробуйте нажать на стрелку в левом верхнем углу) — это тушите свет.
И очень правильное в статье замечание, что дизайнер должен быть режиссером! Полностью согласен.
А в погоне за красотой, содержанием и формой — постоянно, блин, забывают о сценариях и поведении…
Вообщем в реальных условиях резать бы не стал. Поэкспериментировал бы с трением, массой, подходящими камнями и в путь! :)
Вы же способны подтягиваться с гирей? В тоже время держать равновесие с равноценной массой в покое или равномерном движении с небольшим ускорением…
Все реально.
Т.е. как бы стащить вниз камень даже в 2 раза большей массы уже не проблема
Привязав веревку на уступе, вы можете использовать рычаг градуса веревки и собственного тела с отвесом горы. Тогда все еще проще.
Стащите, не бойтесь)
Ищем на горе камень, массой близкой или выше чем вы. (+ сила трения камня о гору)
Привязываем веревку, спускаемся медленно и аккуратно на уступ.
Привязываем нижний конец к уступу.
Посильнее дергаем за веревку. Камень с верхним концом падает на уступ (берегите голову :) или мимо. Пофиг.
Сбрасываем камень вниз, спускаемся.
У нас ведь нету ножа для разрезания, да? Да и тяжело сверху определить полную высоту горы чтобы точно разрезать…
В реальных условиях так бы и было. Тем более если это стальной трос и ножа / кусачек нет полюбому.
Камень на горе нужной массы более вероятен…
в данном примере, происходит инкремент html одного элемента, основанный всего лишь на индексе, не требующий дополнительных вычислений, требующих семантически выделить инкремент (конкатенацию) в блок действий for, а не в блок инициализации.
Смысл моего примера в том, что напрямую связанное с инкрементом единичное действие нефиг выделять в блок выполнения. Ему очень комфортно в итераторе. (проверьте тем же тестом)
Добавьте ваш семантически мусорный буфер в мой код и запустите тот же тест. Теперь мой код быстрее.
На реальной производительности (где на DOM куча вочеров, стилей, событий) наличие буфера никак не сказывается. А вот на «засорение» — да.
И вот пишут мне потом такие «спичечные» оптимизаторы: «посмотри ка мой код, что-то у меня не пойму все зависает после 15 минут работы, хотя везде все оптимизировано». Хотя не привыкать ловить минусы от непонимающих. Уже даже приятно как-то.