Про пункт имитации важности. На моём опыте были люди, которые разговаривали на техническом языке с менеджером. И тут возникало недопонимание. В некоторых компаниях разработка общается с менеджментом через переводчика в лице тех лида, но не везде это так. Поэтому скил простыми словами объяснить сложную штуку весьма востребован бывает) Поэтому такие вопросы и задаются. Там, где это важно. Имитация важности тут не причём)
И как вам тут алгоритмы помогут? Отказоустойчивость проверяется нагрузочным тестированием. Даже идеальный алгоритм захлебнётся, если элементарно не хватит нужных ресурсов.
Если бы вы попробовали в арче разобраться лучше, то осознали бы, что этот дистрибутив вполне себе может использоваться в качестве десктопного. И графические оболочки там те же самые, что и в остальных дистрибутивах, и программы все имеются. Просто после установки вы получаете минимальную систему, на которую уже ставите только то, что вам необходимо. Там не так, как в убунте, куча софта после установки, из которого пользователи могут использовать только малую часть. Этим арч и хорош, что вы ставите только то, что нужно, а не удаляете после установки то, что не нужно. Я успешно его использую на десктопе, кде в минималке и только необходимые программы.
Ну что вы гиперболизируете? Следуя вашей логике, на того, кто отвечает за качество и кто бы это ни был, компания должна подавать в суд. Если отдел QA отвечает за качество, то компания на него должна подавать в суд? Сейчас же этого ни в одной компании не происходит. Ответственность действительно должен нести разработчик, но естественно не материальную, как вы описали. И такие ситуации, когда сроки горят, опытные разработчики сразу менеджера ставят в известность, что при такой постановке качество может пострадать. Грамотный менеджер либо поменяет сроки, либо возьмёт риски на себя. А с неграмотными лучше не работать
Мой вопрос был про то, чем гит для монорепы не походит? Что в нем такого, что не позволяет его использовать для монорепы в сравнении с остальными vcs? Я не писал, что гит — верх совершенства, это вы дофантазировали)
Да, и старайтесь не есть на ночь, как минимум за 3 часа до сна должен быть последний прием пищи. Потребление калорий во все снижено, да и спать с полным желудком плохо. Мозг будет полночи переваривать пищу, и может не успеть наладить процессы метаболизма в организме.
Не нужно соблюдать диету. Можно есть все подряд, но главное правило — дневное потребление калорий не должно превышать их расход. Если вы ведете не особо активный образ жизни и у вас все в порядке с организмом (например, нет диабета), то, потребляя в день не более 2000кал, ваш организм сам отрегулирует вес и начнет сжигать жир. Для подсчета калорий мне отлично помогает мобильное приложение FatSecret. Там есть достаточно большая база готовых блюд, продуктов, овощей и фруктов. Вы можете есть сладкое, просто считайте калории и меряйте вес каждую неделю. Поначалу будет трудно, но потом привыкнете, главное первое время побороть привычку жрать выше меры) Ну и пейте не меньше 1.5 литров воды в день, это очень способствует повышению метаболизма, да и в целом очень полезно.
Вам прежде всего надо скорректировать питание. Тренировки сами по себе мало пользы дают, если вы потребляете большое кол-во калорий и не расходуете их. Поэтому: 1 — сокращаете кол-во потребляемых калорий до 2500-2000 в сутки, 2 — как бонусом добавляете физ нагрузку. Иначе не работает, я пробовал)
Тайпинги не добавляют статической типизации в язык. Это всего лишь подсказки для линтеров и чекеров. Попробуйте определить тайпинг для переменной и записать туда значение другого типа. Питон и глазом не моргнет. И попробуйте то же самое проделать в java. Это и есть статическая типизация. А в питоне просто подсказки для инструментов, сам интерпретатор никак это не проверяет при выполнении
> У вас совершенно очевидно в первой компании был некорректно построен процесс деплоя.
Наверное, вы правы. В первом случае релизили QA, и делали они кумулятивные релизы с несколькими фичами, поскольку так ручное тестирование можно было делать сразу для нескольких фичей (иначе было еще дольше). А во втором — свою фичу тестировал и релизил каждый разработчик самостоятельно, если надо, привлекал кого-то из смежных команд. Поэтому с QA отделом только так, и никак иначе.
> — не так давно (2017г) software developer из GitLab случайно потер 300Гб данных
Эксплуатация кода и эксплуатация инфраструктуры, на котором этот код эксплуатируется — это разные области, и, конечно, за эксплуатацию инфраструктуры должны отвечать не разработчики.
> Сбои бывают у всех, но когда твой бизнес зависит от кого то другого это напрягает
Можно подумать, вы всегда пишите свой фреймворк или свою CI/CD с нуля) Иначе это получается крайне дорогая разработка) Важно перед использованием стороннего инструмента провести всесторонний анализ и оценку рисков при его использовании. И уже тогда делать выбор, если выгода перевешивает риски.
> в итоге в компании вырастет «золушка», которая делает все.
Там написано про то, что профессионалам надо доверять, а не говорить им, как делать свою работу. А если автоматически считать так, как вы, то зона ответственности ваших разработчиков так и останется на уровне написания кода по готовым ТЗ, не понимая, как этот код будет работать и что надо сделать, чтобы код превратился в полноценный продукт как можно быстрее и начал приносить пользу не только пользователям, но и бизнесу.
> А вот это вот «И задачи намного чаще возвращались в разработку из QA» — это недостаток? Ну т.е. тестировщики нашли баги — какие плохие тестировщики?
Конечно недостаток. Если у вас на производстве процент брака очень высокий, такое производство может стать убыточным. Лучше, если большую часть багов находят и исправляют разработчики на этапе разработки. Чем больше ответственности за свой код чувствует разработчик, тем качественнее он проводит тестирование, не надеясь, что все баги найдет QA, а он, если что, потом их исправит. Также у QA не всегда может быть контекст, и чтобы его получить, тратится доп. время на коммуникацию, что опять затягивает релизный цикл.
> И вы серьезно считаете, что если их отменить, то качество кода на проде вырастет?
Ну практика показывает, я же не с пустого места считаю)
> Ну и про маленькие релизы от девелоперов это тоже ниоткуда не вытекает.
Чем меньше конвейер до прода и кол-во звеньев, тем меньше релизный цикл. Если у вас в релизе несколько отделов задействовано, вы автоматически получаете как минимум временные расходы на коммуникацию и синхронизацию.
Мне довелось поработать в компании, в которой был выделенный отдел QA, который кроме тестирования ещё и релизами/деплоями занимался. Еще был выделенный отдел DevOps. Также я сейчас работаю в компании, в которой используется описанный в статье подход. И я могу сравнить оба варианта. В частном случае, все зависит от продукта и рисков. Но в общем, эффективнее подход, описанный в статье. В случае с QA отделом ПО теоретически может быть стабильнее, но начинается интеграционный ад, когда мержаться несколько веток отделом QA, попытка разрулить конфликты, не понимая, как это лучше сделать, начинают привлекать разработчиков, тратя их время. Релизный цикл катастрофически затягивается, и некоторые фичи выкладываются на прод через месяц, когда все тестирование завершается, ибо QA готово тестировать только всю фичу целиком. Релизы редкие, поскольку QA отдел становится узким горлышком. И задачи намного чаще возвращались в разработку из QA. В случае, когда нет QA и релизит сам разработчик-инженер, релизы маленькие и быстрые, по нескольку раз в день могут быть. В статье правильно написано, что, когда на разработчика накладывается ответственность за релиз и проверку, он более ответственно подходит к реализации и тестированию.
Хотя продукты в первом случае и во втором были разные, и в первом случае подход был обусловлен определенными историческими причинами, но анализируя это сейчас и применяя описанный подход в первом проекте, я думаю, скорость доставки была бы намного выше, а качество если бы не осталось на том же уровне, то скорее всего бы даже выросло.
Немного о собеседованиях и совсем чуть-чуть о тестовых заданиях
Про пункт имитации важности. На моём опыте были люди, которые разговаривали на техническом языке с менеджером. И тут возникало недопонимание. В некоторых компаниях разработка общается с менеджментом через переводчика в лице тех лида, но не везде это так. Поэтому скил простыми словами объяснить сложную штуку весьма востребован бывает) Поэтому такие вопросы и задаются. Там, где это важно. Имитация важности тут не причём)
Как именно выглядит предустановка российского ПО на мобильные устройства
Сначала надо рутануть. А это не всегда просто, особенно на новых устройствах
Собеседование в Яндекс: театр абсурда :/
И как вам тут алгоритмы помогут? Отказоустойчивость проверяется нагрузочным тестированием. Даже идеальный алгоритм захлебнётся, если элементарно не хватит нужных ресурсов.
Сражение Linux на поприще Windows
Если бы вы попробовали в арче разобраться лучше, то осознали бы, что этот дистрибутив вполне себе может использоваться в качестве десктопного. И графические оболочки там те же самые, что и в остальных дистрибутивах, и программы все имеются. Просто после установки вы получаете минимальную систему, на которую уже ставите только то, что вам необходимо. Там не так, как в убунте, куча софта после установки, из которого пользователи могут использовать только малую часть. Этим арч и хорош, что вы ставите только то, что нужно, а не удаляете после установки то, что не нужно. Я успешно его использую на десктопе, кде в минималке и только необходимые программы.
На ком лежит ответственность за качество программного обеспечения?
Ну что вы гиперболизируете? Следуя вашей логике, на того, кто отвечает за качество и кто бы это ни был, компания должна подавать в суд. Если отдел QA отвечает за качество, то компания на него должна подавать в суд? Сейчас же этого ни в одной компании не происходит. Ответственность действительно должен нести разработчик, но естественно не материальную, как вы описали. И такие ситуации, когда сроки горят, опытные разработчики сразу менеджера ставят в известность, что при такой постановке качество может пострадать. Грамотный менеджер либо поменяет сроки, либо возьмёт риски на себя. А с неграмотными лучше не работать
«А ты точно senior?»
Мой вопрос был про то, чем гит для монорепы не походит? Что в нем такого, что не позволяет его использовать для монорепы в сравнении с остальными vcs? Я не писал, что гит — верх совершенства, это вы дофантазировали)
«А ты точно senior?»
Мне действительно интересно стало, чем гит для монорепы не угодил?)
Физкультура для программиста, есть ли хороший выход?
Физкультура для программиста, есть ли хороший выход?
Физкультура для программиста, есть ли хороший выход?
Физкультура для программиста, есть ли хороший выход?
Brython: заменяем JavaScript на Python на фронтенде
Тайпинги не добавляют статической типизации в язык. Это всего лишь подсказки для линтеров и чекеров. Попробуйте определить тайпинг для переменной и записать туда значение другого типа. Питон и глазом не моргнет. И попробуйте то же самое проделать в java. Это и есть статическая типизация. А в питоне просто подсказки для инструментов, сам интерпретатор никак это не проверяет при выполнении
Разработка должна ориентироваться на продакшен, всё остальное — чушь
Наверное, вы правы. В первом случае релизили QA, и делали они кумулятивные релизы с несколькими фичами, поскольку так ручное тестирование можно было делать сразу для нескольких фичей (иначе было еще дольше). А во втором — свою фичу тестировал и релизил каждый разработчик самостоятельно, если надо, привлекал кого-то из смежных команд. Поэтому с QA отделом только так, и никак иначе.
Разработка должна ориентироваться на продакшен, всё остальное — чушь
> — не так давно (2017г) software developer из GitLab случайно потер 300Гб данных
Эксплуатация кода и эксплуатация инфраструктуры, на котором этот код эксплуатируется — это разные области, и, конечно, за эксплуатацию инфраструктуры должны отвечать не разработчики.
> Сбои бывают у всех, но когда твой бизнес зависит от кого то другого это напрягает
Можно подумать, вы всегда пишите свой фреймворк или свою CI/CD с нуля) Иначе это получается крайне дорогая разработка) Важно перед использованием стороннего инструмента провести всесторонний анализ и оценку рисков при его использовании. И уже тогда делать выбор, если выгода перевешивает риски.
> в итоге в компании вырастет «золушка», которая делает все.
Там написано про то, что профессионалам надо доверять, а не говорить им, как делать свою работу. А если автоматически считать так, как вы, то зона ответственности ваших разработчиков так и останется на уровне написания кода по готовым ТЗ, не понимая, как этот код будет работать и что надо сделать, чтобы код превратился в полноценный продукт как можно быстрее и начал приносить пользу не только пользователям, но и бизнесу.
Разработка должна ориентироваться на продакшен, всё остальное — чушь
Конечно недостаток. Если у вас на производстве процент брака очень высокий, такое производство может стать убыточным. Лучше, если большую часть багов находят и исправляют разработчики на этапе разработки. Чем больше ответственности за свой код чувствует разработчик, тем качественнее он проводит тестирование, не надеясь, что все баги найдет QA, а он, если что, потом их исправит. Также у QA не всегда может быть контекст, и чтобы его получить, тратится доп. время на коммуникацию, что опять затягивает релизный цикл.
> И вы серьезно считаете, что если их отменить, то качество кода на проде вырастет?
Ну практика показывает, я же не с пустого места считаю)
> Ну и про маленькие релизы от девелоперов это тоже ниоткуда не вытекает.
Чем меньше конвейер до прода и кол-во звеньев, тем меньше релизный цикл. Если у вас в релизе несколько отделов задействовано, вы автоматически получаете как минимум временные расходы на коммуникацию и синхронизацию.
Разработка должна ориентироваться на продакшен, всё остальное — чушь
Ну в статье не написано, что тесты не нужны. Скорее наоборот, там про автоматизацию ручных тестов.
Разработка должна ориентироваться на продакшен, всё остальное — чушь
Хотя продукты в первом случае и во втором были разные, и в первом случае подход был обусловлен определенными историческими причинами, но анализируя это сейчас и применяя описанный подход в первом проекте, я думаю, скорость доставки была бы намного выше, а качество если бы не осталось на том же уровне, то скорее всего бы даже выросло.
О роли CTO (главного инженера / технического директора)
У нас вроде нет рабства. Если вас заставляют заниматься тем, что вам не нравится, всегда можно сменить компанию.
В iOS 14 можно поставить Chrome браузером по умолчанию
Ну наконец-то! Давно от Apple революционных фич не было!)
Планшет как основной компьютер
Веб версия уже давно не отстаёт от десктоп поделия, и вроде даже не падает, в браузере ж)