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

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

Дизайнер может и способен быть и программистом, например разработчиком клиентских приложений.
Я много раз за свою практику и среди своих друзей наблюдал как разработчики интерфейсов и клиентских приложений, веб-дизайнеры и графические дизайнеры, становятся 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://t.me/technologique/1126
https://t.me/technologique/1108
https://t.me/technologique/1042
https://t.me/technologique/1043
https://t.me/technologique/1044
https://t.me/technologique/995
https://t.me/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

https://twitter.com/abreslav/status/937651203873431552

https://twitter.com/andrcmdr/status/936679638339850240

Безопасность работы с памятью и указателями в Kotlin/Native будет, но не ценой усложнения и неудобства использования языка, а также борьбы с компилятором - команда разработки в поиске иных решений, отличных от применённой в Rust модели владений/заимствований и времени жизни областей видимости (пространств имён, scopes).

Хорошо было бы иметь в одном языке и безопасность памяти и сопрограммы/продолжения, интегрированные на уровне языка (suspend functions в Kotlin).

Вообще есть всего две основные сложности при создании нативной реализации компилятора языка - реализация поддержки системных Threads и IO, которые решаются через реализацию собственного run-time для программ (RAII/RC/GC управление памятью, thread-mapper (M:N) для маппинга программных потоков на системные потоки, создания пулов потоков и процессов) и использование системных вызовов ОС (syscalls), но проблема в том, что системные вызовы у каждой системы/ядра свои и только Unix системы стараются придерживаться POSIX стандарта, хотя и в них различий хватает (взять те же сигналы для процессов - есть и уникальные сигналы в проприетарных Unix системах).

Роман Элизаров снова очень хорошо рассказал про сопрограммы и глубоко погрузил всех в асинхронный и многопоточный код на базе сопрограмм, продолжений и suspend functions.

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

Ссылки на предыдущие материалы по теме:
https://t.me/technologique/1042
https://t.me/technologique/1043
https://t.me/technologique/1044

Седрик Беюст (Cedric Beust) рассказал про Kobalt - это очень классная билд-система сборки проектов на Kotlin, написанная на самом Kotlin.

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

http://beust.com/kobalt/home/index.html

http://beust.com/kobalt/plug-in-development/index.html

https://github.com/cbeust/kobalt

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

Разработчики из Netflix рассказали об этапах создания, сборки, формировании поставки и развёртывании проектов в своей облачной инфраструктуре (continuous delivery, deployment, continuous integration) при помощи облачной системы сборки Nebula и облачной платформы непрерывной поставки Spinnaker, которые применяются во всех проектах компании и в которых активно применяется Kotlin - следующие поколения системы сборки и платформы поставки будут полагаться на Kotlin практически полностью, как на базовую технологию, применяемую в этих проектах.

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

Machine learning strikes back!

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

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

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

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

Эрик потрясающий человек и автор, он умеет мастерски объяснять крайне сложные концепции невероятно простым языком.

Главный посыл доклада:
Нейросети должны помогать писать программы, например в IDE и языках поддерживающих flow-sensitive typing, IDE должны не просто уметь показывать места ошибок, но и предлагать варианты решений.

В свою очередь сам язык программирования должен в современных условиях и в текущем состоянии отрасли/индустрии позволять связывать данные из разных источников (выходов нейросетей) и преобразовывать данные для их обработки в других системах (входов других нейросетей) - источниками и приёмниками данных в данном контексте выступают нейросети, а язык программирования должен иметь средства обработки, преобразования и связывания данных, например монады/функторы для связывания категорий и базовые функции для распределённой и параллельной обработки данных (map, fold/reduce). Языки поддерживающие функциональную парадигму программирования в своей основе (например Haskell, OCaml) имеют все необходимые средства структурирования, композиции и обработки данных и прекрасно подходят для этих целей.

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

https://www.youtube.com/watch?v=NKeHrApPWlo&t=50m

"The program of the future is a mix of imperative code with machine learn models... So the programming language of the future are the mix of traditional languages plus machine learn models... So we have to embed that into programming languages, and a way we can do that embedding is using monads and in particular the Probability Monad".

#Great_Insights

Ссылки:
https://t.me/technologique/1002
https://t.me/technologique/1006
https://t.me/technologique/1007
https://t.me/technologique/1131

Заметка для администраторов каналов (и групп) Telegram.

Сегодня заморочился с исходниками недавно вышедшей новой версии десктопного клиента Telegram - https://github.com/telegramdesktop/tdesktop/tree/v1.2.0

В общем, смысл такой — все печатаемые символы которые не покрываются регулярным выражением типа [0-9a-zA-Zа-яА-Я\s\_\-\+\!\@\(\)\[\]\{\}\<\>\,\.\:\;\'\"], т.е. вводимые символы `~#$%^&*=\|/? (а также символы Unicode) позволяют выводить полный листинг участников каналов (и групп) в десктопном клиенте. (!!!)

Т.е. ввод этих символов (`~#$%^&*=\|/? и Unicode, даже смайлов) в поле поиска member'ов позволяет преодолеть показ стандартного списка из 200 подписчиков каналов и показывает всех. В группах работает аналогично.

Подобный очень полезный финт для полного вывода списка/листинга всех пользователей работает как в последней версии (v1.2) десктоп клиента Telegram, вышедшей недавно на днях, так и в предыдущих версиях.

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

Как сделать подобный запрос с выводом member-list'а через API.

Для вывода всех данных о канале или групп-чате и вывода списка участников в числе этих данных, в клиентском API протокола MTProto есть метод getFullChat объекта Messages, который возвращает объект messages.ChatFull с полной информацией о канале или группе.

https://core.telegram.org/method/messages.getFullChat

https://core.telegram.org/type/messages.ChatFull
https://core.telegram.org/constructor/messages.chatFull

https://core.telegram.org/type/ChatFull
https://core.telegram.org/constructor/chatFull

https://core.telegram.org/type/ChatParticipant
https://core.telegram.org/constructor/chatParticipant

https://core.telegram.org/type/ChatParticipants
https://core.telegram.org/constructor/chatParticipants
https://core.telegram.org/constructor/chatParticipantsForbidden

Для справки есть исчерпывающая и актуальная документация о всех методах работы с данными протокола MTProto - https://core.telegram.org/methods

Более того авторы также озаботились созданием Haskell-подобного метаязыка TL с зависимыми типами для описания представления и работы с композицией типов данных протокола MTProto — https://core.telegram.org/mtproto/TL

https://core.telegram.org/schema - схема клиентского API на языке TL, декларативно описывающая типы данных и методы работы с ними в протоколе

https://core.telegram.org/schema/mtproto - схема самого протокола

Композиция типов данных в протоколе довольно сложно структурирована, но для облегчения можно использовтаь сторонние бибилотеки-мапперы типов и методов/функций работы с типами для их использования в парадигме другого языка программирования, например Python с помощью библиотеки Telethon — https://github.com/LonamiWebs/Telethon

https://lonamiwebs.github.io/Telethon/methods/channels/get_full_channel.html

PS: Хочу также порекомендовать жутко полезную библотеку для создания ботов на Haskell, если вы изучаете язык и хотите в него вникнуть через pet проект - https://hackage.haskell.org/package/telegram-api

Но, Bot API при этом например не позволяет запросить полный список подписчиков - только общее количество участников каналов и логировать подписавшихся/ушедших участников после добавления бота в канал или группу:
https://core.telegram.org/bots/api#getchatmemberscount
https://core.telegram.org/bots/api#getchatmember
https://core.telegram.org/bots/api#message (поля данных new_chat_members и left_chat_member объекта Message)

https://hackage.haskell.org/package/telegram-api-0.7.0.0/docs/Web-Telegram-API-Bot-API-Chats.html

You can't spell trust without Rust.

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

https://gotober.com/2017/sessions/252

Отличная вводная лекция на конференции GOTO Berlin 2017 по основным концепциям языка Rust и о принципах обеспечения безопасности памяти субструктурной системой типов языка (uniqueness types) на этапе компиляции (compile-time) и статического анализа исходного текста программ.
В Rust вся run-time активность кода, всё время исполнения программы, покрываются системой типов в фазе compile-time — statically proven in the previous, compile-time, phase. Полностью статическая система проверки типов на низком уровне была создана на основе подобной системы типов в компиляторе языка OCaml.

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

Ссылки на предыдущие публикации по теме:
https://t.me/technologique/1157
https://t.me/technologique/1158
https://t.me/technologique/1159
https://t.me/technologique/1164
https://t.me/technologique/1191
https://t.me/technologique/1012
https://t.me/technologique/1015
https://t.me/technologique/957
https://t.me/technologique/892

#Rust

You can do it, with Conduit!

В компании Buoyant создали новое поколение системы поддержки и управления группами сервисов (service mesh) Conduit для организации сервисных шин и обеспечения реестров сервисов (service discovery), балансировки и распределения нагрузки (load balancing), мониторинга, анализа и предупреждения инцидентов (failure handling), маршрутизации коммуникаций между сервисами (routing for inter-service communication).

Новая, пока экспериментальная (not yet production ready), система управления группами сервисов Conduit написана в большей степени на Rust и в меньшей на Go, ориентирована (в отличии от Linkerd) на управление сверхлёгкими сервисными роями с ограниченными по мощности ресурсами, что хорошо применимо в IoT Cloud Native инфраструктурах.

https://buoyant.io/2017/12/05/introducing-conduit/

Для коммуникаций используется пока только протокол HTTP/2, есть возможность использования фреймворка gRPC для расширения функциональности. В качестве управляемого окружения контейнеров в бэкэнде используется Kubernetes.
При создании Conduit использовались многопоточный фреймворк асинхронного неблокирующего ввода-вывода Tokio (https://github.com/tokio-rs/tokio) и фреймворк Tower (https://github.com/tower-rs/tower) для организации асинхронного IO и многопоточной обработки ввода-вывода посредством функционального Future паттерна (подобного IO Monad в Haskell).

https://conduit.io — https://twitter.com/runconduit

https://github.com/runconduit/conduit

Ранее в компании Buoyant была создана подобная система поддержки межсервисной коммуникации и управления группами сервисов Linkerd, написанная на Scala и использующая JVM стэк (Finagle, Netty).
Linkerd поддерживает различные реестры сервисов (service discovery backends), например Consul, ZooKeeper, Nomad, и управляемые окружения для контейнеров, например Mesos, Kubernetes и Rancher.
Linkerd это production ready система управления группами сервисов, которую используют уже многие компании в своих облачных инфраструктурах, в числе которых такие масштабные проекты как компания Monzo (ранее финансовый стартап), серверная часть которого реализована полностью на Go.

https://buoyant.io — https://twitter.com/BuoyantIO

https://linkerd.io — https://twitter.com/linkerd

https://github.com/linkerd/linkerd — https://hub.docker.com/r/buoyantio/linkerd/


#Rust #Go
#Cloud #CloudNative #IoT
#DevOps #SOA #ESB

Good news!

By Nikolay Igotti, Kotlin/Native Tech Lead

#Kotlin

https://t.me/technologique/1188
https://t.me/technologique/1190
https://t.me/technologique/1191

OCaml in Financial Technologies

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

Несколько очень классных и интересных видео, которые посмотрел на днях, с непосредственным участием Ярона Мински (https://twitter.com/yminsky), соавтора самой лучшей книги об OCaml (да и вообще в целом о создании компиляторов) "Real World OCaml" (https://t.me/technologique/1010) и разработчика трейдинговых биржевых платформ на OCaml в крупной трейдинговой компании Jane Street Capital, в которой OCaml используется не для высокочастотного трейдинга (https://www.youtube.com/watch?v=FDUrItVCeyg&t=7m45s), а для максимального покрытия рисков в биржевых операциях с ликвидными средствами. Jane Street является одним из крупнейших системных интеграторов OCaml в своей инфраструктуре (наряду например с Facebook) — https://blog.janestreet.com
В интервью для San-Francisco Scala Meetup's Ярон рассказал более подробно о моделях вычислений в обработке данных на OCaml для финансового сектора и анализе финансовых данных с помощью OCaml в сравнении с другими языками функционального программирования.

#OCaml

В интервью Ярон затронул также очень тонкий вопрос - в чём основное отличие OCaml, его компилятора и VM, а также Rust/LLVM, от JVM и языков для неё, которые также очень широко используются в финансовом секторе.

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

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

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

Вся соль в метапрограммировании, run-time рефлексии и интроспекции типов.

Rust (равно как и OCaml, и ML) из-за полностью статической системы типов (вывода и статического анализа типов в compile-time) поддерживает метапрограммирование благодаря поддержке гомоиконности через систему compile-time макро-расширений (макросов) языка.
JVM языки (Java, Kotlin, Scala), наряду со статической системой типов (compile-time выводом и статическим анализом типов), также поддерживают run-time рефлексию и интроспекцию типов данных в run-time. Это очень удобно для создания моделей данных и вычислений, особенно в финансовом секторе. Именно поэтому JVM языки стали столь популярны в бизнес среде и разработке приложений для корпоративного и финансового сектора.
И это главное отличие Rust и языков группы ML (Standard ML, Concurrent ML, Dependent ML и их потомка, языка OCaml) от JVM языков.
Но при этом, нужно отметить, что все эти языки, как Rust/OCaml/ML, так и JVM языки, могут проходить разные стадии компиляции, независимо от наличия статической (вывода и статического анализа типов данных в compile-time) и динамической (run-time рефлексии и интроспекции типов данных) системы типов — например, интерпретация байт-кода (JVM), компиляция байт-кода (LLVM IR/MIR), динамическая кодогенерация, т.е. динамическая JIT компиляция байт-кода (JVM и LLVM JIT).

#Rust
#OCaml
#ML

Поисковые механизмы Telegram пока ещё не так совершенны (до сих пор в клиентских приложениях нет глобального поиска по описаниям каналов, содержимому постов или по тегам, как в Twitter, но уже есть внешние индексирующие сервисы, например https://tgstat.ru/search) и встроенные механизмы поиска не позволяют читателям находить каналы с интересующей информацией определённой тематики прямо в клиентских приложениях (через строку поиска), а авторам находить заинтересованную аудиторию, продолжать писать и делиться интересной информацией и опытом.
Единственным самым простым и доступным способом для авторов и читателей найти друг друга остаются подборки и рекомендации каналов.
Поэтому не так давно мы с авторами других IT каналов решили рассказывать вам друг о друге.
В данной подборке каналов каждый из вас сможет найти интересную и полезную для себя информацию из разных направлений IT сферы.
А если вы автор интересного канала — пишите (@andrcmdr), расскажите о себе, мы с коллегами, другими авторами, стараемся создать пул достойных IT каналов разной направленности для блага читателей и поддержки друг друга.