Делиться возникшими проблемами с другими ребятами в команде.
Да — вся эта коммуникация идёт в лес, когда сверхкоммуникативный разработчик каждый поднимает вопрос, который легко гуглится. Надо развивать техническую экспертизу, а не софтскилл «взять и спросить». А то хочется подчас взять черенок от лопаты и…
Негодование не касается концептуальных, в том числе организационных и архитектурных вопросов, но я верю, что разработчики уровнем повыше — не целевая аудитория сей статьи.
В чем смысл начинать «уделывать»? Кандидат не хоботом меряться приходит, а присматриваться к потенциальному работодателю. Как и работодатель к кандидату.
На мой вкус, «параллельное последовательное» выглядит как взаимоисключающие параграфы, особенно для новичка. Предлагаю перевести «Parallel Seq Scan» как «параллельное упорядоченное чтение» — в противоположность «Scattered Read» — случайному чтению.
В России никто не запрещает это делать, в 90% случаев спрашивают (в оставшихся десяти, видимо, просто забывают). Про семейное положение и детей, как часто они болеют, если есть, и прочее.
… собственно, я к чему: генотип (и фенотип) очень вариативен и то, что для одного человека хорошо, для другого неприемлемо и кошмар. Может и не надо человеку никуда ходить, а вы советуете.
Есть притча. У Васи и Феди заболела пятка. Один пошел к врачу, второй забил. Угадайте больного.
Злободневно. Мы, разработчики, обычно любим заботиться о концентрации внимания — было бы интересно отмониторить типичное офисное помещение, например, openspace.
/* Предлагаю поменять по тексту «цена вопроса» и «стоимость» на «цена» — с точки зрения стилистики статья будет сиять. */
Здесь – «клиентом» вы называете отправителя, а «сервисом» получателя, я буду использовать соответственно Consumer и Producer, чтобы окончательно всех запутать.
Как связан message broker с возможностью не доставки ответа и тем как это должен разруливать сервис?
Ну очевидно же :) Если брокер падает, то все переворачивается мехом наружу. Парочка примеров:
1. Producer отправил сообщение, а на брокере очередь не durable. Брокер лёг. Сообщение потерялось до отправки. Ответ не пришел.
2. Более интересный случай. Допустим, producer отправил сообщение, на брокере очередь durable, все хорошо. Брокер отправил сообщение. Consumer начал долгую обработку, ACK еще не отправил, и в этот момент брокер падает… Дальше возможны варианты по количеству (нет ответа, один ответ, два ответа) и правильности, потому что Consumer в любом случае получит два одинаковых сообщения. Второе он может не принимать к обработке, если это особо предусмотрено :)
Если ответ не придет, т.к. сервис например упал во время подготовки ответа, то как должен клиент разруливать эту ситуацию?
Минимально – нужно выставить таймаут на Queue, при необходимости переопределить таймаут на Message, и обработать таймаут на Producer.
Внутренне чувствую, что сложности алгоритмов – ваша любимая тема :)
А вообще, я не знаю, можно ли выразительно пересказать первую главу Макконнелла (ISBN 5-94836-005-9) в одном посте, сохраняя точность и полноту, а потом добавить «парочку» примеров из остальных глав – для закрепления и понимания.
Еще в тему – есть интересная статья, в которой автор утверждает, что создал самый быстрый вариант поиска подстроки в строке, и в доказательство приводит подробные сравнения алгоритмов.
А можно пожалуйста выложить код бенчмарков вместе с тестовым набором данных?
И с какой именно реализацией strstr проводилось сравнение? Внезапно, их тоже много.
Меня смущает два момента:
1. сигнатура не совпадает с библиотечной, т.е. для прямой замены не годится:
char *strstr(const char *s1, const char *s2)
2. понятно, что делает max_len, но непонятно, откуда взялось волшебное число 140.
Да — вся эта коммуникация идёт в лес, когда сверхкоммуникативный разработчик каждый поднимает вопрос, который легко гуглится. Надо развивать техническую экспертизу, а не софтскилл «взять и спросить». А то хочется подчас взять черенок от лопаты и…
Негодование не касается концептуальных, в том числе организационных и архитектурных вопросов, но я верю, что разработчики уровнем повыше — не целевая аудитория сей статьи.
Ответ: Правильно
При переводе потеряли кусочек юмора :)
У romy4 отличный вариант.
Коньяки сделал выводы.Интересен сам подход к «норме» как явлению :)
Есть притча. У Васи и Феди заболела пятка. Один пошел к врачу, второй забил. Угадайте больного.
«Ой, у вас показатель Х на 3% выше нормы, это ужасно». А что такое «норма» — никто не объяснил.
/* Предлагаю поменять по тексту «цена вопроса» и «стоимость» на «цена» — с точки зрения стилистики статья будет сиять. */
Ну очевидно же :) Если брокер падает, то все переворачивается мехом наружу. Парочка примеров:
1. Producer отправил сообщение, а на брокере очередь не durable. Брокер лёг. Сообщение потерялось до отправки. Ответ не пришел.
2. Более интересный случай. Допустим, producer отправил сообщение, на брокере очередь durable, все хорошо. Брокер отправил сообщение. Consumer начал долгую обработку, ACK еще не отправил, и в этот момент брокер падает… Дальше возможны варианты по количеству (нет ответа, один ответ, два ответа) и правильности, потому что Consumer в любом случае получит два одинаковых сообщения. Второе он может не принимать к обработке, если это особо предусмотрено :)
Минимально – нужно выставить таймаут на Queue, при необходимости переопределить таймаут на Message, и обработать таймаут на Producer.
deletedА вообще, я не знаю, можно ли выразительно пересказать первую главу Макконнелла (ISBN 5-94836-005-9) в одном посте, сохраняя точность и полноту, а потом добавить «парочку» примеров из остальных глав – для закрепления и понимания.
И с какой именно реализацией strstr проводилось сравнение? Внезапно, их тоже много.
Меня смущает два момента:
1. сигнатура не совпадает с библиотечной, т.е. для прямой замены не годится:
2. понятно, что делает max_len, но непонятно, откуда взялось волшебное число 140.