Как стать топовым разработчиком, уделяя этому только 8 рабочих часов? Для начала:
1. как следует изучить фундаментальную computer science;
2. регулярно практиковаться;
3. постоянно изучать что-то новое.
И здесь нас ждут подводные камни:
1. Если не пройден первый пункт во время учебы, его приходится проходить после того, как ты стал работать. В свободное от работы время, разумеется.
2. Если структура рабочего времени подразумевает, что широкой практики нет, только выполнение однотипной monkey business (скажем, сопровождение чужого кода, багофикс) и практиковаться в проектировании «с нуля». допустим, негде — опять у меня плохие новости: это нужно будет делать в свободное от работы время.
3. Постоянно изучать что-то новое можно, если на работе постоянно есть парочка «свободных» для этого часов. Постоянно, КАРЛ. Если нет — опять же, нужно уделять свободное время. Нерабочее.
Вывод: если окружающая среда, образование, условия «выращивания» при прочих равных оказалась хуже, чем у других, а амбиции остались на уровне «как у всех», будьте любезны или тратить своё личное время или забыть про амбиции.
Далее. Разработчик в идеале должен быть собран и сконцентрирован. А попробуй-ка не рассыпать в голове пятимерные абстракции, когда девушка регулярно пишет в скайп мимимишности и требует ответа. Кхм.
Матерясь про себя, перечитываешь «Поток» Чиксентмихайи, и задумываешься: ставить крест на личной жизни, ставить крест на работе или попробовать соблюсти баланс? Правильно, да: соблюсти баланс — грань всегда можно найти, было бы желание.
И именно здесь, пока ты занят поисками баланса, в комнату с криком «А вот я же говорил!» врывается разработчик Вася, у которого ващще нет таких проблем, который уделяет личное время личному развитию, инвестируя в себя, и становится «топовым» не через десять лет, как ты, а через шесть. Профит? Профит.
Делиться возникшими проблемами с другими ребятами в команде.
Да — вся эта коммуникация идёт в лес, когда сверхкоммуникативный разработчик каждый поднимает вопрос, который легко гуглится. Надо развивать техническую экспертизу, а не софтскилл «взять и спросить». А то хочется подчас взять черенок от лопаты и…
Негодование не касается концептуальных, в том числе организационных и архитектурных вопросов, но я верю, что разработчики уровнем повыше — не целевая аудитория сей статьи.
В чем смысл начинать «уделывать»? Кандидат не хоботом меряться приходит, а присматриваться к потенциальному работодателю. Как и работодатель к кандидату.
На мой вкус, «параллельное последовательное» выглядит как взаимоисключающие параграфы, особенно для новичка. Предлагаю перевести «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) в одном посте, сохраняя точность и полноту, а потом добавить «парочку» примеров из остальных глав – для закрепления и понимания.
1. как следует изучить фундаментальную computer science;
2. регулярно практиковаться;
3. постоянно изучать что-то новое.
И здесь нас ждут подводные камни:
1. Если не пройден первый пункт во время учебы, его приходится проходить после того, как ты стал работать. В свободное от работы время, разумеется.
2. Если структура рабочего времени подразумевает, что широкой практики нет, только выполнение однотипной monkey business (скажем, сопровождение чужого кода, багофикс) и практиковаться в проектировании «с нуля». допустим, негде — опять у меня плохие новости: это нужно будет делать в свободное от работы время.
3. Постоянно изучать что-то новое можно, если на работе постоянно есть парочка «свободных» для этого часов. Постоянно, КАРЛ. Если нет — опять же, нужно уделять свободное время. Нерабочее.
Вывод: если окружающая среда, образование, условия «выращивания» при прочих равных оказалась хуже, чем у других, а амбиции остались на уровне «как у всех», будьте любезны или тратить своё личное время или забыть про амбиции.
Далее. Разработчик в идеале должен быть собран и сконцентрирован. А попробуй-ка не рассыпать в голове пятимерные абстракции, когда девушка регулярно пишет в скайп мимимишности и требует ответа. Кхм.
Матерясь про себя, перечитываешь «Поток» Чиксентмихайи, и задумываешься: ставить крест на личной жизни, ставить крест на работе или попробовать соблюсти баланс? Правильно, да: соблюсти баланс — грань всегда можно найти, было бы желание.
И именно здесь, пока ты занят поисками баланса, в комнату с криком «А вот я же говорил!» врывается разработчик Вася, у которого ващще нет таких проблем, который уделяет личное время личному развитию, инвестируя в себя, и становится «топовым» не через десять лет, как ты, а через шесть. Профит? Профит.
Да — вся эта коммуникация идёт в лес, когда сверхкоммуникативный разработчик каждый поднимает вопрос, который легко гуглится. Надо развивать техническую экспертизу, а не софтскилл «взять и спросить». А то хочется подчас взять черенок от лопаты и…
Негодование не касается концептуальных, в том числе организационных и архитектурных вопросов, но я верю, что разработчики уровнем повыше — не целевая аудитория сей статьи.
Ответ: Правильно
При переводе потеряли кусочек юмора :)
У romy4 отличный вариант.
Коньяки сделал выводы.Интересен сам подход к «норме» как явлению :)
Есть притча. У Васи и Феди заболела пятка. Один пошел к врачу, второй забил. Угадайте больного.
«Ой, у вас показатель Х на 3% выше нормы, это ужасно». А что такое «норма» — никто не объяснил.
/* Предлагаю поменять по тексту «цена вопроса» и «стоимость» на «цена» — с точки зрения стилистики статья будет сиять. */
Ну очевидно же :) Если брокер падает, то все переворачивается мехом наружу. Парочка примеров:
1. Producer отправил сообщение, а на брокере очередь не durable. Брокер лёг. Сообщение потерялось до отправки. Ответ не пришел.
2. Более интересный случай. Допустим, producer отправил сообщение, на брокере очередь durable, все хорошо. Брокер отправил сообщение. Consumer начал долгую обработку, ACK еще не отправил, и в этот момент брокер падает… Дальше возможны варианты по количеству (нет ответа, один ответ, два ответа) и правильности, потому что Consumer в любом случае получит два одинаковых сообщения. Второе он может не принимать к обработке, если это особо предусмотрено :)
Минимально – нужно выставить таймаут на Queue, при необходимости переопределить таймаут на Message, и обработать таймаут на Producer.
deletedА вообще, я не знаю, можно ли выразительно пересказать первую главу Макконнелла (ISBN 5-94836-005-9) в одном посте, сохраняя точность и полноту, а потом добавить «парочку» примеров из остальных глав – для закрепления и понимания.