Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод.
Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Есть много подходов. В Tunk Based Development есть только мастер, очень удобная методология кстати.
Во-вторых, что вы делаете, если синьор уволился? Говорите мидлу: "Гарри, ты теперь синьор"? И повышаете ли ему зп? Или он просто начинает работать за себя и за того парня? Или вы нанимаете больше стажёров? Сколько стажёров может заменить синьора?
В-третьих, если вы будете нанимать только стажёров, не боитесь технического застоя в компании? У стажёров нет опыта. А новые специалисты с рынка могут принести в компанию в том числе и новые подходы, чтобы проект эволюционировал.
Автор как-то уж очень смахивает на какого-то инфоцыгана. Во всех статьях одна тема - текущие процессы найма против людей, обращайтесь ко мне я сделаю так что вы их пройдёте (научу крутить опыт в резюме). Ну и ссылка на телеграм-канал, куда же без неё.
Была бы хорошая программа, если бы можно было не покупать курсы. Но тут hh надо придумывать другой фильтр бесконечного потока вайтишников. По поводу трудовой, мне кажется, что устройство по ГПХ довольно распространено и это учитывают. Накрученный опыт тоже в трудовой не отразиться.
Вообще накручивать опыт это что-то из вредных советов.
Когда я кликнул на статью с этим заголовком, я ожидал разное: проблемы в процессах собеседования, плохое отношение, обман с вакансией, плохие условия оффера. А оказалось, что вы изначально не хотели туда идти. Слегка разочарован.
Первый вопрос который надо задать при геймификации, а нужна ли тут геймификация? Ответ: скорее всего не нужна. Просто это сейчас модно.
И вот везде, где такой объективный результат есть – там можно применять соревнования, баллы, турнирные таблицы, челленджи, задания и прочее-прочее-прочее. Не забывая про награду.
Мне очень нравится книга "Игрофикация в бизнесе и жизни", там показано что ОРЗ (Очки, Рейтинги, Значки) могут плохо отразится в долгосрочной перспективе на процессах.
Рейтинги плохо влияют на командную работу (а мы как правило собираем людей вместе, чтобы они работали сообща), и могут вызвать нежелательное соперничество вместо кооперации. Очки очень быстро из награды превратятся в обыденность, и надо будет повышать награды, а их отсутствие будет восприниматься как наказание (а мы знаем, что наказание демотивирует сильнее, чем мотивирует награда).
В общем, перед применением игрофикации лучше 100 раз подумать, а нужна ли она вообще, каких целей нужно достичь. ОСОБЕННО в рабочих процессах.
Нужно ещё пользователя заставить запустить своего бота, а телеграм будет рассылать от сервисной учётки. Плюс у телеги есть лимиты на отправку сообщений ботами, что может быть проблемой для крупных сервисов.
А в чём оказуаливание? У каждого решения есть свои цели. Если хотим устроить хаос на чистом везении — берём честный рандом, и пофиг, что одному повезёт с первой попытки, другому с тысячной. Хотим, чтобы игроку выпали и меч, и щит, и броня, и шлем? Берём пул.
Всё так, тут можно играть с размером бесконечно. От этого зависит сколько может быть одинаковых событий подряд, как часто будет пересекаться линия целевой вероятности и прочее
Не уверен, насколько это оно, но есть такой проект НЯН - https://github.com/NyanNyanovich/nyan. Он по умолчанию настроен на парсинг новостных каналов, но можно сконфигурировать любую подборку. Агрегирует одинаковые по смыслу посты с разных каналов в один со ссылками, в выжимки за промежутки он тоже умеет.
Хорошо если так. Не думаю что вам заслуженно заминусовали карму, но статью вполне. Поставьте себя на место человека, который интересуется парсерами на python, что даст ему ваша статья? В материале представлен клиент для вызова api stackexchange, не более, и таких материалов на разных ресурсах уже сотни. Надеюсь данный неудачный опыт поможет писать более ценные статьи для сообщества.
Очень попахивает нейронкой. Новая chatgpt o1 выдаёт ответы примерно в таком же формате: сначала по кусочкам с объяснением каждого, потом полный код программы. Да и сама статья непонятно какую цель преследует.
Проблема всё же есть хотя бы в непопулярности форматтеров.
В Java наиболее популярным решением для проверки code-style кажется считается checkstyle. Но checkstyle не форматтер.
Результаты по поиску форматтера для Kotlin сразу два решения, которые более менее стандарты в индустрии
В Java... данная тема не пользуется популярностью
Почему в Java форматтеры не так популярны? Возможно как раз из-за качества инструментов. Сам я эту тему пока только планировал покопать, но надеюсь что вынесу что-то из обсуждения к данной статье.
Статья интересная, но, пожалуйста, только нигде не используйте этот вариант. Лучше возьмите что-то из уже существующего и более менее распространённого.
Винду окончательно дропнул всего несколько месяцев назад. Сейчас пользуюсь линуксом и макосью. И запрос "как *сделать что-то* в *название ОС*" у меня регулярный для всех трёх операционок, когда дело касается выхода за границы повседневного использования (сёрфинг, игры, написание кода).
Имхо, современные ОС достаточно сложны, чтобы делать с ней какие-то более менее сложные вещи без интернета.
Я буквально так работаю уже много лет.
Как-то всё очень категорично
Мне кажется релиз по инициативе разработчика нажатием одной кнопки в CI это уже стандарт по индустрии.
Есть много подходов. В Tunk Based Development есть только мастер, очень удобная методология кстати.
Во-первых стажёры это хорошо.
Во-вторых, что вы делаете, если синьор уволился? Говорите мидлу: "Гарри, ты теперь синьор"? И повышаете ли ему зп? Или он просто начинает работать за себя и за того парня? Или вы нанимаете больше стажёров? Сколько стажёров может заменить синьора?
В-третьих, если вы будете нанимать только стажёров, не боитесь технического застоя в компании? У стажёров нет опыта. А новые специалисты с рынка могут принести в компанию в том числе и новые подходы, чтобы проект эволюционировал.
Конкретики бы. На какую позицию собеседуетесь? На каком рынке? Сколько лет опыта?
Автор как-то уж очень смахивает на какого-то инфоцыгана. Во всех статьях одна тема - текущие процессы найма против людей, обращайтесь ко мне я сделаю так что вы их пройдёте (научу крутить опыт в резюме). Ну и ссылка на телеграм-канал, куда же без неё.
Была бы хорошая программа, если бы можно было не покупать курсы. Но тут hh надо придумывать другой фильтр бесконечного потока вайтишников. По поводу трудовой, мне кажется, что устройство по ГПХ довольно распространено и это учитывают. Накрученный опыт тоже в трудовой не отразиться.
Вообще накручивать опыт это что-то из вредных советов.
Что на работе выдают, с тем и работаем
Когда я кликнул на статью с этим заголовком, я ожидал разное: проблемы в процессах собеседования, плохое отношение, обман с вакансией, плохие условия оффера. А оказалось, что вы изначально не хотели туда идти. Слегка разочарован.
Первый вопрос который надо задать при геймификации, а нужна ли тут геймификация? Ответ: скорее всего не нужна. Просто это сейчас модно.
Мне очень нравится книга "Игрофикация в бизнесе и жизни", там показано что ОРЗ (Очки, Рейтинги, Значки) могут плохо отразится в долгосрочной перспективе на процессах.
Рейтинги плохо влияют на командную работу (а мы как правило собираем людей вместе, чтобы они работали сообща), и могут вызвать нежелательное соперничество вместо кооперации. Очки очень быстро из награды превратятся в обыденность, и надо будет повышать награды, а их отсутствие будет восприниматься как наказание (а мы знаем, что наказание демотивирует сильнее, чем мотивирует награда).
В общем, перед применением игрофикации лучше 100 раз подумать, а нужна ли она вообще, каких целей нужно достичь. ОСОБЕННО в рабочих процессах.
Или всё-таки нетворкинг?
Нужно ещё пользователя заставить запустить своего бота, а телеграм будет рассылать от сервисной учётки. Плюс у телеги есть лимиты на отправку сообщений ботами, что может быть проблемой для крупных сервисов.
А в чём оказуаливание? У каждого решения есть свои цели. Если хотим устроить хаос на чистом везении — берём честный рандом, и пофиг, что одному повезёт с первой попытки, другому с тысячной. Хотим, чтобы игроку выпали и меч, и щит, и броня, и шлем? Берём пул.
Всё так, тут можно играть с размером бесконечно. От этого зависит сколько может быть одинаковых событий подряд, как часто будет пересекаться линия целевой вероятности и прочее
Не уверен, насколько это оно, но есть такой проект НЯН - https://github.com/NyanNyanovich/nyan. Он по умолчанию настроен на парсинг новостных каналов, но можно сконфигурировать любую подборку. Агрегирует одинаковые по смыслу посты с разных каналов в один со ссылками, в выжимки за промежутки он тоже умеет.
Хорошо если так. Не думаю что вам заслуженно заминусовали карму, но статью вполне. Поставьте себя на место человека, который интересуется парсерами на python, что даст ему ваша статья? В материале представлен клиент для вызова api stackexchange, не более, и таких материалов на разных ресурсах уже сотни. Надеюсь данный неудачный опыт поможет писать более ценные статьи для сообщества.
Очень попахивает нейронкой. Новая chatgpt o1 выдаёт ответы примерно в таком же формате: сначала по кусочкам с объяснением каждого, потом полный код программы. Да и сама статья непонятно какую цель преследует.
Проблема всё же есть хотя бы в непопулярности форматтеров.
В Java наиболее популярным решением для проверки code-style кажется считается checkstyle. Но checkstyle не форматтер.
Результаты по поиску форматтера для Kotlin сразу два решения, которые более менее стандарты в индустрии
В Java... данная тема не пользуется популярностью
Почему в Java форматтеры не так популярны? Возможно как раз из-за качества инструментов. Сам я эту тему пока только планировал покопать, но надеюсь что вынесу что-то из обсуждения к данной статье.
Самый нормальный критерий, на мой взгляд - результаты собесов. Если готовы брать мидлом, значит мидл, если готовы синьором - значит синьор.
Статья интересная, но, пожалуйста, только нигде не используйте этот вариант. Лучше возьмите что-то из уже существующего и более менее распространённого.
Винду окончательно дропнул всего несколько месяцев назад. Сейчас пользуюсь линуксом и макосью. И запрос "как *сделать что-то* в *название ОС*" у меня регулярный для всех трёх операционок, когда дело касается выхода за границы повседневного использования (сёрфинг, игры, написание кода).
Имхо, современные ОС достаточно сложны, чтобы делать с ней какие-то более менее сложные вещи без интернета.