Первого мая этого года будет закрыт хостинг проектов https://alioth.debian.org

Вместе с хостингом будет закрыт один очень хороший проект, Benchmarks Game, с тестами производительности и эффективности программ на разных языках программирования.

Проект http://benchmarksgame.alioth.debian.org существовал с 2004 года (http://web.archive.org/web/20040611035744/http://shootout.alioth.debian.org) и до 2012 года работал на домене http://shootout.alioth.debian.org (http://web.archive.org/web/20121231010227/http://benchmarksgame.alioth.debian.org).

Сайт вместе со всем контентом и кодом тестов на различных языках программирования можно скачать в виде архива:
http://benchmarksgame.alioth.debian.org/download/benchmarksgame-html.zip

Надеюсь проект продолжится уже на GitHub!

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

http://doyoutrustthiscomputer.org/watch

#antitrust

Бэкэнд компилятора Rust 1.25 переведён на инфраструктуру компиляции LLVM 6.
Также улучшены синтаксис импортов и паттерн матчинг выражений - теперь импорты могут быть вложенными, а паттерн матчинг блоки имеют синтаксис как в OCaml.
Подробнее в заметках к релизу:
https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1250-2018-03-29

#Rust

Проект Benchmarks Game продолжит свою жизнь на страницах GitLab:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/

https://t.me/technologique/1279

Финальный вариант RFC по внедрению поддержки async/await синтаксиса на уровне языка (first-class asynchronous support) в #Rust.

https://boats.gitlab.io/blog/post/2018-04-06-async-await-final/

https://t.me/technologique/1277

Проект Corda - блок-чейн БД и лэджер для финансового сектора.

https://www.corda.net

https://github.com/corda/corda

Проект Corda - фреймворк который многое упрощает для интеграции блок-чейн технологий в финансовом секторе и компаниях, работающих в нём.
Используется для создания распределенной блок-чейн БД в сфере финансов, хранения и цифрового учёта ценностей.
Более того фреймворк написан на Kotlin, смарт-контракты для движка БД можно писать также на Kotlin и других языках для JVM.
Фреймворк имеет статус production-ready, применяется в реальных проектах, используется крупными и именитыми европейскими (например UBS), американскими и международными банками, интегрирован в их сервисную инфраструктуру.

#Kotlin

Telegram is down... Again

Before - couple cases of power interruption... Now overheating... And power issues... What's next?
Faults, again and again!
https://outage.report/telegram
Where is the #decentralization of #Telegram and #MTProto? Decentralization is really essential too, as an air - not only that faulty cloud storages!

https://twitter.com/durov/status/990371212877549568

@durov

PEP-484 (mypy) - расширение для gradual typing в CPython и PyPy.

PEP-484 (mypy) давно поддерживается не только официальным интерпретатором, но сторонними реализациями Python, такими как PyPy и Jython.
Но даёт ли статическая аннотация типа до фазы run-time значительно ощутимый прирост производительности исполнения байт-кода в run-time благодаря отсечению лишних проверок вывода типа и более быстрому динамическому связыванию объекта с типом? Или данный механизм помогает только в отладке сложных ситуаций преобразования типов обектов (type casting)?
Больше полугода, как мы стали масштабно использовать это расширение в разработке, вопрос оставался открытым.
Сейчас, спустя время, по метрикам мониторинга сервисов под реальной нагрузкой и на основе имеющегося опыта применения расширения можно делать определённые выводы.

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

Более того возможны также дополнительные задержки при исполнении кода на различных платформах из-за сопоставления и преобразования типов к размеру машинного слова, что сам интерпретатор без аннотаций типов выполняет быстрее и оптимальнее и аннотация в этом случае только помеха для оптимизированного механизма type casting в интерпретаторе.
Поэтому расширение PEP-484 (оно же mypy) стоит использовать в основном в отладочных целях.

http://doc.pypy.org/en/latest/faq.html#would-type-annotations-help-pypy-s-performance

https://bugs.jython.org/issue23973
https://bugs.jython.org/issue32227

Так же расширение помогает в выявлении логических ошибок типов в режиме flow-sensitive typing в IDE, например в PyCharm крайних версий.

Ранее, чем в Python, технология gradual typing была реализована в TypeScript и далее в Dart 1.xx (Dart 2 полностью статически типизированный язык с выводом типов в compile-time) и statical type checker'е Flow от Facebook для реализации gradual typing, как надстройки из дополнительных run-time проверок (диспетчеризации) типов, в языке JavaScript, поддержка flow sensitive typing была внедрена в Visual Studio Code и Atom IDE.

Интересный доклад по данной теме:
https://www.youtube.com/watch?v=_PPQLeimyOM

Предыдущий пост по теме:
https://t.me/technologique/1214

#digging
#compilers

Google I/O 2018

Сейчас начинается открытие конференции Google I/O 2018

https://www.youtube.com/watch?v=ogfYd705cRs&list=PLOU2XLYxmsIIjoHFYLtwS-_dKrtLhhk_D&index=1

Полный плэйлист лайв-стримов трансляций со всех залов конференции:
https://www.youtube.com/playlist?list=PLOU2XLYxmsIIjoHFYLtwS-_dKrtLhhk_D

Полный плэйлист записей трансляций всех докладов:
https://www.youtube.com/watch?v=ogfYd705cRs&list=PLOU2XLYxmsIInFRc3M44HUTQc3b_YJ4-Y

Google IO 2018 пройдёт с 8 по 10 мая

https://events.google.com/io/

Лично мы ждём пресс-релиза Dart 2 и Flutter для Android и iOS, а также возможного анонса OS Fuchsia, статистики применения и распространения Kotlin в сообществе Android за год с предыдущей конференции, больше информации о развитии и стратегии продвижения платформы Android Things для IoT экосистемы, применении WebAssembly в веб-приложениях.

https://events.google.com/io/schedule?section=may-10&sid=7387180b-b1dd-49c3-bddf-de3f87ae1990 - сессия с Андреем Бреславом о #Kotlin

Расписание всей конференции и трансляций можно посмотреть по данным ссылкам:

https://events.google.com/io/schedule

https://events.google.com/io/live

Dart 2.0 уже можно поставить из dev (unastable) репозитория Google

https://www.dartlang.org/tools/sdk

https://storage.googleapis.com/dart-archive/channels/dev/release/latest/linux_packages/dart_2.0.0-dev.53.0-1_amd64.deb

Киллер фича Dart 2 это даже не статический вывод типов и повышение скорости исполнения кода
Главное - AoT компиляция на всех платформах, включая стандартную библиотеку, созданные приложения и пакеты из PUB репозитория (https://pub.dartlang.org)
Итоговый бинарник имеет только run-time код для управления потоками и автоматического управления памятью, т.е. виртуальная машина и JIT компиляция элиминируются из процесса исполнения кода полностью
Это то чего пока что в Java 9 не достигли в полной мере с GraalVM - AoT компиляция невозможна для многих классов даже в стандартной библиотеке, не говоря уже про сторонние библиотеки и приложения.
Я впечатлён - новый Dart 2 получился на редкость годным и конкурентоспособным!

#GoogleIO
#Dart
#Flutter
#Fuchsia

Будущее Intel

Джим Келлер, знаковая и во многом судьбоносная фигура в разработке современных процессорных архитектур, работавший ранее в подразделении Tesla Autopilot над архитектурой бортового компьютера для автопилота автомобилей Tesla, а также до этого дважды в AMD в разные годы (разработал набор инструкций x86-64, архитектуры K7/K8/Zen/Zen-2/Zen-3/K12, шину HyperTransport) и в Apple (разработал архитектуры A4 и A5) - перешёл на работу в Intel!

https://newsroom.intel.com/news-releases/jim-keller-joins-intel-lead-silicon-engineering/

https://www.anandtech.com/show/12689/cpu-design-guru-jim-keller-joins-intel

https://medium.com/syncedreview/chip-guru-jim-keller-leaves-tesla-for-intel-34affc4a6490

Можно в уверенностью утверждать, что суперскалярная конвейерная (pipeline) архитектура исполнительных ядер процессоров себя уже изжила (при наличии более быстрых параллельных архитектур, применяемых в GPU и для вычислений с технологией NVidia CUDA) и во многом была дискредитирована уязвимостями упреждающего предсказания ветвлений в конвейере процессора при исполнении кода (нашумевшие ещё в начале года Meltdown и Spectre).

Поэтому можно ожидать как новых GPU от Intel, новых ультрамобильных (Atom) и embedded процессоров (например для IoT и single board компьютеров), так и при нынешней ситуации, аппаратной уязвимости архитектур предыдущих поколений и сложности перехода c 14 нм на 10 нм фотолитографический техпроцесс в глубоком ультрафиолете (EUV, extreme ultraviolet lithography), нужно ожидать новых технологических прорывов и улучшений в архитектурах и технологических процессах производства основной линейки серверных, десктопных и мобильных процессоров Intel.

Ссылки по теме:
https://t.me/technologique/1102
https://t.me/technologique/772
https://t.me/technologique/28

О будущей архитектуре Intel Tinsley (процессор Sapphire Rapids):
https://t.me/technologique/1242
https://t.me/technologique/1244
https://t.me/technologique/1245

О сути уязвимостей суперскалярной конвейерной архитектуры и найденных решениях для их фиксации:
https://t.me/technologique/1246
https://t.me/technologique/1235

Поддержка групповых звонков в Telegram

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

https://github.com/grishka/libtgvoip/search?l=C%2B%2B&q=group&type=

https://github.com/grishka/libtgvoip/blob/public/VoIPController.cpp

https://github.com/grishka/libtgvoip/blob/public/VoIPController.h

https://github.com/grishka/libtgvoip/blob/public/client/android/tg_voip_jni.cpp

Наш регулярный листинг рекомендаций IT каналов в Telegram.

@MicrosoftRus - Авторские заметки для ITPro & Dev о Microsoft, Windows Server, System Center, Azure, Office 365, OMS, SQL, облаках и не только.

@mustreat - Mustreadы технологий и значимых событий.

@sea_plus_plus - Материалы и заметки из мира C/C++, Python, Go, Linux и не только.

@DXspace - Канал про бизнес и технологии в эпоху цифровой трансформации. Важные новости, презентации, актуальные исследования и инфографика помогут вам адаптироваться к неизбежному будущему.

@msdnru - Официальный канал сообщества Microsoft Developer для разработчиков и всех, кто интересуется новыми технологиям.

#channels
#telegram
#advices
#рекомендации

И ещё один небольшой список замечательных и очень интересных каналов о программировании, DevOps практиках и администрировании, о технологиях и немного о сарказме в IT. =)

@SysadminNotes - Заметки практикующего сисадмина о Linux и администрировании серверов.

@theaftertimes - Несерьезный дайджест IT. Ежедневно. Цитаты, паста, картинки.

@w20to - Настоящее и будущее технологий. Future, Science, Tech, Trands, Robotics, AI, IoT, VR, and more.

@dncuug - Канал посвящён вопросам разработки под .NET Core: новые фичи C#, .NET разработка под macOS X и Linux, микросервисы и HighLoad. Вот это вот все и даже больше.

@ITBroadcast - Канал для тех, кто хочет быть в теме и познавать новое в области IT. Входим в Top 1 каналов Telegram о технологиях.

#channels
#telegram
#advices
#рекомендации

GitHub поглощён корпорацией Microsoft

Сегодня была официально подтверждена сделка о поглощении git хостинга open source проектов GitHub компанией Microsoft за $7.5G.

https://blog.github.com/2018-06-04-github-microsoft/

https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-developers/

https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

Все мы помним к чему приводят поглощения Microsoft open source компаний - достаточно вспомнить проекты открытых мобильных ОС Maemo и Meego (ныне проект Jolla Sailfish) также поглощённой в своё время компании Nokia.

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

Поэтому с трудом верится в bright future for GitHub and developers - это скорее светлое будущее для создателей и светлая память прекрасному сервису для коллаборации миллионов разработчиков по всему миру.

С другой стороны нельзя не признать что Microsoft меняется на гразах и очень быстро - компания вошла в Linux Foundation, был портирован гипервизор HyperV для ядра Linux, создан слой WSL (Windows Subsystem for Linux, https://github.com/Microsoft/WSL) для изоляции Linux окружений (файловых систем и процессов) на ядре Windows, и их интеграции с Windows окружением, открыт исходный код платформы .Net, компиляторов C# и F#, SQL Server, JS движка Chakra Core браузера Microsoft Edge, активно разрабатываются свободные и открытые проекты .Net/Roslyn и .Net Core, LSP (Language Server Protocol, http://langserver.org), редактор кода Visual Studio Code и инструментарий языка TypeScript.

https://github.com/Microsoft

Возможно (при оптимистичном сценарии) что огромное сообщество open source разработчиков теперь будет играть значимую роль в огромной компании и менять её вектор развития в интересах сообщества.

Тем временем сообщество стало активнее бэкапить проекты на сторонние сервисы хостинга git репозиториев - GitLab и Bitbucket сегодня испытывают всплеск нагрузки по импортированию репозиториев с сервиса GitHub:

https://monitor.gitlab.net/dashboard/db/github-importer?orgId=1&from=1527811200000&to=1528156800000

Самое печальное в этой ситуации то, что очень много зависимостей в проектах на Go до сих пор сильно завязаны на хостинг GitHub, не смотря на наличие сервиса https://gopkg.in для проксирования адресов зависимостей.

All about Node

Откровенный рассказ Райана Дала, автора платформы Node.js, о недочётах в концепциях, положенных в основу дизайна при проектировании платформы Node.js на конференции JSConf.EU 2018

https://youtu.be/M3BM9TB-8yA

Ссылки:
https://t.me/technologique/1071

Rust Traits

Прекрасная статья с подробным объяснением различий всех видов трейтов (тайп-классов - &Trait, Box<Trait>, impl Trait, dyn Trait), их обектов (экземпляров) и особенностей реализаций/имплементаций в языке #Rust.

https://joshleeb.com/posts/rust-traits-and-trait-objects/

Framework Benchmarks - Round 16

Шестнадцатый раунд нагрузочного тестирования производительности фреймворков - Framework Benchmarks от TechEmpower.

https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext&a=2

https://www.techempower.com/blog/2018/06/06/framework-benchmarks-round-16/

Тестовые наборы TechEmpower интересны разносторонним подходом к тестированию производительности и выявлением таким образом узких мест фреймворков.

Тестовые наборы находятся в открытом доступе для их open-source community разработки (https://github.com/TechEmpower/FrameworkBenchmarks).

Производительность фреймворков тестируется по различным параметрам и подсистемам, что формирует разные модели нагрузки - сериализация JSON и неформатированные plain-text запросы (для оценки производительности контроллеров и роутеров API запросов согласно идеоме фреймворка), одиночные и множественные (многопоточные) запросы к БД на чтение данных (оценка производительности коннекторов к различным БД и raw подключений к БД), количество операций записи данных в БД (через коннектор либо raw подключение к БД), запрос всех строк и полей таблицы с данными (fortunes) с их последующей шаблонизацией и отсылкой клиенту (комплексная оценка скорости операций чтения данных и производительности шаблонизации данных в формат сериализации для отдачи клиенту или стороннему API).

Dockerificationization!!! [Докерификэйшенизэйшн!!!]

Было обновлено серверное железо (Citrine - triple homogeneous Dell R440), ширина канала связи до серверов увеличена до 10 Гбит/с.

Самое же главное нововведение в данном раунде - контейнеризация тестовых окружений с помощью Docker.
Ранее использовался home-brew sandboxing - 1, 2, 3, 4.
Переход на Docker был произведён для улучшения процесса непрерывного нагрузочного тестирования (continuous benchmarking - https://tfb-status.techempower.com).
Прогон всех тестовых наборов для получения новых показателей занимает сейчас в среднем 67 часов.

Главное, что было проверено под большими нагрузками, что сам движок dockerd, библиотека libvirt и тем более изоляция окружений на базе системных вызовов ядра Linux не дают хоть сколько нибудь ощутимого оверхэда и торможения тестовых наборов в контейнерах - 67 часов прогона всех тестовых наборов без Docker при использовании Docker замедляются всего лишь в пределах минуты. Такой результат находится на уровне погрешности измерений при нескольких прогонах тестовых наборов!

Across the board, our sanity checking of performance metrics has indicated Docker's overhead is immeasurably minute. It's lost in the noise. And in any event, whatever overhead Docker incurs is uniformly applicable as all test implementations are required to be Dockered.

Это весьма сильный аргумент для до сих пор сомневающихся компаний и инженеров в пользу применения Docker в серверной инфраструктуре проектов.

В нагрузочном тестировании stateless контейнеры улучшили сам процесс непрерывного тестирования и воспроизводимость тестовых окружений (reproducibility of builds), что повысило согласованность данных (consistency) при множественных прогонах тестовых наборов в процессе непрерывного тестирования (continuous benchmarking).

Most importantly, thanks to Dockerizing, the reproducibility and consistency of our measurements is considerably better than previous rounds. Combined with our continuous benchmarking, we now see much lower variability between each run of the full suite.

И главное напутствие данного раунда тестов - медленные платформы и их приверженцы, разработчики, пытаясь преодолеть платформенные ограничения, плодят ужасные, некрасивые и неэлегантные архитектурные решения, которые не всегда необходимы, для масштабирования таких платформ под высокой нагрузкой (вспомните опыт инженеров Instagram - https://t.me/technologique/1214).

Стремитесь к красоте и элегантным решениям!

Developers on slower platforms often have so thoroughly internalized the limitations of their platform that they don't even recognize the resulting pathologies: Slow platforms yield premature architectural complexity as the weapons of “high-scale” such as message queues, caches, job queues, worker clusters, and beyond are introduced at load levels that simply should not warrant the complexity.

Предыдущие посты по теме:
https://t.me/technologique/1263
https://t.me/technologique/970
https://t.me/technologique/609
https://t.me/technologique/59

Яндекс.Такси проводит соревнование для бэкенд разработчиков.
Главный приз — 300 тысяч рублей.
В качестве заданий — реальные задачи разработчиков Яндекс.Такси.
Писать можно на C++, Python или Java.

Регистрация открыта до 13 июля:
https://taxi.yandex.ru/action/ytcf/coding_fest

#challenge