0. Вместо введения

Уважаемые читатели, рад вас приветствовать в новой статье. Этот материал является продолжением предыдущей публикации, посвященной замыканиям. В данной части обзора мы углубимся в тему декораторов.

Эта статья написана в первую очередь для тех, кто только начинает свой путь в программировании или начал изучать Python. Потому здесь я не буду рассматривать декораторы классов, чтобы сделать материал более доступным для новичков. Тем не менее, для тех, кто изучит данную статью, не составит труда разобраться в декораторах классов, так как они не имеют существенных отличий от рассматриваемых здесь декораторов функций.

Многопоточность является важной частью современных приложений, позволяя использовать преимущества, такие как параллельное выполнение задач и повышенная отзывчивость пользовательского интерфейса. Однако, работая с несколькими потоками одновременно, мы сталкиваемся со специфическими проблемами безопасности и синхронизации.

Поводом для ревизии данного вопроса стало то, что я по сей день слышу от специалистов (в том числе позиционирующих себя как senior), что современный JavaScript является однопоточным. При этом они охотно задают этот вопрос на техническом интервью, вводя неуверенных кандидатов в заблуждение.

В этот раз я достаточно внимательно прочитал перевод главы про задачи(Tasks) из этого Поста, чтобы выяснить, что он не очень точно передает смысл исходного текста. Я попробую пересказать содержание так, как я его понял, в том числе полагаясь на свой практический опыт программирования многопоточных приложений и embedded приложений с множеством прерываний.

Мне кажется, я придумал хороший формат, чтобы совместить свой пересказ содержания достаточно близко к смыслу исходного текста (надеюсь), с моими комментариями-разъяснениями-догадками.

Пару ссылок на предыдущие работы по этой теме вы тоже найдете под катом.

Я рискну все таки продолжить изложение своего понимания Поста: How Async/Await Really Works in C#, которое в предыдущей статье получило название “ортогональный взгляд”. Также, недавно мы познакомились (возможно несколько преждевременно) с изначальным определением концепции SynchronizationContext на которую ссылается автор этого Поста.

Это не перевод. Это изложение содержания Поста на разных уровнях раскрытия сущностей и их взаимодействия по мере развития (эволюции) моего понимания тех мыслей и идей, которые, как мне кажется, хотел донести до читателя автор Поста Stephen Toub.

То есть я пишу о том, что и как я понял из этого текста и стараюсь обосновать это свое понимание из найденного материала по теме, а вы одобряете или критикуете/уточняете то, что у меня получилось сформулировать. Таким образом мы самым естественным образом получим хорошую и полную интерпретацию содержания статьи на нашем родном языке, надеюсь, да еще и обогащенную критикой возможных заблуждений происходящих из недостаточности или неполноты изложения, например, по этой теме.

В этот раз попробуем сформулировать задачу, которую решает компилятор, то есть те разработчики, которые разрешили нам пользоваться конструкциями Async/Await в C#.

Привет Хабр! Меня зовут Иван, сегодня поговорим о вопросах на собеседованиях Джуну+ (от 6 месяцев работы) и узнаем как ответить на них не как ChatGPT. Я как инженер по ручному и автоматизированному тестированию провожу собеседования на роль Junior+ QA (с дальнейшим ростом в автоматизаторы). Делюсь своим списком вопросов и ответов, которые я ожидаю услышать.

Придумывать заново велосипед не собираюсь. Поэтому ниже список ресурсов на вопросы для подготовки к собесу QA. К сожалению ресурсы предоставляют не все ответы, в том числе не все правильные.

База для Junior QA

1. Что такое тестирование?

Сравнение ожидаемого результата с фактическим результатом ПО. Тестирование это не поиск багов!

Своими словами: тестирование - это процесс сопоставления спецификаций продукта с его финальным результатом. Под финальным результатом мы можем понимать то, что тестировщик получает, когда разработчик реализует функционал по задаче и мы начинаем его тестировать. В ручном тестировании мы сравниваем тестовые случаи с реализованным проектом, а в автоматизированном тестировании мы преобразуем ручные тестовые случаи в автоматические проверки для реализованного проекта.

Всем привет, меня зовут Александр, в последние 2 года занимаюсь автоматизированным тестирование. Хочу поделиться своим наработанным опытом по созданию API тестов. Для написания автотестов в компании используем selenium webdriver, behave.

Behave — это фрейморк для программирования через поведение системы в python-стиле. Behave использует тесты, написанные на “естественном”, то есть, английском языке.

Selenium webdriver широко используется и думаю в представлении не нуждается, но всегда можно загуглить.

Структура тестов behave очень проста, если feature файлы в которых описываются сценарии и папка steps в которой находятся шаги для выполнения этих сценариев.

Первое на что можно обратить внимание это на структуру feature файлов (в этих файлах находятся сами тесты, которые состоят из различных шагов):

Добрый день, меня зовут Виктория и я много лет занимаюсь автоматизацией. В этой статье я хотела бы рассказать о паттернах автоматизации, которые использую, а также о такой штуке, как архитектура проекта.

Привет, Хабр! Меня зовут Александр Бехтерев, я работаю QA-инженером в Учи.ру. Не так давно перед нами встала задача перехода с библиотеки Selenium на новую и мощную библиотеку Playwright. Этот переход был вызван желанием улучшить процессы тестирования и попробовать что-то новое. 

В этой статье я постараюсь подробно рассмотреть процесс создания проекта на Python, Pytest и Playwright с применением паттерна Page Object, а также оставлю шаблон yml, который позволит запускать автотесты в CI. 

Привет, Хабр! Меня зовут Павел Корсаков, я python-разработчик в облачном провайдере beeline cloud.

Почти на всех собеседованиях задают вопросы про SOLID: что это такое, зачем нужен, как его применяет кандидат, как понимает принципы из него?

Мы тоже спрашиваем кандидатов про SOLID. Чаще всего они рассказывают, что SOLID — это акроним, озвучивают все его принципы, но объяснить и привести примеры могут лишь для половины. На остальных либо плавают, либо сливаются.

Чтобы мой материал не получился очередной статьей про SOLID, я изменю формат подачи и последовательность объяснения принципов. Буду добавлять код небольшими инкрементами и на каждом из них указывать, какие принципы SOLID используются в том или ином случае. 

Всем привет! Меня зовут Виктор, я DevOps‑инженер компании Nixys — мы помогаем другим компаниям внедрять в их IT‑решения передовые практики DevOps, MLOps и DevSecOps.

А еще — делимся знаниями и опытом в этой сфере. Сегодня представляем продолжение серии обучающих видеороликов на YouTube "Terraform: от незнания к best practices" и выкладываем сразу два видео!

Всем привет! Меня зовут Виктор, я DevOps‑инженер компании Nixys, которая помогает другим компаниям внедрять в их IT‑решения передовые практики DevOps, MLOps и DevSecOps.

Сегодня я приглашаю вас вместе со мной пройти путь «от незнания к best practices» в работе с Terraform. Этот материал подготовлен для серии наших одноименных видеороликов на YouTube, но мы решили дополнить его и предложить вам более детальное описание процесса в этой статье.

Не забывайте следить за нашими обновлениями на YouTube, Habr и подписывайтесь на наш Telegram‑канал DevOps FM — мы всегда рады новым друзьям. Начнём?

Сегодня для каждого бизнеса требуется высококачественное программное обеспечение в сжатые сроки, чтобы достигнуть этого организациям необходимо проводить эффективное тестирование программ с помощью автоматизации. С развитием agile и DevOps методологий автоматизация тестирования программного обеспечения достигает новых высот. Процесс автоматизации тестирования ускоряется при помощи повторного использования тест-сьютов, также существует множество фреймворков, используемых QA-тестировщиками.

Привет, друзья!

Я — JavaScript-разработчик. Код пишу в основном на React (иногда на Vue), немного на TypeScript, немного на Node, немного знаю SQL, но...

• со мной работает много людей, которые пишут код на Python
• вокруг много разговоров про Python
• повсюду преподают Python
• Яндекс любит Python (раньше Гугл тоже его любил, но теперь у него есть Go)

Короче говоря, сложно было не заинтересоваться Python.

Как известно, лучший способ научиться "кодить" — это писать код.

Предлагаю вашему вниманию 50 популярных в сфере программирования задач, решенных с помощью Python и JavaScript.

Цель — сравнить языки на предмет предоставляемых ими возможностей.

Задачки не очень сложные, хотя имеется парочка из категории продвинутых.

Предполагается, что вы владеете хотя бы одним из названных языков на среднем уровне.

Я продолжаю изучать CAN шину авто. В предыдущих статьях я голосом открывал окна в машине и собирал виртуальную панель приборов на RPi. Теперь я разрабатываю мобильное приложение VAG Virtual Cockpit, которое должно полностью заменить приборную панель любой модели VW/Audi/Skoda/Seat. Работает оно так: телефон подключается к ELM327 адаптеру по Wi-Fi или Bluetooth и отправляет диагностические запросы в CAN шину, в ответ получает информацию о датчиках.

По ходу разработки мобильного приложения пришлось узнать, что разные электронные блоки управления (двигателя, трансмиссии, приборной панели и др.) подключенные к CAN шине могут использовать разные протоколы для диагностики, а именно UDS и KWP2000 в обертке из VW Transport Protocol 2.0.