*Wow!*
_So corporative!_
[Very chat!](https://telegram.org/apps)
Such offtop!

Much flame!

~~Many trolling!~~
~Many trolling!~

<b>Wow!</b>
<strong>Wow!</strong>
<i>So corporative!</i>
<em>So corporative!</em>
<a href="https://telegram.org/apps">Very chat!</a>
<code>Such offtop!</code>
<pre>Much flame!</pre>
<strike>Many trolling!</strike>
<s>Many trolling!</s>
<del>Many trolling!</del>

Релиз GNU/Linux Debian 8.4 https://vk.com/thatislinux?w=wall-33025660_197815

http://andrcmdr.tk/post/49919208753/fennec-fox
http://andrcmdr.tk/post/49898508832/swsxpec

Это комбинация стихотворных стилей Теннисона, Киплинга и Сент-Экзюпери, с калькой на современный манер и переводом на русский.
Стихи сочиняла нейросеть на базе алгоритмов обратного распространения, описанных на Python (General AI, Machine Learning, Natural Language Processing (NLTK) and Neural Networks), почти как автопоэт Яндекса, только на пару лет раньше, пример - https://www.yandex.ru/autopoet/monorim/18, https://yandex.ru/autopoet/news/5
Исходные данные (слова) для развлекухи и ржаки забивала, а потом и запивала при удачных стихосложениях, наша команда разработчиков-безопасников SwSxSpec, это было ещё до сегодняшних модных JS попоек. 😆
Редкая вещь, создавалась just for fun, для распознавания лексики и семантики языка, для конкурса по улучшению поисковых алгоритмов от Google.

Вы ещё не читали "Уставший от колец" (https://en.wikipedia.org/wiki/Bored_of_the_Rings), английскую сатиру на Толкиена - это вообще умора, содержащая в себе много аналогий про кольца привелегий и безопасности ("всевластья") в регистрах CPU (тогда в PDP-11, после уже регистры CR/CR0 в арихитектуре команд i386 поддерживаемые ядром Linux).
Говорят на основе этой книги был создан Unix в BellLabs в 70-х, а после и ядра BSD Unix в университете Беркли, только там "запивали" это дело с LSD, отсюда и ядро BSD. 😂

Опять же - рулят концепции языков, а не сами языки. Нужно изучать концепции языков программирования.
Только так можно стать полиглотом и свободно читать/писать практически любой код.
Многие новые языки искусственны - тот же Rust, авторы в Mozilla открыто говорят о том, что взяли концепции из многих языков и сделали один, по их мнению, идеальный.
И сейчас таких проектов будет всё больше - потому что сами концепции, парадигмы, развиваются крайне медленно, практически не меняются и что-то новое за последние 10-15 лет появлялось редко.
Из не столь давних разработок меня действительно удивили Nim (Nimrod), Elixir и Ur/Web.

Языки близкие по концепциям изучать и переходить между ними легко.
Для себя я выделил несколько близких по концепциям линий:
Go, Python, Ruby, JS, Dart, Lua, Self, Nim (Nimrod)
Java, Scala, Kotlin, Groovy
C, C++, Rust, Vala, Genie
Perl, PHP
OCaml, Haskell, Racket, Clojure, Erlang, Elixir, Ur/Web

Вообще, чтобы понять текущие и будущие тренды в языках программирования и взгянуть за пределы парадигм следует прочитать весьма интересную статью, которую я нашёл случайно, изучая работу байт-кода invoke-dynamic (JSR-292) в Java 7.
Только не смотрите на заголовок - охват статьи намного глубже!

Оригинал:
http://nerds-central.blogspot.com/2012/08/facebook-moving-to-jvm.html

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

Литература:
Роберт Себеста, "Основные концепции языков программирования"
https://telegram.me/thrill_seekers/96

Скоро каналу @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