Не факт, что он не знает, может быть, для него его идея важнее, чем все репозитории мира вместе взятые. Если послушать его доклад, то сначала идет мотивировочная часть (типа, ООП, чтобы было проще разобраться) потом идет основная часть (например, пишите вместо статических функций, объектные ориентированные обертки, которые эквивалентны лениво вычисляемым статическим функциям семантически, но без выигрышей от ленивости) которая противоречит "проще разобраться". А когда ему указывают на противеоречие, он вместо аргументов использует эмоции или вообще ответ сводится к "я так вижу"
Совершенно верно. Поэтому можно поверх что SQL, что HQL построить репозиорий с какими-нибудь ограниченными запросами. Но дело в том, что SQL тогда останется не протестированным, а его бы тоже хотелось.
В случае [хорошего] ORM у нас есть слой, который представляет таблички и запросы в системе типов, в случае прямого SQL у нас такого нет.
По мне, работа этих сервисов показатель ограниченности пользователей. Если я вчера посмотрел боевик, то сегодня мне, скорее всего, захочется чего-нибудь другого.
Теперь вернемся к степени солености пищи. Как вы считаете, один и тот же человек предпочитает одну и ту же соленость или разную для одного и того же блюда? У кого больше возможностей учесть предпочтения - у повара, который солит по своему вкусу или у киберповара с загруженным профилем пользователя?
Смотрите, во-первых, странно видеть утверждение, что что-то не работает на основании одного примера. Это как сказать, что отвертка не работает потому, что она бесполезна, когда надо забить гвоздь. Я могу привести пример, когда рекомендательные сервисы работают. Например навигатор достаточно часто угадывает куда я хочу ехать.
Во-вторых, в самом примере логика достаточно странная. Если я что-от посмотрел вчера оно мне может быть нужно сегодня. Кроме того случая, когда оно потребляется смотрением типа фильма. Коньяк вроде пьют а не смотрят обычно.
В-третьих, любой рандомный товар мне тоже "скорее всего" не нужен. И вопрос - насколько это "скорее всего" больше или меньше чем "скорее всего" у коньяка. Например, я посморел но не выбрал. Или я регулярный покупатель коньяков и он мне нужен будет завтра. Или я регулярный покупатель коньяков и запомню марку до следующего раза. Короче надо сравнивать вероятность успешность продажи у коньяка и у случайной рекламы.
В-четвертых, странно, что все делают рекомендательные сервисы. Вряд ли они все дурачки.
Естественный язык появился как способ записывать звук. Даже если мы его формализуем то в нум останется легаси вот этой последовательной одномерности.
Имхо плюс может быть только в пороге входа. А минус - эта последовательная одномерность (конечно есть костыли в виде всякого форматирования, но все равно если порог входа и так большой - как в математике - то лучше уж переориентировать систему обозначений на визуальную).
Возможно так же сама похожесть на естестенный язык будет не только помогать но и мешать. Разные неформальные оттенки значений которые присутствуют в естестенном языке будут накладываться на на формализованные значения. Я думаю, именно поэтому даже для обычных слов в науке вводят какие-то специальные термины
Очевидно солить по вкусу. Вкус берется в настройках или выводится по предыдущим лайкам конкретного пользователя или обобщенного профиля целевой аудитории. См. как рекомендательные фичи работают.
Угу. Негативная мотивация. Показывать позитив нельзя. Надо стращать негативом. Для этого нанимать наглядное пособие по цене зарплата программиста * k + цена найма и увольнения.
ИМХО, если человек работает на результат, до него можно достучаться логикой (дать попробовать его идею, показать, к чему приводит, прислушаться к нему попробовать найти рациональное зерно, показать ограничения и достигнуть консенсуса). Если он не работает, то надо избавляться на этапе испытательного
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
Это и есть "содержать цикл". Программа тоже не выполняется сама, она декларирует наличие цикла. Чтобы его выполнить нужен какой-то интерпретатор - компьютер или человек может в уме выполнить.
а если разработчики не понимают как оценивать задачи из-за того что не знают как именно будут их решать?
Скрам мастер должен умет учить команду как ей самоуправляться. Один из аспектов самоуправления - умение планировать. Соответственно, он должен знать техники планирования.
Менеджер предложит оформить задачу как исследовательскую и отказаться от её оценки
Да. Это называется spikes. Это как раз один из приемов оценки. Такой же как и использование менее точных единиц измерения. По ссылке еще про backlog refinement.
Тимлид же засчёт технических навыков и опыта может подсказать решение тем самым устранив неопределённость при оценке вместо борьбы с её симптомами.
Тимлид может как иметь так и не иметь технических навыков. эксперт по технологиям может как быть так и не быть тимлидом.
Задача тимлида организовать получение этих знаний из специалиста, если он есть или другим образом, если его нет. Задача скрам мастера - научить команду саму организовывать получение знаний
Не совсем. Скрам не является интерфейсом. Скрам содержит код игрового цикла, который требует наличия реализации интерфейса.
Скрам мастер это разновидность менеджера, по крайней мере так метание считают.
Опытный мастер - опытный менеджер. Неопытный мастер - неопытный менеджер. Как и любой менеджер он не обязан быть специалистом в чем-то ещё, чтобы быть полезным но это ему поможет.
Не факт, что он не знает, может быть, для него его идея важнее, чем все репозитории мира вместе взятые. Если послушать его доклад, то сначала идет мотивировочная часть (типа, ООП, чтобы было проще разобраться) потом идет основная часть (например, пишите вместо статических функций, объектные ориентированные обертки, которые эквивалентны лениво вычисляемым статическим функциям семантически, но без выигрышей от ленивости) которая противоречит "проще разобраться". А когда ему указывают на противеоречие, он вместо аргументов использует эмоции или вообще ответ сводится к "я так вижу"
Совершенно верно. Поэтому можно поверх что SQL, что HQL построить репозиорий с какими-нибудь ограниченными запросами. Но дело в том, что SQL тогда останется не протестированным, а его бы тоже хотелось.
В случае [хорошего] ORM у нас есть слой, который представляет таблички и запросы в системе типов, в случае прямого SQL у нас такого нет.
Так в C# то же самое. Автор просто не понял что HQL объектный поверх объектов
Меня тоже удивляет, что Егор пользуется популярностью. По-моему, типичный Кулибин, что в программировании, что в управлении
«В вашей работе много нового и верного. К сожалению, то, что в ней верно, – то неново, а то, что ново, – то неверно»
Мозговой штурм - это конкретная техника в состав которой водят определенные этапы и ведущий.
Теперь вернемся к степени солености пищи. Как вы считаете, один и тот же человек предпочитает одну и ту же соленость или разную для одного и того же блюда? У кого больше возможностей учесть предпочтения - у повара, который солит по своему вкусу или у киберповара с загруженным профилем пользователя?
Смотрите, во-первых, странно видеть утверждение, что что-то не работает на основании одного примера. Это как сказать, что отвертка не работает потому, что она бесполезна, когда надо забить гвоздь. Я могу привести пример, когда рекомендательные сервисы работают. Например навигатор достаточно часто угадывает куда я хочу ехать.
Во-вторых, в самом примере логика достаточно странная. Если я что-от посмотрел вчера оно мне может быть нужно сегодня. Кроме того случая, когда оно потребляется смотрением типа фильма. Коньяк вроде пьют а не смотрят обычно.
В-третьих, любой рандомный товар мне тоже "скорее всего" не нужен. И вопрос - насколько это "скорее всего" больше или меньше чем "скорее всего" у коньяка. Например, я посморел но не выбрал. Или я регулярный покупатель коньяков и он мне нужен будет завтра. Или я регулярный покупатель коньяков и запомню марку до следующего раза. Короче надо сравнивать вероятность успешность продажи у коньяка и у случайной рекламы.
В-четвертых, странно, что все делают рекомендательные сервисы. Вряд ли они все дурачки.
Естественный язык появился как способ записывать звук. Даже если мы его формализуем то в нум останется легаси вот этой последовательной одномерности.
Имхо плюс может быть только в пороге входа. А минус - эта последовательная одномерность (конечно есть костыли в виде всякого форматирования, но все равно если порог входа и так большой - как в математике - то лучше уж переориентировать систему обозначений на визуальную).
Возможно так же сама похожесть на естестенный язык будет не только помогать но и мешать. Разные неформальные оттенки значений которые присутствуют в естестенном языке будут накладываться на на формализованные значения. Я думаю, именно поэтому даже для обычных слов в науке вводят какие-то специальные термины
Очевидно солить по вкусу. Вкус берется в настройках или выводится по предыдущим лайкам конкретного пользователя или обобщенного профиля целевой аудитории. См. как рекомендательные фичи работают.
Чем меньше непривычных. А это уже зависит от того, к чему привык
А почему это сложнее просто запоминания какого-то отдельного слова?
Оптимист!
"СПОСОБНОСТЬ К ДОВЕРИЮ И ПОДЧИНЕНИЮ
Учитель лучше знает, что для тебя хорошо, а что плохо. Поэтому надо делать то, что говорит учитель. Даже если тебе кажется, что он не прав. "
Угу. Негативная мотивация. Показывать позитив нельзя. Надо стращать негативом. Для этого нанимать наглядное пособие по цене зарплата программиста * k + цена найма и увольнения.
ИМХО, если человек работает на результат, до него можно достучаться логикой (дать попробовать его идею, показать, к чему приводит, прислушаться к нему попробовать найти рациональное зерно, показать ограничения и достигнуть консенсуса). Если он не работает, то надо избавляться на этапе испытательного
А как его творение через код ресью проходило? Или он не код творил?
Чем?
Скрам гайд:
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
Это и есть "содержать цикл". Программа тоже не выполняется сама, она декларирует наличие цикла. Чтобы его выполнить нужен какой-то интерпретатор - компьютер или человек может в уме выполнить.
Скрам мастер должен умет учить команду как ей самоуправляться. Один из аспектов самоуправления - умение планировать. Соответственно, он должен знать техники планирования.
Да. Это называется spikes. Это как раз один из приемов оценки. Такой же как и использование менее точных единиц измерения. По ссылке еще про backlog refinement.
Тимлид может как иметь так и не иметь технических навыков. эксперт по технологиям может как быть так и не быть тимлидом.
Задача тимлида организовать получение этих знаний из специалиста, если он есть или другим образом, если его нет. Задача скрам мастера - научить команду саму организовывать получение знаний
Не совсем. Скрам не является интерфейсом. Скрам содержит код игрового цикла, который требует наличия реализации интерфейса.
Скрам мастер это разновидность менеджера, по крайней мере так метание считают.
Опытный мастер - опытный менеджер. Неопытный мастер - неопытный менеджер. Как и любой менеджер он не обязан быть специалистом в чем-то ещё, чтобы быть полезным но это ему поможет.
https://www.scrum.org/resources/blog/scrum-master-manager