По причине поломки интернета решил отвлечься от работы и переработать список пресуппозиций НЛП в удобоваримую разноцветную диаграмму с группировкой пресуппозиций по смыслу и ассоциативными связями между ними. Думаю, в таком виде их будет удобнее запоминать
Для разработки тестирования под Ethereum вместо публичной удобнее использовать не публичную сеть, пускай даже и тестову, а свою — приватную (Private Network). Для этого достаточно установить на свою рабочую станцию пакет с бинарником ноды (geth) и создать один конфигурационный файл (genesis file) с описанием новой сети.
Далее на примере описывается процесс инсталяции и первоначальной конфигурации приватной Ethereum сети из одной ноды для Ubuntu 16.04. Актуально как мининум для geth 1.6.7-stable-ab5646c5
Итак..
|
1 2 3 4 |
sudo apt-get install software-properties-common sudo add-apt-repository -y ppa:ethereum/ethereum sudo apt-get update sudo apt-get install ethereum |
(По мотивам Private Network — ethereum/go-ethereum)
Блокчейн — цепочка блоков, у неё есть начало — первый блок, с которого всё и начинается. Собственно, genesis-файл содержит описание, как его создавать.
Создаём genesis-файл со следующим содержимым:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "config": { "chainId": 15, "homesteadBlock": 0, "eip155Block": 0, "eip158Block": 0 }, "difficulty": "20", "gasLimit": "2100000", "alloc": { } } |
(описания полей в файле могут быть найдены в Beginners guide to Ethereum (3) — explain the genesis file and use it to customize your blockchain)
Hint: gasLimit лучше задрать повыше (100500000000 стопицот миллионов?), иначе при деплое очередного умного контракта требуемое количество gas может привысить этот лимит и с деплоем ничего не получится.
Тут необходимо определиться с тем, где у нас будет директория с данными блокчейна. Пусть это будет ./private-chain-data/.
Следующая команда в указанной директории создаёт все необходимые файлы для работы Ethereum ноды:
|
1 |
geth --datadir "./private-chain-data/" init ./genesis.json |
|
1 |
geth --datadir "./private-chain-data/" |
но настроек по умолчанию не всегда бывает достаточно, поскольку с нодой может захотеться взаимодействовать через WebSocket или через RPC, сделав при этом доступным тот или иной API:
|
1 2 3 4 |
geth \ --datadir "./private-chain-data/" \ --rpc --rpcport "8080" --rpccorsdomain "*" --rpcapi "db,eth,net,web3,personal,miner" \ --ws --wsorigins "*" --wsapi "db,eth,net,web3,personal,miner" |
тут мы запустили ноду с RPC на порту 8080 отличном от значения по умолчанию (8545) и WebSocket’ами на порту по умолчанию (8546), и открыли доступ к некоторым интерфейсам.
Описание этих и других параметров geth можно посмотреть тут.
Консоль — это то место, где посредством Ethereum JavaScript API можно напрямую взаимодействовать с нодой. Ниже будет пару примеров.
И так, можно при запуске ноды указать, что нужна консоль:
|
1 |
geth <...> console |
Но это не всегда удобно.
Следующей командой можно прицепится к уже запущенной ноде по HTTP:
|
1 |
geth attach http://127.0.0.1:8080 |
Либо по IPC-протоколу:
|
1 |
geth attach ipc://<путь от корневой папки>/private-chain-data/geth.ipc |
Иногда при тестировании удобно сразу иметь адрес с ненулевым балансом. Далее описывается, как этого достичь.
В javascript-консоли:
|
1 2 3 |
> web3.personal.newAccount('1q2w3e') "0xa85968c7ca4ac0b0bcd91b6bf4327d3336b1571c" > |
Получившуюся строку вставить в genesis.json, указав необходимое значение для баланса:
|
1 2 3 |
"alloc": { "0xa85968c7ca4ac0b0bcd91b6bf4327d3336b1571c": { "balance": "20000000000000000000" } } |
Поскольку было изменено описание первоначального блока, просто так подсунуть этот файл в geth init повидимому не удастся.
Поэтому:
Через javascript-консоль теперь можно проверить наличие аккаунта и непустого у него баланса:
|
1 2 3 4 5 |
> primary = eth.accounts[0] "0xa85968c7ca4ac0b0bcd91b6bf4327d3336b1571c" > eth.getBalance(primary) 20000000000000000000 > |
Но, в принципе, можно не усложнять, а просто намайнить тестовой криптовалюты самостоятельно. См. ниже.
Чтобы тестовый блокчейн наконец заработал, необходимо чтобы кто-то валидировал транзакции и ковал блоки — майнер.
Майнера можно запустить из javascript-консоли:
|
1 |
> web3.miner.start(4) |
Цифра в скобках обозначает количество доступных для майнера тредов.
Так, если кроме валидации транзакций, необходимо, чтобы где-нибудь накапливалась валюта, в консоли укажите соответствующий адрес:
|
1 |
> web3.miner.setEtherbase('0xC6F7651506fb2dfA3362932fF0f174F9ccbAebCF') |
Остановить (например, чтобы комп не гудел вентиляторами охлаждения процессора) майнера можно так:
|
1 |
> web3.miner.stop() |
Второй вариант: запустить geth в роли майнера:
|
1 |
geth <...> --mine --minerthreads=1 --etherbase=0xa85968c7ca4ac0b0bcd91b6bf4327d3336b1571c |
В коммандной строке можно так же указать во сколько тредов запускать майнера, и на какой адрес зачислять намайненное.
***
Для начала этого бесхитростного введения вполне достаточно.
Источники:
Setting up a local private testnet
Beginners guide to Ethereum (3) — explain the genesis file and use it to customize your blockchain
В своё время меня понравилось вычитанное где-то утверждение:
Управление людьми — это управление их энергиями.
И я уже не помню, что под этим подразумевал автор, но сама эта формулировка запала мне в голову. И она всплывает у меня в памяти всякий раз, когда сталкиваюсь с недостаточной мотивацией, либо сопротивлением — это все про энергию
Наверное, попробую закрыть этот гештальт, что называется — публикацией этого и возможно последующих статей с картинками, и порассуждать на тему этой фразы в разрезе управления коллективом, скажем, инженеров-программистов. Почему нет? Тем более, что я сам инженер и сам программист 🙂
Итак, что такое Управление? Под управлением можно понимать некоторый набор последовательных и параллельных действий направленных на получение Наилучшего Результата при движении к Цели.
Что такое Наилучший Результат для индивида? Вполне может статься, что Наилучшим Результатом для индивида может быть получение максимального количества бенефитов, например большой кучи денег — почему нет? Ну, или, если возвыситься на бренностью этого мира, за Наилучший Результат индивида вполне можно принять некое состояние, в котором Человек обретает и максимально приближается к своей Идентичности — Сущности, которой он является «на самом деле». Почему нет? Каждому своё 🙂
Могут ли подобные Наилучшие Результаты мотивировать и давать дополнительный импульс двигаться вперёд? Спрашиваете! 🙂
Окей! Что тогда является Наилучшим Результатом для коллектива? 
Поразмышляю. Я бы исходил из предположения, что собравшиеся в одном месте люди — сотрудники одной конторы — собрались в одном месте не просто так, а что-то их всё же объединяет.
Наилучшим Результатом коллектива можно называть арифметическую сумму всех индивидуальных Наилучших Результатов . Это когда работая в одной конторе, кто-то зарабатывает сообразно своим запросам, кто-то горд оценкой себя в глазах сослуживцев, кто-то осуществляет профессиональный, а кто-то душевный рост и развитие.
Такой Составной Общий Наилучший Результат имеет право на существование, но мне наиболее близка другая формулировка.
Другого типа Общий Наилучший Результат конторы может быть явно не вербализован. НО. Как и у человеческого индивида он определим однозначно в любой момент времени.
Примером Невербализованного Общего Наилучшего Результата может быть приятное ощущение освобождения (катарсис) и яркие мысли от сопричастности общему делу сделанному хорошо — Победы, добытой не без труда и от этого более желанной, и интересного опыта совместно прожитого с коллегами-друзьями.
Ещё раз подчеркну
приятное ощущение и яркие мысли от сопричастности общему делу сделанному хорошо.
А ведь и правда, согласитесь, приятные ощущения от несделанного дела или совсем без дела — это немного не совсем то 🙂
Общее Дело — the MUST
* * *
Итак, резюмирую:
Управление — комплекс мероприятий для способствования движению к цели
Наилучший Результат:
Статья о том, как максимально просто заставить роботов (в нашем случае — Jenkins) собирать Docker-образы на каждый коммит в проект Git-репозитария.
Статья-размышление о прекрасном мире крупноблочного проектирования софта, где нет (почти) проблем совместимости системных библиотек, «оторванного» канала связи во время деплоя, хитромудрых вопросов администрирования ОС.
Началась история с того, что решил я настроить Sonatype Nexus для репозитория Docker-образов. Ну коль Docker, то почему бы заодно и не потренироваться в этом самом крупноблочном проектировании софта.
Имеем исходные:
В данной статье описывается одна из многих возможных моделей (само-)управления коллективом Непревзойдённых Талантов (или Долбанных Гениев), или, пользуясь терминологией книги «Как пасти котов» — коллективом «котов». 🙂 В качестве наглядного материала в повествовании мне поможет бригада канадских лесорубов-гомогеев. Итак..
Область применимости данной модели можно ограничить коллективом личностей обладающих примерно одинаковым уровнем профессионализма и ответственности. Кроме того, необходимым качествами можно так же назвать чувство такта и умение отделить своё Я от трезвого расчёта.
Очевидно, прежде чем продолжать сей околонаучный гон, необходимо перечислить некие постулаты и правила на коих должна будет зиждиться наша замечательная теория:
Непересечение — каждый юнит возделывает (метит) только свою «делянку» не покушаясь на чужую территорию.
Взаимозависимость — каждый юнит зависим как минимум от одного другого. В свою очередь от каждого юнита зависит как минимум один другой.
Сильно связанный направленный граф взаимодействия — каждый юнит связан посредством цепочек зависимостей с каждым юнитом системы
Активность — каждому юниту следует проявлять активность в мотивировании юнита, от которого зависит.
Непересечением назовём свойство юнитов позволять другим выполнять свои добровольно возложенные на себя обязанности.
На картинке лесоруб убивает собрата за то, что тот его сильно «опекал».
Бывает не просто разрешить коллегам выполнять их обязанности, тем более пребывая в полной уверенности, что сам это сделаешь много быстрее и, возможно, качественнее. Тем не менее, дабы избежать выхолащивания чувства личной ответственности и сопричастности у своих товарищей, очень важно сдерживаться в своём желании проявить инициативу во всём.
На всякий случай я расскажу тебе одну предостерегающую историю. Ты знаешь сказку о маленьких человечках? Некогда жизнь в Кельне была прекрасной. Люди ложились спать вечером, вставали утром, а вся работа была уже сделана. Это продолжалось до тех пор, пока кому-то не захотелось узнать, как же все этополучается… (с) Берт Хелленгер
Пожалуй единственным правильным способом активно проявлять свою инициативу — это воздействовать на своего коллегу, от которого зависит твой производственный процесс (юнит-зависимость).
На картинке изображён акт мотивации одного Лесоруба-Гомогея другим.
Предполагается именно воздействие на коллегу, но никак не попытка повлиять на то или иное его решение, которое он примет удовлетворяя вашу зависимость от него.
Вполне может статься так, что ваш коллега-зависимость захочет удовлетворить свою зависимость от вас, как от консультанта. Будем считать такие зависимости более высокого порядка малости и опустим их в нашем повествовании для упрощения.
С проблемой SSLHandshakeException столкнулся в контексте настройки Jenkins LDAP Plugin’а, хотя, вероятно данная HowTo’шка может быть полезна и для других контекстов, где происходит взаимодействие Java-приложения с другими сервисами по HTTPS.
При попытке сконфигурировать Jenkins LDAP Plugin получили ошибку:
|
1 2 3 4 5 6 7 8 9 10 |
Unable to connect to ldaps://ldap.example.com:636 : javax.naming.CommunicationException: anonymous bind failed: ldap.example.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] javax.naming.CommunicationException: anonymous bind failed: ldap.example.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:198) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) |
Docker-контейнер с Jenkins (https://hub.docker.com/_/jenkins/) или CentOS 6 сервер с установленным на нём Jenkins.
Заходим в контейнер с Jenkins (либо заходим на сервер под администратором, где установлен Jenkins):
|
1 |
sudo docker exec -u root -it jenkins bash |
Скачиваем InstallCert.java:
|
1 |
wget https://raw.githubusercontent.com/escline/InstallCert/master/InstallCert.java |
Компилируем:
|
1 |
javac InstallCert.java |
В Jenkins-контейнере javac уже установлен, если же компилятор отсутствует, возможно вам стоит установить пакет java-1.8.0-openjdk-devel
Запускаем утилиту, вводим 1 и жмём Enter:
|
1 |
java InstallCert ldap.example.com:636 |
В консоли можно увидеть что-то вроде:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
root@otokarev:/# java InstallCert ldap.example.com:636 Loading KeyStore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/jssecacerts... Opening connection to ldap.example.com:636... Starting SSL handshake... No errors, certificate is already trusted Server sent 1 certificate(s): 1 Subject EMAILADDRESS=helpdesk@example.com, CN=ldap.example.com, OU=Company, O=Company Inc., L=City, ST=State, C=RU Issuer EMAILADDRESS=helpdesk@example.com, CN=ldap.example.com, OU=Company, O=Company Inc., L=City, ST=State, C=RU sha1 16 24 4e 25 af a4 0f 81 8a 63 2e da be 6f d3 0f 6e 0b 1b 0f md5 44 8f ed d6 f8 34 c9 13 ef 8d 66 e2 03 f6 2b a9 Enter certificate to add to trusted keystore or 'q' to quit: [1] 1 [ [ Version: V1 Subject: EMAILADDRESS=helpdesk@example.com, CN=ldap.example.com, OU=Company, O=Company Inc., L=City, ST=State, C=RU Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: Sun RSA public key, 2048 bits modulus: 2787691314059276499264562499000086231759492442570748621621561010462160297747745741581294711760141886474879386369722315641253909452580928614685957438395781052379416501948399013462937713709350234164017278318133350177196480849249951423702392575764528951697640997865766272467712446537181276904915446482128457163631468924670274437819974023081426845763648910137221390761105517613742335399108594574274981151260699441165666413359420060360501886132027396055305115176723155529877157768672928951223012413035634358657762988319396109963530652345545840268017496984924777474310327614659464556052575623783485014682119232 public exponent: 65537 Validity: [From: Thu Dec 13 14:50:14 UTC 2012, To: Sun Dec 11 14:50:14 UTC 2022] Issuer: EMAILADDRESS=helpdesk@example.com, CN=ldap.example.com, OU=Company, O=Company Inc., L=City, ST=State, C=RU SerialNumber: [ ad5df5fa 3eefe865] ] Algorithm: [SHA1withRSA] Signature: 0000: 77 48 DE 49 5C 83 45 FE F9 68 F2 98 97 DF 20 51 wH.I\.E..h.... Q 0010: 5E 23 87 28 83 A8 27 71 EF AA 93 79 A3 91 6A 1A ^#.(..'q...y..j. 0020: B3 8B AB 0D CE 90 A8 3F EF AC 2C A1 15 CA 7B 7C .......?..,..... 0030: B8 77 C8 A0 6A DA E1 B9 18 D7 92 E7 7E 6D 39 9C .w..j........m9. 0040: 72 51 B6 24 66 2C 26 EC B8 61 D7 FF 6F F5 E8 36 rQ.$f,&..a..o..6 0050: C9 E0 1B 4E 40 77 3D EB 1A 86 7E C2 44 2F 3B 5F ...N@w=.....D/;_ 0060: CA 49 F1 7C C3 58 68 AE 43 CA AD 0E 19 61 7D 90 .I...Xh.C....a.. 0070: 35 17 07 80 2A 33 D2 B3 1B 4F FD 15 44 A2 02 F6 5...*3...O..D... 0080: 66 E1 C4 2E 35 30 9B 7E EE 39 A6 D9 81 ED C4 C7 f...50...9...... 0090: B1 90 24 13 94 20 F6 F5 1B 87 8D 72 0A B5 99 7B ..$.. .....r.... 00A0: 2F D3 64 21 12 EC BF C6 01 B1 99 98 15 04 62 2F /.d!..........b/ 00B0: AC DC 9F AD 95 92 2B 4C 07 E6 08 20 3A 8E 7B FD ......+L... :... 00C0: E1 37 5B C0 53 60 5F 3C 6B D8 EB A8 82 CB F8 BA .7[.S`_<k....... 00D0: 2F 0B C1 05 94 A5 87 29 BA E1 78 EF 35 72 9B 4D /......)..x.5r.M 00E0: 36 5B 0E C5 8A B1 6C 98 DC 50 D2 33 65 54 E1 42 6[....l..P.3eT.B 00F0: 18 28 7A A1 59 EB E8 98 D9 5E 96 5E 8D 85 7F 68 .(z.Y....^.^...h ] Added certificate to keystore 'jssecacerts' using alias 'ldap.example.com-1' root@otokarev:/# |
Если ещё раз запустить ту же команду, то увидуим
No errors, certificate is already trusted:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
root@otokarev:/# java InstallCert ldap.example.com:636 Loading KeyStore jssecacerts... Opening connection to ldap.example.com:636... Starting SSL handshake... No errors, certificate is already trusted Server sent 1 certificate(s): 1 Subject EMAILADDRESS=helpdesk@example.com, CN=ldap.example.com, OU=Company, O=Company Inc., L=City, ST=State, C=RU Issuer EMAILADDRESS=helpdesk@example.com, CN=ldap.example.com, OU=Company, O=Company Inc., L=City, ST=State, C=RU sha1 16 24 4e 25 af a4 0f 81 8a 63 2e da be 6f d3 0f 6e 0b 1b 0f md5 44 8f ed d6 f8 34 c9 13 ef 8d 66 e2 03 f6 2b a9 Enter certificate to add to trusted keystore or 'q' to quit: [1] q KeyStore not changed root@otokarev:/# |
Копируем получившийся файл туда, где его найдёт Java
Иногда можно столкнуться с ситуацией, когда, казалось бы, однозначно трактуемая ситуация, идея или предложение, высказываемое одним из членов команды, воспринимается другим в штыки. Со стороны доводы наиболее ущемлённой стороны конфликта могут начинать выглядеть наименее адекватными. Почему так может происходить?
Представим двоих путешественников. У обоих общая цель. Для определенности пускай это будет что-то яркое, горячее и всеобъемлющее, как любая настоящая цель. Пускай это будет Солнце (пальмы, пляж, либо другие приятные ассоциации на выбор)!
Например:
И вот, есть у нас пару путешественников, стремящихся достичь Солнца. И видят они его примерно одинаково, и стремятся они к нему примерно одинаково. И даже, может так получится, что направление, в котором следует двигаться странникам, чтобы достичь Солнца, будет примерно одним и тем же.
Но.
При всей схожести ситуаций есть один немаловажный нюанс: наши герои в данный момент времени могут находится в совершенно различных условиях, в совершенно различных географических точках земного шара — стартовые позиции наших героев, самочувствие, тяжесть заплечных мешков и прочих обременений может отличаться кардинально.
Перед одним из путников путь к вожделенному Солнцу может выглядеть как полевая дорожка по бескрайнему лугу до самого горизонта.
Перед другим же может простираться не столь радужная перспектива. Под ногами может лежать глубокая пропасть, и мягким покрывалом мха может казаться хвойный лес обрамляющий реку в дымке утреннего тумана где-то далеко внизу.
Да, перспектива, может, и манящая, но не имеющая однозначного ответа на вопрос: в каком направлении двигаться оптимальней и даже безопасней. Ведь бывают ситуации, когда Цель начинает казаться не столь важна и значительна в свете сложившихся обстоятельств и накопившихся нерешённых проблем, начинающим угрожать самому твоему существованию непосредственно сейчас на этот самом месте.
Такие различия в восприятии пути к нашему Солнцу, пожалуй, могут стать препятствием к гармоничному рабочему взаимодействию. Сложно общаться с угрюмым пессимистом, отказывающимся рассмотреть твоё предложение и видящем во всём тобою сказанном лишь опасности и ограничения. И, с другой стороны, сложно общаться с восторженным энтузиастом, предлагающим усугубить и без того незавидное твоё положение, да поди ещё и своё по незнанию.
Один:
— Дружище, вот же наша цель! Тебе осталось сделать первый шаг!
Второй:
— В своём ли ты уме, приятель?!? Ведь сделав шаг вперёд, сорвусь я в пропасть! Не стоит тут стремглав кидаться.
Возможно ли двум товарищам прийти к консенсусу в такой ситуации? И если возможно, то как?
Вероятно, когда вдохновение настигнет меня снова, я напишу и об этом 🙂 Но пока оставлю все эти вопросы без ответа.
Целью же поста было проиллюстрировать некие мысле-образы и химеры, могущие лежать в основе определённых затруднений в коммуникации. Развеивать свои и чужие химеры, либо обогощаться и обогощать новым знанием — всё это определённо труд. А как известно:
Терпение и труд всё перетрут
Удачи.
В дикой природе можно обнаружить множество моделей поведения различных представителей фауны, анализ которых может привести к любопытным выводам применимым и в природе не дикой. Взять хотя бы взаимодействие муравьёв и тли. Для НЕдачников пояснение ниже.
Когда я был совсем ребёнок, лазая по дачному участку своей бубушки я обнаружил следующее:
Невысокие побеги, скажем, черёмухи имели на самой макушке молодые ярко зелёные только распустившиеся листики. Причём эти листики явно отличались от здоровых: были скукуженные с какими-то белёсыми еле различимыми глазом вкраплениями. Кроме того, по этим побегам до самой макушки шныряли деловито туда сюда мелкие чёрные муравьи.
Поскольку такую чрезмерную активность у муравьёв до этого я объяснял себе либо постройкой жилища, либо перетаскиванием гусениц, либо кипижем по поводу разворошённого муравейника, то такая аномалия вокруг молодых скукоженных побегов меня заинтересовала. Я попросил бабушку объяснить.
По словам бабушки получалось, что листики скукожились из-за того, что их жрала тля — те мелкие вкрапления оказались живыми существами. Причем на выходе эта тля производила сладкий сироп. И этот сироп весьма привлекал муравьёв. В свою очередь тля была бы счастлива, если бы её не жрали муравьи других видов, предпочитающие саму тлю вместо сахарного сиропа.
Получалось, что тля решала проблему питания муравьёв. А муравьи решали проблему безопасности тли. На этих дополнительных бонусах от взаимодействия и зиждилась крепкая дружба, иногда называемая симбиозом.
Применима ли данная метафора каким-либо образом к процессу разработки ПО? В котором муравьи представляются в виде лидов и менеджеров. А тля — в виде разнообразных узких специалистов. Первым необходимо от вторых получить работающие с надлежащим качеством программы или иные артефакты, вторым необходимо получить от первых ощущение безопасности от нетехнических невзгод, к примеру: от постоянно меняющихся требований бизнеса. Первые — мобильны и способны переносить информацию на большие расстояния (тут расстояние скорее логическое понятие, чем географическое), вторые — сконцентрированы на переработки своего определённого «листика» в «сахар». Первые сильно отличаются от вторых, но все они очень нужны друг другу.