На протяжении 5 лет работы инженером-тестировщиком я всегда старалась найти ходы и выходы, чтобы упростить и оптимизировать процесс тестирования (рутина и монотонность – это не мое). Спойлер: у меня не получилось. В этой статье я хочу вам рассказать историю регрессионного тестирования на проекте, и о том, как у меня не получилось его оптимизировать ручным и авто-тестированием.
Когда мы имеем дело с большим проектом, в репозитории которого накопились десятки тысяч строк кода, иногда единственным здравым решением кажется все переписать с нуля, а не оптимизировать. С точки зрения бизнеса может возникнуть вопрос: а почему вообще нужно оптимизировать или даже переписывать приложение, если оно работает? Дело в том, что по мере роста кодовой базы есть вероятность увеличения дублирующихся компонентов/фрагментов кода, появления устаревших участков, которые тормозят сборку, но полезной нагрузки уже не несут. Это негативно влияет на скорость работы приложения и увеличивает срок разработки.
В этом кейсе мы покажем, как улучшить имеющееся решение с точки зрения архитектуры, а также рассмотрим библиотеки и их особенности, которые помогут сделать приложение быстрее.
В данном примере мы имеем дело с довольно объемной кодовой базой, UI которой обрабатывает большие массивы данных и выводит их на экран в виде списков, таблиц, графиков. Поэтому нам важно обеспечить гибкость нашего приложения как в плане сборки бандла, так и для развертывания в разных средах. И, конечно, иметь в рукаве самые последние фичи, позволяющие делать наш код красивым, понятным и читаемым.
Статья будет полезна тимлидам и техлидам проектов, а также разработчикам, которые столкнулись с развертыванием крупных неоптимизированных React-приложений.
По данным на осень 2021 года в тройку наиболее популярных мессенджеров в России входят WhatsApp, Viber и Telegram. Давайте выясним уровень конфиденциальности и безопасности каждого из них. Сделать это можно, только сравнив их с другими приложениями, поэтому рассмотрим также Skype, Facebook Messenger и ряд малоизвестных у нас мессенджеров: Signal, Riot, Threema, Wickr Me, Wire, Session. А еще возьмем популярный у обладателей «яблочных» устройств iMessage.
В сфере создания квантовых компьютеров в 2023 году может произойти сразу несколько значимых событий. Ожидается, что именно в этом году появится первая коммерческая модель квантового компьютера, а также будет практически завершена работа над первым российским квантовым компьютером на ионах. Будет ли это означать уверенное достижение квантового превосходства, о котором уже заявили в Google, – большой вопрос. В гонке за кубитами участвуют сразу несколько стран, но победителя в этом научном и техническом соревновании может не оказаться. Несмотря на все успехи, наука очень далека от создания по-настоящему массовых квантовых вычислительных технологий. Мы собрали несколько наивных вопросов на этот счет и попросили ответить на них научного консультанта Artezio, доктора технических наук, профессора по кафедре прикладной математики и информатики Владимира Крылова.
Всем привет! Я Head of QA в Scalable Solutions. Так как компания разрабатывает высоконагруженную платформу для управления цифровыми активами и онбордит преимущественно middle+ и senior специалистов с глубокими знаниями трейдинга, финансов и high-load разработки, команды внутри компании строятся по компонентному принципу. Расскажу, как мы выстроили наболевшее кросс-командное взаимодействие между такими командами и на 20% ускорили релизный флоу.
Всем доброго времени суток, это моя первая статья на Habr, надеюсь, это будет кому-то интересно. В этой статье пойдет речь о очень не побоюсь это слова старом, но заслуженном программном решении для ведения журнала. Ведение журнала — это процесс записи действий и состояния приложения во вторичный интерфейс, возможно, в файл или базу данных. Но всегда возникает вопрос, какая информация нам нужна для регистрации в нашем, какие действия и какое состояние приложения мы должны записывать? Можно вести журнал по разным причинам, допустим, вам нужно наблюдать за действиями и состоянием приложения, или использовать журнал для создания статистики, касающейся применения вашего приложения.
В случайно сгенерированном мире Minecraft найдём алмазы с помощью ИИ. Как обученный с подкреплением агент проявит себя в одной из самых сложных задач игры? Подробностями делимся к старту флагманского курса по Data Science.
История о том, как студенты программисты решили помочь школьникам зажечь искру интереса к программированию.
С виду – мужики как мужики. Ну да, среднего возраста, со слегка притухшим взглядом, без искорки. Но таких много среди пытающихся войти в айти. Внешние признаки в резюме и на собеседовании – как у всех, ничего выдающегося.
Но у этих парней есть тайна. Нет, у них Тайна. Вскрывается, как теперь выяснилось, элементарно – задним умом и я крепок. Но то ли я какой-то не такой, то ли явление действительно из ряда вон… Распознать именно тенденцию смог лишь с третьего раза.
История будет короткой, чай не успеете допить.
Привет всем!
Сегодня решил написать основную теорию про применение диаграмм потоков данных как одного из инструментов моделирования процессов.
Диаграмма отображает потоки данных между системами, базами данных. Ключевыми элементами являются входные/выходные данные, системы, точки хранения и сбора данных.
Зачем нужны DFD диаграммы?
DFD диаграммы в отличии от других нотаций позволяют визуально показать все процессы с точки зрения данных. Это может быть полезно:
Без SMSсервера, без PHP(Python) Скриптов, без промежуточных Email...
В habr статье от 08.2019 был рассмотрен рабочий способ для приема SMS.
При всей его громоздкости и костыльности - он пользуется популярностью у бизнеса арбитражников и прочих SMS товарищей. Сам GOIP-SMS-Сервер абсолютно неудобен, а Шлюзы GoIP умеют отправлять СМСки по SIP протоколу. Т.е. с помощью обычного asterisk (или FreePBX)
Рассмотрим настройки SMS на примере GOIP-8 (8 канального GSM шлюза):
1) Configurations-SMS тут мы видим меню, заполняем поле SMS to VoIP, пишем что угодно, например goip8, на каждом из каналов как на скрине ниже
На прошлой неделе разработчики клиента для веб-конференций Zoom закрыли серьезную уязвимость, которая при некоторых обстоятельствах могла приводить к выполнению произвольного кода. Уязвимость получила идентификатор CVE-2022-22787, ее особенности кратко описаны в статье издания The Register и в бюллетене компании Zoom. Обнаружил проблему эксперт из команды Google Project Zero, и вот их подробный отчет представляет большой интерес.
Исследователь Иван Фратрич (Ivan Fratric) по сути смог построить атаку на далеко не самой очевидной основе. Для пересылки сообщений в Zoom используется собственная реализация открытого протокола XMPP. Проблема заключалась в том, что код, отвечающий за разбор содержимого сообщений в формате XML, различается на сервере и на клиенте. Минимальные различия в парсинге удалось превратить в полноценную атаку, которая при этом не требует никаких действий от жертвы, если передача сообщений от атакующего в принципе разрешена.
Сердцем любого backend являются данные. Существует два сценария использования данных. В одном из них данные изменяются редко, но при этом активно используются в сыром или агрегированном виде и применяются для целей аналитики в реальном времени (такие системы принято называть OLAP). В других системах важно обеспечить сохранение с высокой скоростью большого количество неструктурированных или полуструктурированных объектов, поступающих от устройств Интернета вещей, из источников произвольных событий, наблюдений за активностью пользователя (такие системы называются OLTP - Online Transaction Processing, ориентированные на большое количество транзакций с минимальной задержкой обработки). Для таких систем важно обеспечить надежность хранения данных, поддержку распределенного хранения на нескольких серверах и/или дата-центрах и сохранение консистентности распределенного хранилища.
При этом сами объекты могут отличаться от привычной реляционной модели данных и представляться, например, в виде json-документов с произвольной схемой, объектов с полями со множественными значениями или графов. Разумеется это приводит к необходимости изучения новых подходов к поиску и добавлению данных, использованию специальных драйверов. Но что если соединить распределенное надежное хранилище и синтаксис запросов, близкий к SQL? В этой статье мы познакомимся с проектом Apache Cassandra и обсудим на примере разработки API на Kotlin для сбора телеметрии с датчиков, расположенных по всему миру (с поддержкой отказоустойчивости и управляемой репликации между дата-центрами).
Существует огромное множество скриптовых языков. Существует множество графических интерфейсов для скриптовых языков (англ. graphical user interface, GUI). И существует какое то количество дизайнеров для этих интерфейсов. Добавлю к этим разработкам и свои а именно - графический интерфейс и дизайнер форм для сценарного языка OneScript.
Шесть месяцев назад на Habr была написана первая статья по этой теме. В ней описаны процессы, позволившие запустить автотестирование имеющегося web-приложения. Текущая статья описывает доработанный подход к тестированию того же web-приложения.
Любая асинхронность повышает уровень тревожности при разработке автоматических тестов. Особенно в ситуации, когда нужно выполнить проверку корректности работы системы, основанной на графе состояний со взаимодействием с внешним API через Flow. Примером такой системы может быть Telegram-бот, построенный на диалоге с внешним пользователем. В этой статье мы с вами создадим простой бот на Kotlin (с поддержкой многоязычности) и последовательно разберем возможные способы использования асинхронных моков и тестов для Flow с использованием библиотеки mockk и типобезопасной библиотеки для взаимодействия с API Telegram на Kotlin.
Как известно, в мире C++ много способов причинить себе боль, но также много высокой производительности, нетипичных амбициозных задач и прочего увлекательного хардкора. Ну и ещё известно, что плюсовиков хлебом не корми, дай немножко похоливарить про Rust или Go.
А в программе C++ Russia нашлось место всему этому: будут доклады и о производительности, и о специализированных задачах вроде систем реального времени, и о способах уменьшить боль. И ещё немножко про Rust и Go. И внезапное, но интересное: доклад про автоматизацию программирования в СССР.
В начале июня пройдёт онлайн-часть конференции, 26 июня пройдёт офлайн-часть, а сейчас про обе сразу можно узнать, какие доклады там будут.
