User
Всем привет! Меня зовут Роман Аймалетдинов, я разрабатываю клиентское приложение Ситимобил. Продолжаю свою серию статей по JNI, так как технология используется редко, но иногда она бывает очень полезной (или просто интересной). В этот раз я покажу замеры производительности, достаточно тривиальные, но отображающие суть. И если вы не знакомы с JNI, но тема интересна, то советую ознакомиться с первой и второй частью этой серии статей.
Всем привет! Меня зовут Роман Аймалетдинов и я разрабатываю клиентское приложение Ситимобил. Решил написать небольшую серию из трех статей по JNI, так как технология используется редко, но иногда она бывает очень полезной. Несмотря на то, что я разрабатываю классические приложения под Android, иногда хочется посмотреть технологии рядом со своей специализацией.
Всем привет! Меня зовут Роман Аймалетдинов, я разрабатываю клиентское приложение Ситимобил. Продолжаю свою серию статей по JNI, так как технология используется редко, но иногда она бывает очень полезной (или просто интересной). В этот раз я покажу примеры решений на JNI, которые совсем немного сложнее, чем hello world. И если вы не знакомы с JNI, то советую начать с первой части.
Пример создания Full Stack проекта, используя функциональное тестирование как инструмент дизайна(продолжение)
API часть и релиз проекта
Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма.
Работа в IT, как и в любой другой сфере, не всегда приносит удовлетворение. Причиной этому может быть как поспешно выбранная специализация, так и усталость от сферы, в которой человек работает много лет. В IT-индустрии часто переходят на новые позиции: тестировщики становятся автотестировщиками или программистами, бизнес-аналитики — системными аналитиками, разработчики осваивают новые области.
Однако не всем удаётся сменить специальность и не всегда это приводит к положительному результату. Как перейти из одной IT-профессии в другую с минимальными потерями? Опросили экспертов Хабр Карьеры и собрали их мнения.
Всем привет! Меня зовут Иван. Почти год, как я работаю начальником отдела тестирования в одной из крупнейших финтех компаний России. Специализируюсь на построении и управлении командами, администрировании процессов.
Нил Армстронг, пройдя по Луне, сказал: «Это один маленький шаг для человека, но гигантский скачок для всего человечества». Так и наш путь начинается с небольшого, но важного шага - изучения фундаментальных основ тестирования.
Предвосхищаю некоторые комментарии. Тест-кейс и стандарты его оформления - это, конечно, база для любого тестировщика и давно избитая тема. Однако хочется выразить немного мыслей на этот счет. Надеюсь, эти мысли, отраженные на «холсте», помогут тем, кто только вступает на путь тестировщика.
Итак, поехали!
Привет!
Я - Урманчеев Станислав, QA Automation Engineer на проекте «Лояльность» в Mир Plat.Form (НСПК). Хочу поделиться с читателями Хабра нашим опытом в создании и развитии фреймворка для автоматизации тестов на Appium.
Какие проблемы мы собрали по пути, к чему пришли в итоге и почему не стоит усложнять жизнь тестировщикам сложным API для тестирования – читайте под катом.
Дисклеймер: о Kotlin dsl есть подробная статья на Хабре и документация на Kotlinlang.
Меня зовут Денис. В 2010-м я закончил Удмуртский государственный по специальности прикладная математика.
Рецептуры мы половину своровали (воспроизвели популярные составы), а половину придумали сами.
Раньше сорта придумывала моя жена, сейчас этим занимается технолог. На фото я и жена
Команда Spring АйО перевела статью, которая отлично подойдёт тем, кто ещё не знаком со Spring Data Envers. В статье на простых примерах объясняется, как отслеживать изменения данных в приложении, используя этот инструмент.
Тестирование, как неотъемлемый процесс жизненного цикла разработки программного обеспечения, обеспечивает функциональность, совместимость и производительность разрабатываемых приложений. Среди различных видов тестирования особое место занимают smoke-тесты и sanity-тесты, которые проверяют надёжность и стабильность приложений.
Smoke-тестирование обычно является первым этапом тестирования, проводимым после получения новой сборки. Если smoke-тесты успешно пройдены, что указывает на базовый уровень стабильности, то далее переходят к sanity-тестированию, чтобы более детально проверить конкретные изменения. Термины sanity-тестирование и smoke-тестирование часто используются как синонимы, но между ними есть существенные различия, о которых необходимо знать, чтобы выбрать правильную стратегию тестирования.
Наверняка в вашем проекте используется очередь сообщений (не важно kafka, pulsar или какой-нибудь зайчик). Основной проблемой является подробное тестирование работы вашей системы. Рассмотрим варианты решения и посмотрим, что там у автора в рукаве.
Безопасная разработка для современного IT — важнее некуда. Однако создание крупных решений становится сложнее, обновления — всё быстрее. Трудно отловить все баги, убедиться, что пользовательский опыт и ценные данные безупречно защищены. Поэтому всё чаще компании не только развивают внутреннее ИБ-подразделение, но и обращаются к сообществу — открывают программы багхантинга: предлагают опытным айтишникам помочь в поиске уязвимостей.
Мы хотим узнать, кто такой современный багхантер. Хотите помочь разобраться, кто такой багхантер на самом деле? Заходите под кат и поучаствуйте в исследовании. Неважен ваш грейд и неважно, насколько глубоко вы разбираетесь в теме: поучаствовать могут даже те, у кого нет в поиске уязвимостей никакого личного опыта. Нам важно понять, как этих специалистов видит IT-сообщество, в том числе те, кто никогда сам не занимался багхантингом.
В заголовке использовано слово сложной, под которым можно понимать все, что угодно. Утверждение о том, что 2 * 2 = 4, если вдуматься, тоже очень не просто. Но в данном случае всё банальнее. Речь идёт о ЕСКД, ГОСТ, ОСТ и тому подобных скучных терминах, отягчаемых бюрократической процедурой согласования.
Года полтора назад мы втянулись в проект по разработке небольшой отраслевой информационной системы. По этой небольшой системе необходимо было разработать с полсотни взаимоувязанных документов и согласовать их не меньше, чем с сотней человек.
Сразу решили, что попробуем сделать документацию актуальной, т.е. обойтись без покраски травы в зелёный цвет. И сразу решили, что это будет Asciidoc. Почему? Потому что из текстовых языков разметки для подготовки документации он наиболее функциональный, а разворачивать неповоротливые DITA и Docbook не хотелось.
Пройдя определённую боль, мы с коллегами решили ей поделиться.
Системный аналитик всегда и везде сталкивается с бесконечным количеством диаграмм разного вида, с нотациями (правилами), чтобы нарисовать данные диаграммы и с бесконечным количеством инструментов для их описания. Но мало кто говорит о таком инструменте, как PlantUML.
Лично мне завесу тайны приоткрыл Альфа-Банк, здесь документация ведется рядом с кодом, и схемы логичнее описывать тоже кодом. Но это не так страшно и не так сложно (почти) как кажется. Давайте я приоткрою ящик Пандоры и сниму кармическое проклятье с этого инструмента.
В Альфа-Банке мы уже больше 5 лет ведём документацию рядом с кодом. Но она используется не для всех проектных документов. Дело в том, что документация у нас делится по слоям: фронт, миддл и бэкенд. Если с миддлом — слоем микросервисов — всё хорошо, то вот с переводом фронт- и бэк-документации в Bitbucket возникает трудность в необходимости хранения бинарников с примерами пользовательского интерфейса.
В статье я опишу, как мы работаем с миддл-документацией, и поделюсь текущими наработками, а на примере документации по фронту обозначу существующие трудности и расскажу, какие варианты решения мы рассматриваем. Статья подойдёт техническим писателям, системным аналитика и всем, кто занимается подготовкой технической документации на программные продукты.
Наверняка, многие из вас пользуются explain.tensor.ru - нашим сервисом визуализации PostgreSQL-планов или уже даже развернули его на своей площадке. Но визуализация конкретного плана - это лишь небольшая помощь разработчику, поэтому в "Тензоре" мы создали сервис, который позволяет увидеть сразу многие аспекты работы сервера: медленные или гигантские запросы, возникающие блокировки и ошибки, частоту и результаты проходов [auto]VACUUM/ANALYZE.
И сегодня мы, наконец, готовы представить вам демо-режим этого сервиса, куда вы самостоятельно можете загрузить лог своего PostgreSQL-сервера и наглядно увидеть, чем он у вас занимается.
Сегодняшняя тема посвящена нелегким взаимоотношениям клиентского приложения и сервера PostgreSQL: как на ровном месте, неудачной архитектурой приложения, можно обеспечить себе хронические проблемы производительности.
Рассмотрим классические ситуации, когда разработчики начинают жаловаться на производительность БД - а виновата-то и не она!
Привет, Хабр! Меня зовут Артем и я автор и ведущий YouTube канала Android Insights
Сегодня мы погрузимся в мир делегатов и делегированных свойств в Kotlin. Эта тема может показаться сложной на первый взгляд, но я постараюсь объяснить её максимально понятно и подробно. Итак, приступим!