Входящий звонок

Исходящий звонок со стандартной градиентной фоновой заставкой

Исходящий звонок с фоновой аватаркой пользователя

Callback Invitation

End2End шифрование звонка с проверкой публичных ключей

Для вывода отладочной информации нужно тапнуть на имени пользователя

Quality Feedback

В интерфейсе доступен вывод аудиопотока на Bluetooth гарнитуру

Можно даже самому себе позвонить и не дозвониться! 😆😂

Автообновление бета версии приложения клиента Telegram

Два апдейта за один день!
Тестирование идёт очень активно, все баги фиксят оперативно - вчера у меня на Intel x86 сборка universal падала с ошибкой при совершении звонка, сегодня уже всё работает

В этот четверг, 16 марта в 20:00 (UTC+6) компания Klika Tech проведёт вторую практическую часть вебинара "Writing Scalable React Applications: Dive into React", на русском языке, по SPA фреймворку React.js

Ведущим вебинара будет Михаил Ошер (Klika Tech).

Во второй части вебинара Михаил на реальном практическом примере расскажет об использовании React.js и покажет, как писать приложения с использованием этого фреймворка.

Трансляция будет проводиться на YouTube канале Klika Tech.

Первая лекция вебинара - @technologique/704
Ссылка на трансляцию первой лекции вебинара - React Basics

Ссылка на трансляцию второй части вебинара также заранее будет выслана на почту всем подписавшимся.
Если вы ещё не подписаны - подписывайтесь на вебинар в очень простой форме (Имя, E-mail): Dive into React - Subscribe Form
Если вы не можете принять участие в трансляции, вам на почту будут высланы все материалы лекции.

Ссылка на транляцию второй практической части вебинара по React.js от Klika Tech

https://youtu.be/M5WySjinAT4

https://www.youtube.com/c/Klikatech-page/live

Запись трансляции сегодняшнего запуска ракеты-носителя Falcon 9 с телекоммуникационным спутником EchoStar 23.
В этот раз первую ступень не стали спускать из верхних слоёв атмосферы и выполнять её посадку для последующего повторного использования из-за высокой взлётной массы спутника (более 5.5 тонн).

https://youtu.be/dM2Dp1Adlag

https://youtu.be/lZmqbL-hz7U

#space
#spacex

Вот чего мне всегда не хватало в Sublime Text, TextMate (в 2012-2013 годах я работал на MacBook), Vim и Emacs - мультикурсора со всеми степенями свободы и управлением БЕЗ мыши.

https://atom.io/packages/multi-cursor-plus

https://atom.io/packages/multi-cursor

Ниже - скринкасты с демонстрацией возможностей плагинов multi-cursor и multi-cursor-plus в редакторе Atom на списке серверов Stratum1 с сайта NTP.org. В дальнейшем в работе для рефакторинга кода и редактирования логов эти возможности будут очень полезны и юзабельны!

PS: Если есть что-то подобное для Vim и Emacs - киньте ссылку, потому что сколько я искал в экосистемах плагинов для этих редакторов, но плагина реализующего подобную функциональность свободных мультикурсоров я ещё не находил, а для Sublime подобный плагин разработать невозможно из-за ограничений API плагинов редактора и привязки мультикурсоров к событиям мыши (Ctrl+LeftMouseClick) и координатам курсора мыши, которые через API невозможно эмулировать.
В свою очередь в Atom, не смотря на то, что используется PCRE движок Oniguruma (как и в Sublime Text, и в TextMate) - очень слабая поддержка регулярных выражений, что очень нужно при работе с большими отладочными дампами и большими файлами логов, при поиске и замене/удалении по RegExp шаблону.
В Atom не поддерживаются look-behind assertions и back-references - как и в JavaScript, а Atom построен на JS фреймворке Electron и движке V8.

Scalability vs. High-Load

Масштабируемость (scalability) это отдельное понятие, лишь косвенно связаное с нагрузками - а high-load лишь одна из характеристик крупномасшатбных систем.
В русскоязычном сообществе их часто смешивают.
Scalability или иначе ability of scaling, масштабируемость, возможности масштабирования - это в первую очередь про архитектуру, её проектирование, гибкость и возможности её изменения (доработки, поддержки и дальнейшего роста) в крупных, масштабных приложениях, системах и вообще в разработках в целом.
Если коротко - scalability это характеристика гибкости арихтектуры, закладываемой при проектировании, а high-load характеристика системы определённой архитектуры под нагрузкой.

В чём разница терминов Scalability и High-Load?

Чтобы лучше понять я приведу "атомарный" аппаратный пример, не касаясь программной части систем - все сегодняшние микроархитектуры процессоров раньше были большими ЭВМ.

Представьте себе картинку, "die circuit" (https://xn--r1a.website/technologique/773) - микропроцессорный чип и его ядро.
Это VLSI или СБИС - микросхема сверхвысокой степени интеграции компонентов (logic gate array).
Она имеет масштабируемую архитектуру для дальнейшего её развития, проектирование которой чаще всего автоматизируется на языке описания аппаратных компонентов - VHDL, VHSIC (Very High Speed Integrated Circuit) Hardware Description Language.
С основе архитектуры современных микропроцессоров лежит конвейер (pipeline), который может быть загружен исполнением инструкций (линейным или с предсказанием ветвлений и распараллеливанием потоков по ядрам), либо простаивать в тактах ожидания загрузки кода и данных (такты простоя конвейера).
Полная загрузка микропроцессора конвейерной архитектуры и его конвейера исполнением кода - это нагрузка потока исполнения, иначе это микропрототип нагруженной (High-Load) системы.
А теперь вспомните картинку "die circuit" и подумайте в чём отличие архитектуры от потоковой нагрузки на неё - в этом разница Scalability и High-Load.
Теперь вспоминайте эту картинку каждый раз для корректоного использования терминологии, как в ангийском, так и в русском языках.

Масштабируемость характерна не только для server-side back-end, но и для client-side front-end приложений в клиент-серверной архитектуре, не только для железа, но и для всех типов сложных приложений, требующих разделения на компоненты и использующих архитектурные шаблоны при проектировании.

В client-side front-end SPA, scalability - это характеристика гибкости оптимизации архитектуры приложения для дальнейшего его роста и развития, и для оптимизации скорости работы интерфейса и расхода памяти браузерным движком.

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

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

Cравните компонентную архитектуру SPA приложений на React (которую проектируете вы сами) c фронт-энд фреймворками предлагающими каркас архитектуры - MVC (Angular), MVVM (Ember), MVP (Backbone), и т.д.
Главное преимущество React это гибкость разрабатываемой архитектуры каждого SPA приложения, отсюда и их масштабируемость (scalability).
Эти же концепции, свободно проектируемой масштабируемой архитектуры SPA приложений и интерфейсов, продвигают Vue.js и Polymer.
Поэтому React.js, Vue.js и Polymer скорее библиотеки, чем фреймворки - пропагандируется DRY, повторное использование кода, но не каркас архитектуры.

https://youtu.be/M5WySjinAT4

@technologique/885