В двадцать лет я тоже вынашивал кучу очень интересных (как мне казалось) идей. Сейчас мне сорок, и ни одна из этих идей так и не была реализована. Зато я понял, почему:
Идеи дёшевы. Очень наивно было полагать, что некая идея пришла ко мне в голову единственному во всём мире. Если чего-то нет — вряд ли это потому, что никто просто не додумался так сделать. Скорее всего для этого существуют другие причины. Понять их помогут референсы и анализ рынка.
Обязательно нужно сформулировать, в чём идея конкретно. Если ограничиваться общими словами, получится как в анекдоте про сову "я стратегией занимаюсь". Очень часто оказывалось, что идея — на самом деле не идея даже, а желание, ощущение, какие-то фантазии, которые хотелось бы видеть в мире, нередко идущие от отрицания (не нравится то, что есть). При этом чёткого понимания того, как конкретно это должно работать, не было.
Если сейчас у меня нет времени и навыков для проработки идеи — они не появятся в будущем сами из ниоткуда. Ждать бессмысленно, скорее будет наоборот — окажется занято то время, которое есть сейчас. Время и навыки появятся, только если сам целенаправлено выстроил систему, ведущую к их появлению.
Отсюда имеем важность референсов — надо изучать аналогичные решения, которые уже есть. Узнавать про авторов, у которых получилось. Смотреть, как это произошло, и что для этого было нужно.
Почему-то в статье их упомянуто очень мало, хотя озвученная идея (живой мир) в том или ином приближении есть много где. Навскидку в голову приходят такие игры как:
Shadows of Doubt, огромный живой город, где игрок — просто один из его жителей
Mount & Blade: Warband, игрок — наёмник в живом мире фентезийного средневековья
Серия X, где игрок — пилот корабля в целой галактике, живущей по своим законам
Kenshi, где игрок странствует по постапокалиптической пустыне
Middle-earth: Shadow of Mordor, где игрока могут фармить НПЦ и повышать свой статус
Dwarf Fortress, где и мир, и все его жители, и даже история и мифы генерируются процедурно и существуют по своим законам. При этом есть режим, когда игрок представляет не колонию, а конкретного персонажа.
Dwarf Fortress вообще очень знаковый проект, давший начало целому жанру. Очень долго (лет 15) его разрабатывал фактически один человек. Именно разрабатывал, а не вынашивал идеи.
Вообще концепт "ИИ играет наравне с игроком" не такой уж редкий. В той же серии Civilization ИИ-игроки — это полноправные участники, играющие по тем же правилам. Стоит упоминания Songs Of Syx, где с одной стороны есть равноправные игроки-правители, а с другой каждый житель — это самостоятельно живущая сущность со своими интересами.
Вот примерный чеклист, по которому стоит пройтись в процессе проработки идеи:
Зачем? Какую проблему я пытаюсь решить?
Эта проблема есть только у меня, или у других людей тоже?
Как её решают другие люди?
Что я хочу предложить в качестве решения?
Как именно предлагаемый механизм ведёт к решению?
Как будет выглядеть минимально рабочая реализация?
Чего будет стоить такая реализация? Оценить сроки.
Не приведёт ли она к другим проблемам, которые перечеркнут полученную ценность?
Какие примеры уже есть? Привели ли они к решению? Если нет, то почему?
Зашёл на страницу рейтинга за 2023 год — а там "огромных" компаний 20 штук против всего 106 "небольших", что делает конкретно данный комментарий невалидным. Но на Хабре удалять комментарии нельзя, так что пусть висит.
Увы, но это манипуляция статистикой. Медианная оценка взята не от всех компаний, а от топ 10. Естественно, что в топ 1% (лучшие 10 в выборке из 1000) будут результаты выше, чем в топ 20% (лучшие 10 в выборке из 50). Но в отчёте этого не видно, поэтому кажется, что в целом в маленьких компаниях работать лучше.
Не лучший выбор — начинать с аналогии, умолчав о том, что это аналогия. Мы сразу ставим человека в неправильный контекст, и когда в объяснении наконец появится "софт", слушатель будет обескуражен. Если подходить к задаче более системно, то первое, что нужно сделать — это обозначить тематику: компьютеры, серверы и сети, ПО. Скорее всего этого будет достаточно.
Но, как говорится, "отрицаешь — предлагай". Вот как бы я объяснил, что такое Kubernetes, человеку, который работал с компьютерными устройствами только как пользователь:
«Почти все имели дело с компьютерными программами (приложениями). Но кроме персональных компьютеров и смартфонов есть ещё серверы, за счёт которых все эти системы работают через интернет. На серверах тоже есть свои программы, которые сейчас принято организовывать в т.н. контейнерах — это механизм, упрощающий запуск и развёртывание программ. Контейнеры тут — это не физические коробки, это такие виртуальные сущности внутри сервера. Так вот, Kubernetes помогает работать с этими контейнерами — автоматически создаёт их, запускает, останавливает и т.д. Это может быть нужно, если контейнеров много, или управлять ими нужно в реальном времени — например, в зависимости от нагрузки.»
сделайте форки их актуальных версий для себя хотя бы на Гитхабе
А форки вышеупомянутых закрытых репозиториев выжили? В статье свидетельств этому я не увидел. То, что их закрыли одномоментно, наводит на мысль, что это было сделано централизованно, то есть через сам Гитхаб.
Что возможно, ведь Гитхаб уже блокировал Иран, когда отношение США с ним были в острой фазе, а сейчас США ведёт экономическую войну с Китаем.
Я не могу однозначно ответить «нет», так как не знаю, что происходит в голове у человека, но мне на такое не жаловались.
Цель code review — убедиться, что написанный код понятен другим участникам команды. Если код непонятен, а вопросы не задаются из страха перед коллегами — это тревожный симптом, который может являться частью большей проблемы.
Мой опыт разработки (больше восьми лет в разных командах) показывает, что лучше всего работает т.н. peer review — когда код проверяет коллега твоего же уровня. В этом случае роли чётко разделены:
Автор кода целиком несёт ответственность за свой код. Однако он не может оценить читаемость — для него его код всегда понятен — поэтому привлекает коллегу для code review.
Ревьюер читает код и убеждается, что код понятен и ему тоже. Он заинтересован в этом, потому что в дальнейшем ему скорее всего придётся поддерживать данный код. Но саму реализацию он не проверяет, доверяя коллеге как эксперту.
Поддержка уровня читаемости кода — задача, с которой code review справляется, не добавляя лишних проблем.
Другой допустимый вариант: когда старший разработчик выступает ментором для джуна. В этом случае он проверяет работу джуна целиком, включая весь написанный им код. Но это уже не совсем code review, это скорее проверка навыков ученика, то есть преподавательская деятельность. Тут роли тоже ясны — ментор готов тратить своё время на обучение джуна, а джун хочет научиться. Ответственность за качество итогового кода ментор целиком и полностью берёт на себя.
Проблемы начинаются, когда на code review пытаются навесить другие функции, пытаясь таким образом удешевить разработку — сэкономить на сеньорах или тестировщиках. Часто это выглядит так:
Есть несколько миддлов, которые не дотягивают до уровня проекта, но были наняты за неимением лучшего (например, других не заинтересовали предлагаемые условия).
Есть один сеньор, который прекрасно ориентируется в проекте, но не успевает всё делать сам.
Руководство вешает на сеньора обязанность проверять за миддлами их работу, надеясь таким образом и разгрузить сеньора, и не упасть в качестве.
В итоге имеем описанный в статье букет: приходится переделывать уже написанный код, миддлы демотивируются, портятся отношения в команде, сеньор всё равно перегружен, не всегда ясно кто ответственен за ошибки в коде.
Исправить это со стороны процесса не получится, т.к. причины проблемы не организационные. Но есть способы облегчить ситуацию:
Сеньору целенаправленно выделять время для работы с миддлами. Принять, что это теперь его основная обязанность.
Миддлам обсуждать с сеньором реализацию до написания кода, а не после.
Не играть в "бокс по переписке" в комментариях к ревью. Любой диалог длиннее двух реплик должен проходить в формате в очной встречи или созвона.
Автоматизировать линтерами всё, что можно. Настроить прекоммит-хук, чтобы неправильно отформатированный код в принципе не мог попасть в ветку. Не тратить время на проверку code style на ревью.
Писать юнит-тесты и настроить CI/CD на каждый пуш. Приступать к ревью только по факту успешного прохождения тестов.
Отдельный разговор про тестирование — ведь задачу могут вернуть на доработку, что повлечёт за собой новый цикл code review, и так по несколько раз. Но это уже совсем другая история.
По первым двум абзацам может показаться, что любой добавленный в группу бот становится администратором. Важно понимать, что это не так. В статье речь про сценарий, когда бот намеренно добавляется в роли администратора, но с ограниченными правами.
Спасибо! Первый комментарий и сразу очень сильный аргумент. Но нет ли здесь подмены причины и следствия? Ведь продавец использует телеметрию чтобы корректировать цены, а не наоборот. И если телеметрии у него не будет, корректировать цены он не перестанет. Телеметрия не является причиной проблемы, она является её следствием.
То есть решать это надо с другой стороны: законодательно запрещая персональное завышение цен. Во многих странах такое уже есть. Равно как и многочисленные ограничения по сбору личных данных.
Вопрос-то был не в том, почему это плохо "в принципе". Это как раз более-менее понятно. Вопрос в том, зачем лично мне как пользователю выключать телеметрию. Что мне это даст?
Спасибо! "Возникает неприятное чувство" — это сильный и честный аргумент, и я сейчас серьёзно. Более того, мне кажется, это и есть основная мотивация, просто почему-то её не всегда хотят признавать. Вторая по важности мотивация — идеалистическое представление об анонимности как о базовом праве человека. Вот тут написал об этом более подробно.
В двадцать лет я тоже вынашивал кучу очень интересных (как мне казалось) идей. Сейчас мне сорок, и ни одна из этих идей так и не была реализована. Зато я понял, почему:
Идеи дёшевы. Очень наивно было полагать, что некая идея пришла ко мне в голову единственному во всём мире. Если чего-то нет — вряд ли это потому, что никто просто не додумался так сделать. Скорее всего для этого существуют другие причины. Понять их помогут референсы и анализ рынка.
Обязательно нужно сформулировать, в чём идея конкретно. Если ограничиваться общими словами, получится как в анекдоте про сову "я стратегией занимаюсь". Очень часто оказывалось, что идея — на самом деле не идея даже, а желание, ощущение, какие-то фантазии, которые хотелось бы видеть в мире, нередко идущие от отрицания (не нравится то, что есть). При этом чёткого понимания того, как конкретно это должно работать, не было.
Если сейчас у меня нет времени и навыков для проработки идеи — они не появятся в будущем сами из ниоткуда. Ждать бессмысленно, скорее будет наоборот — окажется занято то время, которое есть сейчас. Время и навыки появятся, только если сам целенаправлено выстроил систему, ведущую к их появлению.
Отсюда имеем важность референсов — надо изучать аналогичные решения, которые уже есть. Узнавать про авторов, у которых получилось. Смотреть, как это произошло, и что для этого было нужно.
Почему-то в статье их упомянуто очень мало, хотя озвученная идея (живой мир) в том или ином приближении есть много где. Навскидку в голову приходят такие игры как:
Shadows of Doubt, огромный живой город, где игрок — просто один из его жителей
Mount & Blade: Warband, игрок — наёмник в живом мире фентезийного средневековья
Серия X, где игрок — пилот корабля в целой галактике, живущей по своим законам
Kenshi, где игрок странствует по постапокалиптической пустыне
Middle-earth: Shadow of Mordor, где игрока могут фармить НПЦ и повышать свой статус
Dwarf Fortress, где и мир, и все его жители, и даже история и мифы генерируются процедурно и существуют по своим законам. При этом есть режим, когда игрок представляет не колонию, а конкретного персонажа.
Dwarf Fortress вообще очень знаковый проект, давший начало целому жанру. Очень долго (лет 15) его разрабатывал фактически один человек. Именно разрабатывал, а не вынашивал идеи.
Вообще концепт "ИИ играет наравне с игроком" не такой уж редкий. В той же серии Civilization ИИ-игроки — это полноправные участники, играющие по тем же правилам. Стоит упоминания Songs Of Syx, где с одной стороны есть равноправные игроки-правители, а с другой каждый житель — это самостоятельно живущая сущность со своими интересами.
Вот примерный чеклист, по которому стоит пройтись в процессе проработки идеи:
Зачем? Какую проблему я пытаюсь решить?
Эта проблема есть только у меня, или у других людей тоже?
Как её решают другие люди?
Что я хочу предложить в качестве решения?
Как именно предлагаемый механизм ведёт к решению?
Как будет выглядеть минимально рабочая реализация?
Чего будет стоить такая реализация? Оценить сроки.
Не приведёт ли она к другим проблемам, которые перечеркнут полученную ценность?
Какие примеры уже есть? Привели ли они к решению? Если нет, то почему?
Что я понял из статьи:
Люди не занимаются "полезными" делами из-за недостатка мотивации.
Дефицит дофамина вызывает недостаток мотивации.
Чтобы стало больше мотивации, надо ещё больше усилить дефицит дофамина.
Зашёл на страницу рейтинга за 2023 год — а там "огромных" компаний 20 штук против всего 106 "небольших", что делает конкретно данный комментарий невалидным. Но на Хабре удалять комментарии нельзя, так что пусть висит.
Увы, но это манипуляция статистикой. Медианная оценка взята не от всех компаний, а от топ 10. Естественно, что в топ 1% (лучшие 10 в выборке из 1000) будут результаты выше, чем в топ 20% (лучшие 10 в выборке из 50). Но в отчёте этого не видно, поэтому кажется, что в целом в маленьких компаниях работать лучше.
Не лучший выбор — начинать с аналогии, умолчав о том, что это аналогия. Мы сразу ставим человека в неправильный контекст, и когда в объяснении наконец появится "софт", слушатель будет обескуражен. Если подходить к задаче более системно, то первое, что нужно сделать — это обозначить тематику: компьютеры, серверы и сети, ПО. Скорее всего этого будет достаточно.
Но, как говорится, "отрицаешь — предлагай". Вот как бы я объяснил, что такое Kubernetes, человеку, который работал с компьютерными устройствами только как пользователь:
«Почти все имели дело с компьютерными программами (приложениями). Но кроме персональных компьютеров и смартфонов есть ещё серверы, за счёт которых все эти системы работают через интернет. На серверах тоже есть свои программы, которые сейчас принято организовывать в т.н. контейнерах — это механизм, упрощающий запуск и развёртывание программ. Контейнеры тут — это не физические коробки, это такие виртуальные сущности внутри сервера. Так вот, Kubernetes помогает работать с этими контейнерами — автоматически создаёт их, запускает, останавливает и т.д. Это может быть нужно, если контейнеров много, или управлять ими нужно в реальном времени — например, в зависимости от нагрузки.»
А форки вышеупомянутых закрытых репозиториев выжили? В статье свидетельств этому я не увидел. То, что их закрыли одномоментно, наводит на мысль, что это было сделано централизованно, то есть через сам Гитхаб.
Что возможно, ведь Гитхаб уже блокировал Иран, когда отношение США с ним были в острой фазе, а сейчас США ведёт экономическую войну с Китаем.
«Да не согласен я. — С кем? С Энгельсом или с Каутским? — С обоими»
Даже если сразу это непонятно, то при первой же ошибке (проблемы со связью, перегрузка севера или отказ в обслуживании) становится очевидно.
ИИ-системы общаются между собой? Или же пассаж от DALL-E — это просто заранее написанный человеком промпт к ChatGPT для генерации сообщения об ошибке?
Не "включили", а обновили до версии 11.8. Во вступительном абзаце написано правильно, а в пункте в "основных нововведениях" странности.
Я не могу однозначно ответить «нет», так как не знаю, что происходит в голове у человека, но мне на такое не жаловались.
Цель code review — убедиться, что написанный код понятен другим участникам команды. Если код непонятен, а вопросы не задаются из страха перед коллегами — это тревожный симптом, который может являться частью большей проблемы.
Мой опыт разработки (больше восьми лет в разных командах) показывает, что лучше всего работает т.н. peer review — когда код проверяет коллега твоего же уровня. В этом случае роли чётко разделены:
Автор кода целиком несёт ответственность за свой код. Однако он не может оценить читаемость — для него его код всегда понятен — поэтому привлекает коллегу для code review.
Ревьюер читает код и убеждается, что код понятен и ему тоже. Он заинтересован в этом, потому что в дальнейшем ему скорее всего придётся поддерживать данный код. Но саму реализацию он не проверяет, доверяя коллеге как эксперту.
Поддержка уровня читаемости кода — задача, с которой code review справляется, не добавляя лишних проблем.
Другой допустимый вариант: когда старший разработчик выступает ментором для джуна. В этом случае он проверяет работу джуна целиком, включая весь написанный им код. Но это уже не совсем code review, это скорее проверка навыков ученика, то есть преподавательская деятельность. Тут роли тоже ясны — ментор готов тратить своё время на обучение джуна, а джун хочет научиться. Ответственность за качество итогового кода ментор целиком и полностью берёт на себя.
Проблемы начинаются, когда на code review пытаются навесить другие функции, пытаясь таким образом удешевить разработку — сэкономить на сеньорах или тестировщиках. Часто это выглядит так:
Есть несколько миддлов, которые не дотягивают до уровня проекта, но были наняты за неимением лучшего (например, других не заинтересовали предлагаемые условия).
Есть один сеньор, который прекрасно ориентируется в проекте, но не успевает всё делать сам.
Руководство вешает на сеньора обязанность проверять за миддлами их работу, надеясь таким образом и разгрузить сеньора, и не упасть в качестве.
В итоге имеем описанный в статье букет: приходится переделывать уже написанный код, миддлы демотивируются, портятся отношения в команде, сеньор всё равно перегружен, не всегда ясно кто ответственен за ошибки в коде.
Исправить это со стороны процесса не получится, т.к. причины проблемы не организационные. Но есть способы облегчить ситуацию:
Сеньору целенаправленно выделять время для работы с миддлами. Принять, что это теперь его основная обязанность.
Миддлам обсуждать с сеньором реализацию до написания кода, а не после.
Дробить работу на задачи меньшего размера.
Сеньору прокачивать навыки ненасильственного общения.
Не играть в "бокс по переписке" в комментариях к ревью. Любой диалог длиннее двух реплик должен проходить в формате в очной встречи или созвона.
Автоматизировать линтерами всё, что можно. Настроить прекоммит-хук, чтобы неправильно отформатированный код в принципе не мог попасть в ветку. Не тратить время на проверку code style на ревью.
Писать юнит-тесты и настроить CI/CD на каждый пуш. Приступать к ревью только по факту успешного прохождения тестов.
Отдельный разговор про тестирование — ведь задачу могут вернуть на доработку, что повлечёт за собой новый цикл code review, и так по несколько раз. Но это уже совсем другая история.
По первым двум абзацам может показаться, что любой добавленный в группу бот становится администратором. Важно понимать, что это не так. В статье речь про сценарий, когда бот намеренно добавляется в роли администратора, но с ограниченными правами.
Putty в 2023-м году уже не особо актуальна. В Windows 10/11 из коробки есть ssh-клиент, равно как и неплохой терминал.
Отбой, увидел Keepass2Android, извините.
На Андроид устройствах он есть? Я так сходу не нашёл.
Вы сейчас описали механизм репутации. Её тоже быть не должно?
Спасибо! Первый комментарий и сразу очень сильный аргумент. Но нет ли здесь подмены причины и следствия? Ведь продавец использует телеметрию чтобы корректировать цены, а не наоборот. И если телеметрии у него не будет, корректировать цены он не перестанет. Телеметрия не является причиной проблемы, она является её следствием.
То есть решать это надо с другой стороны: законодательно запрещая персональное завышение цен. Во многих странах такое уже есть. Равно как и многочисленные ограничения по сбору личных данных.
Вопрос-то был не в том, почему это плохо "в принципе". Это как раз более-менее понятно. Вопрос в том, зачем лично мне как пользователю выключать телеметрию. Что мне это даст?
Спасибо! "Возникает неприятное чувство" — это сильный и честный аргумент, и я сейчас серьёзно. Более того, мне кажется, это и есть основная мотивация, просто почему-то её не всегда хотят признавать. Вторая по важности мотивация — идеалистическое представление об анонимности как о базовом праве человека. Вот тут написал об этом более подробно.