Всем привет! Меня зовут Иван, я - android-разработчик в компании Joy Dev.
Здесь будет знакомство с Compose и его магическими побочными эффектами . Статья рассчитана на новичков и любителей. Первая часть статьи будет посвящена экскурсу в термины и особенности Compose, вторая - расскажет о таком явлении, как побочные эффекты: что это и как работает.
Здравствуйте, меня зовут Дмитрий Марков. Я архитектор направления в Альфа-Банке. В этой статье мы поговорим об архитектуре, как ни странно. Без космических «прорывов» и «аналоговнет». Всё жизненно.
Зайдем с разных сторон, проведем параллель с реальностью, даже, может, улыбнемся местами. И посмотрим и на рабочий пример архитектурной концепции, продиктованной определенными реалиями.
Материал предназначен, прежде всего, читателю, который интересуется архитектурой и разработкой, тому, кто ищет опыта коллег по цеху и их соображения, тому, кто уже что-то читал и, возможно, даже успел набить кое-какие шишки, задев мизинцем дверные косяки действительности.
Тут у нас с вами будет про условия/проблемы, про концептуальное решение со сменой технического стека, про аутентификацию, авторизацию, API-шлюз и, конечно же, немного про микро- и макросервисы, куда ж без них.
Надеюсь, из статьи вы заберете определенный положительный опыт с изложением хода мыслей автора о том, почему мы все скомпоновали именно так.
Библиотека Jackson является мощным инструментом для сериализации и десериализации данных в формат JSON в Java-приложениях. Она предоставляет гибкую и эффективную обработку JSON-данных, позволяя преобразовывать Java-объекты в JSON-строки (сериализация) и обратно (десериализация).
Но не всегда процесс десериализации данных в библиотеке Jackson происходит очевидным образом. В этой статье я хочу разобрать несколько примеров неочевидной десериализации Boolean в библиотеке Jackson.
Привет, Хабр! Меня зовут Сергей Ребров, я работаю в команде машинного обучения в МТС. У меня две дочки, которых стараюсь знакомить с миром разработки, поэтому решил написать статью про обучение азам программирования детей и подростков. Есть личные кейсы, есть информация к размышлению, описываю и полезные, на мой взгляд, инструменты. Если для вас эта тема интересна - прошу под кат!
Я уже много лет занимаюсь созданием IT-продуктов. Всё это время для себя и коллег собираю метафоры, которые позволяют наглядно показать, как нужно и как ненужно выстраивать работу по созданию ПО.
По мере работы над IT-продуктом мы узнаем что-то новое о рынке и пользователях и за счет этих знаний продукт перестраиваем. В физическом мире довольно сложно постоянно перестраивать, а в IT – это повседневная задача. По мере перестройки системы мы получаем результат, который все лучше и точнее попадает в запросы клиентов, что и приводит нас к прибыли.
Я рассмотрю 5 моих любимых метафор, которые помогают сонастраивать общее видение процесса для команды разработки и заказчика:
И снова привет, Хабр! Я Ольга Кузнецова, QA Lead.
В прошлый раз я рассказывала, какие Hard skills нужны для входа в тестирование бэка.
В сегодняшней статье хочу поделиться своими наработками в части коммуникаций внутри команды и предложить разобрать 5 ситуаций, понимание которых поможет повысить результативность коммуникации и ускорить “склейку” между “новой” и “старой” частями команды.
Статья будет построена в формате: “проблема – решение”.
Привет, Хабр! Когда-то у нас выходил материал по применению протокола SV на электроэнергетических объектах, в котором мы обещали разбор протокола GOOSE. Итак, время пришло.
В этом материале напомним читателям, зачем нужен этот протокол, кто его использует, как выглядят и из чего состоят GOOSE-сообщения. Покажем пример обмена устройствами таким трафиком, а также как, имея программно-аппаратный комплекс для моделирования в реальном времени, создать модель энергосистемы и провести опыт моделирования GOOSE-spoofing атаки на защищающие ее терминалы РЗА.
Надеемся, что статья будет полезна начинающим специалистам и специалистам, работающим с цифровыми технологиями в электроэнергетике, все-таки шпаргалки всегда полезны.
Правильно выбранная CRM-система помогает избавиться от повседневной рутины и использовать рабочую энергию более продуктивно. Рассказываем, как выбрать CRM под ваши цели и делимся подборкой сервисов.
Специалист по машинному обучению Игорь Котенков рассказывает, так ли страшен искусственный интеллект, как его малюют, и какие сферы разработки явно переоценены
mstsc.exe.
МойОфис выпустил масштабное обновления продуктов своей экосистемы. Изменения коснулись всех компонентов платформы офисных решений, в том числе были улучшены настольные, мобильные и веб-редакторы, серверные продукты и почтовая система Mailion.
Среди нововведений: возможность использовать электронную подпись в редакторах «МойОфис Стандартный 2», функция валидации надстроек в настольных приложениях, расширенный поиск в почтовой системе Mailion.
Подробнее о составе релиза 2.5 читайте под катом.
Не секрет, что на сегодняшний день Swift обладает одними из самых (возможно самыми) функциональными и гибкими в настройке перечислениями. Каждый Swift-разработчик может подтвердить, что работать с ними довольно приятно и удобно. Однако, мало кто задумывается как это устроено внутри. Может показаться, что за подобную функциональность обязательно придётся заплатить либо производительностью, либо памятью, либо размером билда. На самом деле, чтобы максимально избежать подобных издержек, под капотом в языке имеется шесть разных реализаций перечислений.
У всех компаний есть разнообразные данные: о клиентах, транзакциях, закупках, оборудовании, доходах и расходах. Но для одних компаний данные – драйвер роста, а другие несут убытки, полагаясь на них. Разница в том, что первые управляют информацией: знают, как и в какой форме она поступает, как ее внести в корпоративные системы, обогатить, и главное - как использовать, а вторые пускают эту работу на самотек и живут в зоопарке информационных систем без единой версии правды.
Это обзорный материал, я расскажу в нем об объектах основных данных, о том, по каким причинам часто возникают ошибки, какими инструментами улучшить качество данных и рассмотрю шаги конкретного проекта по внедрению НСИ.
В данной заметке хочу оставить пару комментариев к примеру работы с файловой системой /proc из вышеприведенного мануала. Во время познания материала обнаружил некоторые несостыковки и вещи не совсем поясненные до конца, так что тут попытаюсь внести немного больше ясности для тех, кто начнет топать этим путем.
В этой статье продолжим тему решения криптографических задач с ресурса MysteryTwister. И сегодня на очереди любопытный шифр, далёким предком которого является квадрат Полибия. Мы познакомимся с трёхраздельным шифром Феликса Деластеля. Что интересно информации об этом энтузиасте криптографии очень мало в английском и французском сегментах сети (Деластель — француз), а в русскоязычном о нём почти нет совсем, хотя наверняка человеком он был очень неординарным. Почему я так решил? Да потому, что Феликс Деластель по роду профессиональной деятельности не имел к криптографии совершенно никакого отношения, поскольку всю жизнь проработал в порту Сен-Мало и криптографией занимался факультативно. Тогда как ранее и позже криптография была уделом учёных, профессиональных военных и дипломатов. Биографических данных о нём очень мало, но одно известно точно: на рубеже XIX и XX веков Деластель написал книгу "Traite Elementaire de Cryptographie" (Базовый трактат по криптографии), в которой он описывал системы шифрования, которые создал.
За окном 2023 год, а среди разработчиков только и разговоров, что про микросервисы да API First. Несмотря на то, что эти темы не новы, похоже, что их актуальность даже набирает обороты.
Про микросервисы уже много написано и теоретического и практического. Есть у этого подхода и свои евангелисты (Microservice Architecture) :) В целом это тема достаточно холиварная, особенно при крайних точках зрения. Сегодня мы ее отложим, но обязательно вернемся в контексте темы этой статьи. Конечно, это будет не менее обсуждаемая история, посвященная методологии API First и программным интерфейсам (прежде всего, web, но не только) при проектировании и разработке современных информационных систем :)
Меня зовут Антон, я руководитель Архитектурного комитета в компании SimbirSoft. Мы используем подход API First для проектов самой разной направленности, где есть несколько команд разработки (как минимум Backend и Frontend), а также при высокой неопределенности на этапе реализации (быстроменяющиеся требования и цели, параллельные процессы проектирования и реализации, высокие запросы к TTM и так далее).
Поскольку API First не является чем-то новым для многих команд разработки, то мы решили не писать про то, что все уже знают, а остановиться на отдельных вопросах и разобраться в практическом аспекте применения методологии API First в части проектирования, прототипирования и разработки.
Этот материал открывает цикл статей, посвященных практическому внедрению методологии API First в разработку наших команд. Если быть точным, то мы отдаем предпочтение «младшему брату» API First, практикующему проектирование (design), — известному как Design API First. Чтобы избежать путаницы, далее термин «API First» будет обозначать подход к разработке ПО, а термины «Design API First» и «Design First» – проектирование ПО в рамках подхода API First.
2 часть: Как мы внедряли Design API First. Показываем на примере сервиса аутентификации
Для разработки iOS-приложений можно использовать два основных фреймворка: UIKit и SwiftUI. Однако при переходе на SwiftUI многие разработчики сталкиваются с трудностями, ведь парадигмы программирования у двух инструментов сильно отличаются.
В этой статье я хочу помочь разработчикам приложений для iOS понять различия между императивным и декларативным подходами к программированию, а также рассмотреть плюсы и минусы фреймворков UIKit и SwiftUI. Знакомство с ними необходимо для оптимизации процесса разработки и создания продукта высокого качества.
