Максимально свежее и быстрое видео с конференции E-CODE от меня про GraphQL 🚀
А заодно, и код приложения Rangiffler, на котором можно поупражняться в тестировании.
Традиционно благодарю за frontend (React + Apollo) Иру 🤍
Ставьте звездочки, лайки, нам будет приятно, а кому-то из вас, уверен, полезно 🙌
А заодно, и код приложения Rangiffler, на котором можно поупражняться в тестировании.
Традиционно благодарю за frontend (React + Apollo) Иру 🤍
Ставьте звездочки, лайки, нам будет приятно, а кому-то из вас, уверен, полезно 🙌
❤19🔥12👍8🍓1
Что не так в этом отличном коде из документации Playwright ?
Слово
Проблема-то тут фундаментальнее некуда, асинхронное API в библиотеках для тестов нафиг не нужно. Ну, вот просто не нужно, и все тут. Поэтому миллионы строк кода тестов на PW, Webdriver.IO и прочих сайпрессах - извините за выражение - засраны абсолютно ненужным словом
С удовольствием послушал бы мнения в треде ⬇️
Слово
await в начале каждой строки теста.Проблема-то тут фундаментальнее некуда, асинхронное API в библиотеках для тестов нафиг не нужно. Ну, вот просто не нужно, и все тут. Поэтому миллионы строк кода тестов на PW, Webdriver.IO и прочих сайпрессах - извините за выражение - засраны абсолютно ненужным словом
await в начале каждой строки кода. При этом на других ЯП, имеющие вполне себе рабочую модель асинхронного программирования, почему-то хватает ума библиотеки для тестов делать с обычным (синхронным) API. А может я чего-то не понимаю, и есть смысл делать тестовые билиотеки асинхронными и каждую строчку теста начинать с await? С удовольствием послушал бы мнения в треде ⬇️
👍9👎6🔥3🤔1🍓1
Часто на собесах, когда начинаем плыть в ООП🙂, можно услышать фразу от AQA -
То есть, кроме шуток, многие считают что, если в его языке есть ключевое слово
Если кто-то из прочитавших думает примерно так же, то, я предлагаю к прочтению на выходных одну из самых зацепивших меня книг по IT тематике за последние пару лет: LISP Жемчужины программирования.
Эту книге несложно найти, но, мне понадобилось прочитать ее 3 раза, что бы начать понимать. При том, что она написана легким языком и талантливо, это не какой-то фундаментальный и скучный учебник для ВУЗ-ов. Это интересное погружение в вопрос - что же такое на самом деле функциональное программирование.
Всем советую, даже если вы, в итоге, не напишете ни строчки кода на LISP
ну, я скорее про функциональное программирование, мой {ЯП name} - мультипарадигменный!
Я просто вызываю друг за другом функции.
То есть, кроме шуток, многие считают что, если в его языке есть ключевое слово
fun, или function, то, вызов их друг за другом - это функциональное программирование.Если кто-то из прочитавших думает примерно так же, то, я предлагаю к прочтению на выходных одну из самых зацепивших меня книг по IT тематике за последние пару лет: LISP Жемчужины программирования.
Эту книге несложно найти, но, мне понадобилось прочитать ее 3 раза, что бы начать понимать. При том, что она написана легким языком и талантливо, это не какой-то фундаментальный и скучный учебник для ВУЗ-ов. Это интересное погружение в вопрос - что же такое на самом деле функциональное программирование.
Всем советую, даже если вы, в итоге, не напишете ни строчки кода на LISP
🔥20👍8❤4🍓1
Выступил на Heisenbug. В зале было 43 человека. Это меньше, чем на митапе Ю.money. за пару недель до этого 🙃
Вы, конечно, скажите: Дима, у тебя неинтересная тема.
Что ж, возможно это так.
Потом я сходил к Славе Смирнову и Саше Волкову, и там было примерно столько же.
Мой топ докладов:
Саша Волков
Слава Смирнов
И Артем, если вы, как и я, не слышали про Allure 3.
UPD:
Рекомендации от Лени Руденко по крутым докладам, на которых я сам не был:
Про тестирование Helm чартов
Про тестирование математических библиотек
Развлекательный про гейм-дев
Своим поделюсь, как только выложат👌
Вы, конечно, скажите: Дима, у тебя неинтересная тема.
Что ж, возможно это так.
Потом я сходил к Славе Смирнову и Саше Волкову, и там было примерно столько же.
Мой топ докладов:
Саша Волков
Слава Смирнов
И Артем, если вы, как и я, не слышали про Allure 3.
UPD:
Рекомендации от Лени Руденко по крутым докладам, на которых я сам не был:
Про тестирование Helm чартов
Про тестирование математических библиотек
Развлекательный про гейм-дев
Своим поделюсь, как только выложат👌
Heisenbug 2024 Autumn. Конференция по тестированию не только для тестировщиков
Поиграть в игру != протестировать игру | Доклад на Heisenbug 2024 Autumn
Расскажу об основных участниках разработки игр и покажу на примерах, что тестирование необходимо абсолютно каждой команде.
❤28🔥10🍓1
Всем привет!
16 ноября в Алматы выступаю на конференции CodeTalks.
С ребятами на Квартирнике обсудим реальные проблемы, с которыми сталкиваются QA-инженеры, тест-лиды и команды. Дискуссию проведем в интерактивном формате: участники сами выбирают темы на которые будем говорить и сами непосредственно будут участвовать в обсуждении.
Приходите похоливарить тоже. Буду рад увидеться.
Рега на конфу ещё открыта, вот тут по ссылке — https://2024.codetalks.kz
16 ноября в Алматы выступаю на конференции CodeTalks.
С ребятами на Квартирнике обсудим реальные проблемы, с которыми сталкиваются QA-инженеры, тест-лиды и команды. Дискуссию проведем в интерактивном формате: участники сами выбирают темы на которые будем говорить и сами непосредственно будут участвовать в обсуждении.
Приходите похоливарить тоже. Буду рад увидеться.
Рега на конфу ещё открыта, вот тут по ссылке — https://2024.codetalks.kz
🔥14
#Вакансия
В понедельник открываем вакансию Senior QA Mobile на наш флагманский B2C продукт - мобильное приложение Dodo Pizza.
Приложение работает в 20+ странах и обеспечивает ~95% всех заказов пиццы.
Нужен full stack, осознано готовый заниматься ручным тестированием минимум 50% своего времени, автоматизация у нас Kaspresso (Kotlin) и XCTest (Swift).
Рассматриваем настоящих синьеров с настоящими синьерскими зарплатами 🙂
Если интересно, пишите мне в Л.С. @dtuchs
В понедельник открываем вакансию Senior QA Mobile на наш флагманский B2C продукт - мобильное приложение Dodo Pizza.
Приложение работает в 20+ странах и обеспечивает ~95% всех заказов пиццы.
Нужен full stack, осознано готовый заниматься ручным тестированием минимум 50% своего времени, автоматизация у нас Kaspresso (Kotlin) и XCTest (Swift).
Рассматриваем настоящих синьеров с настоящими синьерскими зарплатами 🙂
Если интересно, пишите мне в Л.С. @dtuchs
👍10
https://youtu.be/nQmrAAggLYA?si=EckxU1yNCgbBDXw8
Запись доклада с митапа Ю.money, который принес мне (и, надеюсь, зрителям) много позитивных эмоций от, казалось бы, скучной темы - про баги. А еще классный шарфик и шапку, в которых я хожу каждый день.
Запись доклада с митапа Ю.money, который принес мне (и, надеюсь, зрителям) много позитивных эмоций от, казалось бы, скучной темы - про баги. А еще классный шарфик и шапку, в которых я хожу каждый день.
YouTube
О чём врут тестировщик...ам? | Дмитрий Тучс
🔥22❤17😁1
Всем привет! Советую посетить стрим нашего Head of Mobile и нашего же преподавателя по ios автоматизации в QA guru.
Будет интересно, инфа сотка
Будет интересно, инфа сотка
Forwarded from QA.GURU | Автоматизация, ручное тестирование, карьера в QA
🚀 Тесты в стартапе: враг скорости или лучший друг? Разберемся на открытом уроке!
Привет! Я Михаил Рубанов, и у меня есть для вас классная идея 🙂
Давайте поговорим про тесты. Нет, не те, которые проверяют терпение вашей команды, а те, которые про код и стартапы. Почему именно стартапы? Потому что это особенный вид безумия: все меняется каждые 15 минут, планы превращаются в хаос, а код пишется так быстро, что за ним почти не успевают тесты.
На самом деле, каждый стартап — как утренний кофе: бодрит, заряжает энергией, но если перестараться, может и потрясти. И да, я знаю, что вы сейчас подумали: "Это стартап, там все быстро меняется, тесты — это лишняя трата времени.". Без тестов хаос растет, баги множатся, а вы потом объясняете пользователям, что эта "фича" — "так и задумано". Так профессионалы дела не делают 🙂
Я — Head of mobile в Dodo Engineering, автор книги "Про доступность iOS", и мне есть чем поделиться. Поэтому приглашаю вас на открытый урок 5 декабря в 20:00 по МСК, где мы:
• Разберем, как стартапы запускаются, почему так страдают и как это можно исправить.
• Поговорим о том, как тесты могут реально ускорять разработку, даже если вы все переписываете каждую неделю.
• Найдем инструменты, которые помогут получать обратную связь быстро, как любимую доставку пиццы.
• И да, честно обсудим, что делать, если тесты писать лень (знаем-знаем, все мы люди).
Приходите, будет весело, легко и, главное, полезно. Жду вас! 😊
Зарегистрироваться на открытый урок
Привет! Я Михаил Рубанов, и у меня есть для вас классная идея 🙂
Давайте поговорим про тесты. Нет, не те, которые проверяют терпение вашей команды, а те, которые про код и стартапы. Почему именно стартапы? Потому что это особенный вид безумия: все меняется каждые 15 минут, планы превращаются в хаос, а код пишется так быстро, что за ним почти не успевают тесты.
На самом деле, каждый стартап — как утренний кофе: бодрит, заряжает энергией, но если перестараться, может и потрясти. И да, я знаю, что вы сейчас подумали: "Это стартап, там все быстро меняется, тесты — это лишняя трата времени.". Без тестов хаос растет, баги множатся, а вы потом объясняете пользователям, что эта "фича" — "так и задумано". Так профессионалы дела не делают 🙂
Я — Head of mobile в Dodo Engineering, автор книги "Про доступность iOS", и мне есть чем поделиться. Поэтому приглашаю вас на открытый урок 5 декабря в 20:00 по МСК, где мы:
• Разберем, как стартапы запускаются, почему так страдают и как это можно исправить.
• Поговорим о том, как тесты могут реально ускорять разработку, даже если вы все переписываете каждую неделю.
• Найдем инструменты, которые помогут получать обратную связь быстро, как любимую доставку пиццы.
• И да, честно обсудим, что делать, если тесты писать лень (знаем-знаем, все мы люди).
Приходите, будет весело, легко и, главное, полезно. Жду вас! 😊
Зарегистрироваться на открытый урок
🔥10
Пост ниже не реклама, точнее не совсем она.
Мы только-только запустили новый поток моего авторского курса java advanced (более 50 занятий от меня и Миши Рубанова) в QA.guru. Если вдруг вы хотели на него попасть, то сейчас самое время успеть, а если вам интересно, что там и как там, приходите в пятницу меня послушать:
🎄 Пирамида тестирования, или как перестать бояться deploy на продакшен и встретить Новый год без багов!
Друзья, привет!
У нас с QA.GURU для вас специальный новогодний подарок – финальный открытый урок в этом году, и он будет суперполезным и праздничным! Уже в эту пятницу, 27 декабря, в 18:00 по МСК, мы разберем, как строить пирамиду тестирования, чтобы ваш код не рухнул, как новогодняя елка, когда на нее прыгнул кот 😼
🎅 Стрим буду вести я🌲
✨ На встрече вы узнаете:
• Как правильно выстроить пирамиду тестирования, чтобы проект держался крепко и уверенно.
• Где заканчиваются юниты, начинаются интеграции и появляется немного end-to-end тестов.
• Какие тесты реально спасают ваши нервы и продакшен, а какие просто красиво смотрятся в отчете.
🎄 Звездой на вершине новогодней елки станет написание тестов для микросервисного Spring Boot проекта Niffler-NG:
• Юнит-тесты (JUnit + Mockito) – чтобы убедиться, что методы работают не хуже, чем новогодние скидки.
• Интеграционные тесты (spring-test + h2db) – чтобы проверить, как работает наше REST API
• End-to-end тесты — чтобы выглядело красиво, а не только просто работало.
И все это за 1 час!
Регистрируйтесь по ссылке и зовите коллег, друзей и всех, кто хочет встретить праздники с прокачанным QA-навыком!
С наступающими праздниками, и до встречи на стриме!
Мы только-только запустили новый поток моего авторского курса java advanced (более 50 занятий от меня и Миши Рубанова) в QA.guru. Если вдруг вы хотели на него попасть, то сейчас самое время успеть, а если вам интересно, что там и как там, приходите в пятницу меня послушать:
🎄 Пирамида тестирования, или как перестать бояться deploy на продакшен и встретить Новый год без багов!
Друзья, привет!
У нас с QA.GURU для вас специальный новогодний подарок – финальный открытый урок в этом году, и он будет суперполезным и праздничным! Уже в эту пятницу, 27 декабря, в 18:00 по МСК, мы разберем, как строить пирамиду тестирования, чтобы ваш код не рухнул, как новогодняя елка, когда на нее прыгнул кот 😼
🎅 Стрим буду вести я🌲
✨ На встрече вы узнаете:
• Как правильно выстроить пирамиду тестирования, чтобы проект держался крепко и уверенно.
• Где заканчиваются юниты, начинаются интеграции и появляется немного end-to-end тестов.
• Какие тесты реально спасают ваши нервы и продакшен, а какие просто красиво смотрятся в отчете.
🎄 Звездой на вершине новогодней елки станет написание тестов для микросервисного Spring Boot проекта Niffler-NG:
• Юнит-тесты (JUnit + Mockito) – чтобы убедиться, что методы работают не хуже, чем новогодние скидки.
• Интеграционные тесты (spring-test + h2db) – чтобы проверить, как работает наше REST API
• End-to-end тесты — чтобы выглядело красиво, а не только просто работало.
И все это за 1 час!
Регистрируйтесь по ссылке и зовите коллег, друзей и всех, кто хочет встретить праздники с прокачанным QA-навыком!
С наступающими праздниками, и до встречи на стриме!
🔥20❤12👍5
Сегодня ровно 3 года в DODO.
Чем я могу гордиться? Успешной борьбой за то, что бы вилки QA Auto и QA Performance были такими же высокими, как у разработчиков. Полным ребилдом наших нагрузочных тестов своими руками, а затем - наймом лида, закрывшего собой вопросы нагрузочного тестирования "под ключ". Вообще, мы собрали очень крутых лидов для всех направлений тестирования (Mobile, Web, Perf и Drinkit). Горжусь выстроенными взаимодействиями с CIO, CTO и продактами, благодаря которым нам не мешают внедрять то, что мы хотим, тестировать - как мы хотим, а мы не мешаем релизить, менять инфру и требования на лету. Технически - внедрили TestOps, Playwright, Kaspresso, написали тестов на flutter приложение курьера, создали уникальное для рынка self-service решение для работы с нагрузкой. Собрали топовую команду тестирования в наш второй по размеру, но не по значимости бизнес - Drinkit - и эта команда завела 574 бага за 2024 год🥲. Мы стали считать баги, и мы не витаем в абстрактных процессах "сделать так, что бы багов не было". Мы стали писать код на собеседованиях. Мы продолжаем релизить ядро нашей системы - DODO IS - без ручного тестирования вообще.
Нас уже 31 QA инженер, мы выросли в 2 раза. Закрываем по 6-7 OKR на свою QA гильдию каждый квартал, и нам все еще есть куда стремиться.
Мы выступаем на конференциях и митапах, и у нет-нет, да и приходят кандидаты, которые хотели бы работать именно с нами.
А я - все еще хочу работать именно в DODO 🍕
Чем я могу гордиться? Успешной борьбой за то, что бы вилки QA Auto и QA Performance были такими же высокими, как у разработчиков. Полным ребилдом наших нагрузочных тестов своими руками, а затем - наймом лида, закрывшего собой вопросы нагрузочного тестирования "под ключ". Вообще, мы собрали очень крутых лидов для всех направлений тестирования (Mobile, Web, Perf и Drinkit). Горжусь выстроенными взаимодействиями с CIO, CTO и продактами, благодаря которым нам не мешают внедрять то, что мы хотим, тестировать - как мы хотим, а мы не мешаем релизить, менять инфру и требования на лету. Технически - внедрили TestOps, Playwright, Kaspresso, написали тестов на flutter приложение курьера, создали уникальное для рынка self-service решение для работы с нагрузкой. Собрали топовую команду тестирования в наш второй по размеру, но не по значимости бизнес - Drinkit - и эта команда завела 574 бага за 2024 год🥲. Мы стали считать баги, и мы не витаем в абстрактных процессах "сделать так, что бы багов не было". Мы стали писать код на собеседованиях. Мы продолжаем релизить ядро нашей системы - DODO IS - без ручного тестирования вообще.
Нас уже 31 QA инженер, мы выросли в 2 раза. Закрываем по 6-7 OKR на свою QA гильдию каждый квартал, и нам все еще есть куда стремиться.
Мы выступаем на конференциях и митапах, и у нет-нет, да и приходят кандидаты, которые хотели бы работать именно с нами.
А я - все еще хочу работать именно в DODO 🍕
🔥82👍10❤8☃1👏1
Про премии 📈
Премии, на мой взгляд, обычно бывают трех видов (с двумя из них я сталкивался в своей работе, третий знаю в теории):
1) Просто "Пришла радость откуда не ждали" - это когда на Новый Год (или ДР компании, или на 8 Марта, в общем, в дени ИКС) всем приходит push из банка о поступлении 13-й з.п. Вне зависимости от должности, успехов и так далее - назовем его условно "благодать ❤️"
2) Когда компания ставит прозрачные цели (всем вместе заработать за квартал 100 рублей, всем вместе продать 3 ящика пива, выкопать 854 метра траншеии и так далее), и если цель достигается - все сотрудники получают push из банка о премии. Тут может быть дифференцацция от стажа, может быть должности - но важно, что это не некий персональный KPI Васи-тестировщика или менеджера, это - компания делится достигнутым успехом со всеми - назовем ее условно "успехшэринг 📈"
3) Когда у конкретного Васи-тестировщика или (что чаще в реальной жизни) менеджера по продажам или рекрутера есть персональный KPI: заведистолько-то багов или автотестов, продай столько-то зановесок, найми столько-то других Василиев. Обычно сопровождается маленьким базовым окладом и премия является неотъемлемой частью совокупного дохода и требует персональной борьбы за KPI. Назовем такую премию "личныйкнутопряник 👔"
Есть еще четвертый тип - у топ-менеджеров C-lvl (чаще CEO/CIO), но, тут не о них.
Так вот, я в своей карьере постоянно встречался с типами 1(благодать) и 2(успехшэринг). И это было клево, клево во всех смыслах - все радовались на новый год, все старались в меру своих сил и талантов помогать компании заработать / выкопать / продать побольше и потом опять-таки радовались.
С типом 3(личныйкнутопряник) я не сталкивался никогда, и есть мнение что это плохо: люди борются только за свою циферку, а не за общий абстрактный успех, начинается непрозрачность, грызня и прочее.
Теперь важный факт: В DODO нет премий. Вообще никаких 🥲
А на вопросы почему - приводятся аргументы о недостатках кнутоприянка, которые объективно есть, но не приводят аргументов о преимуществах двух других типов, которые тоже объективно есть.
Ниже будет опрос, хочу подискутировать 🦆
Премии, на мой взгляд, обычно бывают трех видов (с двумя из них я сталкивался в своей работе, третий знаю в теории):
1) Просто "Пришла радость откуда не ждали" - это когда на Новый Год (или ДР компании, или на 8 Марта, в общем, в дени ИКС) всем приходит push из банка о поступлении 13-й з.п. Вне зависимости от должности, успехов и так далее - назовем его условно "благодать ❤️"
2) Когда компания ставит прозрачные цели (всем вместе заработать за квартал 100 рублей, всем вместе продать 3 ящика пива, выкопать 854 метра траншеии и так далее), и если цель достигается - все сотрудники получают push из банка о премии. Тут может быть дифференцацция от стажа, может быть должности - но важно, что это не некий персональный KPI Васи-тестировщика или менеджера, это - компания делится достигнутым успехом со всеми - назовем ее условно "успехшэринг 📈"
3) Когда у конкретного Васи-тестировщика или (что чаще в реальной жизни) менеджера по продажам или рекрутера есть персональный KPI: заведистолько-то багов или автотестов, продай столько-то зановесок, найми столько-то других Василиев. Обычно сопровождается маленьким базовым окладом и премия является неотъемлемой частью совокупного дохода и требует персональной борьбы за KPI. Назовем такую премию "личныйкнутопряник 👔"
Есть еще четвертый тип - у топ-менеджеров C-lvl (чаще CEO/CIO), но, тут не о них.
Так вот, я в своей карьере постоянно встречался с типами 1(благодать) и 2(успехшэринг). И это было клево, клево во всех смыслах - все радовались на новый год, все старались в меру своих сил и талантов помогать компании заработать / выкопать / продать побольше и потом опять-таки радовались.
С типом 3(личныйкнутопряник) я не сталкивался никогда, и есть мнение что это плохо: люди борются только за свою циферку, а не за общий абстрактный успех, начинается непрозрачность, грызня и прочее.
Теперь важный факт: В DODO нет премий. Вообще никаких 🥲
А на вопросы почему - приводятся аргументы о недостатках кнутоприянка, которые объективно есть, но не приводят аргументов о преимуществах двух других типов, которые тоже объективно есть.
Ниже будет опрос, хочу подискутировать 🦆
😭8❤1🤡1
Если не премии, то что?
Прошлый мой пост про премии был бы не полным без рассуждения о том, что же предлагают нам те работодатели, которые не платят премии, и DODO Brands в частности?
У нас это оклады по верху рынка + опционы.
И в этом новогоднем 🌲посту хочется порассуждать про такую щекотливую тему, как наши оклады, грейды, ну и опционов чуть-чуть коснемся.
10 апреля этого года отвечал на вопрос о зарплатах QA у нас, и без контекста это выглядит действительно странными цифрами: от 128 до 540.
Все дело в том, что позиция QA в нашей сетке грейдов поднимается довольно высоко - от 11 грейда до 7-го (для контекста: C-lvl обитает в 1-4). итого 128 - это минимальная зарплата на 11 грейде, 540 - была максимальной для QA на 7-м. Почему "была"? Потому что на 2025 год у нас будет новая сетка окладов , которая для некоторых грейдов выше до 20% относительно окладов 2024 года.
Итого, отвечая на прямой вопрос - можно ли зарабатывать, скажем, порядка 6000$ будучи QA (да, максимального грейда, то есть техлидом)? Да. Сложно ли это? Безусловно. Но эта возможность закреплена в нашей сетке грейдов, а значит, она есть.😁
Выше рынка ли такие зарплаты? Я считаю, что на данный момент для СНГ рынка - да, а причина тому - именно тот факт что наши C&B (компенсэйшн энд бенефитс) специалисты закладывают премии в оклад.
Почему это лучше?
Потому что вам все равно, в какой месяц увольняться, а не вот это вот "готов выйти вам после декабря или марта", как это часто бывает 😁. Вы в безопасности, потому что сумма прописана в вашем трудовом договоре, и вы рассчитываете на нее, берете кредиты - ипотеки и т.д., а любая премия может быть просто отменена (как и корпоратив).
Допускаю, что в коментах будут те, у кого и оклад 100500, и еще и премии каждый квартал (и я понимаю, что по мировым меркам мы, конечно, не FAANG), но мне хочется верить, что кто-то из вас примет вызов стать QA 7 грейда в DODO в 2025 году.
Всех с новым годом!🎄
Прошлый мой пост про премии был бы не полным без рассуждения о том, что же предлагают нам те работодатели, которые не платят премии, и DODO Brands в частности?
У нас это оклады по верху рынка + опционы.
И в этом новогоднем 🌲посту хочется порассуждать про такую щекотливую тему, как наши оклады, грейды, ну и опционов чуть-чуть коснемся.
10 апреля этого года отвечал на вопрос о зарплатах QA у нас, и без контекста это выглядит действительно странными цифрами: от 128 до 540.
Все дело в том, что позиция QA в нашей сетке грейдов поднимается довольно высоко - от 11 грейда до 7-го (для контекста: C-lvl обитает в 1-4). итого 128 - это минимальная зарплата на 11 грейде, 540 - была максимальной для QA на 7-м. Почему "была"? Потому что на 2025 год у нас будет новая сетка окладов , которая для некоторых грейдов выше до 20% относительно окладов 2024 года.
Итого, отвечая на прямой вопрос - можно ли зарабатывать, скажем, порядка 6000$ будучи QA (да, максимального грейда, то есть техлидом)? Да. Сложно ли это? Безусловно. Но эта возможность закреплена в нашей сетке грейдов, а значит, она есть.😁
Выше рынка ли такие зарплаты? Я считаю, что на данный момент для СНГ рынка - да, а причина тому - именно тот факт что наши C&B (компенсэйшн энд бенефитс) специалисты закладывают премии в оклад.
Почему это лучше?
Потому что вам все равно, в какой месяц увольняться, а не вот это вот "готов выйти вам после декабря или марта", как это часто бывает 😁. Вы в безопасности, потому что сумма прописана в вашем трудовом договоре, и вы рассчитываете на нее, берете кредиты - ипотеки и т.д., а любая премия может быть просто отменена (как и корпоратив).
Допускаю, что в коментах будут те, у кого и оклад 100500, и еще и премии каждый квартал (и я понимаю, что по мировым меркам мы, конечно, не FAANG), но мне хочется верить, что кто-то из вас примет вызов стать QA 7 грейда в DODO в 2025 году.
Всех с новым годом!🎄
❤33🔥12🎄7👍2😁1
#java
Сегодня впервые воспользовался ключевым словом
Я такой - "о, а return из функции
Вывод - советую читать релиз ноуты того, что в вашем резюме, как бы банально это не казалось 🥲
Сегодня впервые воспользовался ключевым словом
yield в Java, описывая банальный switch-case: return switch (action) {
case ADD -> ...;
case ACCEPT -> ...;
case REJECT -> ...;
case DELETE -> {
userDataClient.remove(username, input.username());
yield ...;
}
};
Я такой - "о, а return из функции
-> {} тут уже не работает" и стал смутно вспоминать, что должен же быть какой-то иной способ. Решил погуглить, когда оно там появилось, оказалось что аж в 13 Java - вот так и живешь годами не используя целое ключевое слово.Вывод - советую читать релиз ноуты того, что в вашем резюме, как бы банально это не казалось 🥲
Oracle
JDK Release Notes
This document provides links to the release notes for all versions of the JDK.
👍15❤4💯2
#graphql
Как известно, спецификация graphql предусматривает информирование об ошибке одновременно с возвратом той части данных, которые удалось получить. И, в связи с этим, референсная frontend библиотека apollo даже имеет три стратегии обработки таких ответов:
1️⃣ игнорировать errors, если пришло хоть что-то в data
2️⃣ игнорировать data, если пришло хоть что-то в errors
3️⃣ не игнорировать ничего (и data и errors предлагается обрабатывать самостоятельно как вы хотите)
Глядя на эти политики, меня не покидает ощущение, что варианты 1️⃣ и 2️⃣ как будто сужают спецификацию, что для меня бы, как гипотетического бэкендера, выглядело странно: почему ты игнорируешь то, что я старательно тебе вернул? 😁
А вариант 3️⃣ представлен красивым примерчиком frontend-кода:
Внимание вопрос: если вы работаете с GraphQL, то какая стратегия обработки ошибок используется у вас?
И, если это 3️⃣ (не игнорировать ничего), то весь ваш фронтенд действительно обмазан и обработкой data, и обработкой error для всех запросов, где есть nullable fields?
Как известно, спецификация graphql предусматривает информирование об ошибке одновременно с возвратом той части данных, которые удалось получить. И, в связи с этим, референсная frontend библиотека apollo даже имеет три стратегии обработки таких ответов:
1️⃣ игнорировать errors, если пришло хоть что-то в data
2️⃣ игнорировать data, если пришло хоть что-то в errors
3️⃣ не игнорировать ничего (и data и errors предлагается обрабатывать самостоятельно как вы хотите)
Глядя на эти политики, меня не покидает ощущение, что варианты 1️⃣ и 2️⃣ как будто сужают спецификацию, что для меня бы, как гипотетического бэкендера, выглядело странно: почему ты игнорируешь то, что я старательно тебе вернул? 😁
А вариант 3️⃣ представлен красивым примерчиком frontend-кода:
function ShowingSomeErrors() {
const { loading, error, data } = useQuery(MY_QUERY, { errorPolicy: "all" });
if (loading) return <span>loading...</span>;
return (
<div>
<h2>Good: {data.goodField}</h2>
<pre>
Bad:{" "}
{error.graphQLErrors.map(({ message }, i) => (
<span key={i}>{message}</span>
))}
</pre>
</div>
);
}Внимание вопрос: если вы работаете с GraphQL, то какая стратегия обработки ошибок используется у вас?
И, если это 3️⃣ (не игнорировать ничего), то весь ваш фронтенд действительно обмазан и обработкой data, и обработкой error для всех запросов, где есть nullable fields?
Apollo GraphQL Docs
Handling operation errors
Learn how to manage errors in your application
😁2👍1
Копаясь в вещах случайно обнаружил завалявшуюся часть своих бэйджиков с конференций.
Моей первой крупной конференцией, не считая митапов, был Heisenbug весной 2018 года, где я сразу занял почетное 8 место 😁 из 30+ докладов.
Сейчас за спиной уже около 20 конференций, три программных комитета (прямо сейчас мы готовим QA секцию Codefest.15, пишите, если интересно выступить✍️ ), но, сил делать доклады сейчас почти не осталось. Всю свою энергию рассказывать и делиться я трачу на запись ~50 видосов своего авторского курса. Записывать приходится по вечерам и ночам, вид у меня (как говорят) - усталый, но, таким образом я оцифровываю весь свой технический QA опыт, который неизбежно будет таять с этим менджерством, в котором я уже 4-й год. Об этом, кстати, ни разу не жалею🤘
Предлагаю в треде делиться своими любимыми спикерами и докладами, на любые IT темы. Свой список тоже напишу ⬇️
Моей первой крупной конференцией, не считая митапов, был Heisenbug весной 2018 года, где я сразу занял почетное 8 место 😁 из 30+ докладов.
Сейчас за спиной уже около 20 конференций, три программных комитета (прямо сейчас мы готовим QA секцию Codefest.15, пишите, если интересно выступить✍️ ), но, сил делать доклады сейчас почти не осталось. Всю свою энергию рассказывать и делиться я трачу на запись ~50 видосов своего авторского курса. Записывать приходится по вечерам и ночам, вид у меня (как говорят) - усталый, но, таким образом я оцифровываю весь свой технический QA опыт, который неизбежно будет таять с этим менджерством, в котором я уже 4-й год. Об этом, кстати, ни разу не жалею🤘
Предлагаю в треде делиться своими любимыми спикерами и докладами, на любые IT темы. Свой список тоже напишу ⬇️
👍18🔥10❤6
Раз уж выяснилось, что треды к постам работают как-то странно, то дублирую отдельным постом мой топ спикеров, которых рекомендую к просмотру 📺
Итак, мой топ спикеров (в случайном порядке, со ссылками на некоторые доклады):
Андрей Солнцев - доклады из серии WTF {что-то} - простыми словами про тредпулы, конекшнпулы, архитектуру и кучу всего еще. Доклады про TDD, крутые воркшопы для начинающих;
Владимир Ситников - любые технические доклады про JVM мир. Один из топовых инженеров, кто регулярно делится экспертизой;
Алексей Шипилёв - самое понятное объяснение действительно сложных нюансов JVM - тут про GC, про устройство стринга под капотом и прочие виртуальные потоки;
Егор Бугаенко - если вы считаете его доклады бредом, то вы - это я лет 8-10 назад. Пересматривая его доклады сейчас, я думаю что это ценнейший материал для того, что бы перосмыслить свой код, свои привычки, свой менджмент и это один из тех, ради кого бы персонально я пошел бы и купил билет на конфу;
Евгений Борисов - тут просто топ-1 спикер на русском про Spring, но и не только о нем есть его доклады;
Вячеслав Смирнов - любой доклад технически грамотен, выверен и интересен. Особенно запомнились доклады про JMeter, websocket;
Никита Липский - не самое простое, но интереснейшее погружение в JVM и не только;
Тагир Валеев - тот у кого вы можете бесплатно учиться Java, и автор очень интересных докладов про фичи JDK (и если лень читать релиз ноутсы), тонкости Stream API ;
Евгений Пешков - один из немногих в моем списке совсем не джавист, интересно про перформанс С# и не только;
Иван Пономарёв - очень приятно слушать, темы интересные (есть доклады про testcontainers, про Java и Kotlin)
Роман Елизаров - перед тем, как читать Java Concurrency in Practice, посмотрите его видео про теорию многопоточного программирования, и скорее всего - вы не сможете остановиться
Итак, мой топ спикеров (в случайном порядке, со ссылками на некоторые доклады):
Андрей Солнцев - доклады из серии WTF {что-то} - простыми словами про тредпулы, конекшнпулы, архитектуру и кучу всего еще. Доклады про TDD, крутые воркшопы для начинающих;
Владимир Ситников - любые технические доклады про JVM мир. Один из топовых инженеров, кто регулярно делится экспертизой;
Алексей Шипилёв - самое понятное объяснение действительно сложных нюансов JVM - тут про GC, про устройство стринга под капотом и прочие виртуальные потоки;
Егор Бугаенко - если вы считаете его доклады бредом, то вы - это я лет 8-10 назад. Пересматривая его доклады сейчас, я думаю что это ценнейший материал для того, что бы перосмыслить свой код, свои привычки, свой менджмент и это один из тех, ради кого бы персонально я пошел бы и купил билет на конфу;
Евгений Борисов - тут просто топ-1 спикер на русском про Spring, но и не только о нем есть его доклады;
Вячеслав Смирнов - любой доклад технически грамотен, выверен и интересен. Особенно запомнились доклады про JMeter, websocket;
Никита Липский - не самое простое, но интереснейшее погружение в JVM и не только;
Тагир Валеев - тот у кого вы можете бесплатно учиться Java, и автор очень интересных докладов про фичи JDK (и если лень читать релиз ноутсы), тонкости Stream API ;
Евгений Пешков - один из немногих в моем списке совсем не джавист, интересно про перформанс С# и не только;
Иван Пономарёв - очень приятно слушать, темы интересные (есть доклады про testcontainers, про Java и Kotlin)
Роман Елизаров - перед тем, как читать Java Concurrency in Practice, посмотрите его видео про теорию многопоточного программирования, и скорее всего - вы не сможете остановиться
Telegram
Миша Сидельников in LikeaDuck🦆 Chat
у меня не видится и ссылка из сообщения не кликабельна 🙂 если открыть ее в браузере - то через редиректы - откроется сообщение в chat, где все сообщения, а тут в треде не видно все равно 🙂
🔥61👍10❤6✍2
LikeaDuck🦆 pinned «Раз уж выяснилось, что треды к постам работают как-то странно, то дублирую отдельным постом мой топ спикеров, которых рекомендую к просмотру 📺 Итак, мой топ спикеров (в случайном порядке, со ссылками на некоторые доклады): Андрей Солнцев - доклады из серии…»