Несколько раз задавался вопросу "разница между DevOps и SRE". Так вот, DevOps - это философия доставки продукта до пользователя с сокращением рутины и времени - как можно больше автоматизируя; а SRE - это больше про эксплуатацию продукта на стендах, разбор проблем, метрики
Когда работал в одной из крупных организаций страны (называют себя IT-компанией), то DevOps-инженер автоматизировал пайплайны для доставки продукта на тест-среды и прод, SRE следили чтоб этот продукт отдавал метрики, при ошибках оповещал команду о проблемах. Кратко как-то так
Как по мне, лучше человеку почитать что такое API и познать REST да gRPC, чем всю жизнь не понимать 'что такое gRPC и причём тут API, ведь REST - это API'
К сожалению, это настоящая история как человек на входе не мог усвоить API и понять где здесь gRPC
Мне показалось (или нет), но статья была ради статьи
Допустим, были перечислены либо часто описываемые в вакансиях, либо те пункты, что известно автору, как мне кажется. То есть тут нет какого-то обзора бэкенда вообще:
Пункт про протоколы - описан только HTTP, ну хотя б взять список частых протоколов и предложить прочитать людям для обзорности;
Пункт про БД - только реляционная, а как же разные системы от NoSQL? Redis, Mongo да Neo4J;
Т.д.
Я понимаю, что это статья про "в большинстве случаев". Но много чего не хватает, чтоб человек, взявший этот список, мог называться специалистом. По моему скромному мнению, человек прочитает статью, потратит по 1 дню на каждый пункт и пойдёт на собеседование уверенным что он базу познал. А потом 2 часа испытаний и депрессия :)
P.s.: Молодец что написала. Но смотри самое первое предложение
P.s.s.: Тут нет пункта "думать". Это тот самый инструмент, который отличает Homo sapiens от бездушных машин
С мнением отделения разработчика от тестировщика не согласен
На сегодняшний день системы становятся сложнее и больше. И если будем придерживаться принципа "у каждого своя зона ответственности", то бизнесу разработка будет дороже с каждым витком технологий. И в конечном итоге рынок айти будет сокращаться, а не расти.
Если брать именно разработку нового функционала, то тестер, аналитик и разраб должны быть в диалоге. Это взаимодействие позволяет экономить деньги и выпускать более качественный продукт
Берём ISTQB (допустим) и читаем, что тестирование это одно из основных инструментов обеспечения качества (QA)
Текст из задания "Программисты закончили нашу веб версию, осталось только протестировать." говорит о том, что они видят тестировщика, а не инженера по обеспечению качества
Организаторы не скрывают что они для тестировщиков готовят задания. Даже на кубке что написано?
Если б они назвали "баг хантерс чампс", то было бы лучше?
Если идти по "тестировщиков не бывает! Только куа инженеры", то что придумать для соревнований QA? Интересно мнение
В целом, задачки были из разряда "нам нужно больше багов". Да, может зря они использовали слова "QA" и подобные в статье. Но ребята подошли ответственно. И за этом им отдельный респект. А мы продолжим сидеть на диванчике, пить смузи и хейтить их попытки сделать интересный чемпионат для сообщества куа
Прошу прощения, хотелось бы уточнить - в тексте нет ошибки по сроку существования подставного проекта и датах его раскрутки?
Сразу после того, как закрыли указанную компанию, а с ней — сервисы обмена зашифрованными сообщениями EncroChat и Sky ECC криминальные группировки стали искать альтернативу.
<..>
Волна популярности настигла эти устройства со специализированным ПО на них в марте 2021 года. Полиция закрыла чрезвычайно популярный среди криминала сервис Sky ECC в марте 2021, и преступникам пришлось искать ему замену уже срочно.
<..>
Конечно, переписку изучали не два дня, на это ушло полтора года кропотливой работы.
Несколько лет назад надумывал заниматься фрилансем (одноклассник показывал пример). Но подумал что не вывезу конкуренцию и будет всё зря. А оказалось вот как :)
Статья передаёт мой личный опыт начинающим специалистам. В статье нет какой-то технической информации, я преследую цель нетворка и объясняю какие-то (по-моему мнению нужные) основные вещи
В статье я ссылаюсь на абсолютно разных людей с разным опытом и разным способом обмена информации с сообществом. Можно ли найти эти ссылки на просторах интернета? Да, можно. Но ссылок гораздо больше, чем я предоставил. Порой информация на некоторых ресурсах совсем теоретическая и/или довольно низкого качества
на работу тебя возьмут приналичии а) молодость, б) знакомство
Много историй о том как тестировщиком стали люди в возрасте 30-40 лет, меняя профессию с продажника/охранника. Да, начать работать в 50 лет — это как раз в большей вероятности через знакомых
Если хотите стать тестировщиком и Вам это «по зубам», то, пожалуйста, учитесь! Я не утверждаю «учитесь на курсах», а сами: попить чай за чтением книжек (Романа Савина и/или Святослава Куликова), прочитать статью перед сном на Хабре и в течение дня попробовать новый инструмент или попытаться устроиться асессором-тестировщиком сервисов Яндекс/стать бета-тестером во Вконтакте/начать работу на платформе краундтестинга
Согласен с Вашим мнением. Но я чаще читал что нанимателям начинающих специалистов нужен человек, который потратил время на своё обучение, а не пошёл на курсы. Есть несколько объяснений:
Разобрался в сложностях
Теперь есть опыт поиска информации (архиважно)
Смена профессии для соискателя дороже (потратил много сил и времени)
Вытекающая из списка выше — соискатель не ленивый, а умеет самообразовываться
Года и образование, мне кажется, не основательно решают — мне 25 и окончил колледж на техника по компьютерным системам. Я читал ни одну историю, когда тестировщиком становились люди в возрасте в 30-40 лет при смене профессии, не имея смежного образования в тестировании. Притом слышал истории и в моём городе — Новосибирск
P.s.: ЗП не демпинговал, искал среднерыночную по городу и шёл в соответствии с ней
На такие должности мне кажется надо брать по релевантным знаниям и опыту, а не по возможности протестировать карандашь.
Почему нельзя взять начинающего специалиста с прекрасными софт скиллами (умеет общаться, сам учится, а не ждёт когда ему объяснят и прочее), обучить работе с инструментами и помочь изучить теорию на практике, если позволяют процессы и финансы? А карандаш — это способ увидеть как мыслит человек, а не ответ «брать»/«не брать»
Несколько раз задавался вопросу "разница между DevOps и SRE". Так вот, DevOps - это философия доставки продукта до пользователя с сокращением рутины и времени - как можно больше автоматизируя; а SRE - это больше про эксплуатацию продукта на стендах, разбор проблем, метрики
Когда работал в одной из крупных организаций страны (называют себя IT-компанией), то DevOps-инженер автоматизировал пайплайны для доставки продукта на тест-среды и прод, SRE следили чтоб этот продукт отдавал метрики, при ошибках оповещал команду о проблемах. Кратко как-то так
Как по мне, лучше человеку почитать что такое API и познать REST да gRPC, чем всю жизнь не понимать 'что такое gRPC и причём тут API, ведь REST - это API'
К сожалению, это настоящая история как человек на входе не мог усвоить API и понять где здесь gRPC
Мне показалось (или нет), но статья была ради статьи
Допустим, были перечислены либо часто описываемые в вакансиях, либо те пункты, что известно автору, как мне кажется. То есть тут нет какого-то обзора бэкенда вообще:
Пункт про протоколы - описан только HTTP, ну хотя б взять список частых протоколов и предложить прочитать людям для обзорности;
Пункт про БД - только реляционная, а как же разные системы от NoSQL? Redis, Mongo да Neo4J;
Т.д.
Я понимаю, что это статья про "в большинстве случаев". Но много чего не хватает, чтоб человек, взявший этот список, мог называться специалистом. По моему скромному мнению, человек прочитает статью, потратит по 1 дню на каждый пункт и пойдёт на собеседование уверенным что он базу познал. А потом 2 часа испытаний и депрессия :)
P.s.: Молодец что написала. Но смотри самое первое предложение
P.s.s.: Тут нет пункта "думать". Это тот самый инструмент, который отличает Homo sapiens от бездушных машин
С мнением отделения разработчика от тестировщика не согласен
На сегодняшний день системы становятся сложнее и больше. И если будем придерживаться принципа "у каждого своя зона ответственности", то бизнесу разработка будет дороже с каждым витком технологий. И в конечном итоге рынок айти будет сокращаться, а не расти.
Если брать именно разработку нового функционала, то тестер, аналитик и разраб должны быть в диалоге. Это взаимодействие позволяет экономить деньги и выпускать более качественный продукт
Хендбук по пайтон от Я - ссылка ведёт на курсеру гугла
Кто же мешает вводить?)
Берём совет 1 ака проблема 1. Обсуждаем с командой проблему. Приходим к консенсусу. Завтра же начинаем исправлять проблему
Берём ISTQB (допустим) и читаем, что тестирование это одно из основных инструментов обеспечения качества (QA)
Текст из задания "Программисты закончили нашу веб версию, осталось только протестировать." говорит о том, что они видят тестировщика, а не инженера по обеспечению качества
Организаторы не скрывают что они для тестировщиков готовят задания. Даже на кубке что написано?
Если б они назвали "баг хантерс чампс", то было бы лучше?
Если идти по "тестировщиков не бывает! Только куа инженеры", то что придумать для соревнований QA? Интересно мнение
В целом, задачки были из разряда "нам нужно больше багов". Да, может зря они использовали слова "QA" и подобные в статье. Но ребята подошли ответственно. И за этом им отдельный респект. А мы продолжим сидеть на диванчике, пить смузи и хейтить их попытки сделать интересный чемпионат для сообщества куа
Прошу прощения, хотелось бы уточнить - в тексте нет ошибки по сроку существования подставного проекта и датах его раскрутки?
В статье я ссылаюсь на абсолютно разных людей с разным опытом и разным способом обмена информации с сообществом. Можно ли найти эти ссылки на просторах интернета? Да, можно. Но ссылок гораздо больше, чем я предоставил. Порой информация на некоторых ресурсах совсем теоретическая и/или довольно низкого качества
Благодарю!
Много историй о том как тестировщиком стали люди в возрасте 30-40 лет, меняя профессию с продажника/охранника. Да, начать работать в 50 лет — это как раз в большей вероятности через знакомых
Если хотите стать тестировщиком и Вам это «по зубам», то, пожалуйста, учитесь! Я не утверждаю «учитесь на курсах», а сами: попить чай за чтением книжек (Романа Савина и/или Святослава Куликова), прочитать статью перед сном на Хабре и в течение дня попробовать новый инструмент или попытаться устроиться асессором-тестировщиком сервисов Яндекс/стать бета-тестером во Вконтакте/начать работу на платформе краундтестинга
P.s.: ЗП не демпинговал, искал среднерыночную по городу и шёл в соответствии с ней
Почему нельзя взять начинающего специалиста с прекрасными софт скиллами (умеет общаться, сам учится, а не ждёт когда ему объяснят и прочее), обучить работе с инструментами и помочь изучить теорию на практике, если позволяют процессы и финансы? А карандаш — это способ увидеть как мыслит человек, а не ответ «брать»/«не брать»