Привет! Меня зовут Екатерина Никишина, и я занимаюсь 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 и начать применять его в работе.

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

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

В некоторых технологиях и языках программирования юнит-тестирование — уже давно неотъемлемая часть написания кода. Оно интегрировано в разработку и доступно «из коробки» в виде фреймворков, как, например, JUnit для Java, xUnit/nUnit для C# и т. д. Но в Oracle культура юнит-тестирования мало распространена. В статье я расскажу, как и зачем мы внедрили автотесты при разработке на Oracle и для чего их используем.

К написанию статьи меня побудил интерес разработчиков Oracle к изучению Java. Статья не носит обучающий характер и не является инструкцией для перехода с одной технологии на другую. Цель — рассказать, как я переходил на Java и с какими трудностями столкнулся.

Недавно у нас на работе стихийно возник спор о том, стоит ли вводить непрерывную доставку. Не имея в виду сразу переделывать все наши процессы под непрерывную доставку, я, однако, отстаивал целесообразность такого подхода «в общем». К сожалению, после начала спора я за приемлемые 5–10 минут так и не нашел в интернете подходящего текста, доходчиво объясняющего, зачем нужна непрерывная доставка, чтобы хорошенько подкрепить свою точку зрения. Материалов о том, как наладить непрерывную доставку, очень много, а вот статей (на русском языке) о том, зачем же это нужно, недостает.

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

«Сказать программисту, что уже есть библиотека, делающая Х, — это то же самое, что сказать музыканту, что уже есть песня про любовь» (с)

Есть разные способы посмотреть, чем занят сервер под Windows: можно зайти по RDP и открыть Task Manager или Process Explorer, а можно запустить удаленный сеанс через PowerShell и набрать команду Get-Process. Но что если серверов много и нужна информация по всем сразу? Заходить по RDP неудобно, а для работы с PowerShell требуется определенная квалификация.

Мы не нашли подходящего инструмента, поэтому разработали свой. Итак, встречайте ProcInsp — совершенно новый диспетчер задач для Windows.

Допустим, перед вами стоит задача написать фронтенд-приложение. Есть ТЗ с описанием функционала, тикеты в баг-трекере. Но выбор конкретной архитектуры лежит на вас.

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

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