НЛП: Диаграмма Пресуппозиций

Пресуппозиции НЛП

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

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

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

Далее на примере описывается процесс инсталяции и первоначальной конфигурации приватной Ethereum сети из одной ноды для Ubuntu 16.04. Актуально как мининум для geth 1.6.7-stable-ab5646c5

Итак..

Управление и наилучший результат

- много вопросовВ своё время меня понравилось вычитанное где-то утверждение:

Управление людьми — это управление их энергиями. Читать далее →

Автосборка Docker-образов на коленке: Git -> Jenkins -> Docker Registry

docker: как блинчик испечьСтатья о том, как максимально просто заставить роботов (в нашем случае — Jenkins) собирать Docker-образы на каждый коммит в проект Git-репозитария.

Размышлизмы о контейнерах: Крупноблочное строительство

puzzel-stukСтатья-размышление о прекрасном мире крупноблочного проектирования софта, где нет (почти) проблем совместимости системных библиотек, «оторванного» канала связи во время деплоя, хитромудрых вопросов администрирования ОС.

Постановка

Началась история с того, что решил я настроить Sonatype Nexus для репозитория Docker-образов. Ну коль Docker, то почему бы заодно и не потренироваться в этом самом крупноблочном проектировании софта.

nginx-nexus-ansible-docker

Имеем исходные:

  • Docker Registry (х.з. как там срастётся с Nexus’ом, пока решили образа складировать в родной Docker-репозитарий)
  • Sonatype Nexus Repository (Nexus будет настроен для проксирования запросов к внешним и внутренним репозитариям, при этом он будет кэшировать все запрашиваемые образы, чтобы в следующий раз за ними далеко, скажем, на DockerHub не лазить)
  • Nginx (накручивает поверх Nexus’овских портов всякие SSL, TLS, HTTPS и пр.)

В общем и целом схема нашего приложения могла бы выглядеть так:

Software repository (principal schema)Для иллюстрации процедуры запуска нашего мультиконтейнерного приложения будем использовать нотацию Ansible (да, можно и Swarm).

docker-1024x347

Docker Registry

Запуск контейнера в Ansible мог бы выглядеть так:

Обратим внимание на restart_policy: always. Эта настройка заставляет Docker-демона перезапускать контейнер каждый раз, как он по какой-либо причине «упадёт». Это свойство может быть полезно тем, кто своей работе привык использовать решения на базе supervisord.

Параметр ports перечисляет, какие порты внутри контейнера (справа от «:») «прокинуть» на порты (слева от «:») хостовой системы. К примеру:

в этом примере приложение, слушающее внутри контейнера 43ий порт, станет доступным на порту 4343 в хостовой системе.

volumes — если необходимо, что часть хостовой файловой системы была примонтирована внутрь контейнера, например, чтобы иметь доступ к файлам, в которых Docker Registry хранит физически образы контейнеров, без необходимости каким-либо образом взаимодействовать с Docker.

 

Sonatype Nexus Repositorysonatype-nexus_logo-stacked_whiteBG

При запуске Nexus помимо выше описанных параметров будут использоваться ещё пара

  • links — сообщает Docker’у, что необходимо доменное имя registry внутри контейнера (справа от «:») наделить свойствами необходимыми для сетевого взаимодействия с Docker-контейнером с именем (name) registry (слева от «:»). В моём простом примере два этих имени одинаковые (registry), но, в принципе, они могут не совпадать. links — позволяет далее, при настройке репозитариев в Nexus, так и писать в панели управления — registry. DNS внутри контейнера (внутри которой исполняется и панель управления Nexus) будет давать верный IP-адрес нужного контейнера registry, который мы создали перед этим.
  • name — этот параметр, как мы только что выяснили, позволяет посредством links разным контейнерам на одной хостовой системе «видеть» друг друга в сети.
  • expose — приложение внутри контейнера может использовать такие сетевые порты, про которые и думать не могли разработчики Docker-образов. Чтобы они могли быть доступны извне, необходимо их перечислить с помощью параметра expose (ports автоматически этого не делает).

Nginxnginx

Ansible-код для nginx ничем не примечателен кроме того, что содержит в себе пример того, как можно передавать настройки контейнеру путём монтирования папки с конфигурационными файлами. Для этого используется уже известный по первому примеру параметр volumes.

Ещё можно привести кусок конфига nginx для демонстрации взаимодействия name и links:

внутри контейнера registry будет резолвиться в адрес контейнера с именем (name) registry, об этом мы и сообщаем параметром links, затронутым в этом тексте ранее.

Внимание!!!

Помните про expose при конфигурации сервисов типа nginx и HAproxy!!! Буквально сегодня потратил пару часов с непривычки, разбираясь с чего это сервис недоступен снаружи 🙂

Заключение

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

Пространные размышления

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

Действительно, микросхемы — это эдакие чёрные ящички, и, чтобы начать работать с ними, инженеру совсем не обязательно знать, какие внутри этих чёрных ящичков p-n-p переходы, сколько там миллионов транзисторов, и как эти транзисторы там внутри соединены.

микросхемыНаличие готовых микросхем, скрывающих за своим невзрачным корпусом весьма навороченные структуры и логику взаимодействия, позволяет после прочтения сравнительно простой документации (простой по сравнению с тем путём, что прошла научная и инженерная мысль за последние лет 50) начать проектировать достаточно сложные и, вместе с тем, достаточно надёжные устройства.

Позволяет перейти от ручного создания таких вот плат с паяльником в руках (php, pip, npm, bower, bash scripts, java, и пр. фарш с его конфигами и нетривиальным деплойментом):

страшная-плата

К очень технологичному процессу проектирования из готовых блоков:

kicadи автоматическому производству (Mesos, Docker Swarm, Kubernetes, etc.?)

монтаж-печатных-плат

∗∗∗ Читать далее →

Самоуправление в коллективе с взаимным анальным приводом

канадские лесорубы-гомогеи

В данной статье описывается одна из многих возможных моделей (само-)управления коллективом Непревзойдённых Талантов (или Долбанных Гениев), или, пользуясь терминологией книги «Как пасти котов» — коллективом «котов».  🙂 В качестве наглядного материала в повествовании мне поможет бригада канадских лесорубов-гомогеев. Итак..

Область применимости

Область применимости данной модели можно ограничить коллективом личностей обладающих примерно одинаковым уровнем профессионализма и ответственности. Кроме того, необходимым качествами можно так же назвать чувство такта и умение отделить своё Я от трезвого расчёта.

Описание модели

Очевидно, прежде чем продолжать сей околонаучный гон, необходимо перечислить некие постулаты и правила на коих должна будет зиждиться наша замечательная теория:

Непересечение — каждый юнит возделывает (метит) только свою «делянку» не покушаясь на чужую территорию.

Взаимозависимость — каждый юнит зависим как минимум от одного другого. В свою очередь от каждого юнита зависит как минимум один другой.

Сильно связанный направленный граф взаимодействия — каждый юнит связан посредством цепочек зависимостей с каждым юнитом системы

Активность — каждому юниту следует проявлять активность в мотивировании юнита, от которого зависит.

 Непересечение

Непересечением назовём свойство юнитов позволять другим выполнять свои добровольно возложенные на себя обязанности.

На картинке лесоруб убивает собрата за то, что тот его сильно «опекал».

motivation-04

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

На всякий случай я расскажу тебе одну предостерегающую историю. Ты знаешь сказку о маленьких человечках? Некогда жизнь в Кельне была прекрасной. Люди ложились спать вечером, вставали утром, а вся работа была уже сделана. Это продолжалось до тех пор, пока кому-то не захотелось узнать, как же все это
получается… (с) Берт Хелленгер

Активность

Пожалуй единственным правильным способом активно проявлять свою инициативу  — это воздействовать на своего коллегу, от которого зависит твой производственный процесс (юнит-зависимость).

На картинке изображён акт мотивации одного Лесоруба-Гомогея другим.

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

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

[HowTo]: Jenkins LDAP Plugin и SSLHandshakeException

java-sslС проблемой SSLHandshakeException столкнулся в контексте настройки Jenkins LDAP Plugin’а, хотя, вероятно данная HowTo’шка может быть полезна и для других контекстов, где происходит взаимодействие Java-приложения с другими сервисами по HTTPS.

Проблема

При попытке сконфигурировать Jenkins LDAP Plugin получили ошибку:

jankins-ldap-unable_to_find_valid_certification_path_to_requested_target

Контекст

Docker-контейнер с Jenkins (https://hub.docker.com/_/jenkins/) или CentOS 6 сервер с установленным на нём Jenkins.

Решение

Заходим на сервер с Java-приложением

Заходим в контейнер с Jenkins (либо заходим на сервер под администратором, где установлен Jenkins):

Устанавливаем InstallCert.java

Скачиваем InstallCert.java:

Компилируем:

В Jenkins-контейнере javac уже установлен, если же компилятор отсутствует, возможно вам стоит установить пакет java-1.8.0-openjdk-devel

Запускаем InstallCert.java

Запускаем утилиту, вводим 1 и жмём Enter:

В консоли можно увидеть что-то вроде:

Если ещё раз запустить ту же команду, то увидуим
No errors, certificate is already trusted:

Копируем получившийся файл туда, где его найдёт Java

Копируем только что сгенрённый файл в $JAVA_HOME/jre/lib/security/ (это в контейнере Jenkins):

Для CentOS $JAVA_HOME оказался другим:

Перезапускаем Java-приложение

После этого Jenkins перестаёт ругаться на SSLHandshakeException

jenkins-ldap-success

Замечание

Это решение не является единственным, например, можно сертификаты внешних серверов разместить в системных настройках SSL, минуя Java.

Ссылки

Разные дороги на пути к общей цели

ди-каприо_остров-проклятыхИногда можно столкнуться с ситуацией, когда, казалось бы, однозначно трактуемая ситуация, идея или предложение, высказываемое одним из членов команды, воспринимается другим в штыки. Со стороны доводы наиболее ущемлённой стороны конфликта могут начинать выглядеть наименее адекватными. Почему так может происходить?
Ещё больше вопросов возникает в случае, если обе стороны спора согласны по существу вопроса. Действительно, кто же может быть против всего хорошего за всё плохое? Да, никто! Почему же тогда одна сторона может сопротивляться, что называется, позитивным трансформациям?
На ум тут приходит следующая метафора..

 

Представим двоих путешественников. У обоих общая цель. Для определенности пускай это будет что-то яркое, горячее и всеобъемлющее, как любая настоящая цель. Пускай это будет Солнце (пальмы, пляж, либо другие приятные ассоциации на выбор)!

Например:

море-солнце-и-песок

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

Но.

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

Перед одним из путников путь к вожделенному Солнцу может выглядеть как полевая дорожка по бескрайнему лугу до самого горизонта.

grass-field-road-138-1920x1080

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

nature-landscape-photography-16Да, перспектива, может, и манящая, но не имеющая однозначного ответа на вопрос: в каком направлении двигаться оптимальней и даже безопасней. Ведь бывают ситуации, когда Цель начинает казаться не столь важна и значительна в свете сложившихся обстоятельств и накопившихся нерешённых проблем, начинающим угрожать самому твоему существованию непосредственно сейчас на этот самом месте.

Такие различия в восприятии пути к нашему Солнцу, пожалуй, могут стать препятствием к гармоничному рабочему взаимодействию. Сложно общаться с угрюмым пессимистом, отказывающимся рассмотреть твоё предложение и видящем во всём тобою сказанном лишь опасности и ограничения. И, с другой стороны, сложно общаться с восторженным энтузиастом, предлагающим усугубить и без того незавидное твоё положение, да поди ещё и своё по незнанию.

Один:
— Дружище, вот же наша цель! Тебе осталось сделать первый шаг!
Второй:
— В своём ли ты уме, приятель?!? Ведь сделав шаг вперёд, сорвусь я в пропасть! Не стоит тут стремглав кидаться.

 

Возможно ли двум товарищам прийти к консенсусу в такой ситуации? И если возможно, то как?

Вероятно, когда вдохновение настигнет меня снова, я напишу и об этом 🙂 Но пока оставлю все эти вопросы без ответа.

Целью же поста было проиллюстрировать некие мысле-образы и химеры, могущие лежать в основе определённых затруднений в коммуникации. Развеивать свои и чужие химеры, либо обогощаться и обогощать новым знанием — всё это определённо труд. А как известно:

Терпение и труд всё перетрут

pamir_47

 

Удачи.