Программирование *

Вероятно, одной из наиболее часто используемых аннотаций Spring является @Transactional. Несмотря на ее популярность, иногда она используется неправильно, в результате чего получается не совсем то, что задумал инженер-программист.

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

1. Вызовы в пределах одного класса

@Transactional редко подвергается достаточному количеству тестов, и это приводит к тому, что какие-то проблемы не видны на первый взгляд. В результате вы можете столкнуться со следующим кодом:

Аннотация не работает в методе registerAccount:

XSS, или межсайтовый скриптинг, является одной из самых часто встречающихся уязвимостей в веб-приложениях. Она уже долгое время входит в OWASP Top 10 – список самых критичных угроз безопасности веб-приложений. Давайте вместе разберемся, как в вашем браузере может выполниться скрипт, полученный со стороннего сайта, и к чему это может привести (спойлер: например, к краже cookie). Заодно поговорим о том, что необходимо предпринять, чтобы обезопаситься от XSS.

Вместо return в корутине используется co_return, возвращающий результат. В этой заметке я хочу реализовать простую корутину с использованием co_return.

Я работаю программистом в игровой студии IT Territory, а с недавних пор перешел на направление экспериментальных проектов, где мы проверяем на прототипах различные геймплейные гипотезы. И работая над одним из прототипов мы столкнулись с задачей генерации случайных чисел. Я хотел бы поделиться с вами полученным опытом: расскажу о псевдогенераторах случайных чисел, об альтернативе в виде хеш-функции, покажу, как её можно оптимизировать, и опишу комбинированные подходы, которые мы применяли в проекте.

.NET 6 в процессе разработки, и я хотел поделиться некоторыми из моих любимых новых API в .NET и ASP.NET Core, которые вам обязательно понравятся. Почему они понравятся? Потому что они разработаны при прямом участии нашего фантастического сообщества разработчиков .NET. Подробнее в статье.

Заметки KPHP: тестирование и бенчмарки

Перед вами первая статья из серии «Как использовать KPHP в open source?».

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

В сегодняшнем выпуске обсудим:

• базовое использование composer с KPHP;
• как писать и запускать unit-тесты для KPHP;
• бенчмаркинг KPHP-кода (профилирование затронем в другой раз);
• как правильно сравнивать результаты бенчмарков.

Качеством кода в тестах часто пренебрегают. Когда в совместной разработке участвуют десятки QA-инженеров, возникает острая необходимость ввести формализованные правила, чтобы все могли быстро ориентироваться в тестовом проекте. К тому же часто тесты пишутся по аналогии или копируются с небольшими изменениями. Когда счет тестов идет на тысячи, то код, написанный в плохом стиле, быстро распространяется. Для решения этих проблем в тестовом проекте Wrike мы уже больше двух лет используем связку инструментов PMD и Checkstyle. И она отлично работает. В этой статье хотим поделиться опытом по настройке этих инструментов, их использованию и кастомизации.

Многие не знают, что некоторые сложные для написания и неэффективные для выполнения SQL-запросы можно легко выразить и эффективно выполнить в графовой базе данных. Это справедливо даже для тех, кто уже знает, что графовые алгоритмы являются наиболее эффективным, а иногда и единственным решением для сложных бизнес-задач, таких как кластеризация пользователей (с использованием Лувенского алгоритма), поиск инфлюенсеров - людей или компаний (алгоритмом PageRank) или прогнозирование поведения пользователей для персональных рекомендаций (алгоритмом label propagation).

В этой статье мы опишем SQL запрос с 24 JOIN в корпоративный knowledge graph и покажем, что задачу можно решить в графовой базе данных - и это будет понятней, более легко поддерживаться и эффективно выполняться. Пример взят из проблемы, описанной в сообществе: https://community.tigergraph.com/

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

Всем привет, я Павел – Junior Backend Developer в Kolesa Group. Хочу поделиться историей и рассказать о пути, который прошел, чтобы оказаться там, где я сейчас.  

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

Полноценных школ по компьютерному зрению, таких, чтобы участники могли получить опыт от разработчиков алгоритмов из крупных технологических компаний, осталось очень немного. В этом плане больше всего повезло студентам из Нижнего Новгорода, ведь каждое лето силами преподавателей Университета Лобачевского и инженеров компании Intel проводится Computer Vision Summer Camp - Летняя школа по компьютерному зрению. А для тех, кому не удалось на нее попасть, мы расскажем самое важное и интересное…

Среди свойств разбиений чисел на части можно указать одно, не называемое другими авторами, которое в ряде случаев оказывается весьма полезным. Речь идет о свойстве разбиений числа, закрепляющем за конкретными слагаемыми подмножества позиций (точек) дискретной плоскости, в котором эти слагаемые могут перемещаться, не выходя за его пределы. Например, рассмотрим такую задачу. Имеется 2 спицы длиной 12 ед и 7 шаровых бусин с диаметрами 2,2,2,3,3,4,4 ед и сквозными отверстиями, проходящими через центры бусин. Как распределить и нанизать бусины на спицы, чтобы спицы после вставки их в кольцо с диаметром большим 12 образовали симметричную фигуру?

TL,DR: gerbmerge+pdf merge+non-kicad interactivebom позволяет нам эффективно склеивать очень похожие, но при этом разные по форме и нюансам платы электронных блоков управления ДВС. Другие новости про rusEFI, до сих пор ищем единомышленников :)

В статье от 2014 года https://habr.com/ru/post/244737/ рассказ об открытом электронном блоке управления двигателями внутреннего сгорания rusEFI остановился на плате Frankenso. За четыре года мы продали 100 юнитов rusEFI, потом за последние 12 месяцев мы продали ещё 100 более современных юнитов, многому научились - но всё равно продолжаем пытаться понять, чего же именно мы хотим. Сейчас мы смещаем фокус с универсальности на устройства для конкретных семейств автомобилей с конкретными разъёмами и схожими распиновками ЭБУ, этим мы в том числе мечтаем привлекать программистов, которым не комфортно паять.

Давайте для начала я расскажу про Hellen https://github.com/andreika-git/hellen-one - это наш инструментарий разработки семейства модульных, склеенных из кусочков похожих, но всё-таки разных плат под конкретные проводки конкретных автомобилей.

Примерно год назад стало понятно, что универсальные блоки слишком сложны в поддержке: возможность управлять практически любым бензиновым двигателем с почти любыми оригинальными датчиками и формами сигналов ДПКВ/ДПРВ достигается только за счёт огромных усилий по поддержке нашей очень небольшой командой экспертов. При этом результат механически и электрически обычно выглядит всё равно очень плачевно. И со своей стороны мы устали сильно много допаивать руками после изготовления платы сервисом JLCPCB. Вместо большого универсального https://rusefi.com/s/proteus и маленького универсального https://rusefi.com/s/microrusefi ЭБУ мы решили сделать пару десятков ЭБУ под конкретные распиновки конкретных популярных автомобилей, изначально оптимизированных именно под JLCPCB каталог компонентов. Не хотелось разрабатывать и поддерживать много плат под конкретные автомобили ручным копированием блоков схемы и блоков трассировки. Наше решение: Hellen One Framework, это набор скриптов для склеивания gerber, PDF схем, описаний монтажа и HTML просмотрщика плат.

На конференции GUADEC 2021  был представлен новый инструмент для быстрой разработки интерфейсов GTK3 и GTK4 под названием Cambalache. В отличии от Glade, он способен поддерживать создание нескольких интерфейсов пользователя в одном проекте.

Привет, друзья!

В последнее время мне на глаза часто попадаются статьи, посвященные работе с формами в React и разработке соответствующих кастомных хуков. Вот парочка таких статей:

• Using Forms in React
• React.js — формошлепство или работа с формами при помощи пользовательских хуков
• Form validation with React Hooks WITHOUT a library: The Complete Guide

Я тоже решил попробовать в этом свои силы, чему и посвящена настоящая статья. Под "этим" я подразумеваю разработку кастомного хука для работы с формами в React.

Сначала мы разработаем хук, затем используем его в формах для регистрации и авторизации.

Для большей правдоподобности мы напишем простой express-сервер, который будет возвращать некоторые пользовательские данные (например, jwt-токен и хешированный пароль), а также некоторые типичные для процесса авторизации ошибки (например, 404 User not found или 409 Email already in use).

При разработке хука и компонентов приложения мы применим несколько продвинутых паттернов, которые, смею надеяться, покажутся вам интересными.

Исходный код проекта находится здесь.

Демо приложения:

Возможно, для того, чтобы в песочнице все заработало, потребуется ввести команду yarn dev в терминале.

Хук в форме npm-пакета — simple-form-react.

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

На данный момент одной из лидеров в машинном обучении для многих задач является библиотека XGBoost, основанная на алгоритме дерева решений и реализующая методы градиентного бустинга. Почему? Библиотека наиболее эффективна при построении моделей предсказания на структурированных больших данных, XGBoost поддерживает реализацию на Hadoop, имеется встроенная регуляризация и правила для обработки пропущенных значений, а также с помощью множества настроек можно улучшать качество прогнозирования модели за кратчайшие сроки, ведь имеется возможность параллельной обработки.

В этой серии блогов мы рассмотрели:

Введение

Тесты контрактов на основе Pact для сервисов, взаимодействующих синхронно

Тесты контрактов на основе Pact для сервисов, взаимодействующих асинхронно

Давайте перейдем к следующей теме. Pact брокер!

До сих пор мы видели, что потребитель публикует контракт в локальной директории. Провайдер забирает контракт из этой директории. Это самый простой способ обмена контрактами. И, возможно, наиболее подходящий в процессе его изучения. Однако в реальных проектах это не сработает. Часто в разработке участвуют несколько человек, команд, поэтому нам нужно централизованное место для размещения всех контрактов. Pact Foundation решил эту проблему с помощью брокера. Брокер — это структура, где потребители могут публиковать свои контракты, а провайдеры — результаты проверки.

В этом переводе к старту курса по Fullstack-разработке на Python напоминаем о том, насколько важно знать технологии в деталях, грамотно применять их и планировать работу в целом. Цифра 2850 в заголовке — не преувеличение: ранее занимавший две минуты запрос в базе данных компании Affinity сегодня выполняется за 42 миллисекунды. Подробности, как всегда, под катом. А если вам нужен план развития навыков с большим количеством практики, вы можете обратить внимание на наши курсы.

Примерно год назад фронтенд нашего проекта, в качестве фреймворка для которого используется Vue.js 2, дошел до состояния, хорошо описываемого словами "проще сжечь".

К тому времени наш нетипизированный корабль уже трещал по всем швам, и решено было убить сразу нескольких зайцев одним выстрелом: полностью перевести проект на TypeScript, внедрить Vue Composition API и решить проблемы валидации сложных форм.

А проблемы были. Vuelidate - отличная библиотека с массой готовых валидаторов и остается таковой до тех пор, пока мы имеем дело с, так сказать, плоскими формами - формами, не использующими вложенных компонентов, также требующих валидации. Vuelidate работает на уровне компонента, требует наличия миксина, содержит массу правил, которые нам не были нужны, но все равно тянулись в составе пакета, поддержка TypeScript и Composition API на тот момент отсутствовала, и мы не могли более с этим миритьcя.