Архив рубрики: Программирование

Ethereum: Как запустить ноду с приватной сеткой

Для разработки тестирования под Ethereum вместо публичной удобнее использовать не публичную сеть, пускай даже и тестову, а свою — приватную (Private Network). Для этого достаточно установить на свою рабочую станцию пакет с бинарником ноды (geth) и создать один конфигурационный файл (genesis file) с описанием новой сети. Читать далее →

Размышления на тему «хрупкого» ПО

унитаз-04Ничто так не помогает иллюстрировать суть явления, как красочная, хлёсткая метафора. К примеру, фекакльно-анальная метафора поможет в описании эксплуатационной хрупкости (противоположность запасу прочности) софта.

Предположим, что команда разработала такую вот бесхитростную систему, как на картинке слева. Зиждясь на твёрдом основании (к примеру, системных библиотек), она, тем не менее, имеет некие степени свободы: её можно «качнуть» влево-вправо, вперёд-назад, немного двинуть в тех же направлениях. Однако, для того, чтобы разрушить-завалить эту конструкцию, необходимо приложить достаточные усилия. Читать далее →

Ansible & UML: Кто-нибудь пробовал описывать playbook’и на UML?

ansible-umlДля описания Ansible плэйбуков и ролей попробуем использовать UML-диаграммы. Ранее уже была предпринята попытка взглянуть на Ansible, как на некое подобие языка программирования под углом ООП, сейчас же проделаем подобное с помощью диаграмм классов UML. Читать далее →

ООП на Ansible? Да ладно!

ansible-oop-miniatureВ одной из последних статей я знатно набросил на Puppet  в пользу Ansible. В этой же статье попробую продемонстрировать, от чего я был в особенности в восторге при знакомстве с Ansible — от функций, а именно, от возможности объединять куски последовательностей действий (tasks) в некое подобие функций и даже классов. В общем, адепт ООП везде объекты найдёт. 🙂 Перейдем к примеру… Читать далее →

Мониторинг на коленке: PHP -> StatsD(Bucky) -> Graphite

php-to-graphite_miniatureРаньше уже наталкивался на упоминания Graphite и StatsD, но всё в контексте каких-то нереальных приседаний с конфигами, и потому проходил мимо. Недавно же на службе звёзды сошлись таким образом, что-таки решил сесть и запилить по-быстрому сбор и отображение неких стат.данных PHP-приложения посредством StatsD и Graphite. Читать далее →

RabbitMQ: Пример реализации RPC на PHP

php-rpc-rabbitmqОказалось нетривиальной задачей найти вменяемый пример кода реализации RCP поверх RabbitMQ для PHP. Пакет videlalvaro/Thumper, в основе своей имеющий videlalvaro/php-amqplib, кроме некоторых искусственных ограничений для пользователя (субъективно), обладает ещё и недостатком videlalvaro/php-amqplib — создать соединие и отправить сообщение в RabbitMQ занимает 120 попугаев по времение против 20 попугаев в PECL :: Package :: amqp — биндинге сишной библиотеки librabbitmq. Читать далее →

Ansible vs. Puppet: лирическое отступление.

puppet-ffffuuuuAnsible считается наипростейшим способом автоматизировать IT инфраструктуру — это то, что написано на сайте производителя. Так это или не так, судить не берусь. Однако, имея небольшой опыт почти одновременного кавыряния в Puppet и Ansible, неавторитетно заявляю: Ansible действительно проще в освоении нежели Puppet. Читать далее →

Консолидация логов Storm (Storm — Rsyslog — Logstash — Elasticsearch)

storm-logsТут коротко описаны мои изыскания касательно сбора информацией из текстовых логов компонентов кластера Twitter Storm средствами Rsyslog с последующей передачей оной через Logstash в базу Elasticsearch c возможностью анализировать её через Kibana. Читать далее →

Модель управления разработчиками

триугольникНедавно смотрел фильм «Гравитация». В одном из эпизодов героиня Сандры Буллок чувствовала себя весьма не камфортно, оказавшись в открытом космосе — там, где нет опоры и не за что зацепиться.

В каком-то смысле и Разработчик (среднестатистический сферический в вакууме) пользовательских приложений чувствует себя незащищённым, оказавшись в этом мире. В то время, как три основные Опоры дают ему устойчивость и уверенность: Читать далее →

Когда можно расширить команду разработчиков?

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

Менеджер проектов считал приемлемым расширять команду только после того, как станет очевидной «пропускная способность» текущей команды. То есть, появится возможность предсказывать с большой долей вероятности, какое количество проектов будет успешно сдано в единицу времени. Читать далее →