Скоро каналу @thrill_seekers 3 месяца!
И кто-то из друзей задавал мне вопрос откуда пришло название @Thrill и кто такие @Thrill_Seekers.
Ответ простой - названия пришли от двух замечательный Uplifting/Tech Trance композиций. В конце двухтысячных я стал интересоваться и слушать Trance музыку, хотя вообще электронную музыку слушал очень давно.
Thrill это гимн фестиваля Trance Energy 2008, который проводился в выставочном центре Jaarbeurs в Утрехте, Нидерланды.
Thrillseekers это псевдоним Steve Helstrip, британского музыкального продюсера и Trance ди-джея (https://en.wikipedia.org/wiki/The_Thrillseekers).
Обе композици можно описать одним ёмким словом - "движуха"! 😄😂👍

https://www.linkedin.com/pulse/mongodb-32-now-powered-postgresql-john-de-goes

Вся соль этого расследования:
"Postgres foreign data wrappers support barely any pushdown," I stated matter-of-factly. "This is all the more true in the Multicorn wrapper you're using for the BI connector, which is based on an older Postgres and doesn't even support the full pushdown capabilities of the Postgres FDW."

Ron admitted defeat. "That's true," he said.

Вообще Mongo создавалась с прицелом на rich data structures и программист сам несёт ответственность за схему данных.
Правда в том что разработка BI коннектора была нацелена на то чтобы дать доступ реляционным базам к rich data structures в Mongo в реляционном формате этих баз для инструментов бизнес аналитики типа OLAP систем.

https://www.youtube.com/watch?v=0kwopDp0bmg

Вообще сама концепция rich data analytics интересна:
http://www.infoworld.com/article/2983953/nosql/how-to-choose-a-nosql-analytics-system.html

А СМИ привязались к деталям реализации (был использован код PostgreSQL драйвера и создана обёртка для него, опенсорс же - это уже факап презентации коннектора) и раздули новость о смерти Mongo, мол всё "теперь Mongo точно войдёт в PostgreSQL", у управленцев и аналитиков подскочил пульс и многих кондратий хватил. 😂
Да, шумихи много было, для СМИ это норма и их работа, давать сенсации.

А вообще это очень круто - конкуренция двух масштабных open source проектов для хранения и работы с данными, а что может быть важнее в сетевых проектах чем данные пользователей!?
Всё дело как обычно в деньгах - это бизнес, большие компании платят open source проектам за поддержку их продуктов и сами участвуют в этих проектах активно.
Отсюда и конкуренция.

В руководстве проекта Mongo творится какая-то ересь!
Партнёров создающих инструменты NoSQL аналитики они не жалуют заявляя от первых лиц со сцены на презентации нового релиза, "что Mongo сейчас не имеет своих инструментов аналитики, поэтому мы вам предлагаем юзать BI коннектор", который по сути драйвер PostgreSQL, обёрнутый в транлятор запросов/ответов NoSQLtoSQL, по типу ORM.

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

Есть другие достойные документно-ориентированные базы:
http://www.couchbase.com
http://couchdb.apache.org
и
http://orientdb.com
это продукт универсален - documents store, key-value storage, graph storage

http://db-engines.com/en/ranking
http://db-engines.com/en/ranking/document+store
http://db-engines.com/en/ranking_definition

MX Player-ом или VLC открываешь и смотришь на город Бишкек 😄👍

http://iptv.saima.kg/hls-cam/alatoo.m3u8

http://iptv.saima.kg/hls-cam/berengold.m3u8

http://iptv.saima.kg/hls-cam/chui-ibraimova.m3u8

Проекты - это летающий цирк Монти Пайтон (откуда происходит имя языка Python) - слышали шутку про "самую смешную шутку", "министерство дурной походки" и "что едят пингвины - лазанью!" (найдите и посмотрите на YouTube), тогда вы уже на половину готовы к проекту, ведь позитивный и весёлый настрой это уже пол дела, потому что проект на любом этапе может оказаться провальным 😂 и к этому нужно будет отнестись с юмором, типа:
Приходит Винни Пух в гости к Пятачку, а у того постирушки!
- Оу, у тебя труселя уплывают!
- Ну и хер с ними!
- И хер с ними!!!???
Так нужно относится к провалам и так меня учил мой замечательный учитель (нет, он не в моей голове). 😂 Ну или на крайняк, let's get drunk! Можно отметить завершение проекта досрочно! 😂

Когда эзотерический этап медитаций, сакрального поиска идеи и её осознания пройден...
Нужно обозначить ключевые технологические концепции проекта и архитектурные паттерны для проектирования - например событийный асинхронный ввод вывод и обработка (reactor pattern), многопоточность, сетевая распределённая среда, микросервисы (service-oriented architecture, SOA, enterprise service bus, ESB), MOM (MQ), контейнеры и т.д.
Далее из имеющихся навыков программирования, спланированной архитектуры и концепций, расчётных нагрузок по различным параметрам можно уже выбрать стек базовых технологий, фреймворк и БД - в помощь нагрузочные тесты производительности фреймворков и БД по различным параметрам от TechEmpower (http://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=json).

И если делать проект основательно и он действительно стоящий...
Тогда начинать стоит с блок-схем и диаграм на бумаге или сразу в векторном редакторе проектов (я юзаю LibreOffice Draw и иногда InkScape - для SVG схем в документации они отлично подходят).
Нужно прибегуть к объектно-реляционному дизайну/проектированию и моделированию системы и БД под неё.
Нужно проработать связи между объектами, модулями в системе и данными.
На этом этапе закладывается архитектура и нужно применять подходящие паттерны проектирования и модели.
Это круто прочищает мозги и раскладывает всё по полочкам.
Со временем схема будет меняться и усложняться - поверьте, если проект серьёзный, она вам очень пригодится для документации и при рефакторинге кодовой базы проекта, крупных изменениях архитектуры и возможно смене стека при дальнейшем возможном росте проекта и нагрузок.

Спросите кто так проектирует, кто так уже делал?
За примером далеко ходить не нужно.
Павел Дуров и его команда так проектировали серверсайдный бэкэнд Телеграм, который мы все здесь используем, протокол MTProto и его API, который используют все клиенты, а также Bot API для ботов.
При создании API такие подходы проектирования необходимы и очень полезны.

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

Так что всё просто! 😄👍

К слову про проекты и объектно-реаляционное проектирование в них.

Когда степень интеграции компонентов и взаимосязи между ними (сильносвязная архитектура) переваливают какую-то критическую массу в монолитном проекте, тогда создаётся прецедент для перехода к микросервисной архитектуре (service-oriented architecture, SOA, enterprise service bus, ESB) и слабосвязной дезинтеграции.
Микросервисы базируются на принципах слабосвязной архитектуры ПО.
Хотя есть исключения, проекты с сильными связями подсистем, например ядро Linux, оно до сих пор монолитное (хотя в нём очень много подсистем), модульное, не мироядерное, т.к. такая арихтектура ядра имеет большую производительность ввиду отсутствия механизма IPC и соответственно накладных расходов на переключение контекста и привелегий процессов.
Микросервисные архитектуры хорошо согласуются с философией Unix и компонентно-ориентированной моделью разработки ПО - самодостаточные компоненты, которые хорошо выполняют свои задачи и взаимодействуют на общих принципах (протоколах) с другими компонентами.
При этом микросервисная архитектура хорошо подходит для проектов разной величины, если она в них применима.

Django, Celery, Sentry...

При том что Django это реализация MVP паттерна проектирования приложений, не MVC в чистом виде!
А Celery это частный случай message queue - job queue.
Python сообщество вообще удивляет своими решениями! 😄
Как-то это всё не энтерпрайзно... 😂
Тем более с точки зрения бывшего явиста. 😂
Поэтому Google уволили Гвидо Ван Россума и наняли Роба Пайка и Кена Томпсона в компанию к Роберту Гризмеру для создания Go (в оппозит Java и Python), а Dropbox свернули проект JIT компилятора Python, перешли на Go в бэкэнде более чем полностью и начали великий исход из облака Amazon, который завершили только недавно.
Для Python вообще нет нормального JIT компилятора, такого как LuaJIT, V8 (Node.js) или JRuby (MLVM on JVM) - PyPy им вообще не ровня по скорости и расходу памяти, его ещё можно с проектом Rubinius сравнить, но Rubinius вообще мультиязыковой теперь, как LLVM и Parrot, а проект Jython скорее мёртв чем жив, развивается медленно и давно стагнировал.
So long... столько лет с 1991 года прошло и так никто и не запилил для Python нормальный JIT! До сих пор стандартом остаётся CPython.
Поэтому большинство компаний с крупными проектами сейчас переходят на Go.
Если и дальше так же будет - Python ждёт стагнация, он станет таким же маргинальным как PHP и Perl, дороги в large enterprise у него уже нет.
Печально и грустно это...
Мой профиль это ведь телекоммуникации, а это как раз large enterprise и я так ждал широкого применения Python в этой отрасли, в её серверсайдном бэкэнде!
А пока что Python годен только для скриптовых автоматизаций в этой отрасли, которые тоже не весьма производительными выходят.

Facebook кстати создали язык Hack (https://en.wikipedia.org/wiki/Hack_(programming_language)) и HHVM (https://en.wikipedia.org/wiki/HipHop_Virtual_Machine).

Потому что тоже разочаровались в PHP и Python (проект Tornado).

Часть бэкэнда вообще перевели на JVM перед созданием Hack и HHVM.

http://nerds-central.blogspot.com/2012/08/facebook-moving-to-jvm.html

Перевод от белорусов:
https://dev.by/lenta/main/facebook-perehodit-na-virtualnuyu-mashinu-java

Действительно эпичная история исхода дропбокса из облака Амазона http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire

Some interesting synthetic tests of JRuby with invoke-dynamic and JIT on Java 8 MLVM in JVM (aka Da Vinci Machine) versus Go 1.6

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=jruby&lang2=go

https://www.youtube.com/watch?v=fYlxBrKX-DI&t=1h11m20s

https://www.youtube.com/watch?v=fYlxBrKX-DI&t=1h59m30s

Интересно получилось! 😄👍


скину немного теории и ссылок по smart contracts, чтобы смотрящим и заинтересовавшимся было легче разобраться
вообще возможности технологии огромны!
итак, доки для более глубокого понимания технологии Ethereum:
http://ethdocs.org/en/latest/
https://github.com/ethereum/wiki/wiki
https://ethereum.gitbooks.io/frontier-guide/content/

Solidity - это JS или Си подобный язык (Contract-Oriented Programming Language) со статической типизацией для написания контрактов, их компиляции и включения их в блокчейн
https://solidity.readthedocs.org/en/latest/
https://github.com/ethereum/wiki/wiki/Руководство-по-Solidity
https://github.com/ethereum/solidity

есть браузерный компилятор Solidity
https://github.com/chriseth/browser-solidity
и форма для написания, оптимизации и компиляции контрактов
http://chriseth.github.io/browser-solidity/

Solidity исполняется на Ethereum VM в клиенте Ethereum
есть библиотека для динамической (JIT) компиляции байт-кода EVM под LLVM
https://github.com/ethereum/evmjit

есть официальная реализация протокола Ethereum в клиенте написанном на Go
содержит:
geth - CLI клиент протокола Ethereum
evm - Ethereum Virtual Machine
bootnode - deploy сетевой ноды Ethereum для service discovery
https://github.com/ethereum/go-ethereum
https://github.com/ethereum/go-ethereum/wiki
https://godoc.org/github.com/ethereum/go-ethereum
https://hub.docker.com/r/ethereum/client-go/

нужно обязательно опубликовать информацию о митапе по Эфириуму и умным контрактам тут:
http://www.meetup.com/topics/ethereum/
http://www.meetup.com/topics/smart-contracts/

OMG, technologies moving so fast for the latest few years! 😱

короче если коротко...

криптовалюты основаны на сетевой распределённой децентрализованной транзакционной БД - это и есть технология blockchain
транзакции используют шифрование, proof-of-work и proof-of-stake для доказательства вычислительной работы по обработке и подтверждению транзакций (PoW), их шифрованию, формированию блока, его подписи, последующего сцепления в блокчейн, а также доказательства хранения доли монет (PoS) для подтверждения транзакций в некоторых реализациях протоколов криптовалют на основе блокчейна (Ethereum, Peercoin, Novacoin)
поэтому транзакции необратимы и каждую транзакцию можно отследить по базе blockchain вплоть до момента эмитирования монет (но для этого нужно иметь 51% вычислительной мощности всей сети, что практически нереально)

умные контракты это программный код для распределённой БД blockchain, для создания управляемых транзакций - умных контрактов
это как PL/SQL для написания хранимых процедур и тригеров в Oracle

на Solidity можно реализовать транзакционный распределённый процессинг с моделью программно управляемых "активных данных", распределённый (distributed) биллинг на БД blockchain и подобие протоколов radius/diameter
всё это весьма востребовано и очень нужно, для применения в сервисно-ориентированных архитектурах (service-oriented architecture (SOA), enterprise service bus (ESB)), как финансовое средство для приёма онлайн оплат, обработки платежей и взаиморасчётов на основе умных контрактов