Разработка

Привет! Меня зовут Денис. В августе 2024 года я присоединился к компании ЮMoney в роли Fullstack-тестировщика с автоматизацией на Kotlin. Наша команда тестирует и фронтенд, и бэкенд. Автотесты в основном интеграционные — они охватывают интерфейс пользователя и внутренние процессы.

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

Блокировки в СУБД — основа механизма параллельного доступа к данным, но также и частый симптом проблем в архитектуре или ошибок в логике работы с БД. Когда из-за них запросы зависают, нам требуется разбираться, кто кого и когда заблокировал, то есть поднимать и смотреть историю возникновения блокировок.

Чтобы понять цепочку блокировок, обычно строят их дерево рекурсивными запросами. Но частое выполнение таких запросов может существенно замедлить работу СУБД. В худшем случае можно усугубить проблему, которую мы пытаемся диагностировать.

Меня зовут Александра Кузнецова, я бэкенд-разработчик в СберТехе, в команде Platform V Kintsugi — это графический инструмент для сопровождения, разработки и диагностики СУБД на основе PostgreSQL. Расскажу о том, как мы с коллегами интегрировали сбор данных о блокировках в наш мониторинг сессий. Решение работает в фоне и не нагружает БД. И дерево блокировок можно построить для любого момента в прошлом, даже через несколько дней после инцидента. Начнём.

Я из тех, кто всерьёз задумывается о проектировании и реализации хеш-таблиц. Недавно обнаружился донельзя милый вариант, который заслуживает широкой огласки. Это робин-гудовская открытая адресация с применением линейного зондирования, где размер самой таблицы увеличивается как степень двойки. Если вы не знакомы с терминологией хеш-таблиц, то все эти слова могут показаться вам каким-то невразумительным салатиком, но, когда мы разберём этот пример с привлечением кода — всё должно стать понятнее.   

Чтобы не пришлось усложнять код, начнём со следующих допущений:

Как Python помогает находить симметрии в поэтическом тексте. Простой код для поиска палиндромов (слов и фраз, читающихся одинаково в обе стороны) в творчестве Владимира Маяковского.

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

Привет, Хабр. Меня зовут Люба Вайгель. Я системный аналитик в СберЗдоровье — MedTech компании №1 в России. Я довольно давно работаю системным аналитиком: помимо медтеха, на моем счету опыт в финтехе, госсекторе. В этой статье я хочу поделиться материалами, которые в своё время помогли мне и могут быть полезны всем, кто только делает первые шаги в системном анализе.

Привет! Я Фёдор, CEO OpenIDE. За год с момента анонса OpenIDE выросла в стабильную, привычную и активно используемую IDE, которую всё чаще выбирают разработчики и компании. Мы создали её быстрой, предсказуемой и полностью доступной — и теперь готовы к следующему шагу.

В этой статье — что мы сделали, зачем мы это делаем и куда дальше движется OpenIDE.

Рынок вакансий для системных аналитиков меняется. Растет спрос на работу с данными, облачные технологии и инструменты ETL/ELT. Бизнесу нужны специалисты, которые понимают архитектуру хранения данных, знают процессы их преобразования и принципы управления. Но требования в таких вакансиях часто пугают — со стороны это выглядит как другой мир, требующий совершенно новых знаний.

На своем примере перехода из финтеха в data-платформу VK Tech покажу, что все не так страшно. Расскажу, что в профессии системного аналитика остается неизменным, какие есть ключевые концепции и инструменты Data-направления и что на самом деле нужно знать для перехода.

Хабр, привет! На связи Александр Леонов, ведущий эксперт PT Expert Security Center и дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies регулярно исследуем информацию об уязвимостях из баз и бюллетеней безопасности вендоров, социальных сетей, блогов, телеграм-каналов, баз эксплойтов, публичных репозиториев кода и выявляем во всем этом многообразии сведений трендовые уязвимости. Это те уязвимости, которые либо уже эксплуатируются вживую, либо будут эксплуатироваться в ближайшее время.

С прошлого дайджеста мы добавили еще 4 трендовые уязвимости.

По традиции начнем с Windows.

Когда продукт растет, скорость изменений всегда начинает конкурировать с рисками. Бизнес хочет выкатывать фичи быстрее, а разработчики — держать продакшен в безопасности. Feature Flags решают этот конфликт: позволяют менять функциональность без деплоя, тестировать гипотезы на ограниченной аудитории и мгновенно выключать ошибки.

Привет, Хабр! Меня зовут Михаил Олейник, я разработчик IBS. В этой статье — практический разбор, как устроены фича-флаги, где их хранить, как получать их состояние на фронтенде и что учитывать в реальных проектах. Если вы искали краткий и понятный гайд по теме, это он.

Помимо полноценных клавиатур, есть клавиатуры с несколькими кнопками, клавиши которых можно запрограммировать. Их называют еще макропадами. Макропад не сложно купить, хоть часто он стоит дороже обычной клавиатуры, но можно и сделать. Статей как его смастерить много, самый простой способ — использовать каждый вывод микроконтроллера, пока они не закончатся. Но у меня не было никакого желания делать все как у всех. Хотелось чего-то по-настоящему DIY.

Поэтому в статье пойдет подробный рассказ о разработке USB-клавиатуры на микроконтроллере CH32V003, в котором по умолчанию нет поддержки USB. Но чтобы проект был более интересным, клавиатура состоит из 9 кнопок, 3-х энкодеров и 2-х светодиодов. При этом корпус и кейкапы тоже сделаны самостоятельно (почти).

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

Теперь, после того как в предыдущей статье так красочно описаны преимущества Fluent API появилось опасение что все  эти “плюшки” просто не могут быть бесплатными. Наверняка это очень дорого, или нет?

Продолжаем разговор о Fluent API. И теперь, после того как мы из предыдущей статьи (или/и личного опыта) узнали о том что это чудо из себя представляет давайте разберемся зачем оно нужно?

В то время как аналитики жарко спорят на тему станет ли основным языком программирования 6-го (видимо) поколения английский или все-таки китайский предлагаю поговорить немного на другую тему, но в том же направлении: как сделать код программы ближе к человеку? 

Один из ответов на этот вопрос зародился еще в 70-х годах прошлого столетия как method chaining в рамках языка Smalltalk и, благодаря стараниям Эрика Эванса и Мартина Фаулера дошел до нас как Fluent API.

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

Обычно, в 1С много показателей и отчётов по ним, а при желании почти каждый можно собрать под свои потребности, так как платформа гибкая и легко поддается доработке. Но это долго и разработка стоит дорого, особенно если речь про кастомный отчёт под руководителя. А с обработкой можно получать короткий отчет сразу в Telegram.

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

Splinter Cell (2002) была одной из первых игр, купленных мной для Xbox, и она по-прежнему остаётся одной из самых любимых моих игр. Эта игра была разработана Ubisoft на движке Unreal Engine 2, лицензированном у небольшой инди-студии Epic Games, которая и сегодня продолжает использовать и лицензировать этот движок в современных малобюджетных инди-играх наподобие Fortnite и Halo: Campaign Evolved.

Я начал заниматься программированием/хакингом благодаря видеоиграм, и до сих пор получаю удовольствие от дата-майнинга/исследования контента, вырезанного из тех немногих игр, в которые играю сегодня. Недавно я решил поискать онлайн вырезанный контент Splinter Cell, и был удивлён отсутствием раскопанной информации. За исключением прототипа игры для Xbox, в котором содержались два уровня, вырезанные из розничной версии для Xbox и некоторые другие мелкие отличия, информации об игре практически нет.

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

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

Один клик по вредоносной ссылке — и контроль над аккаунтом потерян. Без фишинга, без вредоносного ПО.

Я обнаружил уязвимость в механизме OAuth аутентификации популярного десктоп-приложения, позволяющую похитить учетную запись любого пользователя всего в один клик. Основные причины проблемы: отсутствие проверки состояния (state validation), хранение долгоживущих токенов после перенаправления (loopback redirect) и слепое доверие параметру remote_key. В данном посте я подробно расскажу обо всех этапах атаки, почему она сработала настолько эффективно, и каким образом разработчики могут устранить данную проблему.

Несколько месяцев назад я решил заняться поиском уязвимостей в десктоп-приложениях. Для ясности поясню: говоря о поиске ошибок в десктоп-программах, я имею в виду взаимодействие приложений с веб-сервисами (процесс аутентификации, обмен данными или любые точки интеграции). Целью моего исследования стала известная компания, и я не вправе раскрывать ее название, поэтому на протяжении всей статьи буду использовать redacted.com.

Привет, Хабр! Меня зовут Александр Любин, я архитектор 1С в CDEK. В этой статье расскажу про наш опыт интеграции 1С в ERP‑систему и личный кабинет. Расскажу, с какими проблемами мы сталкивались, как их решали, какие инструменты использовали. 

Мой опыт в разработке — 15 лет. Последние три с половиной года — в CDEK.За это время мы с командой смогли в корне изменить позиционирование 1C в компании от «что‑то там для бухгалтерии» до фундамента финансового, регламентированного и оперативного учёта. Смогли доказать, что 1C может быть средой быстрой разработки и инструментом, который позволяет обеспечить потребности как фронт, так и бэк контуров. Я расскажу, как у нас всё проходило.

Недавно команда Цифрового СИБУРа и ЭКОПСИ провела большое исследование. Мы сравнили портреты IT-специалистов из BigTech (таких как Яндекс или VK) с теми, кто работает на заводах и предприятиях. В результате получилось описание двух типов людей: одни ценят стабильность и реальные, осязаемые результаты на производстве, другие предпочитают скорость и свободу в IT. 

Это исследование наглядно показало разницу между ценностями специалиста из Heavy Digital и BigTech, очень рекомендуем его почитать. Но в нём не хватало одного важного элемента — момента выбора. Почему человек, который всегда работал в классической IT-среде, вдруг серьёзно задумывается о переходе на завод? Что он при этом чувствует, чего боится и на что надеется?

Чтобы найти ответы на эти вопросы, мы провели собственный опрос, разделив респондентов на две группы:

1. Те, кто уже работает в IT на производстве (ветка опроса «Я эксперт в Heavy Digital»).

2. Те, кто пока не работает, но думает о карьере в IT-проме (ветка «Я пока не в Heavy Digital»).

Итоги опроса в целом подтверждают выводы ЭКОПСИ, а местами их отлично дополняют. Мы смогли заглянуть в тот самый переломный момент, когда человек стоит на распутье и размышляет: «А не попробовать ли мне свои силы в промышленном IT?»

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

Но так быть не должно было. Чёрт возьми, так никогда не должно было быть. Если бы компании взяли на себя часть ответственности, тикающей экономической бомбы под названием «пузырь ИИ» никогда бы не случилось, и вы жили бы экспоненциально лучше. Позвольте мне объяснить.

Почему существует пузырь ИИ? Не поверхностные спекуляции, а реальные структурные силы, стоящие за ним. Что ж, есть четыре простые, но весомые причины.