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

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

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

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

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

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

Итак..

Устанавливаем geth

Genesis-файл и первоначальная загрузка

(По мотивам Private Network — ethereum/go-ethereum)

Блокчейн — цепочка блоков, у неё есть начало — первый блок, с которого всё и начинается. Собственно, genesis-файл содержит описание, как его создавать.

Создаём genesis-файл со следующим содержимым:

(описания полей в файле могут быть найдены в Beginners guide to Ethereum (3) — explain the genesis file and use it to customize your blockchain)

Hint: gasLimit лучше задрать повыше (100500000000 стопицот миллионов?), иначе при деплое очередного умного контракта требуемое количество gas может привысить этот лимит и с деплоем ничего не получится.

Тут необходимо определиться с тем, где у нас будет директория с данными блокчейна. Пусть это будет ./private-chain-data/.

Следующая команда в указанной директории создаёт все необходимые файлы для работы Ethereum ноды:

Запуск ноды

но настроек по умолчанию не всегда бывает достаточно, поскольку с нодой может захотеться взаимодействовать через WebSocket или через RPC, сделав при этом доступным тот или иной API:

тут мы запустили ноду с RPC на порту 8080 отличном от значения по умолчанию (8545) и WebSocket’ами на порту по умолчанию (8546), и открыли доступ к некоторым интерфейсам.

Описание этих и других параметров geth можно посмотреть тут.

Запуск javascript-консоли

Консоль — это то место, где посредством Ethereum JavaScript API можно напрямую взаимодействовать с нодой. Ниже будет пару примеров.

И так, можно при запуске ноды указать, что нужна консоль:

Но это не всегда удобно.

Следующей командой можно прицепится к уже запущенной ноде по HTTP:

Либо по IPC-протоколу:

Тестовый аккаунт с предопределённым балансом

Иногда при тестировании удобно сразу иметь адрес с ненулевым балансом. Далее описывается, как этого достичь.

В javascript-консоли:

Получившуюся строку вставить в genesis.json, указав необходимое значение для баланса:

Поскольку было изменено описание первоначального блока, просто так подсунуть этот файл в  geth init повидимому не удастся.

Поэтому:

  1. Остановить запущенный geth-процесс
  2. Удалить из ./private-chain-data/  всё кроме папки keystore/там лежит в том числе и закодированный приватный ключ только что созданного адреса
  3. Запустить geth init, как это проделывалось ранее
  4. Запустить geth

Через javascript-консоль теперь можно проверить наличие аккаунта и непустого у него баланса:

 

Но, в принципе, можно не усложнять, а просто намайнить тестовой криптовалюты самостоятельно. См. ниже.

Miner

Чтобы тестовый блокчейн наконец заработал, необходимо чтобы кто-то валидировал транзакции и ковал блоки — майнер.

Майнера можно запустить из javascript-консоли:

Цифра в скобках обозначает количество доступных для майнера тредов.

Так, если кроме валидации транзакций, необходимо, чтобы где-нибудь накапливалась валюта, в консоли укажите соответствующий адрес:

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

Второй вариант: запустить geth в роли майнера:

В коммандной строке можно так же указать во сколько тредов запускать майнера, и на какой адрес зачислять намайненное.

***

Для начала этого бесхитростного введения вполне достаточно.

 

Источники:

Setting up a local private testnet

Beginners guide to Ethereum (3) — explain the genesis file and use it to customize your blockchain Читать далее →

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

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

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

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

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

Итак, что такое Управление? Под управлением можно понимать некоторый набор последовательных и параллельных действий направленных на получение Наилучшего Результата при движении к Цели.

human destiny

Что такое Наилучший Результат для индивида? Вполне может статься, что Наилучшим Результатом для индивида может быть получение максимального количества бенефитов, например большой кучи денег — почему нет? Ну, или, если возвыситься на бренностью этого мира, за Наилучший Результат индивида вполне можно принять некое состояние, в котором Человек обретает и максимально приближается к своей Идентичности — Сущности, которой он является «на самом деле». Почему нет? Каждому своё 🙂

Могут ли подобные Наилучшие Результаты мотивировать и давать дополнительный импульс двигаться вперёд? Спрашиваете! 🙂

Окей! Что тогда является Наилучшим Результатом для коллектива?  Управление - оркестрПоразмышляю. Я бы исходил из предположения, что собравшиеся в одном месте люди — сотрудники одной конторы — собрались в одном месте не просто так, а что-то их всё же объединяет.

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

Такой Составной Общий Наилучший Результат имеет право на существование, но мне наиболее близка другая формулировка.

Другого типа Общий Наилучший Результат конторы может быть явно не вербализован. НО. Как и у человеческого индивида он определим однозначно в любой момент времени.

Примером Невербализованного Общего Наилучшего Результата может быть приятное ощущение освобождения (катарсис) и яркие мысли от сопричастности общему делу сделанному хорошо — Победы, добытой не без труда и от этого более желанной, и интересного опыта совместно прожитого с коллегами-друзьями.

Ещё раз подчеркну

приятное ощущение и яркие мысли от сопричастности общему делу сделанному хорошо.

А ведь и правда, согласитесь, приятные ощущения от несделанного дела или совсем без дела — это немного не совсем то 🙂

Общее Дело — the MUST

* * *

Итак, резюмирую:

Управление — комплекс мероприятий для способствования движению к цели

Наилучший Результат:

  • Индивидуальный
  • Коллективный
    • Составной — сумма индивидуальный
    • Невербализованный — катарсис от успешно совмесно сделанного Дела
    • Читать далее →

  • Автосборка 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 и пр.)
  • Читать далее →

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    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 Читать далее →

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

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

     

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

    Например:

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

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

    Но.

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

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

    grass-field-road-138-1920x1080

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

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

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

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

     

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

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

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

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

    pamir_47

     

    Удачи.

    Тля и муравьи

    тля и муравейВ дикой природе можно обнаружить множество моделей поведения различных представителей фауны, анализ которых может привести к любопытным выводам применимым и в природе не дикой. Взять хотя бы взаимодействие муравьёв и тли. Для НЕдачников пояснение ниже.

    Когда я был совсем ребёнок, лазая по дачному участку своей бубушки я обнаружил следующее:

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

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

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

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

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