Привет! Меня зовут Игорь Шаталкин, я разработчик-эксперт в CUSTIS. В этой статье продолжим обсуждение монолитов и микросервисов. Я подробно рассмотрю важные моменты работы с микросервисной архитектурой и поделюсь как своим опытом, так и опытом компании CUSTIS: с чем нам приходилось сталкиваться в проектах и какими способами мы решали возникшие проблемы.

Привет! Меня зовут Игорь Шаталкин, я разработчик-эксперт в CUSTIS. В ИТ только и разговоров о том, что лучше — разделять или монолитствовать. Однако выбор архитектурного подхода зависит от множества факторов: масштабов проекта, бизнес-логики, организационной структуры команды и технических ограничений.

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

А в следующих статьях планирую поделиться практическими кейсами внедрения микросервисов и рекомендациями по переходу от монолита к микросервисам.

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

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

Для большинства ИТ‑компании офис давно уже стал чем‑то большим, чем обычное пространство для работы. Для многих — это настоящее место силы, где рождаются новые идеи и прорывные проекты, где встречаются команды; место, где находят единомышленников и новых друзей.

Но как быть, если ваш офис далёк от совершенства? И если вы не ИТ‑гигант с огромными бюджетами, который может позволить себе исполнять любые капризы сотрудников? В статье я поделюсь простыми примерами, как можно сделать удобным и современным даже самый скромный офис. А также расскажу, как нам удалось за 2 года повысить уровень удовлетворённости условиями труда в CUSTIS аж на 23% и достичь почти 100-процентного показателя.

В современном мире неуклонно растёт спрос на высококлассных ИТ‑специалистов. В связи с этим увеличивается и потребность в формировании качественных знаний и устойчивых навыков у сотрудников.

Может ли корпоративная библиотека помочь в решении этих задач? И нужна ли она в принципе ИТ‑компаниям? На эти вопросы я отвечу в статье, а также поделюсь опытом компании CUSTIS по созданию и развитию библиотеки, которой уже более 10 лет.

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

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

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

Привет! Меня зовут Екатерина Никишина, и я занимаюсь HR-проектами в ИТ-компании CUSTIS. Каждый год перед нами, как и перед тысячами компаний, вставал вопрос, как праздновать 23 февраля и 8 марта? Делать ли это в привычном формате отдельно мальчики, отдельно девочки или что-то менять? Как вовлекать сотрудников, когда многие работают в гибридном или удалённом формате? А главное — как сделать праздник, соответствующий ценностям и корпоративной культуре компании?

В этой статье я расскажу о нашем опыте: как мы пришли к традиции отмечать общий праздник «23 + 8», а со временем сделали из него серию полезных и интересных мероприятий под названием «Инженерная весна».

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

Привет! Меня зовут Алексей Маряхин, я разработчик на Oracle. В этой статье продолжим знакомиться с темой отладки PL/SQL-кода.

 В предыдущей статье мы изучили возможности отладки в PL/SQL Developer. В этой предлагаю рассмотреть ещё один инструмент — SQL Developer (версия 21.2.0.187 Build 187.1842). Также обозначим плюсы и минусы этих инструментов в сравнении.

Как оказалось, информации на русском языке на эту тему не так много, а документация по SQL Developer не отвечает на многие вопросы. В статье постараюсь осветить основные моменты касательно использования SQL Developer для отладки. Если тема для вас актуальна, велком!

Привет! Меня зовут Алексей Маряхин, я работаю разработчиком на Oracle и пишу много, очень много кода. И когда программа ведёт себя не так, как ожидалось, на помощь приходит отладка.

Не так давно выяснил, что не все разработчики владеют функционалом отладки или знают её фичи. А если код сложный и баги искать всё равно надо? Литературы на русском языке про отладку практически нет.

Тогда я собрал подробный гайд для коллег и провёл внутренний семинар по обмену опытом. Материал получился настолько подробным и полезным, что решил поделиться им с сообществом программистов. На примере инструментов для работы с СУБД Oracle, которые используются у нас в компании, посмотрим, как работает отладка, сравним их в теории и узнаем, что внутри.

В серии из двух статей подробно расскажу о способах, инструментах и нюанса отладки кода PL/SQL. Первая часть — про инструмент PL/SQL Developer. Поехали!

В ходе обсуждений докладов на Analyst Days возник вопрос о связи Domain-driven design (DDD) с объектно-ориентированным подходом (ООП): оказывается, для большинства она вовсе не так очевидна, как мне представлялось. Подробнее погружаясь в это обсуждение, я понял, что для современной разработки их общность действительно не очевидна, а практики DDD можно применять, не связывая с ООП. Я думаю, что подробное рассмотрение этого вопроса будет полезно для получения комплексного представления и понимания DDD, что сделает его применение эффективнее.

Около десяти лет назад мы в CUSTIS реализовали систему распределения товара для «Спортмастера». Со времени ее запуска изменилось многое: корректировались цели заказчика, менялись возможности и потребности рынка, появились новые способы автоматизации. Но на протяжении всех этих лет система дорабатывалась, поддерживалась и настраивалась нами, чтобы оставаться максимально удобной и эффективной для заказчика.

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

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

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

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

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

Решение — подход DDD, Domain Driven Design, было предложено Эриком Эвансом в 2003. Но прежде, чем о нем говорить, необходимо немного углубиться в историю развития разработки софта как такового.

Многие методологии требуют сначала описать требования к системе как черному ящику и лишь затем переходить к проектированию и построению моделей. Способам такого описания посвящена инженерия требований. Однако, это присуще и Agile-методам, ведь User Story тоже описывает систему как черный ящик. Целью такого подхода была гарантия, что разработанная система будет пригодна для использования, внедрение пройдет гладко. Проблема в том, что так — не работает. А значит, нет смысла чересчур углубляться в требования, а стоит быстро переходить к моделям системы, которые можно строить по-разному.

В EF Core много полезных фич по работе с базами данных, но что, если этих возможностей не хватает? Я был удивлен, когда узнал, что фреймворк из коробки не умеет создавать вьюшки и отслеживать изменения их исходного кода. А что, если нам нужны не только вьюшки, но еще и синонимы, гранты и DB link? При этом мы хотим видеть их как на производственной БД, так и в интеграционных тестах! В посте будет инфа про загадочный внутренний мир фреймворка: про ключевые интерфейсы, отвечающие за генерацию и применение миграций, про то, как можно подменить эти интерфейсы, и, самое главное, почему тут не поможет контейнер, создаваемый в Startup. Также поговорим про основные объекты EF Core: что такое модель и зачем нужен снепшот? Из чего состоит миграция и зачем нужно транслировать операции в SQL?

Пост будет интересен как тем разрабам, которые столкнулись с задачами создания и обновления вьюх, синонимов и других SQL-объектов (они узнают про наш пакет, позволяющий закрыть эти вопросы), так и тем, кто хочет написать свое расширение (они узнают про подмену сервисов). Если Вы хотите, чтобы мир EF Core стал для вас менее загадочным, но ничуть не менее интересным, добро пожаловать под кат.

Меня зовут Роман, я ведущий специалист по обеспечению качества ПО. Сегодня я поделюсь своим опытом наставничества. Этот рассказ не инструкция по применению, и здесь вы не получите конкретный алгоритм. Но это success-story для вдохновения, мой личный опыт и мысли, которые могут быть полезными, если вам представится возможность стать наставником.

Что чувствует ваш новый коллега в свой первый рабочий день? Он может испытывать целый букет эмоций, но одно можем сказать наверняка: у него много вопросов! Кого и как зовут, чем занимаются разные отделы, каковы принципы работы в компании. Как всё устроено?

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

Меня зовут Игорь, мне 34 года. Я разработчик и будущий летчик. Работаю в компании CUSTIS и при этом студент-первокурсник Якутского авиационного технического училища. Мой процесс поступления растянулся на три года, но я не потерял мотивацию, не сдался и всё же сумел доказать самому себе, что возможно всё — было бы желание!

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

Этот материал для тех, кто хочет эффективно погружаться в проекты большого масштаба и следить за состоянием их здоровья. В статье расскажу, как максимально быстро разобраться в стандарте OMG Essence и начать применять его в работе.

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