Привет, меня зовут Света и я тимлид Mobile QA в Emerging Travel Group. В этой статье я простым языком расскажу про один из самых полезных и простых в использовании инструментов тестирования мобильных приложений — мистер Charles Proxy, и покажу на примерах некоторые самые полезные его функции.
Для начала разберёмся, кто вообще такой этот Charles.
Charles Proxy — это сниффер (sniffer – перехватчик) трафика, инструмент для анализа трафика, который позволяет отслеживать, записывать и анализировать сетевые запросы между устройствами и интернетом.
Charles — не единственный инструмент для анализа трафика, у него есть аналоги, например: WhireShark, Fiddler, Proхyman, mitmproxy. Все они в той или иной степени про одно, различие лишь в интерфейсе, поддержке разных платформ, и наборе функционала.
Создание многоразового орбитального корабля «Спейс Шаттл» стало триумфом американской авиапромышленности. Но эксплуатация уникальной системы скорее разочаровывала, а катастрофа «Челленджера» сделала необходимость скорой замены «челнока» очевидной. Американцы не стали размениваться по мелочам, а замахнулись сразу на одноступенчатый носитель. Три проекта, бросивших вызов формуле Циолковского, дошли до отработки агрегатов и экспериментальных прототипов. Мы поговорим о первом из них.
Первой частью цикла будет создание простого http-сервера, хранящего данные и поддерживающего авторизацию по генерируемым токенам.
Введение к нескольким статьям по использованию Qt6 для токенезированного доступа к данным в изолированных системах.
Чиновники работают над системой отправки предупреждений прямо в информационно-развлекательные системы автомобиля. Вот как это будет работать.
В новостях технологий мы часто видим заметки об успехах ChatGPT. Например о том, что умный бот успешно сдал экзамены в очередной ВУЗ. Или о том, что многие скоро останутся без работы, поскольку их заменит генеративная система на базе большой языковой модели. Наверняка у многих возникало желание потестировать возможности ChatGPT и выяснить действительно ли он так умён, как об этом пишут в прессе. Если у вас возникал такой вопрос, эта заметка для вас.
Здравствуйте. Это версия моей первой статьи на русском языке, прошу не судить строго.
Одним из способов хранения древовидных структур в реляционных СУБД является “материализованный путь”. В интернете можно найти множество описаний этого и других способов, следует выбирать исходя из вашей задачи.
В PostgreSQL существует специальное расширение ltree, предоставляющее дополнительные инструменты для работы с метками и путями. О нем и о решении вопросов, связанных с консистентностью (целостностью) данных, и поговорим.
Итак, задача: сделать таблицу item с полем path типа ltree для удобной работы с деревом, а также обеспечить целостность данных на уровне базы.
Терминология:
От маленького камня и большой загрохочет; маленькими делами большие делаются
В статье «Чем задача отличается от цели?» мы разобрали различия между сущностью «цель» и сущностью «задача».
Есть ещё одна сущность, от которой надо чётко отделить «задачу». Это сущность – «действие».
В статье «Что такое задача?» я писал: «Для того чтобы приступить к выполнению задачи её надо декомпозировать до уровня действий. Крупные (ёмкие) задачи, декомпозируются на более мелкие задачи, те в свою очередь – ещё на более мелкие, а задачи самого нижнего уровня – декомпозируются на действия».
Здесь довольно часто возникает вопрос: чем задача отличается от действия?
Раньше этот вопрос ставил меня в тупик.
Когда меня спрашивали: нужно ли фиксировать в качестве задачи всё, что делается? Каждое наше действие. Я не знал, что на это ответить.
Не знал, как соизмерить задачу и действие? Как их чётко разграничить, чтобы не мешать друг с другом? Не мог объяснить, на каком уровне декомпозиции мы ещё имеем дело с задачей, а на каком – уже с действием? В какой момент нужно завершать декомпозицию задач?
Сформулировать ответы на эти вопросы нужно было. Иначе эти понятия будут смешиваться, отождествляться и, тем самым, создавать путаницу.
Более того, сущность «действие» — это тоже очень важная сущность, участвующая в управлении потоком задач. Особенно в выполнении бизнес-процесса «Обеспечить воспроизводимость выполнения запоточенных задач» (кратко - Воспроизводимое выполнение ЗЗ)[1].
Поэтому отвечаю.
Задача отличается от действия:
Теперь к истокам задачи: часто, чтобы математическая модель была применима в реальном секторе, необходимо использовать очень много ограничений и большое количество переменных. Задачи, возникающие в бизнесе в реальных условиях, требуют использования моделей с большим количеством ограничений и большим количеством переменных. Временами задача в лоб может и не решиться, поэтому были придуманы различные трюки. Один из них - метод « генерации столбцов» (Column generation).
В прошлой статье я говорил о том, что поиск себя и попытки найти дело своей жизни часто проваливаются. А сейчас поговорим о том, почему даже если вам очень нравится, то чем вы занимаетесь (да еще и получается к тому же), шансов на успех меньше, чем хотелось бы.
Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.
Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!
Но помимо восхваления их здравого смысла, я думаю, что здесь есть более важный момент, который применим ко всей нашей отрасли...
Телефон для меня — как икона,
Телефонная книга — триптих,
Стала телефонистка мадонной,
Расстоянье на миг сократив.
/В. Высоцкий/
С тех пор, как у людей появилась информация, они начали искать способ её передачи. Идеи были разными и человечеству вечно чего-то не хватало: надёжности (гонца могли поймать и изъять у него сообщение), скорости (голуби ещё ладно, а вот ямщики пока доедут, пока в пути отдохнут…), дешевизны передачи (корабли и автомобили были слишком накладны). Вечно что-то мешало: то шероховатость поверхности, то проводящие способности воздуха, то пресловутая гравитация… Но ни у кого из нас не было бы в руках смартфона с сотовой связью и интернетом, если бы не было ямщиков, голубей, крайне неудачного итальянского проекта с трубами между домами (почти пневмопочта) и, конечно, телеграфа.
А главное, если бы не было их — первых телефонов.
В Prime Video мы предлагаем нашим клиентам тысячи прямых трансляций. Чтобы гарантировать, что клиенты беспрепятственно получают контент, Prime Video создала инструмент для мониторинга каждого потока, просматриваемого клиентами. Этот инструмент позволяет нам автоматически выявлять проблемы с качеством воспринимаемого контента (например, повреждение блока или проблемы с синхронизацией аудио / видео) и запускать процесс их устранения.
У нашей команды анализа качества видео (VQA) в Prime Video уже был инструмент для проверки качества аудио / видео, но мы никогда не планировали и не проектировали его для масштабной работы (нашей целью было отслеживать тысячи одновременных потоков и увеличивать это число со временем). Подключая к сервису больше потоков, мы заметили, что масштабная эксплуатация инфраструктуры обходится очень дорого. Мы также заметили узкие места в масштабировании, которые мешали нам отслеживать тысячи потоков. Итак, мы сделали шаг назад и пересмотрели архитектуру существующего сервиса, сосредоточив внимание на стоимости и узких местах масштабирования.
Первоначальная версия нашего сервиса состояла из распределенных компонентов, которые были организованы AWS Step Functions. Двумя наиболее дорогостоящими операциями с точки зрения затрат были рабочий процесс оркестровки и передача данных между распределенными компонентами. Чтобы решить эту проблему, мы переместили все компоненты в единый процесс, чтобы сохранить передачу данных в памяти процесса, что также упростило логику оркестровки. Поскольку мы объединили все операции в единый процесс, мы могли полагаться при развертывании на масштабируемые экземпляры Amazon Elastic Compute Cloud (Amazon EC2) и Amazon Elastic Container Service (Amazon ECS).
Даже если вы раньше ни разу не имели дела с расчетом электрических сетей, с этой библиотекой вы можете быстро войти-в-айти-начала-прошлого-века... (спойлер: в электричество).
Итак, продолжаем цикл изучения электрических python-библиотек с разбора pandapower - открытой библиотеки для расчета электрических сетей.
Подробные комментарии прилагаются (необходимы лишь минимальные знания физики электричества).
Два с половиной года назад я написал первую статью на эту тему. Когда я наткнулся на неё в 2023, я подумал, что за последние годы многое поменялось в нашей работе жизни и мне есть о чём вам рассказать. Статья будет полезна всем кто интересуется различными схемами организации труда в коллективе и IT инструментами, которые помогают в этой организации.
