Действительно. Зачем делать готовый удобный продукт в привычном формате? Могли просто исходники скинуть, кому надо, сбилдит себе!
Я просто привык к комфорту. Уже 2025-й год и даже многие бесплатные open-source продуты распространяются в формате пакетов для установки. Я ожидаю deb или snap, кто-то другой будет ставить себе rpm или flatpak. Конечно, мир linux обширен и я понимаю, что некоторым ребятам действительно всё это не нужно, но мне важно удобство установки, обновления, удаления на конкретной операционной системе.
Мало того, что это банальный обзор на игру, больше уместный для игрового журнала, нежели для Хабра, так в нём ещё и нет ничего нового, ведь игра вышла ещё в прошлом году (скоро будет позапрошлый) и сам обзор не блещет оригинальностью и просто повторяет основные тезисы из других таких же обзоров.
Не понятно, почему всё расписано для Windows. Если это тестирование веб-сервисов, то логично было бы сразу описывать настройку ci/cd для какого-нибудь тестового стенда на linux. Собственно основная мысль - запустить коллекции постмана в ньюмане и отправить результаты в testIt. Это буквально пару команд. И видимо это костыль, призванный как-то автоматизировать ручную работу тестировщиков. Самому приходилось делать что-то похожее на Groovy. В итоге всё же усложнение бизнес-процесса привело к идее, что написать нормальные автотесты проще, чем поддерживать такие вот костыли в ci/cd.
Вроде бы встречал такую инструкцию много раз в сети. Как насчёт того, чтобы настроить не только отправку, но и приём писем для автоматической обработки в приложении? Это более редкий случай, но зато хоть что-то новое было бы.
Я так понимаю, цель исследования - доказать каким-то образом, что выборы неверно посчитали. Результат исследования - явка вполне правдоподобна. К чему тогда заключительный абзац? Или думаете, что специально мало людей выделили на организацию? Тогда можно было пойти дальше и сравнить с предыдущими годами. Больше явка или меньше? Можно ли было предугадать резкий рост количества избирателей?
Любопытный текст. Даж не подозревал о существовании QA Architect. Их и обычных мало, а тут прям QA. Я бы конечно несколько иначе структурировано статью. Я всегда считал, что если вы у потолка, то очевидно вы уже Automation QA. Собственно все последующие пункты предполагают умение писать код. Сомневаюсь, что кто-то из Manual QA сразу пойдёт в архитекторы, минуя стадию написания автотестов. Ну и естественно, как бывший свитчер, не могу не указать, что иногда, если ты понимаешь, что дальше расти уже некуда, то стоит попробовать шагнуть в сторону разработки или аналитики (не только с упором на QA), смотря куда больше тянет.
Базовые Unit-тесты неплохо описаны, но эту тему конечно надо развивать. Хотелось бы увидеть статьи про интеграционные и e2e-тесты, различные фреймворки и т.д..
Ну это очень просто, прям очевидно. Это даже до простого уровня не дотягивает. Лучше б написал статью "Как я вошёл в IT после курсов, не зная элементарных вещей".
Если вы, как и я раньше, наивно полагаете, что потенциальные рекрутеры хотя бы откроют ваш гитхаб, то глубоко ошибаетесь. Подавляющему большинству из них на это плевать. Если и делать README, то не для работодателя (ему нужен коммерческий опыт) и не для пользователя (ему хорошо бы интерактивное обучение в самом приложении и интуитивно-понятный интерфейс), а для отработки навыков (тогда описание нужно делать для себя, чтоб потом быстро найти и вспомнить) или для решения прикладной задачи, которая может пригодится другим разработчикам (тогда хорошо бы писать нормальный читаемый код и добавлять примеры использования). В любом случае, оформление из статьи не может служить хорошим примером.
Если бы вторая причина была надуманной, то давно бы написали множество привычных офисных программ для непродвинутого пользователя. А пока что даже офисные пакеты часто некорректно сохраняют и открывают файлы в форматах MS Office. Что уж говорить о более сложных продуктах.
Серьёзно? Гайд на тему, как установить на Андроид приложение не из Google Play?
Однако же на официальном сайте есть предложение скачать в виде пакета для Ubuntu. Думаю, некоторое участие JetBrains тут всё же есть.
Действительно. Зачем делать готовый удобный продукт в привычном формате? Могли просто исходники скинуть, кому надо, сбилдит себе!
Я просто привык к комфорту. Уже 2025-й год и даже многие бесплатные open-source продуты распространяются в формате пакетов для установки. Я ожидаю deb или snap, кто-то другой будет ставить себе rpm или flatpak. Конечно, мир linux обширен и я понимаю, что некоторым ребятам действительно всё это не нужно, но мне важно удобство установки, обновления, удаления на конкретной операционной системе.
IDE Cбера ходит за плагинами на серваки JetBrains, где вестимо получает ошибку доступа. Там своего только плагин для их ИИ GIGA Chat.
Ну и собрать deb или snap пакет для linux они не осилили, тупо бинарник. Про OpenIDE автор это не упомянул, так что я надеюсь на лучшее.
Мало того, что это банальный обзор на игру, больше уместный для игрового журнала, нежели для Хабра, так в нём ещё и нет ничего нового, ведь игра вышла ещё в прошлом году (скоро будет позапрошлый) и сам обзор не блещет оригинальностью и просто повторяет основные тезисы из других таких же обзоров.
И на основе какой выборки эта статистика?
Не понятно, почему всё расписано для Windows. Если это тестирование веб-сервисов, то логично было бы сразу описывать настройку ci/cd для какого-нибудь тестового стенда на linux. Собственно основная мысль - запустить коллекции постмана в ньюмане и отправить результаты в testIt. Это буквально пару команд. И видимо это костыль, призванный как-то автоматизировать ручную работу тестировщиков. Самому приходилось делать что-то похожее на Groovy. В итоге всё же усложнение бизнес-процесса привело к идее, что написать нормальные автотесты проще, чем поддерживать такие вот костыли в ci/cd.
Вроде бы встречал такую инструкцию много раз в сети. Как насчёт того, чтобы настроить не только отправку, но и приём писем для автоматической обработки в приложении? Это более редкий случай, но зато хоть что-то новое было бы.
Новость конечно хорошая. Радостно, что на русском языке. На каких площадках будет продаваться игра в России? Не будет ли игра эксклюзивом для VKPlay?
Очень интересно и познавательно. Но сам так я делать конечно не буду. IDEA наше всё.
Я так понимаю, цель исследования - доказать каким-то образом, что выборы неверно посчитали. Результат исследования - явка вполне правдоподобна. К чему тогда заключительный абзац? Или думаете, что специально мало людей выделили на организацию? Тогда можно было пойти дальше и сравнить с предыдущими годами. Больше явка или меньше? Можно ли было предугадать резкий рост количества избирателей?
Полезно. Нашёл свою ошибку, спасибо за статью.
Любопытный текст. Даж не подозревал о существовании QA Architect. Их и обычных мало, а тут прям QA. Я бы конечно несколько иначе структурировано статью. Я всегда считал, что если вы у потолка, то очевидно вы уже Automation QA. Собственно все последующие пункты предполагают умение писать код. Сомневаюсь, что кто-то из Manual QA сразу пойдёт в архитекторы, минуя стадию написания автотестов. Ну и естественно, как бывший свитчер, не могу не указать, что иногда, если ты понимаешь, что дальше расти уже некуда, то стоит попробовать шагнуть в сторону разработки или аналитики (не только с упором на QA), смотря куда больше тянет.
Базовые Unit-тесты неплохо описаны, но эту тему конечно надо развивать. Хотелось бы увидеть статьи про интеграционные и e2e-тесты, различные фреймворки и т.д..
Тема интересная. Сам с Камундой не работал, но было бы интересно почитать ещё статьи на эту тему.
Ну это очень просто, прям очевидно. Это даже до простого уровня не дотягивает. Лучше б написал статью "Как я вошёл в IT после курсов, не зная элементарных вещей".
Вижу статью в поддержку строгой типизации - ставлю плюс.
Если вы, как и я раньше, наивно полагаете, что потенциальные рекрутеры хотя бы откроют ваш гитхаб, то глубоко ошибаетесь. Подавляющему большинству из них на это плевать. Если и делать README, то не для работодателя (ему нужен коммерческий опыт) и не для пользователя (ему хорошо бы интерактивное обучение в самом приложении и интуитивно-понятный интерфейс), а для отработки навыков (тогда описание нужно делать для себя, чтоб потом быстро найти и вспомнить) или для решения прикладной задачи, которая может пригодится другим разработчикам (тогда хорошо бы писать нормальный читаемый код и добавлять примеры использования). В любом случае, оформление из статьи не может служить хорошим примером.