Technologique
660 subscribers
143 photos
3 videos
42 files
945 links
Deeply involved developers about various aspects, tendencies & conceptions of programming technologies, FLOSS, Linux, security, cloud infrastructures & DevOps practices, distributed systems, data warehousing & analysis, DL/ML, web3, etc.
Author: @andrcmdr
Download Telegram
Quality Feedback
В интерфейсе доступен вывод аудиопотока на Bluetooth гарнитуру
Можно даже самому себе позвонить и не дозвониться! 😆😂
Автообновление бета версии приложения клиента Telegram
Technologique
TMessagesProj-fat-debug.apk
Два апдейта за один день!
Тестирование идёт очень активно, все баги фиксят оперативно - вчера у меня на 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
Если вы не можете принять участие в трансляции, вам на почту будут высланы все материалы лекции.
Запись трансляции сегодняшнего запуска ракеты-носителя 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://t.me/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.
Roman Kononov
https://stackoverflow.com/research/developer-survey-2016
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://t.me/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
Technologique
https://www.youtube.com/watch?v=uCaYkUmdtPw Yehuda Katz (https://twitter.com/@wycats) - автор пакетного менеджера и сборщика проектов Cargo (https://crates.io) для экосистемы пакетов языка Rust, фреймворка Ember.js, шаблонизатора Handlebars.js и других многих…
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) и без применения кластерной распределённой компиляции (распределённых компиляторных фабрик на кластерных фермах).
Британский энтузиаст NODE собрал весьма интересный портативный компьютер Zero Terminal на базе Raspberry Pi Zero W.

Для сборки помимо одноплатного компьютера Zero W (W - модификация с беспроводным контроллером wifi/bluetooth) он использовал чехол слайдер с Bluetooth клавиатурой, 3.5" дисплей и батарею на 1.5 Ah, поместив всю аппаратную часть в корпусе, распечатанном на 3D принтере, с отверстиями для стандартных разъёмов (Mini HDMI, USB, Micro SD) одноплатного компьютера.

У меня этот девайс вызвал ностальгию по временам Nokia N900. 😁

https://youtu.be/YWlZ3B_hq_g

https://n-o-d-e.net/zeroterminal.html

Ещё пара интересных разработок автора:
https://youtu.be/hqG8ivP0RkQ

https://youtu.be/aZc5gUKcRZA

https://youtu.be/NMkhRK2lV0E


#DIY
Technologique
Вчера я писал про проект Ruby+OMR и что не вижу особого смысла переделывать существующие Ruby и Python для ускорения исполнения выдаваемого их интерпретаторами кода - они и так сами по себе как языки достаточно хороши, а попытки как-то встроить динамические…
Нагрузочное тестирование производительности и многопоточности в языках пограммирования и application серверах приложений при обработке http запросов.

https://github.com/costajob/app-servers#results

Crystal, Rust и Go себя показали очень хорошо по всем параметрам - максимальным rps, минимальным задержкам ответа, многопоточности и главное, минимальному расходу памяти.
Но в продакшн системах у Go и Crystal memory footprint будет выше, чем у Rust, из-за наличия GC (на личном опыте).
Nim полностью загрузил на 100% одно ядро, отработал в один поток асинхронно, с не очень высоким rps и высокими максимальными задержками ответов, но минимальным расходом памяти.
Crystal развивается быстрее Nim.
В Cystal уже с версии 0.21 есть CSP многопоточность, подобная модели многопоточности Go - thread-pool с fibers/green threads, управляемые через каналы, и M:N mapping'ом на системные треды через minimal GC runtime - и GC с минимальными latency при подсчёте указателей и сборке мусора.

https://crystal-lang.org/docs/guides/concurrency.html

https://crystal-lang.org/2017/02/24/state-of-crystal-at-0.21.html

Веб-фреймворк Kemal уже использует встроенную в Crystal CSP многопоточность.

https://twitter.com/sdogruyol/status/833369972919382019

В этом году проекту языка Crystal исполняется пять лет и к концу года планируется довести его до релизной версии 1.0.

https://crystal-lang.org/2016/12/29/crystal-new-year-resolutions-for-2017-1-0.html

https://github.com/crystal-lang/crystal/wiki/Roadmap

Nim пока что далеко не production ready - язык отличный с обширной stdlib, но разработка движется крайне медленно.
https://youtu.be/EI-tGVFg7PU?t=42m30s

https://youtu.be/bqUIX3Z4r3k?t=58m25s

Технология вертикальной посадки многоразовых ракет есть не только у SpaceX, но и у компании Blue Origin Джеффа Безоса (основателя и владельца компании Amazon).
Но их ракеты New Shepard значительно меньше по длине и массе, чем Falcon-9, а полёты пока суборбитальные со спуском ракеты с малых высот (~100 km).
Но у ракеты и капсулы New Shepard есть свои преимущества. Двигатели BE-3 ракеты New Shepard работают на смеси жидкого водорода и жидкого кислорода (окислитель для поддержания горения в безкислородной среде), что обеспечивает очень чистое горение в атмосфере Земли (см. видео старта) и бОльшую экологичность выбросов продуктов горения.
Такая же топливная смесь использовалась в центральном разгонном блоке системы Space Shuttle.
Сама же капсула имеет механизм с возможностью экстренного отделения от ракеты на любой высоте для спасения экипажа при чрезвычайной или аварийной ситуации с разгонным блоком первой ступени ракеты.

https://youtu.be/bqUIX3Z4r3k?t=52m10s

https://youtu.be/3r6r0eglKPo

https://youtu.be/N5i-f-D_A-M

https://youtu.be/TgjIYVUfkE4

Нужно отметить, что система New Shepard создавалась для вывода экипажа на околоземную орбиту и его доставки на МКС.
Для вывода спутников и доставки полезных грузов на/с МКС будет использоваться другая модификация капсулы и ракета New Glenn.

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

#Space