За сравнительно небольшое время генеративный искусственный интеллект (Gen AI) превратился в одну из ключевых технических парадигм и уже породил отдельное направление в программной инженерии. Это происходит аналогично тому, как сначала это сделали СУБД, потом интернет с поиском и мобильными платформами. Gen AI несет в себе не меньший потенциал для решения и автоматизации ключевых бизнес-проблем.

Привет! Меня зовут Татьяна Руфанова. Сегодня мы будем понимать и принимать Reactive (Реактив). В статье расскажу, почему мы выбрали Реактив в мидл слое мобильного приложения Альфа-Банка (а у нас 300 микросервисов и треть из них реактивные), разберём, почему «нелогичное» поведение реактивной программы на самом деле очень логичное, какие сложности реактивный подход принесёт в процессе написания и исполнения кода, и как с этим бороться. А чтобы не траблшутить в проде, будем ломать тесты на Project Reactor.

Налейте чаю, включите звуки природы и настройтесь пройти все стадии принятия Reactive.

Disclaimer. Данная работа не повлияла на мои взгляды на программирование, но повлекла достаточно радикальные изменения в подходах к проектированию автоматных объектов.  Теперь, если процесс  автономен и/или не предъявляет требований  к синхронизации, он может использовать другие механизмы параллелизма, не переставая при этом быть автоматным по сути. А почему так случилось, что этому предшествовало  и что это за изменения, вы прочтете далее.

Это не самая большая моя статья (так я думал, начиная ее), над которой я работал, пожалуй, дольше и больше, чем над другими. Но это точно первая моя статья, в которой автоматы и ВКПа не будут главной темой. Тема потоков для меня достаточно необычна, т.к. я совсем не фанат многопоточного программирования. Но,  тем не менее, занимаясь параллельным программированием, время от времени возвращаюсь к теме многопоточности. И вот, чтобы добыть какие-то аргументы для критики и одновременно попробовать найти практическое применение потокам, я решил в этот очередной раз более плотно заняться потоками. А что из этого получилось,  читайте далее.

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

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

GraphQL — невероятная технология, привлёкшая много внимания с тех пор, когда я начал в 2018 году использовать её в продакшене. Вам не придётся долго листать мой блог, чтобы увидеть, как я раньше продвигал её. После создания множества React SPA поверх путаницы нетипизированных JSON REST API технология GraphQL показалась мне глотком свежего воздуха. Я искренне поддерживал хайп вокруг GraphQL.

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

В статье для примеров я буду использовать код на Ruby с превосходной библиотекой graphql-ruby, но я уверен, что многие из перечисленных проблем не зависят от выбора языка/библиотеки GraphQL.

Если вы знаете более качественные решения или способы, напишите мне комментарий.

При написании SQL кода для разворачивания БД и написании хранимых процедур порой очень нехватает простейшего макроязыка. Простыми макросами можно заменять сложные похожие выражения, последовательности операторов SQL или даже из множества файлов собирать один скрипт для разворачивания БД.

Несмотря на то, что наиболее развитым макроязыком является m4, многие разрабочики его не знают. Поэтому был выбран более простой, но многим знакомый препроцессор C - cpp из состава GCC.

Все дальнейшие примеры верны для Linux с установленными GCC и Perl. К сожалению, Windows под рукой у меня нет, но проблем с установкой там GCC и Perl возникнуть не должно.

Привет! Меня зовут Артём и когда-то я уже писал о том, как проводить собеседования от лица нанимающего тимлида. Сегодня мы посмотрим на эту тему с другой стороны. Я расскажу, как техническому специалисту пройти интервью так, чтобы повысить свои шансы на успех:)

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

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

Итак, добро пожаловать под кат :-)

Недавно появились мысли походить на собеседования чем я успешно занялся. Если конкретно - смотрел лидовскую/сеньерскую позиции на Python и Golang(но статья может пригодиться backend разработчикам в целом). Не ставлю целью статьи объять все не объятное и дать какие-то гарантии. Я лишь зафиксирую данные для себя на будущее.

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

Сразу сделаю пометку, что некоторые навыки/ресурсы специфичны(по типу нарешивания Leetcode), но отталкиваемся от текущих реалий рынка.

Привет %user_name%! Сегодня я хочу поделиться своим опытом, как я проходил собеседование в Тинькофф в несколько этапов. На просторах Хабра периодически встречаются статьи на тему HR и там либо рассказывают как успешно пройти собеседование и что нужно HR специалистам услышать, чтобы вас принять на работу или же совсем обратное где специалисты разного уровня и мастей жалуются на работу тех самых HR! Но сегодня будет не про это! И так если стало интересно, добро пожаловать подкат. Осторожно, много текста.

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

Сейчас я больше года не преподаю в Нетологии, но продолжаю это делать в компании Отус, так вот сложилось так, что этот вопрос актуален для студентов и на этой площадке тоже. Скажу сразу у меня богатый опыт прохождения собеседований в несколько этапов, в Рамблер например я едел 3 или 4 раза, где меня собеседовало сразу около 4-5 человек. Чуть больше полугода назад я проходил собеседование в Яндекс, где успешно завалил алгоритмическое программирование, но прошел все остальные этапы, и даже пообщался с руководителем Яндекс Облака где поделился своим мнением по факту прохождения этапов. Все закончилось на том, что меня ждут ровно через пол года на алгоритмической секции и если я ее пройду, то дойдет дело до офера, но я не пошел. У меня нет желания решать задачи с LetCode для прокачки этого не нужного мне скила. 

Мой опыт в компании Virto Commerce Solutions, где я занимал ключевую роль UI автоматизатора, подвергся серьёзному испытанию из‑за безответственности тимлида, что неожиданно привело к моему увольнению.

Моя работа включала разработку собственного фреймворка, который интегрировал Java, Katalon/Maven, JavaScript с Cypress и иногда Python. Я не просто выполнял задачи; я был центральной фигурой в автоматизации UI всего проекта. Этот фреймворк позволил команде ускорить тестирование и повысить надежность релизов.

Помимо разработки, я активно обучал коллег по Java, делясь своими знаниями и помогая им освоить сложные аспекты автоматизации. У меня было много успешных взаимодействий с клиентами из США, где я оперативно решал их проблемы и улучшал процессы. Я также взял на себя проекты, которые изначально терпели неудачу, исправляя ошибки и доводя их до успешного завершения, несмотря на изначальные трудности и плохое управление.

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

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

Меня зовут Никита, я — Python бэкенд-разработчик из Surf. Месяц назад я закончил первый проект в аутсорс-компании. Признаться, он стал для меня открытием — раньше я работал только в инхаус-продуктах. Это два совершенно разных опыта с разным отношением к продукту, коду, работе, которые повлияли на моё общее отношение к программированию. И сегодня я хочу поделиться этими изменениями за 2 года коммерческого опыта. Многие из этих вещей могут показаться очевидными, но я их осознал только со временем (да, два года для молодых – это уже срок).

Рутина при написании кода неизбежна. Порой, соблазн скопипастить уже написанное, чуть подправив под задачу слишком велик. В статье показан один из множества способов выделить структуру рутинной задачи и помочь программисту не раздувать код бездумным копированием.

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

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

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