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

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

Теперь «фриланс» становится новым трендом. И поскольку многие начинают к нему присматриваться, первый вопрос, который возникает: «Где можно найти хорошие предложения по удаленной работе?»

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

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

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

В предыдущей статье мы рассказывали о том, что такое Attribute-Based Access Control и в чем его преимущества по сравнению с наиболее распространенным на сегодняшний день Role-Based Access Control. Пришло время рассмотреть ABAC более детально, через существующий стандарт под названием XACML.

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

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

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.