I’m using vscode for a long time, but only recently appreciated how cool Remote set of extensions is. It allows you to run vscode-server on remote host or inside a container while utilizing local UI vscode window for all operations.

For the long time, I’ve been using nix-darwin and home-manager to configure and and keep my laptop configuration up-to-date. Today I had a little bit of spare time and decided to finally migrate towards using nix flakes.

There is a wonderful kotlin library for reading configuration from various sources (environment variables, files, etc.) – konfig. It allows to define your application configuration in a declarative way and even perform some data transformations along the way.

Current version of JIRA inside Itransition does not allow to validate “whether a person belongs to a certain group” for multi-people fields, only for single-user fields. Coorish – is a small utility to determine ineligible people being specified in JIRA tickets.

Gitman is a Telegram chat bot. It helps to manage source code repositories in Itransition Bitbucket server. Instead of creating repositories manually, our HelpDesk operators are using this bot. It sets up all merge hooks, commit message checks, default reviewers policy, other things which is tedious to do by hands.

Personer is a small bot written in Kotlin, which is started by systemd timer (thanks nixos) and performs a read-update cycle over our project cards (custom JIRA issues). It features modern Kotlin’s Flow framework.

Хочу рассказать о Low Code Platform, которой пришлось воспользоваться буквально на днях – Power Automate от Microsoft. Мне, как разработчику ПО, никогда не нравились подобные системы для “программирования мышкой”. Казалось, что с их помощью сложно добиться хоть сколько-нибудь приемлемого результата.

С большим опозданием, продолжаю цикл статей про Workplace бота. Ссылки на предыдущие части: 1, 2, 3 и 4. Сегодня, впрочем как обычно, речь пойдет про очедную функциональную дичь ;).

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

Nitrax (NIX + ITRAnsition, I suck at naming) is my nixops configuration to deploy bots and services.

This is a short description of the project I’ve been working in a previous company. I’ll try to mention all technologically interesting aspects of it without revealing any intellectual property, which belongs to the customer.

Trimmer is a small bot, which iterates over JIRA issues and trims whitespaces fields values. Without that, human mistakes on copy-paste operations can make automated JIRA statistics collections harder.

Хранение паролей/токенов любого характера и толка в репозитории – плохая и опасная практика. Несмотря даже на то, что это информация может относиться к изолированному staging или даже локальному окружению. Даже если они “потом будут встроены в итоговый html”. Даже если пароль “явно выглядит как заглушка”. Наличие паролей “от staging-а” может легко привести к компрометации настроек “от prod-а”.

Методика разработки через feature branches или pull requests позволяет организовать максимально независимую работу разработчиков – без необходимости частой синхронизации между ними. Большим плюсом этой методики является простота участия всех членов проектной команды в процессе code review, так как каждая новая feature, исправленный дефект, или доставка версии представлены отдельными ветками в репозитории исходного кода. Желательно, чтобы любое вносимое в ПО изменение происходило через создание отдельной ветки и включение ее (после code review) в основной стрим (обычно, ветка master).

Возможно я в этом не одинок, но меня сильно разочаровывают размеры современных приложений. Сейчас считается нормой создавать сайты, скачивающие десятки мегабайт при первой загрузке, иметь приложения для телефонов размером в несколько сотен мегабайт, базовые образы docker контейнеров занимают гигабайты… Ситуация парадоксальная – “дешевле” не заботиться о размере, так как усилия, потраченные в этом направлении будут стоить компании-разработчику дороже.

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

Итак - подошло время очередной технической статьи. На этот раз речь пойдет про API-over-HTTP. Вроде банальнейшая вещь, каждый так “сто раз делал” и чего вообще можно было на эту тему необычного придумать… Действительно, практически в любом backend-е есть слой “контроллеров”, который отвечает за то, чтобы функции приложения были доступны извне по протоколу http. Кто-то использует json, кто-то xml, но общий знаменатель всегда - http.

Что-то давно не видно технических статей, спешу исправиться. В связи с задержкой, “градус гиковости” будет временно значительно повышен. В публикации на прошлой неделе я рассказал про новый бот для Workplace, который помогает управлять проектными (и не только) группами не прибегая к помощи HelpDesk. Он написан на языке программирования Haskell, что для нашей компании выбор не совсем типичный (хотя с RFX-ами на эту тему к нам обращались). Знаниями надо делиться, так что запланировал несколько статей по мотивам написания этого бота. Статьи будут раскрывать некоторые интересные аспекты реализации, которые, на первый взгляд, могут показаться странными или неочевидными, но все же позволяют по новому взглянуть на типовые задачи, возникающие при разработке ПО.

Here is a facebook bot (we use facebook’s Workplace product as an intranet collaboration point) to manage AD groups. There are number of articles about the creation process.

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

Причина, по которой вам стоит потратить время на заполнение одна – это возможность взглянуть на положение дел на проекте “со стороны” и определиться с возможными улучшениями.

Я бы хотел продолжить цикл технических статей на Workplace рассказом о том, с какими трудностями можно столкнуться при работе с Active Directory по LDAP протоколу. Полноценной статьей такой рассказ назвать сложно, скорее – сборник рецептов. Стоит заранее оговориться – никаких упоминаний о Windows и PowerShell в статье нет, это тема очень обширна и заслуживает отдельной публикации (а может и нескольких).

Что такое “культура разработки?” Само слово культура очень многогранное. В рамках статьи мы поговорим не столько про процесс написания кода, сколько про грамотную работу со вспомогательными инструментами в стремлении сделать итоговый продукт максимально качественным. Мнением на эту тему поделился Александр Шестаков, который рассказал, почему так важна личная заинтересованность каждого сотрудника и какой путь уже проделан компанией в этом направлении.

Защита программного обеспечения от уязвимостей – важный аспект для IT-индустрии. При проектировании систем или написании программного кода случаются ошибки, которые потенциально могут стать причиной брешей в безопасности. Они приводят к возможным утечкам строго конфиденциальной информации, потере доверия к программному продукту и финансовым убыткам. Для предотвращения подобных случаев в IT-отрасли регулярно появляются новые инструменты аудита, давно существуют и отлично описаны методики “безопасного” программирования. Казалось бы, следуй правилам и избежишь проблем, однако в процессе разработки ПО всегда существует пресловутый человеческий фактор.

Чистота кода – понятие не новое. Все разработчики стремятся к читаемости, поддерживаемости, простоте, отсутствию copy-paste и hardcode. Случается, что в программном коде можно увидеть нецензурную лексику и оскорбления. Своим мнением на эту тему поделился Александр Шестаков, который рассказал, чем чревато использование ругательств и какой опыт компании в этом направлении.

В марте этого года в компании появилась новая инициатива – открытые митапы для разработчиков, которые проводятся раз в два месяца. Их организаторами выступили Александр Шестаков и Александр Зенькович.

Я работаю в текущей компании вот уже 12 лет. Пришел сюда еще на третьем курсе университета. Работал все время в отделе разработки программных систем. Занимался программированием на C#, потом была Java и немножко JavaScript, долгое время работал на Ruby — все, кто меня знают, ассоциируют с этим языком программирования. Ruby я люблю за выразительность, в нем в единице кода помещается больше «смысла». Если, к примеру, на C# принято писать «Войну и мир», то на Ruby — баловаться хокку.

Я прошел все стадии карьерной лестницы от junior и senior developer до software engineer. За последние пару лет я успел поработать на большом проекте HSS – архитектором, затем я решил отдохнуть и начал писать Ruby-код для одной социальной сети американских военных. Примерно 30% своего времени я уделял технической координации, помогал людям на других проектах. С окончанием работы на проекте у меня появилось некоторое количество свободного времени, и тут как раз было решено позицию CTO разделить на две части. Влад Никитин стал публичным лицом компании, а меня сделали «внутренним лицом» — VP Engineering, я являюсь главой технических координаторов.

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

Современная разработка ПО не обходится без автоматических тестов. Сюда входят базовые Unit и Integration тесты, сложные Performance и Penetration тесты, а также множество других способов проверить программу ещё до отправки тестировщкам. Менеджеры давно перестали спорить о пользе автоматических тестов. Команды, практикующие автоматизацию тестирования, следующие методологиям TDD и BDD, быстрее поставляют работающие системы с меньшим количеством ошибок. Что делает их, в конечном счете, конкурентоспособными на перегретом рынке коммерческой разработки программных систем.

This repository has born as a solution for the repeating and tedious Continuous Integration servers (TeamCity) installation across the company. It provides a way to quickly bootstrap and run TeamCity, automatically integrated with VCS of choice and setup reporting tool for many languages.

Непрерывная интеграция (continuous integration, CI) – это методология организации процесса разработки программных систем, при которой каждое изменение исходного кода, как и поведение самой системы с внесенным изменением, подвергается набору различных проверок.

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

Статья также доступна на Английском языке.

Mutants, zombies… Yes, there is an inconsistency between the article’s topic and image to attract attention. But I swear to god it is actually the poster hanging on the wall inside my flat.

The topic of this article is mutation testing – a very special methodology among others in the field of testing software quality. It is capable to amaze, make you think you lost your mind and, finally, can bring peace into your programmer’s soul. I know, the definition sounds quite bold and pretentious, but I hope that after reading the rest of the article you’ll be convinced just like I am.

To stand the test of time, software products must be built with changes in mind.

Continuous Integration (CI) is a methodology of organizing the software development process in which every change of the source code from the shared repository, as well as the behavior of the software system as a whole with the aforementioned changes, are checked for validity.

Article is also available in Russian language.

Ruby is a multi-paradigm programming language. It fully allows writing old-fashioned procedural code, but also provides many useful constructs and features from the functional world.

The majority of developers come to Ruby from the imperative world. They are used to making many local variables, changing their state and relying on implicit dependencies. Very quickly, it becomes clear that code can be much more expressive, using powerful idioms from functional languages. Ruby isn’t a fully functional language by any means; functions are not first class citizens, evaluation flow is not lazy, pattern matching support is very limited, etc. But still, it is possible to write code in a functional way and garner many benefits as a result.

In the field of testing, there are many ideas and movements, some of which have formed into schools. But there is really no universally accepted standard for what testing is and how it should be performed.

The attempts to establish such a standard (such as the infamous ISO 29119) are met with either ice-cold indifference or hell-hot opposition. Why? Well, because professional developers want to be able to choose approaches and tools that fit particular projects, time frames, budgets and business goals, and deep down they know they will continue to do what’s best to perform their duties well.