Зашёл на страницу рейтинга за 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, и так по несколько раз. Но это уже совсем другая история.
По первым двум абзацам может показаться, что любой добавленный в группу бот становится администратором. Важно понимать, что это не так. В статье речь про сценарий, когда бот намеренно добавляется в роли администратора, но с ограниченными правами.
Спасибо! Первый комментарий и сразу очень сильный аргумент. Но нет ли здесь подмены причины и следствия? Ведь продавец использует телеметрию чтобы корректировать цены, а не наоборот. И если телеметрии у него не будет, корректировать цены он не перестанет. Телеметрия не является причиной проблемы, она является её следствием.
То есть решать это надо с другой стороны: законодательно запрещая персональное завышение цен. Во многих странах такое уже есть. Равно как и многочисленные ограничения по сбору личных данных.
Вопрос-то был не в том, почему это плохо "в принципе". Это как раз более-менее понятно. Вопрос в том, зачем лично мне как пользователю выключать телеметрию. Что мне это даст?
Спасибо! "Возникает неприятное чувство" — это сильный и честный аргумент, и я сейчас серьёзно. Более того, мне кажется, это и есть основная мотивация, просто почему-то её не всегда хотят признавать. Вторая по важности мотивация — идеалистическое представление об анонимности как о базовом праве человека. Вот тут написал об этом более подробно.
Поясню, зачем мне всё это. Когда-то давно я очень заморачивался на теме собственной анонимности: не оставлять в интернете следов, не отправлять данные, вот это всё. Потом оказалось, что для правоохранительных органов найти тебя не проблема, ну а подавляющему большинству людей ты просто не нужен. Ещё позже я совсем отказался от подобных практик.
В результате моё качество жизни как пользователя улучшилось. Никаких негативных последствий я не ощутил, скорее наоборот, и при этом из жизни ушёл огромный пласт тревог и лишних действий, освободились силы на что-то более конструктивное. Однако тревожность апологетов анонимности в инфополе с годами наоборот, только возрастала.
Когда же я стал знакомиться с их аргументацией, оказалось, что она по большей части аксиоматична. Право на анонимность они рассматривают как базовое право человека, которое у него просто должно быть потому что должно, точка. То есть, требование анонимности имеет не прагматические, а скорее морально-этические причины. При этом многие и вовсе не могут отрефлексировать, откуда взялось их мнение, не могут расставить приоритеты в своей аргументации. Их мнение строится на простых аксиомах-лозунгах ("анонимность — хорошо, телеметрия — плохо"), аргументы ищутся под вывод, а не наоборот. Но должно же быть у хабравчан критическое мышление, в конце концов?
Поясню: я хочу не яркий пример, не убедительный аргумент, и не красивую историю из жизни. Хватит давить на эмоции. Я хочу максимально сухой, аналитический ответ на вопрос.
Вопрос был:
Какой практический вред мне причиняет сбор информации браузером?
Ваша версия: "будут показывать всякую стрёмную рекламу, а это может вылиться в конфликт с близкими". Я правильно понял? Что-то не уверен, что именно в этом состоит главная мотивация апологетов анонимности.
Наоборот же, стрёмную рекламу вероятнее будут показывать, если она НЕ таргетируется. Всякую дичь на Ютубе я вижу в основном тогда, когда захожу туда анонимно.
Зашёл на страницу рейтинга за 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, извините.
На Андроид устройствах он есть? Я так сходу не нашёл.
Вы сейчас описали механизм репутации. Её тоже быть не должно?
Спасибо! Первый комментарий и сразу очень сильный аргумент. Но нет ли здесь подмены причины и следствия? Ведь продавец использует телеметрию чтобы корректировать цены, а не наоборот. И если телеметрии у него не будет, корректировать цены он не перестанет. Телеметрия не является причиной проблемы, она является её следствием.
То есть решать это надо с другой стороны: законодательно запрещая персональное завышение цен. Во многих странах такое уже есть. Равно как и многочисленные ограничения по сбору личных данных.
Вопрос-то был не в том, почему это плохо "в принципе". Это как раз более-менее понятно. Вопрос в том, зачем лично мне как пользователю выключать телеметрию. Что мне это даст?
Спасибо! "Возникает неприятное чувство" — это сильный и честный аргумент, и я сейчас серьёзно. Более того, мне кажется, это и есть основная мотивация, просто почему-то её не всегда хотят признавать. Вторая по важности мотивация — идеалистическое представление об анонимности как о базовом праве человека. Вот тут написал об этом более подробно.
Спасибо!
Поясню, зачем мне всё это. Когда-то давно я очень заморачивался на теме собственной анонимности: не оставлять в интернете следов, не отправлять данные, вот это всё. Потом оказалось, что для правоохранительных органов найти тебя не проблема, ну а подавляющему большинству людей ты просто не нужен. Ещё позже я совсем отказался от подобных практик.
В результате моё качество жизни как пользователя улучшилось. Никаких негативных последствий я не ощутил, скорее наоборот, и при этом из жизни ушёл огромный пласт тревог и лишних действий, освободились силы на что-то более конструктивное. Однако тревожность апологетов анонимности в инфополе с годами наоборот, только возрастала.
Когда же я стал знакомиться с их аргументацией, оказалось, что она по большей части аксиоматична. Право на анонимность они рассматривают как базовое право человека, которое у него просто должно быть потому что должно, точка. То есть, требование анонимности имеет не прагматические, а скорее морально-этические причины. При этом многие и вовсе не могут отрефлексировать, откуда взялось их мнение, не могут расставить приоритеты в своей аргументации. Их мнение строится на простых аксиомах-лозунгах ("анонимность — хорошо, телеметрия — плохо"), аргументы ищутся под вывод, а не наоборот. Но должно же быть у хабравчан критическое мышление, в конце концов?
Поясню: я хочу не яркий пример, не убедительный аргумент, и не красивую историю из жизни. Хватит давить на эмоции. Я хочу максимально сухой, аналитический ответ на вопрос.
Вопрос был:
Ваша версия: "будут показывать всякую стрёмную рекламу, а это может вылиться в конфликт с близкими". Я правильно понял? Что-то не уверен, что именно в этом состоит главная мотивация апологетов анонимности.
Наоборот же, стрёмную рекламу вероятнее будут показывать, если она НЕ таргетируется. Всякую дичь на Ютубе я вижу в основном тогда, когда захожу туда анонимно.