Selenium WebDriver создавался как кросс-платформенный инструмент для управления веб браузерами. И вот уже почти 14 лет он делает эту работу очень и очень хорошо. Впрочем, автотесты из реального мира создают ситуации, в которых Selenium бессилен. Например, по сценарию нужно загрузить или скачать какой-либо файл. После нажатия кнопки "Загрузить" или "Скачать", поверх окна браузера появляется окно файлового менеджера операционной системы к которому Selenium уже не имеет доступа. Тест останавливается.

Я слышал рекомендации использовать утилиты типа AutoIt или Sikuli для работы с такими системными окнами. Мой совет — никогда так не делайте, это порочная практика, которая приводит к нестабильным тестам:

• Такое решение не кросс-платформенное. Приходится изобретать свой велосипед для каждой новой операционной системы.
• Хрупкое. Нет гарантии, что скрипт будет работать корректно если на машине открыто несколько браузеров.
• Это делает невозможным использование headless режима браузера

Меня зовут Ярослав Пернеровский. Я уже 15 лет в тестировании и около 8 лет в автоматизации. Сейчас я расскажу как нужно правильно обрабатывать такие ситуации.

Зарплаты и отношение к кадрам в российском ИТ как отображение заката эпохи «среднего класса».

Для лиги лени: «9 из 10 российских работодателей испытывают ужасающий дефицит высококвалифицированных низкооплачиваемых работников, но Юрьев День для оставшихся официально никак не введут, это огорчает эффективных сов».

Эта заметка — приквел к циклу статей «Равновесие Нэша или почему эта музыка будет вечной» и ответ на пост «Вас просто стало слишком много».

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

1. Настаивайте на том, чтобы всё выполнялось через «каналы». Не допускайте того, чтобы для ускорения реализации решений выбирались кратчайшие пути.

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

3. По возможности отправляйте все вопросы в комитеты для «более глубокого изучения и рассмотрения». Стремитесь делать комитеты как можно больше, не менее чем из пяти членов.

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

6. Возвращайтесь к темам, по которым было принято решение на последнем совещании, и пытайтесь повторно открыть вопрос о целесообразности этого решения.

7. Советуйте «быть аккуратными». Будьте «разумны» и подталкивайте других участников совещаний к «разумности», к тому, чтобы они избегали спешки, которая может в будущем вызвать неудобства или сложности.

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

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.

Хабры и Хаброчки, я хотел бы перед самой статьёй обсудить вопрос целесообразности писать свой движок, вместо готовых решений. Есть куча статей, которые опишут разные движки от более популярных до менее. Я бы хотел затронуть немного другой вопрос: "Как человеку, который изучал программирование много лет заняться геймдевом?". Обычно, есть два пути в геймдев:

Умышленный путь. Это когда человек, который играет в игры рано или поздно решит их создать. Тогда, он выбирает где ему учиться этому и выучивает игровые движки и C-образные языки к ним (чаще всего, C#).

Путь прогеров. Программист увлекается математикой и пишет код. Так или иначе, везде где есть код — есть компьютер. Цифровые развлечения (в том числе и игры) не проходят мимо тех людей, который постоянно пишут код. Так, часть прогеров решает написать свою игру и начать свой путь в геймдев. Об этом пути мы и поговорим.

Так зачем выбирать "сложный" путь? Во-первых, не для всех он сложнее. Лично мне сложнее перейти на C# с использованием Unity, чем написать новый проект на Python. Во-вторых, люди не всегда понимают сам движок. Сейчас я преподаю в институте "Бизнеса и Дизайна". Это один из первых профильных учреждений, занимающихся геймдевом. И вот у студентов я спросил зачем им движок. Каково было моё удивление, что далеко не все понимаю, вообще зачем он нужен. Спойлер, не из-за пресетов.

Всех заинтересовавшихся, приглашаю в мир змеиных игр!

Меня зовут Алексей Казаков, я техлид команды «Клиентские коммуникации» в ДомКлик. В большинстве приложений, с которыми мне приходилось иметь дело, при взаимодействии с БД не ограничиваются лишь драйвером, который позволяет выполнять сырые запросы. Для удобства и избавления от SQL-запросов внутри, например, Python-кода дополнительно используют библиотеки (Object Relational Mapper, ORM).

Это первая статья в серии, посвященной различным ORM. Начнём мы с DjangoORM.

• Мы поняли, что ML в 50% задач не нужны. Нужна, например, камера, которая по цвету определяет, где есть железка, и смотрит её геометрию в реальности. Всё. Или другая камера, которая следит, чтобы в нужной зоне ничего не шевелилось.
• Всё это прекрасно до первого солнечного зайчика. ML отлично показывают себя там, где вам лень строить крышу или ставить прожектор над конвейером.
• У нас была идея, что мы можем сами в нейросети. Чуть не написали свой сервис для распознавания номеров вагонов. Казалось, делов-то на 20 минут, а у подрядчика это стоит 25 копеек за фото. Сделали свой, сферические вагоны в вакууме он определял хорошо. Потом приехало вот это:

Коллеги, в подходящем к финалу 2023г. у меня случилось два инсайта. Первый тревожный и, кажется, весьма очевидный, а второй - ободряющий. Первый заключается в том, что функция архитектора в текущем виде перестает быть востребованной. Второй, в том, что у всех нас есть очень хорошие шансы быть успешными в новой эре - в эре управления архитектурой v2.0.

Все мы знаем, что Django предоставляет ORM прямо из коробки, что не позволяет нам писать SQL-запросы. В этом механизме есть большой потенциал. Однако большинство из нас знакомы только с методами filter(), get(), update() и delete() из Django ORM.

В Django ORM есть много других опций, поэтому у нас все же возможность использовать функционал традиционных SQL-запросов. Сегодня в статье я вам про него расскажу.

ВНИМАНИЕ! Если у вас нет шума в ушах (тиннитуса) и/или нейросенсорной тугоухости, но есть особенности психики в части психосоматики или подобного – покиньте данный пост не читая.

Самые важные победы в мире – победы над собой

Всем привет. Меня зовут Паша Герасимов, мне 38, я – инженер в ИТ, геймер, и у меня диагноз НСТ (нейросенсорная тугоухость), а также субъективный шум в ухе (тиннитус) и гидропс правого лабиринта. По ощущениям, это комбо – шум/гул/свист в ухе, снижение слуха, чувство заложенности за перепонкой, и гиперакузия (повышенная чувствительность к некоторым звукам). Для тех, кто не в теме – представьте, что у вас ухо заложено ваткой, а внутри уха – звук неработающего канала ТВ (как видео пример, или mp3). И так – регулярно, месяцами, без возможности исправления.  

До 37 лет я практически не болел и не ходил по поликлиникам, это повлияло на всю историю с тиннитусом, поэтому для многих очевидные вещи, я понял на своей шкуре. 

semantic add button
semantic add icon

Как должны выглядеть современные сервисы на питоне, многие имеют представление. Все они, так или иначе, имеют поддержку асинхронных операций. А вот, как их лучше деплоить? Здесь некоторые руководства (как FastAPI) отвели целый раздел для рекомендаций, а некоторые (как Django) ограничились несколькими абзацами с крайне размытыми формулировками. Мне не посчастливилось следовать именно последнему.

Прочитав эту статью, Вы, возможно, захотите внести изменения в докерфайлы Ваших сервисов. Благодаря протоколам WSGI и ASGI, это можно сделать без особого труда. Именно поэтому все изложенные в статье советы - вредные. Также, Вы узнаете о nginx unit - ещё об одном годном сервере приложений.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Introduction to ASGI: Emergence of an Async Python Web Ecosystem" автора Florimond Manca.

"Черепахи рядом с водоемом", Ricard Baraham на unsplash.com

Python не замыкается только на Data Science, веб-разработка на Python вернулась с новым асинхронным витком в развитии языка!

Сейчас происходит много важных событий в экосистеме веб-разработки на Python. Одним из основных драйверов этих изменений является ASGI — Asynchronous Server Gateway Interface.

Я уже несколько раз упоминал ASGI в моем блоге, в частности, когда анонсировал Bocadillo (асинхронный open-source веб-фреймворк на Python — прим.пер.) и tartiflette-starlette (библиотека для построения GraphQL API поверх HTTP через ASGI — прим.пер.), но я никогда не писал подробное введение о нем. Теперь я это сделаю.

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

Прежде чем мы начнем, я хотел бы рассказать, что недавно создал awesome-asgi — отличный список для отслеживания постоянно расширяющейся экосистемы ASGI.

Краткая история серверов WSGI Python