тестировщик-автоматизатор
Владение языком Python станет прекрасным активом будущего программиста. Если ваш ребенок увлекается программированием, то процесс обучения можно разнообразить с помощью полезных видео, обучающих игр, вступления в тематические сообщества и многого другого. В этой статье мы собрали полезные ресурсы по Python и поделили их по категориям.
Привет, Хабр! Меня зовут Александр Карпенко, я QA Engineer в inDrive. Я подготовил эту статью для начинающих QA-специалистов. Ниже расскажу, как использовать Android Debug Bridge (ADB) в тестировании мобильных приложений и нужен ли вообще этот инструмент.
Задача матчинга в последнее время набирает всё большую популярность и используется во многих сферах: банки матчат транзакции, маркетплейсы – товары, а Google и другие IT-гиганты проводят соревнования по решению таких задач на Kaggle.
Для маркетплейса матчинг – очень важный процесс, который решает сразу несколько задач:
1. При поисковом ранжировании из множества товаров показывать сначала самые выгодные предложения.
2. Объединять множество товаров в одну сущность и показывать предложения одного и того же товара от разных селлеров.
3. Понимать, как предложения селлеров выглядят относительно друг друга, и поощрять их дополнительными бонусами.
Сегодня мы поговорим не только о решении этой задачи, но и о способах её реализации: offline (batch) vs online (realtime). Также обсудим, как и зачем переходить от первого ко второму.
Мой мадригал тем инструментам разработки, которые изменили мою жизнь
Программирование стало гораздо более многогранным ремеслом с тех пор, как в середине 1990-х я впервые попробовал AmigaBASIC. В те времена еще можно было купить один большой том о компьютере, на котором вы программируете – и там бы нашлось 99% всей нужной информации. Эта книга, где на множестве страниц уголки загнуты в качестве закладок, обклеенная стикерами, лежала бы у вас под рукой, пока вы вбивали бы команды в монохромный текстовый редактор.
Современная книга по клиентскому веб-фреймворку может быть толще, чем во времена программирования под C64 бывали мануалы, достаточные для создания полноценных игр. С другой стороны, сегодня информация по любым платформам, для которых требуется писать код, находится буквально в одном клике.
Сегодня никто бы больше и не подумал покупать документацию по разработке – и Microsoft, и Apple свободно выкладывают свою документацию в Интернете для всех желающих. А что говорить о проектах с открытым исходным кодом!
Во времена npm, PyPI и GitHub сложно объяснить, насколько неоднозначным решением (которое требовалось всесторонне обдумывать) раньше считалось потребовать хоть какие-нибудь возможности, которые выходили бы за рамки функционала операционной системы. Часто вместе с продуктом приходилось сдавать и все его зависимости.
Как бы мы себя не обманывали - Размер имеет значение! И конечно, мы будем говорить о размере нашего андроид приложения, куда мы добавляем кучу классных features, и даже не задумываемся как это может негативно повлиять на размер приложения. Поэтому мы научимся обнаруживать регрессию размера нашего приложения на CI для автоматизации этого процесса.
В последней части, оптимизируем процесс обнаружения регрессии размера андроид приложения.
Написание тестов в современной разработке играет одну из самых важных и неотъемлемых этапов разработки современного программного обеспечения. В рамках разработки одного из последних проектов перед нами возникла подобная задача. Одним из способов тестирования стала разработка полноценных End2End тестов.
Компании могут проверять свои продукты, сервисы или инфраструктуру на реальность взлома разными способами: это и пентест, и редтиминг, и bug bounty. Дыры в программном обеспечении могут обернуться убытками для компаний и компрометацией персональных данных (а иногда и финансовыми потерями) для пользователей. В этой и следующих статьях мы подробно пройдемся по теме bug bounty и расскажем о том, как прокачаться в багхантинге веб- и мобильных приложений.
Первая статья будет особенно интересна самым маленьким начинающим багхантерам. Но и те, кто уже зарабатывал на этом, смогут найти для себя что-то новое.
В книге «Пятьдесят занимательных вероятностных задач с решениями - Ф. Мостеллер» есть интересная задача про пьяницу, который с вероятностью 
делает один шаг к обрыву и с вероятностью 
один шаг от обрыва. Пьяница стоит на расстоянии одного шага от обрыва. Что можно сказать про вероятность того, что он упадет?
IBM PC. Всего пять букв, но сколько теплых чувств они вызывают глубоко в душе каждого, кто неравнодушен к зарождению эры персональных компьютеров. Но история IBM PC – это не просто набор фактов о модели или семействе машин, и даже не долгий рассказ о годах, которые познакомили весь мир с понятием «персональный компьютер». Это целая эпоха, которая продолжается до сих пор. Эпоха открытых стандартов, передовых технологий и гибкой платформы, которая уже 40 лет сохраняет все те же преимущества, что были представлены 12 августа 1981 года. Сегодня я расскажу вам полную историю рождения великого IBM PC – не компьютера, но концепта, который не только изменил весь мир, но и сделал Билла Гейтса всемогущим.
Я веду канал в Telegram GameDEVils и блог на Substack . Подписывайтесь, я делюсь там материалами про геймдизайн, разработку и историю игр. 
Это руководство описывает развёртывание HTTPS-прокси с помощью dumbproxy на практически любом Linux-сервере. Потребуется только curl и рутовый доступ.
Всем ведь приходилось заниматься улучшением производительности? Для игр особенно актуально, ну может какая-то три-в-ряд не страдает этим. Как обычно серебряной пули нет, начинаем со структур данных, алгоритмов, спускаемся ниже если не помогает, придумываем SoA, AoS шаблоны. Если проблема не решается, подтягиваем профайлеры и предметно разбираем узкие места, но все чтобы мы не делали зачастую таким узким местом всегда будет "железо". Можно сколько угодно оптимизировать другие места, но CPU c его гигагерцами будет простаивать 90% времени если его неправильно "кормить" данными. Одной (только одной из проблем) проблемой организации эффективной работы с данными будет меньше, если знать и уметь работать с кэшами разных уровней. Тут на вики описано, как "на пальцах" быстренько убить перф на обходе массива, простого и общего решения для такого обхода нет. Можно и дальше увеличивать размер кэша, что собственно и делают (гдето здесь на хабре была новость, что Интел при переходе на L1 кэш размером 32кб, заново спроектировал блок доступа к нему, сорян не нашел ссылку), но это дорого, неэффективно на масштабах современных процов, и всегда найдутся данные, которые этот кэш отравят, опять. Интересно как починить? го под кат...
Продумать структуру приложения на этапе создания очень важно, но часто в начале пути этому вопросу посвящают мало внимания. Предлагаю обсудить проблемы масштабирования современных веб-приложения с которыми сталкиваются разработчики.
Первое время разработка идет бодро, добавлять новые функции легко и приятно, приложение работает быстро, все просто и понятно. Но с ростом количество модулей, компонентов, сервисов скорость разработки падает, как и скорость работы приложения. Задач на рефакторинг появляется в спринте все больше. Кроме прочего, команда разработчиков может регулярно меняться (одни увольняются, другие приходят), что не добавляет порядка. Со временем может показаться, что проще все снести и написать заново.
Привет, друзья!
Представляю вашему вниманию перевод нескольких статей из серии Mastering TypeScript, посвященных углубленному изучению TypeScript.
В какой-то момент времени я превратился в педанта брюзгу. В фильмах малейшие нестыковки и провалы в логике портят мне весь просмотр. В чатах меня бесит it's вместо its. А в статьях про программирование... Всё плохо. За меня всё уже сказал @AlexanderAstafiev, я лишь процитирую:
Простите, я не могу так больше. Я слишком хорошо знаю Python, чтобы молчать при виде такого кода.
Я устал. Я не могу это читать. Простите за токсичную критику, накипело.
Самое забавное, что, по моим ощущениям, везде я вижу одни и те же классы проблем. Я даже запилил сервис, где можно закинуть код и получить код ревью, и, собрав немного статистики, понял, что 50 типов ошибок достаточно, чтобы покрыть большую часть проблем в чужом коде. Но выборка у меня была небольшая, и я подумал: а что, если проверить много кода?
С чего началась наша компания? В первую очередь, конечно, с людей и с идеи. Как это обычно бывает, правильные люди абсолютно случайно познакомились друг с другом, и вот я здесь, сижу и пишу этот пост =) Была, однако, и ещё одна очень важная составляющая - данные...
Любой ML-проект начинается с анализа ландшафта доступных данных - что мы можем скачать, выгрузить, разметить, купить. За четыре года наша культура работы с данными, инструментарий, подходы, процесс разметки претерпели очень большие изменения. Сейчас у нас накоплено почти 100 терабайт медицинских исследований, но количество данных абсолютно не важно, если они плохого качества, и их неудобно изучать, понимать и использовать. Недавно я делал обзорный доклад про разные аспекты качества медицинских данных, а вот наше выступление про технические аспекты пути к качеству. Сегодня же я хочу поговорить об очень интересной концепции (или даже философии), которая в последнее время на слуху, но, судя по разным постам в интернете, её суть понятна далеко не всем. Это Data Mesh.
Впервые я столкнулся с этим понятием в докладе Леруа Мерлен на митапе LeanDS. Доклад любопытный, но суть дата меш мне из него была понятна не до конца, так что недавно я взялся за чтение книги от авторки этой концепции и термина - Data Mesh: Devlivering Data-Driven Value at Scale.
Книга мне очень понравилась - она концептуальная, почти не затрагивает конкретные инструменты и способы реализации, но раскрывает суть идеи целиком и полностью. Полный конспект я могу скинуть в комментариях, если кого-то заинтересует, а в этом посте я поговорю об основных принципах, моей интерпретации и самых интересных моментах для нашей компании.
В предыдущей статье (Синаптические веса в нейронных сетях – просто и доступно) рассказывалось о смысле синаптических весов на примере модели определения цифры для 13-ти сегментного индикатора.
