Разработка

Инструменты покрытия кода помогают понять, какая часть кодовой базы выполняется (или, как еще говорят, покрывается) при выполнении данного набора тестов. Какое-то время Go поддерживал измерение покрытия кода на уровне пакета, введенное в Go 1.2, она включалась флагом команды go test -cover.

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

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

Двоичные файлы интеграционных тестов создаются командой go build, а не go test, поэтому инструментарий Go до сих пор не предоставлял простого способа сбора профиля покрытия этих тестов.

С версии Go 1.20 программы с инструментированием покрытия можно создавать командой go build -cover, а затем, чтобы расширить область покрытия, передавать эти инструментированные двоичные файлы в интеграционный тест.

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

В данной статье расскажу про мобильное приложение образовательного комплекса Campus

Привет Хабр! В прошлой статье мы векторизировали данные, теперь нам осталось написать модель и протестировать её

Мы построим модель для обнаружения спам-сообщений с использованием алгоритма случайного леса. Случайный лес — это очень мощный алгоритм, который очень широко используется. Мы не будем углубляться в математику алгоритма случайного леса, а воспользуемся его реализацией в библиотеке Scikit-Learn.

Сказ пойдет о том, как я протаптывал тропинки в этом неизведанном мире GraphQL и Python

Господа, приветствую! Решил описать результаты изучения абсолютно бесплатных курсов и статей по языку программирования python, любые комментарии с одобрениями/осуждениями/пожеланиями приветствуются.

И так, дело было вечером - делать было нечего.... Бесплатный(пробный) курс на Я.Практикуме подтолкнул зафиксировать полученные знания хоть как-нибудь, так родилась идея создания Калькулятора Лазерной Резки(далее КЛР), аплодисменты в студию!! Видео на ютубе "Учим python за 7 часов! Уроки Python Полный курс обучения программированию на python с нуля" канала Python Hub Studio придало уверенность.

Доброго дня всем заинтересованным в теме. Пару дней назад столкнулся я с одной настолько неочевидной и вместе с тем опасной особенностью выполнения SQL в Teradata, что не мог не поделиться. Хотя допускаю, что post mortem поведение ее (Терадаты) выглядит по-своему логичным, но все же для тех, кто не специализируется конкретно на Teradata и при этом много работает с данными в разных типах хранилищ, подобное поведение является первоклассной расческой ловушкой, и мне пока не удалось найти другую БД, в которой она есть.

Постараюсь кратко.

Представим, что у нас есть огромная таблица с критичными данными:

Веб платформа ASP.NET за последние десятилетия получила достаточно широкое распространение. С ее помощью разрабатывают веб-сайты и веб-приложения с помощью таких средств как HTML, CSS и JavaScript. Также с помощью ASP.NET можно создавать веб-API и веб сокеты.

Одной из основных проблем при разработке в контексте безопасности является невозможность функциональной проверки у того, или иного приложения. То есть, при разработке приложения мы не можем просто подключить какие-то библиотеки, сделать какие-то настройки при сборке проекта, и затем сказать, что все, наше приложение защищено и можно передавать его в продакшен. Так не бывает. На практике возможны два основных сценария: худший когда мы узнаем о проблемах с безопасностью нашего приложения из СМИ и интернета, например, когда приложение взломали или, когда в сеть утекли данные, обрабатываемые нашим приложением (да, обычно эти утечки организуют бывшие или действующие сотрудники, и это не совсем вина приложения, но, как говориться  осадочек все-равно остается). Более мягким является сценарий, когда мы узнаем об уязвимостях в нашем приложении в результате пентеста или когда сознательные исследователи сами сообщают разработчикам о найденных уязвимостях, например в рамках баг баунти. В таком случае нас скорее всего еще не скомпрометировали и репутационного ущерба для компании разработчика не будет. Ну а срочные баг фиксы выпускают все.

И к чему было все это вступление? ASP.NET является достаточно сложным решением, а сложность это всегда враг безопасности. С одной стороны вроде-бы злоумышленнику трудно разобраться в сложном решении, но с другой и защищать сложное решение тоже весьма непросто. И практика показывает, что очень часто именно злоумышленники быстрее разбираются в сложных системах и оперативно находят уязвимые места.

Рассказываю как сберечь нервы разработчикам сайтов.

Сложно найти тестировщика, который не знал бы о DevTools, но еще сложнее найти человека, который знает о них всё. Помимо знакомой всем базовой функциональности, есть много полезных и удобных фич. А если не ограничиваться Хромом, то их количество запросто можно удвоить.

Осенью на нашей конференции по тестированию Heisenbug Татьяна Дроздова рассказала о возможностях DevTools в Chrome, Firefox и Safari, и доклад очень понравился участникам. Сейчас мы готовим следующий Heisenbug, где Татьяна выступит с новым докладом о браузерных расширениях — а в ожидании этой конференции сделали для Хабра текстовую версию доклада с предыдущей. Далее текст идёт от лица Татьяны.

На текущем месте работы столкнулся с необходимости собирать Docker образы для сервисов написанных на Rust. Обычно в таком случае пишется Dockerfile, который внутри докера просто собирает контейнер и все. Но все оказалось не так однозначно: такая схема довольно неплохо работает, когда у тебя есть x86_64 Linux машина, но любой шаг в сторону и начинаются большие проблемы.

Все довольно неприятно уже на Intel MacBook машинах, докер поедает довольно много ресурсов с хоста, а еще возникают всякие странные приколы с монтированием файловой системы и правами доступа. Но настоящий ужас начинается на Макбуках с Apple Silicon процессорами, где обычной виртуализацией уже не обойдешься и можно часами ждать сборки простого сервиса через qemu. Можно решать эту проблему через сборку контейнеров в CI, но когда разработчиков много, а им надо часто что-то пересобирать, то там образовывалась очередь.

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

Периодически я сталкиваюсь с проблемой - не хочу ставить лишний класс элементу внутри различных кнопок, ссылок и label-ов. Зачастую это текст, который нужно подсветить или галочка чекбокса или маленькая иконка.

В решении этой проблемы мне обычно помогают необычные операторы CSS > + и ~

cypress-plugin-api, написанный амбассадором Cypress Филипом Хриком (Filip Hric), представляет собой плагин для эффективного тестирования API. Представьте себе Postman, но в Cypress; этот плагин выводит на печать всю информацию о вызове API в пользовательском интерфейсе приложения Cypress, обеспечивая несколько преимуществ:

1) В cypress-plugin-api команда cy.api() работает также как cy.request(). Основное отличие заключается в том, что помимо вызова вашего API, cy.api() также печатает информацию о вызове API в вашем Cypress Test Runner.

2) Всю эту информацию можно просмотреть в виде time-travel (реверсивная отладка) snapshots.

3) Также формируется простая таблица для просмотра файлов cookie, сворачивания объектов данных JSON и массива, а также цветового кодирования методов в представлении пользовательского интерфейса и на таймлайне (временной шкале)

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

Меня зовут Кирилл Смирнов. Я технический лидер iOS команды в СберЗдоровье. Последний год наша команда плотно занималась улучшением инструментов разработки, в том числе модуляризацией. В этом материале я поделюсь опытом и рекомендациями по подготовке бизнеса (заказчиков, исполнителей, смежников и др.) к модуляризации iOS приложений.

Нужен ли каждому разработчику свой dev-сервер? Многие компании, опасаясь лишних расходов и проблем, даже не пробуют внедрить такой подход.

CarPrice развернул свои dev-серверы еще в те далекие времена, когда все работало на монолите. А после монолита пилил собственный сервис для оркестрации dev-серверов на базе Docker, затем разворачивал их на Minikube и постепенно пришел к Kubernetes.

На связи ведущий инженер отдела DevOps CarPrice Михаил Чешуин. В этой статье я расскажу, как мы запускали dev-серверы в разные периоды — и как все работает сейчас

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

Теперь же веб-страница может быть полноценным приложением, которое получает данные из различных источников, выполняет манипуляции «на лету» и предоставляет полную интерактивность. Это значительно повысило полезность интернета, но ценой размера, пропускной способности и скорости. За последние 10 лет средний размер веб-страниц для десктопа увеличился с 468 КБ до 2284 КБ, что составляет рост на 388,3%. У мобильных устройств скачок еще более впечатляющий — от 145 КБ до 2010 КБ, то есть больше на 1288,1%.

В этом блоге я неоднократно обращался к теме астроинженерных сооружений, чрезвычайно интересующей Хабр. Навскидку вспоминаются материалы о сфере Дайсона (91 комментарий), космическом лифте (124 комментария) и обустройстве космической станции внутри астероида (212 комментариев). Все подобные идеи кажутся осуществимыми в обозримом будущем, так как мы привыкли экстраполировать успехи, уже достигнутые при сборке космических станций. Эпоха обитаемых космических орбитальных станций начинается в 1971 году и хронологически выглядит так:

С выходом Spring 6 и Spring Boot 3 Java 17+ стала базовой версией фреймворка.

Поэтому сейчас самое время начать использовать компактные Java Records в качестве объектов передачи данных (DTO, Data Transfer Object) для различных вызовов баз данных и API.

Предпочитаете ли вы читать или смотреть, давайте рассмотрим несколько подходов к использованию записей Java в качестве DTO, которые применимы к Spring Boot 3 с Hibernate 6 в качестве поставщика персистентности.

1С:ERP — внедрять или подождать? Для нас это уже пройденный этап, поэтому я собрал распространенные опасения, что проект внедрения 1С:ERP затянется, вас разорит или банально провалится. И, соответственно, ответил на них — что делать, чтобы внедрение или миграция на 1С:ERP стали не болью, а как на сленге маркетологов, «историей успеха».

Как отмечалось в первой части, условно эволюцию языка Фортран можно разделить на классический период (Фортран I – Фортран IV), когда ведущую роль в разработке занимала фирма IBM, язык абсолютно доминировал среди программистов (особенно в США) и сохранял значительную преемственность с самой первой версией; и современный период (Фортран 90 – Фортран 2018), когда разработка велась в основном ISO, синтаксис и семантика языка были значительно осовременены, но, несмотря на это, язык был уже вытеснен на периферию инструментальных средств. Версия Фортран 77 занимает промежуточное положение между этими периодами.