Мне нравится использовать композицию и инъекцию зависимостей, но когда каждая сущность начинает инъектится несколькими зависимости, получается некое нагромождение.

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

Но есть более управляемый способ.

Общая рыночная капитализация глобального рынка криптовалют за последний год выросла с $6 млрд (в январе 2016 года) до $28 млрд (на текущий момент). С начала 2017 года рынок криптовалют вырос примерно в полтора раза. На биржах торгуются уже больше сотни разных криптовалют. Крупные организации объединяются в консорциумы, чтобы выпускать свою валюту. Даже государства делают свои национальные криптовалюты. Технологии блокчейна дошли до такого уровня, что уже почти любой может запустить свою криптовалюту, чем мы в этой статье и займемся. Легче всего создать свои монеты на смарт контрактах на базе ethereum.

Введение

При unit-тестированиии кода рано или поздно встает вопрос тестовых данных. И если в одном случае достаточно просто несколько жестко зашитых переменных, то в других случаях необходимы сколько-нибудь большие и случайные данные. В управляемом мире нет проблем с генерацией пользовательских типов (взять тот же Autofixture), но мир C++ зачастую вызывает боль и страдание (поправьте меня, если это не так). Не так давно я познакомился с замечательной библиотекой boost::di и под ее влиянием у меня начала созревать идея библиотеки, которая позволила бы C++ программистам генерировать пользовательские типы данных, забитых случайными значаниями, и это не потребовало бы предварительного их описания. Получилось что-то вроде:

struct dummy_member{
    float a;
    int b;
};
struct dummy{
    explicit dummy(dummy_member val, std::string c) : val_(val), c_(c) {}
private:
    dummy_member val_;
    std::string c_;
};
int main(int argc, char* argv){
    auto d = datagen::random<dummy>();
    return 0;
}

→ Ссылка на код. Библиотека header-only,C++14. Всех интересующихся прошу под кат.

В статьях про PVS-Studio всё чаще говорят об уязвимостях и дефектах безопасности, которые можно найти с помощью статического анализа. Авторов этих статей критикуют (и я в том числе), что не каждая ошибка является дефектом безопасности. Возникает однако интересный вопрос, можно ли пройти весь путь от сообщения статического анализатора до эксплуатации найденной проблемы и получения какой-то выгоды. В моём случае выгода всё же осталась теоретической, но эксплуатировать ошибку удалось, не особо вникая в код проекта.

Я всегда восхищался силой коллективного разума. И укреплению моей убежденности в ней послужила недавняя история: я рассказал, как можно интегрировать телефонию с Telegram с помощью сервиса IFTTT, на что коллеги из Voximplant ответили, как это можно сделать проще, а потом господин recompileme в своем комментарии обратил внимание на то, что удобный API телеграма решает задачу без участия каких-либо третьих сервисов.

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

Преимущество № 1: Вы можете заблаговременно находить баги и ошибки

char *str = (char *)malloc(sizeof(char) * strlen(buffer));

Во-первых, определение

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