Нативные бинарные модули на Rust для проектов написанных на Ruby.

Оптимизация производительности критических участков кода на Ruby с помощью бинарных модулей, написанных на Rust и используемых в проектах через Ruby-FFI.

https://blog.codeship.com/improving-ruby-performance-with-rust/

https://github.com/d-unseductable/ruru

https://usehelix.com

https://github.com/tildeio/helix

https://github.com/ffi/ffi

Оптимизация скорости/производительности исполнения кода скриптовых языков с использованием статически скомпилированных бинарных модулей, написанных на Rust - это действительно уже устойчивый тренд!

Ссылки по теме:
https://xn--r1a.website/technologique/1162

#ITSUBBOTNIK в Санкт-Петербурге

9 декабря в Санкт-Петербурге состоится пятый #ITsubbotnik
Это бесплатная конференция для опытных разработчиков и инженеров.

13 спикеров поделятся своим опытом и лайфхаками в реальных рабочих проектах. В этот раз доклады будут в следующих направлениях: Data Science, JavaScript & Mobile, DevOps и Java.

Также вас ждут стенды, гейм-зона и многое другое.
Приходите!

Регистрация здесь: https://epa.ms/itsubbotnik-winter

https://events.epam.com/events/itsubbotnik-winter-2017

Go Garbage Collector — concurrent tri-color incremental mark & sweep algorithm.

Доклад Рика Хадсона на конференции GopherCon 2015 о том, как в Go 1.5 удалось радикально уменьшить STW (Stop-The-World) задержки исполнения потоков программы (до наносекундных/субмиллисекундных показателей в последующих версиях, вплоть до крайних Go 1.8 и 1.9) благодаря применению гибридных алгоритмов многопоточной сборки мусора (GC) для программ написанных на языке Go.

https://www.youtube.com/watch?v=aiv1JOfMjm0

https://blog.golang.org/go15gc

Слайды:
https://talks.golang.org/2015/go-gc.pdf

Roadmap - на пути к версии 1.5:
http://golang.org/s/go14gc (https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/edit)

Метрики:
https://github.com/bmhatfield/go-runtime-metrics

https://twitter.com/brianhatfield/status/900473287750365184

Статья с оценкой производительности и метрик сервиса Twitch в их блоге:
https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7

В версии языка и компилятора Go 1.5 был кардинально переработан код сборщика мусора (GC), до этой версии он был полностью переписан на самом Go методами автоматного (транс-компиляция с языка Си), а после и ручного программирования (коррекция) и были внедрены новые (вернее старые, но давно забытые) улучшения в алгоритмы многопоточной сборки мусора, благодаря чему данный GC стал лучшей программой в своём классе (субмиллисекундные задержки при освобождении памяти даже для оперативных in-memory хранилищ данных с размером кучи в 256 ГиБ (heap-size) для каждой ноды кластера!).

Эта разработка стала исторической вехой не только для языка Go, укрепившей его позиции в серверной разработке облачных инфраструктур, сетевых сервисов и демонов сетевых протоколов (server-side cloud infrastructure software development), но и большим прецедентом для доказательства работоспособности концепций (proof-of-concept) алгоритмов сборки мусора, разработанных ещё в 1970-х годах (tri-color, quad-color, incremental, mark & sweep algorithms).

Алгоритм сборки мусора, применённый в GC для программ на Go - это многопоточный трёхцветный (по фазам пометки указателей с последующим перемещением и освобождением блоков памяти) алгоритм коллектора (concurrent tri-color incremental mark & sweep collector), концепция которого была разработана известным датским математиком и инженером Эдсгером Дейкстра в 1978 году.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD520.html

Но run-time (фаза исполнения) программ на Go был не первым проектом где был применён подобный алгоритм для коллектора памяти (GC).
Ранее Майк Пэлл (Mike Pall), автор знаменитого оптимизированного JIT копилятора Lua, применил подобный алгоритм в LuaJIT версий 1.x/2.0 для run-time фазы исполнения программ на языке Lua.
В LuaJIT будущей версии 3.0 автор планирует реализовать ещё более продвинутый четырёх-цветный оптимизированный алгоритм коллектора (Quad-Color Optimized Incremental Mark & Sweep GC).

http://wiki.luajit.org/New-Garbage-Collector

В run-time фазе исполнения программ оригинальным интерпретатором Lua версий 5.1/5.2 также используется трёхцветный алгоритм коллектора (Tri-Color Incremental Mark & Sweep GC). В более ранней версии Lua 5.0 использовался стандартный двухцветный алгоритм для коллектора памяти (Two-Color Mark & Sweep GC).

Отличная статья в блоге Майка Хёрна (Mike Hearn) о Go GC и вызовах современной компьютерной индустрии при создании гибридных алгоритмов коллекторов памяти:
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e

Визуализация различных алгоритмов сборки мусора - https://xn--r1a.website/technologique/958

#Go
#GC
#Lua
#ThrowbackTech

Ссылки:
https://xn--r1a.website/technologique/721
https://xn--r1a.website/technologique/722
https://xn--r1a.website/technologique/750
https://xn--r1a.website/technologique/1057

https://xn--r1a.website/technologique/732
https://xn--r1a.website/technologique/551
https://xn--r1a.website/technologique/423

https://xn--r1a.website/technologique/1157

Go CSP concurrency (cooperative/non-preemptive multithreading) versus actor model for multithreading.

Сравнение многопоточной производительности, реализаций очень близких моделей кооперативной многопоточности, Go CSP (goroutines+channels) и акторных фреймворков от Parallel Universe, Quasar для Java/Kotlin/Scala и Pulsar для Closure — скорости порождения новых программных потоков (green threads, user threads, fibers), их мапинга (M:N) во время исполнения на пул системных тредов (thread-pool) процесса приложения, предачи данных между потоками, задержек и оверхэда всех операций с потоками.

Quasar:

http://www.paralleluniverse.co/quasar/
http://blog.paralleluniverse.co/2014/08/12/noasync/
http://blog.paralleluniverse.co/2013/10/16/spaceships2/

Go 1.1:
http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/

Go 1.6.2:
http://blog.paralleluniverse.co/2016/05/03/skynet-go-quasar/

Skynet, бенчмарк для теста многопоточности:

https://github.com/atemerev/skynet

Dependent Typing and Monads as type system extensions.

Интересная беседа со Стефани Вейрих по зависимым типам, монадам, как коллекциям типов для расширения базовой системы типов языка Haskell (системы типов Хиндли-Милнера, λω = λ2 + λω_) — применении теории категорий для создания струкурных (высокоуровневых) и субструктурных (низкоуровневых) систем типов, применении теории типов Мартина-Лёфа (Martin-Löf type theory) для создания систем зависимых типов (исчисление конструкций, CoC, λPω) для (структурного и субструктурного) вывода типов при статическом анализе программ.

https://www.infoq.com/interviews/weirich-haskell-dependent-types

#Haskell

Ссылки по теме:
https://xn--r1a.website/technologique/1051
https://xn--r1a.website/technologique/1052
https://xn--r1a.website/technologique/1054

О тщете всего сущего. :)

Недавно в одном из чатов я писал:

"Синтаксис реально важен! Читабельность важна! Аккуратная ментальная модель языка, чтобы держать её в голове (и пользоваться ей) важна! Гвидо это прекрасно понимал, поэтому Python вышел настолько удачным!"

Как в подтверждение моих слов попалась статья Алексис Кинг "Восхождение по бесконечной лестнице абстракций", переведённая на русский язык недавно:

https://lexi-lambda.github.io/blog/2016/08/11/climbing-the-infinite-ladder-of-abstraction/

Перевод на русский язык:
https://ru.hexlet.io/blog/posts/infinite-ladder-of-abstraction

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

Сегодня в разговоре мне мой старый добрый друг и коллега, программист за 40 (yes, you can! you made it! =), сказал такую мысль, очень важную я считаю, поэтому хочу донести её до каждого из вас:

"Вот представь, что наша цивилизация вымерла (факторов для этого сейчас предостаточно, взять хотя бы биологические - питание, перенаселение, устойчивость вирусов и бактерий к антибиотикам), но до вымирания мы успели на неком носителе (типа кварцевого голографического, имеющего самую высокую ёмкость) сохранить хотя бы весь GitHub - какой код сможет понять будущая цивилизация (при допустимости того факта, что цивилизации умирали и жизнь возобновлялась на нашей планете не один раз), как расшифровать логику его работы, не имея железа архитектуры наших дней?
Cкорее всего большинство кода будет подобно манускриптам древних цивилизаций (типа шумерского царства или древнеегипетской цивилизации) - что-то смогут расшифровать и постичь, но большая часть останется не ясной, многое зависит от логики исследователей.
Той постижимой частью будет простой человеческий язык в комментариях с аналитической семантикой (языки индо-европейской группы) и код с императивной семантикой и структурной логикой (языки программирования высокого и среднего уровня), например байт-код виртуальных машин будет понятен, если их исходники на языках среднего уровня останутся, но работающее железо, кремниевая логика нанометровых транзисторных цепей, будут навсегда утеряны!
Поэтому - пиши комментарии в коде на русском и английском языках, выбирай языки не слишком низкоуровневые и не слишком высокоуровневые, практичные, ищи золотую середину и пиши код так, будто завтра мы все разом вымрем и цивилизациям будущего придётся читать, дебажить и запускать наши исходники! =)
Остальные принципы не столь важны!"

Этот пост за дружбу посвящается моему давнему другу Ярославу, разработчику Linux kernel subsystems developer at Novell - я уверен, ты скоро поправишься, выздоравливай! Иначе с кем мне крушить мои философские камни!? =)

Также огромное спасибо Александру Чистякову за подачу хорошего поста (ко времени) и за канал (for sure, это реально философский авторский блог!):
https://xn--r1a.website/lhommequipleure/21
http://telegra.ph/Da-zdravstvuet-zhizn-na-vysokoj-stupenke-12-02

#Telegram
#IT
#Software
#Development

Serverless/FaaS архитектура сервисов и платформа OpenFaaS на базе Docker контейнеризации.

Functions as a service (FaaS) это готовая к работе и самодостаточная (не требующая обслуживания со стороны пользователя/разработчика, serverless) облачная инфраструктура, чаще на базе нижележащих Docker контейнеризации и инструментов оркестрирования контейнеров (Kubernetes, Docker Swarm), предоставляемых как сервис, для упрощения развёртывания и обслуживания наносервисов.

Существует проект открытой платформы OpenFaaS на базе Docker для самостоятельного (self-hosted) развертывания FaaS инфтраструктуры на собственной хостинг площадке (например в дата-центре компании) для обслуживания сервисов.

Плэйлист с недавней конференции DockerCon Europe 2017, прошедшей в Копенгагене, Дании, 17 октября 2017 года - главной темой конферении были FaaS платфома OpenFaaS и serverless инфраструктуры для наносервисов:
https://www.youtube.com/watch?v=C3agSKv2s_w&list=PLlIapFDp305AiwA17mUNtgi5-u23eHm5j

https://www.openfaas.com

https://github.com/openfaas/faas

Автор проекта платформы OpenFaaS - Алекс Эллис.

Демонстрация работы:
https://www.youtube.com/watch?v=sp1B7l5mEzc
https://www.youtube.com/watch?v=BK076ChLKKE

Канал Алекса:
https://www.youtube.com/channel/UCJsK5Zbq0dyFZUBtMTHzxjQ

Также есть несколько коммерческих FaaS платформ - Amazon Lambda, Oracle Fn и Iron Functions:

https://github.com/fnproject/fn
http://www.opennet.ru/opennews/art.shtml?num=47314

https://github.com/iron-io/functions
https://xn--r1a.website/technologique/608

#FaaS
#Go
#Golang

Код проекта системы контроля версий Mercurial переводят на Rust.

Представлен план переноса (портирования) кодовой базы проекта распределённой системы управления версиями исходного кода Mercurial с языка Python на язык программирования #Rust.

https://www.mercurial-scm.org/wiki/OxidationPlan

Проект Mesosphere планирует активно применять Rust в DevOps инструментах.

Платформа Mesosphere и Datacenter Operating System (DC/OS) будут активно применять #Rust в серверной облачной инфраструктуре и DevOps инструментарии.

На вопросы Флориана Лейберта (CEO Mesosphere) о применении Rust для создания инструментов управления (DevOps) облачными инфраструктурами ответил Стив Клабник, один из основных core developers проекта компилятора Rust, а также Rust Community Manager (неофициально).

https://mesosphere.com/blog/rust-devops/

Designing Futures. Design Fiction.

Семинар CS547 по человеко-машинному взаимодействию Университета Стэнфорда.

Джулиан Бликер (Julian Bleecker), инженер, промышленный дизайнер человеко-машинных интерфейсов, о проектировании и юзабилити тестировании прототипов и человеко-ориентированных интерфейсов для взаимодействия с машинами.

https://www.youtube.com/watch?v=iH8X6Bcs7w8

Вы когда-нибудь задумывались о том почему кнопки и элементы управления в любых интерфейсах сгруппированы и расположены справа или слева (симметричный дизайн)? Я задумывался. Но многие ли из нас левши или от природы воспринимают мир иначе?
Грамотно спроектированный интерфейс должен быть интуитивным, транспарентным, прозрачным и понятным, не ощущаемым и естественным, как воздух. Этому способствует вертикально и горизонтально симметричный дизайн.

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

Очень советую поискать лекции и интервью Ноама Хомски (автора принципов универсальной и порождающей грамматики, на основе которых базируются все инструменты NLP, в т.ч. NLTK на Python), Марвина Мински (заложившего основы науки об искусственных нейросетях и машинном обучении) и Яна ЛеКуна (https://xn--r1a.website/technologique/1152).

Сам я это всё узнал, когда стал изучать машинное обучение для анализа данных - на EDX был курс по "дизайну человеко-машинных интерфейсов", в котором даже рассказывали как AI помогает дизайнерам в создании интуитивных интерфейсов, а на Coursera был интереснейший курс по лингвистической антропологии на основе работ Ноама Хомски.

#thinkingoutloud

Благодарю за идеи и вдохновение на посты по данной теме:
@Schvepsss и @Luger_08

О юзабилити и как оно связано с проектированием и прототипированием в более широком смысле промышленной разработки.

#thinkingoutloud

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

Высокий показатель юзабилити (usability) это фактически показатель удобства и положительного пользовательского опыта (User eXperience, UX - не нужно путать с UI, User Interface, самим интерфейсом взаимодействия пользователя с устройством!).

В промышленном дизайне интерфейсов есть способы измерения юзабилити на тестовых группах пользователей - юзабилити тестирование, которое хорошо интегрируется в цикл производства от тестирования прототипов до запуска в массовое производство (production).

По статистике многих юзаюилити тестирований наиболее удобными являются симметричные структурированные интерфейсы, которые по своей сути позволяют использовать компонентный подход в их проектировании. В промышленности такой подход хорошо подходит для массового производства (конвейерного производства и сборки, pipelining).

Тоже самое свойственно промышленному программирванию и дизайну интерфейсов - компонентный подход.

Когда-то Borland развивала серию RAD (Rapid Application Development) IDE (Delphi, C++ Builder, JBuilder) с удобным компонентным проектированием интерфейсов на базе библиотеки компонентов интерфейса (interface widget toolkit library) VCL (Visual Component Library), которая работала поверх WinAPI.
Сейчас тоже есть Lazarus для FreePascal, Glade (для GTK+), wxGlade (для wxWidgets) и Qt Creator (для Qt).

Ключевое здесь - юзабилити и компонентный подход к проектированию интерфейсов, который позволял даже программистам без чувства прекрасного быстро делать приложения со вполне приемлемым юзабилити!

С готовыми компонентами было проще cделать композицию с потребным юзабилити.
Сейчас же, с веб-технологиями, можно сделать вообще любой интерфейс (хоть с применением WebGL!), до такой степени, что теперь макеты интерфейса разрабатывают дизайнеры в графических редакторах.
И когда столько свободы в построении интерфейсов резко встаёт вопрос (и спрос) в обучении подходам в юзабилити. (Маркетинг и рынок это с радостью продают и потребляют. =)

Многие компании стараются унифицировать проектирование интерфейсов при помощи Material и других компонентных подходов к дизайну, при помощи компонентных библиотек элеметов интерфейса (виджетов) и фреймворков, напрмер Polymer (JS), Bootstrap (CSS) и подобных.

Все подходы (How-To), продвигаемые крупными компаниями и вендорами, нацелены на то, чтобы сделать приложения единообразными, с определённым расположением и видом элементов интерфейса, чтобы опять же прийти к компонентному дизайну и единому интуитивному опыту для пользователя (UX, User eXperience) и повысить юзабилити.

Однако после курса MIT на EDX становится вполне очевидно, что все самые базовые и основные подходы основаны даже не на психологии пользователя - но на человеческой физиологии и нейробиологии работы полушаний человеческого мозга!
Именно на физиологических корнях особенностей восприятия строятся все человеко-машинные интерфейсы, в том числе и программные интерфейсы.

Например, взять мобильное приложение Telegram для Android - это образец послойного Material дизайна интерфейса, где можно слои двигать свайпами, это и есть основная концепция Material дизайна интерфейсов, управление жестами в одно касание, для удобства управления одним пальцем, держа устройство в одной руке. Для более сложных жестов, кроме свайпов (swipe) - это всегда проблема стандартизации, т.к. нет единых соглашений и данных об их удобстве.

Почему я затронул эту тему...

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

Дизайнер может и способен быть и программистом, например разработчиком клиентских приложений.
Я много раз за свою практику и среди своих друзей наблюдал как разработчики интерфейсов и клиентских приложений, веб-дизайнеры и графические дизайнеры, становятся server-side разработчиками с отличными навыками проектирования.
Могу сказать и про себя - я изучал математику, занимался веб и графическим дизайном (с 2002 по 2010 годы) одновременно с разработкой клиентских и серверных приложений, быстро перерос в системного программиста (С/C++, с 2005 года по сей день).

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

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

#thinkingoutloud

Видео докладов с недавней конференции KotlinConf 2017, прошедшей в Сан-Франциско 2-3 ноября.

Полный плэйлист докладов:
https://www.youtube.com/playlist?list=PLQ176FUIyIUY6UK1cgVsbdPYA3X5WLam5

https://www.kotlinconf.com

#Kotlin

Ссылки на предыдущие посты и материалы по теме:
https://xn--r1a.website/technologique/1126
https://xn--r1a.website/technologique/1108
https://xn--r1a.website/technologique/1042
https://xn--r1a.website/technologique/1043
https://xn--r1a.website/technologique/1044
https://xn--r1a.website/technologique/995
https://xn--r1a.website/technologique/928

Дискуссия по ключевым темам на открытии конференции.

https://www.youtube.com/watch?v=pjnHDXkeK-4

(https://www.youtube.com/watch?v=pt0MYJWvxtc)

Дискуссия с обсуждением итогов и ключевых тем докладов, перспектив развития Kotlin, на закрытии конференции.

https://www.youtube.com/watch?v=NMs8Z6rFnzE

Андрей Бреслав немного приоткрыл завесу тайны над будущим внутренним устройством проекта компилятора Kotlin/Native.

https://www.youtube.com/watch?v=3Lqiupxo4CE

Рассказал о том какая модель автоматического управления памятью будет в Kotlin/Native - ARC (т.к. используется LLVM бэкэнд компилятор), очень похожая на подобную в Swift и Vala/Genie, с использованием weak references, но также дополнительно уже реализована сборка мусора (GC) в видео циклического коллектора:
https://www.youtube.com/watch?v=3Lqiupxo4CE&t=28m

Насколько безопасной будет система типов Kotlin/Native, будет ли реализована субструктурная система уникальных или линейных типов (uniqueness types, linear types/logic - проверка обёрнутых в типы (boxed, box model) указателей с помощью правил системы типов на низком уровне в процессе статического анализа и компиляции программы) для контроля владений (owned, unowned) и заимствований (borrowed) для указателей на сегменты памяти - вопрос открытый и пока не решённый.

И главная киллер-фича, которая будет в Kotlin/Native (и есть в Kotlin на всех платформах) и которая приравнивает его к Go - это сопрограммы и CSP многопоточность, которая очень лаконично объединяет концепции асинхронного и многопоточного кода, делает программирование асинхронного и многопоточного кода очень простым, снижая при этом накладные расходы по памяти и времени/задержкам порождения новых потоков, но нужен также фреймворк для удобного мапинга сопрограмм на системные треды (при ARC механизме управления памятью), либо автоматический мапинг в run-time (при реализации автоматической сборки мусора, GC механизме управления памятью):
https://www.youtube.coma/watch?v=3Lqiupxo4CE&t=34m56s