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

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

Yehuda Katz (https://twitter.com/@wycats) - автор пакетного менеджера и сборщика проектов Cargo (https://crates.io) для экосистемы пакетов языка Rust, фреймворка Ember.js, шаблонизатора Handlebars.js и других многих проектов (более подробно - http://yehudakatz.com/projects/), а также Core Team Member проектов библиотеки jQuery, фреймворка Ruby on Rails и самого проекта языка Rust.

На мини-конференции компании Code Genius он очень толково рассказал о концепциях языка Rust. 👍
Очень интересно про scope based RAII (automatic destructors) для автоматического управления памятью без GC, про borrow ownership checker и его связь с actor based concurrency, и про создание примесей (mixins) через композицию трейтов в Rust.

StackOverflow опубликовали результаты исследования опроса разработчиков на 2017 год. Опрос проводился с 12 января по 6 февраля 2017 года.

http://stackoverflow.com/insights/survey/2017

https://stackoverflow.blog/2017/03/22/now-live-stack-overflow-developer-survey-2017-results/

Исследования предыдущих лет можно найти на странице http://stackoverflow.com/insights/survey/

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

Всего в исследовании приняли участие 64227 респондентов из 213 стран, из которых были использованы (прошли ценз и были достаточными для корректности статистики) ответы 51392 респондентов.

http://stackoverflow.com/insights/survey/2017#methodology

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

Уже второй год подряд Rust (https://xn--r1a.website/technologique/892) оказывается самым любимым разработчиками языком. 👍

http://stackoverflow.com/insights/survey/2017#technology-most-loved-dreaded-and-wanted-languages

http://stackoverflow.com/insights/survey/2016#technology-most-loved-dreaded-and-wanted

Тем не менее для многих разработчиков Rust остаётся языком выходного дня для pet проектов и в промышленной разработке распространённость Rust пока небольшая.

https://stackoverflow.blog/2017/02/07/what-programming-languages-weekends/

https://medium.com/@hoffa/the-top-weekend-languages-according-to-githubs-code-6022ea2e33e8

http://www.opennet.ru/opennews/art.shtml?num=46033

Некоторые вопросы оказались весьма забавны, например, можно ли использовать шумную клавиатуру (шумную мышь?) в офисе или co-working пространстве? 😆

http://stackoverflow.com/insights/survey/2017#work-can-a-developer-whos-sharing-an-office-use-a-noisy-keyboard

Вспомнился анекдот:
- Коллега, у вас мышь громко щёлкает.
- Коллега, а вам не мешает шум в моей голове при её работе? 😅


#StackSurvey17
#StackSurvey

https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1160-2017-03-16

https://blog.rust-lang.org/2017/03/16/Rust-1.16.html

16 марта был выпущен релиз Rust 1.16.
В сборщик Cargo добавили команду cargo check для проверки корректности кода проекта без его сборки и компиляции.
Сейчас ведётся работа по оптимизации и ускорению условной и раздельной компиляции, для компилятора и его инструментария, сборщика Cargo, что очень сильно ускорит процесс создания скомпилированных исполняемых бинарных файлов даже для очень больших проектов.
Условная компиляция (conditional compilation) в Rust реализована через директивы компилятора (#[cfg], https://doc.rust-lang.org/book/conditional-compilation.html) в исходных текстах.
В сборщике cargo и компиляторе rustc изначально реализована раздельная (модульная) компиляция (separate compilation), на основе проверки изменеий трейтов/интерфейсов (trait) для типов и описаний/имплементаций их реализации (impl) в модулях (mod) крэйтов (crate - контейнер, пакет, библиотека).
Если изменяется интерфейс трейта, поля и методы его имплементации impl, то производится перекомпиляция модуля содержащего эти трейты и имплементации со сборкой модулей в crate контейнер (который можно опубликовать в репозитории пакетов https://crates.io), в ином случае производится сборка уже скомпилированных объектных файлов модулей, без перекомпиляции, что оптимизирует и ускоряет сам процесс компиляции значительно.
Всё это очень похоже на концепции модульной раздельной компиляции в Modula-2 и Oberon-2, а также в OCaml, на котором изначально был написан компилятор Rust до стадии его бутстраппинга.
В Go используется тот же принцип раздельной компиляции для структурного программирования, также взятый из Oberon-2 и Modula-2, что обеспечивает рекордно быструю компиляцию, даже для очень крупных проектов (типа Docker, Juju и Kubernetes) и без применения кластерной распределённой компиляции (распределённых компиляторных фабрик на кластерных фермах).