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

Пару лет назад я проходил на собеседование в подразделение IT в одной достаточно известной компании. Сам процесс проходил достаточно гладко. Я рассматривался на позицию разработчика и аналитика данных, который занимается хранилищами и следит за управленческой отчетностью. Мы очень быстро нашли общий язык и о сумме оклада договорились без проблем. Собеседование принимал сам директор IT подразделения, который услышав мой финансовый запрос, ответил "Без проблем. Просто говорите когда готовы выйти"

После чего я получил вопрос которого вообще не ожидал "А вы хотите серую зарплату или белую?", и предложили мне сумму на 30% больше, той что запросил, при условии если я выберу серую схему оплаты. Т.е. минимально допустимую сумму по МРОТ платить официально, а все остальное на руки, либо в конверте. Моя первая реакция вызвала отторжение и ответил "Белую! Ну а как же будущая пенсия, на которую хотелось бы верить, что буду получать"

После чего я получил риторический вопрос, который я сам себе задаю до сих пор "А точно ли вы аналитик?"

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

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

Меня зовут Аксёнов Вячеслав и я бэкенд разработчик, пишу на Java/Kotlin, расскажу про то, как я сдавал сертификацию на знания Java SE 11 от Oracle. И какие нюансы я понял в процессе подготовки и сдаче.

В ответ на мою статью про тупиковость развития линейки процессоров Эльбрус в качестве базовой платформы для отечественных general-purpose CPU, пользователь @alexanius (Алексей Маркин) написал свою статью-ответ, где привёл возражения моим тезисам. Дабы не превращать дискуссию в формат форумной перепалки, я попытаюсь структурировать изложенные возражения, максимально опустив малозначимые на мой взляд детали и не относящиеся к делу реплики. Также мы оставим на совести Алексея некорректные высказывания и переходы на личности. Это мишура, которая не поможет нам глубже понять суть проблемы.

Итак, если суммировать, то в моей статьей были приведены следующие недостатки Эльбруса:

Относительно недавно мы начали строить качественно новую версию платформы "Юнидата", в которой изменилось очень многое, включая архитектуру, технологии, подход. Даже основная идея продукта приросла новыми деталями.

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

Об авторе статьи. Меня зовут Илья, я занимаюсь разработкой новой версии. Мне не довелось работать с предыдущими версиями "Юнидата", и в проект я пришел на этапе прототипа. Я могу быть не до конца объективен на тему того, почему было выбрано то или иное решение, если это происходило еще до моего присоединения к продукту. В причинах перехода я написал свое видение, после общения с командой.

Итак, всем, кто любит истории переезда с ноткой технических особенностей, добро пожаловать под кат.

Краткий тех.обзор

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

Кроме того, продукт разделён на Community Edition (хранится в публичном гитлабе) и Enterprise Edition.

Фронтенд состоит из 20 модулей (число не конечное). Мы используем свежую версию typescript и почти свежую react (сейчас 16, но перевод на 17 - дело ближайшего времени). Применяем MVC подход в каждом модуле: реакт только view-слой, своя observable модель (обязательно про нее напишем отдельную статью), mobx сторы в качестве контроллеров.

Как все знают, в нашей прекрасной стране существует интересный федеральный закон «О персональных данных» он же 152-Ф3 (можно ознакомиться с ним, например, тут), но суть немного не о нём, а о том как главная социальная сеть ВКонтакте нарушает данное законодательство.

Предыдущая статья про микропроцессор Эльбрус вызвала живой отклик читателей Хабра. Изначально я планировал написать только статью о технических проблемах VLIW-архитектур на конкретном примере Эльбруса и имел мало желания углубляться в вопрос дальше, ввиду его куда большой скользкости и дискуссионности. Но сказать «А» и не сказать «Б» было бы, наверное, не совсем правильно. Поэтому в данной статье я попытаюсь изложить исключительно СВОЙ взгляд на проблематику того, какие процессорные Архитектуры (в контексте general purpose CPU) надо развивать и поддерживать рублем в России.

Любое серьёзное преобразование в компании, от «внедрения» какого-либо нового ИТ-процесса до пресловутой цифровой трансформации, является организационным изменением: требуется изменить уже имеющиеся системы управления, чтобы они стали работать по-новому, или обрели новые свойства и способности. Приходится работать с формальной стороной (регламенты), культурной стороной (как у нас принято делать дела), технической составляющей, политической и так далее. Это — очень интересная работа, проводить организационные изменения в средних и крупных компаниях.

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

В частности, некоторые эксперты выделяют три явно отличные друг от друга фазы крупного организационного изменения. На первой фазе требуется понять цели и задачи, провести проектирование первых новых систем и структур, составить коалицию влияющих и неравнодушных, приобрести новые необходимые компетенции — много всего. Главное — «сдвинуть махину», «придать ей ускорение», «дать импульс».

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

- Составь, пожалуйста, руководство по тому, как делать архитектуру.

С такой просьбой ко мне однажды обратились менеджеры по разработке софта в компании, где я работаю или работал (не хочу раскрывать время и место). И надо сказать, что сначала эта просьба меня здорово озадачила. На тему архитектуры софта написано много книг, и не самых тонких. Мне предлагается написать еще одну? Чем она будет отличаться от существующих? И зачем вообще им это?

Что касается "зачем", то здесь все было понятно. Цель у менеджеров была благая. Проектов в компании обычно больше, чем могут осилить штатные архитекторы. Идея была в том, чтобы архитектуру для небольших проектов делали либо сами менеджеры по разработке, либо старшие разработчики, а архитектор только проверял, направлял и помогал где нужно.

Цель хорошая, запрос хороший. Оставалось только понять, как оказать им конструктивную помощь, а не отправить читать книжки или не засесть писать свою.

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

Собственно, этот список я здесь и публикую.

Эджайл – это модно или полезно? Не знаю, как бы мы ответили на этот вопрос года три назад, а сейчас однозначно: это полезно и нужно! Именно благодаря Agile-подходам нам удалось успешно воплотить довольно давнюю идею и запустить в компании важнейший проект по созданию хранилища мастер-данных «М.Каталог». Но дело не столько в нем – кардинально изменились мы сами, что еще не раз покажет себя на новых проектах. Попробуем описать, в чем заключаются эти перемены и чем они полезны.

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

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

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

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

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

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

В предыдущей публикации мы сравнивали российские системы ДЭГ (дистанционного электронного голосования) с эстонскими — и мгновенно залезли в такие технические детали, как слепая подпись, ключевые пары и так далее, то есть, по сути, в архитектуру систем ДЭГ.

Впрочем, залезли мы относительно поверхностно — на самом деле, российская система ДЭГ (для определённости дальше будем описывать федеральную систему, ибо она в целом интереснее московской) с технической точки зрения устроена крайне непросто, но сложность эта имеет причину. И большинство комментариев о том, что «начальнику на стол ляжет список, кто как проголосовал» — из непонимания или нежелания, иногда намеренного, разобраться в этой сложности.

Конкретные объяснения, «почему с ДЭГ всё плохо», зависят от квалификации высказывающегося — и простирается от «какие числа захотят, такие и покажут» (Дарья Митина, «Коммунисты России», на недавнем круглом столе у Александра Асафова) до ссылок на протокол двух агентств с указанием на отсутствие таковых агентств (статья Александра Исавнина на Хабре).

Попробуем разобраться, так ли всё плохо на самом деле, как устроена российская — для определённости возьмём федеральную, которую делает «Ростелеком», она интереснее — система ДЭГ, что там с протоколом двух агентств и что помешает показать такие числа, какие захотят. Ну и заодно — какие есть основания верить, что система реализована действительно так, как говорится в документах.

Надеемся, вам будет интересно — в конце концов, на Хабре можно быть равнодушным к выборам, но не к сложным технологическим системам!

Привет, Хабр!

На связи Андрей Рыжкин, CTO AGIMA. В нашей компании более 30 команд разработки, и у каждой свой тимлид (или несколько). Людей много, а значит, их нужно нанимать, развивать, мотивировать, а иногда – расставаться с ними. Работа с людьми на мой взгляд – это одна из важнейших и при этом самых сложных функций тимлида или технического руководителя. Эта статья – об одном из аспектов этой работы: о том, как искать и нанимать разработчиков. В основе материала мой контент для курса «Руководитель команды разработки», а также мой опыт за весь карьерный путь от разработчика до CTO.

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

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

А как хорошо всё начиналось…