Есть ещё одна частая интересная ошибка. Допустим в примере нужна группировка по клиентам, но вывести надо client_name. Его и включают в group by, получая ... группировку по тезкам.
В group by нужно включить client_id как первичный ключ и client_name (для большинства баз избыточно, но говорят где то ещё требуется).
Сам вряд ли, разные полки стоят разные деньги, хотя бы по высоте.
Была раньше гипотеза: идея переставить всё идёт от мерчандайзеров, чтобы потребитель, который бежит по привычному flow, тормознулся и пошел искать, нашел что-то новенькое.
Потом рассказали, что в магазинах одной сети наоборот стараются делать одинаковый порядок.
HR'ы обычно говорят на это мантру: бюджет привлечения больше бюджета удержания.
Лучше реализовывать систему грейдов, чтобы она была прозрачной и сотрудники мерялись ими чем зарплатой (все равно обсуждают, а некоторые ещё и придумывают, чем провоцируют конфликты).
Отличная статья получилась, замечательные примеры. На самом деле важно найти баланс между теорией, практикой и научить находить знания и решения, а также учиться самостоятельно, но ведь каждый человек индивидуален, значит не может быть единого подхода, хотя лично мне нравится заход через практику, а вот видеоформат идёт плохо...
Не соглашусь с утверждением, что «Если професору с мехмата скажут рассказать 8 классикам тему „тригонометрия“ ему не нужно будет никуда ничего копать, он и так все знает в пару миллиардов раз лучше чем этого требуется для продвинутого школьника».
Вы никогда не слышали историй как коллективы математических кафедр вузов бились вокруг школьных задач и не могли их решить только из-за того, что совершенно иначе понимали формулировку задачи, т.к. она была ориентирована на целевую аудиторию и ее понимание исходя из кривой обучения?
Аудитория исключительно важна, т.к. ей мало сделать доклад, нужно сделать его на основе уровня аудитории с учетом ее особенностей.
Возвращаясь к теме статьи каждое выступление ориентировано на конкретную аудиторию и преследует определенную цель/конверсию, иначе выступление лишено смысла. В ходе подготовки любой лектор часто сталкивается с тем, что что-то забыл, изначально неправильно понимал, но не предавал этому никакого значения и т.п.
Собственно это и иллюстрирует анекдот: «Ну и тупые студенты попались, три раза рассказал, сам все понял...»!-)
Понятно, что есть другой путь, когда приглашаем самого продвинутого инженера, который знает ВСЕ, но… не знает/не может этого объяснить, не умеет работать с аудиторией. Увы, это разные скиллы, способность объяснить другим надо развивать, начинать с коллег, потом вести стажировки, потом переходить к группам.
Возвращаясь к примеру «преподователя по бекенду» я как минимум ожидаю, что он лет 10 ковыряется в его дебрях" у него вполне могут быть пробелы в знаниях, т.к. за 10 лет он понял что нужно (ему), что не нужно (ему), поэтому многие вещи он не помнит или не акцентирует на них внимание, какие-то вещи не счел нужным изучить, т.к. в работе ему они не нужны (а вот в обучении других должен знать хотя бы рамочно).
Что касается докера — как раз использовал его для тестирования. Удобно. Но надо понимать, что человек после тебя может не знать докер. К тому же бывают строгие т.з. и стандарты компании, которые не предусматривают докер.
Учитывая тренд на микросервисы маловероятно, да и скорее спасибо скажет, т.к. проще обновить докер, если конечно все честно вынес на volume, чем отдельно системный софт и продукты Jira. Тут у каждого свой путь!-)
В прошлом году столкнулся с переносом одного проекта в Jira (ServiceDesk по сути надстройка над Jira, хотя может устанавливаться и отдельно). Столкнулся с тем, что если проект в облаке уже NextGen, а его люди выбрали по умолчанию, т.к. на тот момент никуда переезжать не собирались, к тому же задействовали имеющийся там функционал Roadmap. Вот его перенос это был нечто, к тому же выяснилось что у них отдельная команда поддержки для облака, отдельная для Selfhosted, которые с честью поиграли в игру «ошибка не на нашем конце, отправляем ваш тикет в ...», в итоге перетащили практически вручную, т.к. весь лимит времени съела переписка с поддержкой, а владельцы проекта оказались еще и демотивированы отсутствием функционала Roadmap, который Atlassian так и не сподобился добавить в серверную версию.
Касательно развертывания Jira я предложил бы просто использовать… докер, просто и быстро, легко обновлять, для небольшой команды проблем вообще не видел, одни плюсы.
Русскоязычная платежеспособная аудитория значительно меньше англоязычной, а перевод с русского на английский технической литературы редкость.
Можно также посмотреть на курсы на Udemy и т.п. ресурсах, там есть такие же истории, где курс кормит автора (с учетом де-факто околонулевой поддержки аудитории курса), но опять же англоязычные.
Жаль, что не реализовали. Был бы отличный кейс. Главное определить нужный ноутбук, но это можно по модели. А диск, если это был обычный HDD, скорее всего подвергся бы коррозии, т.е. еще восстановление данных с него было бы трудоемким и под вопросом.
Привет!
Есть ещё одна частая интересная ошибка. Допустим в примере нужна группировка по клиентам, но вывести надо client_name. Его и включают в group by, получая ... группировку по тезкам.
В group by нужно включить client_id как первичный ключ и client_name (для большинства баз избыточно, но говорят где то ещё требуется).
Можно из этого отдельный пример сделать.
Сам вряд ли, разные полки стоят разные деньги, хотя бы по высоте.
Была раньше гипотеза: идея переставить всё идёт от мерчандайзеров, чтобы потребитель, который бежит по привычному flow, тормознулся и пошел искать, нашел что-то новенькое.
Потом рассказали, что в магазинах одной сети наоборот стараются делать одинаковый порядок.
Очень верно передана суть в заголовке:
"которая украсит ваши полки"
HR'ы обычно говорят на это мантру: бюджет привлечения больше бюджета удержания.
Лучше реализовывать систему грейдов, чтобы она была прозрачной и сотрудники мерялись ими чем зарплатой (все равно обсуждают, а некоторые ещё и придумывают, чем провоцируют конфликты).
Спасибо за статью. Какой метод подключения плагинов, например rabbitmq_web_stomp, порекомендуете?
Отличная статья получилась, замечательные примеры. На самом деле важно найти баланс между теорией, практикой и научить находить знания и решения, а также учиться самостоятельно, но ведь каждый человек индивидуален, значит не может быть единого подхода, хотя лично мне нравится заход через практику, а вот видеоформат идёт плохо...
Вы никогда не слышали историй как коллективы математических кафедр вузов бились вокруг школьных задач и не могли их решить только из-за того, что совершенно иначе понимали формулировку задачи, т.к. она была ориентирована на целевую аудиторию и ее понимание исходя из кривой обучения?
Аудитория исключительно важна, т.к. ей мало сделать доклад, нужно сделать его на основе уровня аудитории с учетом ее особенностей.
Возвращаясь к теме статьи каждое выступление ориентировано на конкретную аудиторию и преследует определенную цель/конверсию, иначе выступление лишено смысла. В ходе подготовки любой лектор часто сталкивается с тем, что что-то забыл, изначально неправильно понимал, но не предавал этому никакого значения и т.п.
Собственно это и иллюстрирует анекдот: «Ну и тупые студенты попались, три раза рассказал, сам все понял...»!-)
Понятно, что есть другой путь, когда приглашаем самого продвинутого инженера, который знает ВСЕ, но… не знает/не может этого объяснить, не умеет работать с аудиторией. Увы, это разные скиллы, способность объяснить другим надо развивать, начинать с коллег, потом вести стажировки, потом переходить к группам.
Возвращаясь к примеру «преподователя по бекенду» я как минимум ожидаю, что он лет 10 ковыряется в его дебрях" у него вполне могут быть пробелы в знаниях, т.к. за 10 лет он понял что нужно (ему), что не нужно (ему), поэтому многие вещи он не помнит или не акцентирует на них внимание, какие-то вещи не счел нужным изучить, т.к. в работе ему они не нужны (а вот в обучении других должен знать хотя бы рамочно).
Учитывая тренд на микросервисы маловероятно, да и скорее спасибо скажет, т.к. проще обновить докер, если конечно все честно вынес на volume, чем отдельно системный софт и продукты Jira. Тут у каждого свой путь!-)
Касательно развертывания Jira я предложил бы просто использовать… докер, просто и быстро, легко обновлять, для небольшой команды проблем вообще не видел, одни плюсы.
Музей воды в СПб включает водонапорную башню, интересный образец современного видения музея.
Можно также посмотреть на курсы на Udemy и т.п. ресурсах, там есть такие же истории, где курс кормит автора (с учетом де-факто околонулевой поддержки аудитории курса), но опять же англоязычные.