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

Так мы нашли проект Золотоева Андрея. Гусеничную платформу для исследовательского робота.


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

Экосистема Rust еще не до конца устоялась. В ней часто появляются новые библиотеки, которые заметно лучше предшественников, а ранее популярные фреймворки устаревают. Именно это произошло с веб-фреймворком Iron, который мы использовали при разработке Exonum.

В качестве замены Iron был выбран actix-web. Дальше я расскажу, как мы портировали существующий код на новое решение, используя приемы обобщённого программирования.

Сегодня поговорим об оптимизации кода, который реализует муравьиный алгоритм нахождения оптимальных путей на графах. Узкие места в программе будем искать с помощью Intel VTune Amplifier XE 2016 Update 2, а оптимизировать с использованием MPI, OpenMP и библиотеки Intel Threading Building Blocks.



Наша цель заключается в том, чтобы добиться эффективной работы программы на компьютере с четырьмя процессорами Intel Xeon E7-8890 v4. Система оснащена 512 Гб оперативной памяти, на ней установлена Linux 3.10.0-327.el7.x86_64, код компилировался с помощью Intel Parallel Studio XE 2016 U2.

“Absolute statements are the root of all evil.
The key is balance. There are no answers, only questions.”
????

Автор статьи: zolkko.

Оптимизации

Когда говорят про оптимизацию в контексте ПО, часто подразумевают оптимизацию производительности программиста и/или оптимизацию самого ПО.

Исходя из YAGNI-принципа, Python позволяет программисту сосредоточиться на реализации ПО, избавив его от необходимости заботиться о низкоуровневых вещах: регионах памяти, в которых выделяются объекты, освобождении памяти, соглашениях о вызовах.

На обратную проблему в одной из его лекций о Haskell указал Саймон Джонс. У него был слайд со стрелкой, закрашенной градиентом. В начале было написано “no types”, посередине — “Haskell”, в конце — “Coq”. Указав на Coq, он сказал: “This stresses power over usability. Right?! You need a PhD here!”[1]. Несмотря на то, что это была шутка, мантра Python — одна из любимых программистами особенностей этого языка. По моему опыту, это то, что позволяет выпускать готовый продукт несколько быстрее.

Предлагаю вашему вниманию перевод статьи "Neon: Node + Rust".

Javascript программистам, которых заинтриговала rust-овская тема бесстрашного программирования (сделать системное [низкоуровневое] программирование безопасным и прикольным), но при этом ждущих вдохновений или волшебных пендалей — их есть у меня! Я тут поработал немного над Neon — набором API и тулзов, которые делают реально легким процесс написания нативных расширений под Node на Rust.

TL;DR:

• Neon — это API для создания быстрых, надежных нативных расширений Node на Rust
• Neon позволяет использовать параллелизм Rust-а с гарантированной потокобезопасностью
• Neon-cli позволяет легко и непринужденно создавать Neon проект и дает легкий старт… и наконец...
• проекту требуется помощь!

Несколько недель назад я наткнулся на сравнительный анализ Rust, D и Go от Андрея Александреску. Андрей, уважаемый член сообщества C++ и главный разработчик языка программирования D, нанес Rust сокрушительный удар под конец своего повествования, высказав нечто, что выглядит довольно проницательным наблюдением:

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

После нескольких встреч с Андреем, увидев некоторые из его выступлений, я убедился, что он любит подшучивать. Тем не менее, давайте проглотим наживку. Эта шутка смешная только потому, что она выглядит смешной, или может быть потому, что в ней только доля шутки?

От переводчика. Позвольте представить на суд хабрасообщества перевод части документации о браузерном движке Servo. Этот движок разрабатывается сообществом Mozilla на языке Rust, и является, пожалуй, самым большим активным проектом на этом языке. В этом документе рассказывается об архитектуре движка, как разработчики используют Rust совместно с C++ и с какими трудностями они столкнулись при разработке. Оригинал доступен в wiki проекта на github.

Это очень поверхностный обзор архитектуры Servo. Servo остаётся прототипом, и некоторые части архитектуры ещё не представлены в виде кода. Некоторые важные аспекты системы ещё не были подробно рассмотрены.

Обзор и цели

Немного о ProDBG от переводчика и автора проекта

ProDBG — это новый дебаггер, который сейчас разрабатывает Daniel Collin. Одна из целей проекта — поддержка множества архитектур и операционных систем. Изначально пишется на C/C++, заложена поддержка плагинов. На данный момент находится на ранней стадии разработки, и в основном нацелен на MacOS. Далее передаю слово автору поста.

---

Как известно тем из вас, кто читает меня в Твиттере, я не очень люблю C++. У него свои обычные проблемы с заголовочными файлами, отстойными шаблонами, и так далее. И большая проблема — найти альтернативу. Я рассматривал вариант перейти на C#, но сделать так, чтобы он хорошо заработал на всех платформах, кажется очень сложной задачей (например, на данный момент поддержка x86 на Mac практически отсутствует). К тому же некоторым людям такой выбор будет не по вкусу.

Мне нравится (Common) Lisp. Я восхищаюсь устройством его макросов, в нём есть та элегантность, которая встречается не во всех языках. Однако он кажется каким-то чужеродным для многих людей, так что вкладывать в проект станет намного сложнее. К тому же я хочу по возможности использовать язык без сборщика мусора, и хотя Lisp можно сильно ускорить, сделать это не так уж просто.

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

2015

Прежде чем мы поговорим о будущем, вот несколько цифр за прошлый год:

В 2015 году силами сообщества Rust:

• Создано 331 предложение по улучшению языка (RFC)
  • из которых 161 было принято и влито в основной репозиторий
  • всего 120 человек подало RFC, из них 6 человек создало 10 и более, Alex Crichton создал 23 RFC
• Создано 559 задач по улучшению RFC
• Прислано и влито в репозиторий Rust 4630 Pull-запросов
  • авторами которых является 831 человек, из них 91 создали больше 10 запросов, 446 человек создали только один, а Steve Klabnik был автором 551 pull-запроса
• Создано 4710 задач
  • из которых 1611 еще открыты
  • авторами которых является 1319 человек, из которых 79 создали больше 10, а Alex Crichton открыл всего 159 задач
• Выпущено шесть стабильных релизов Rust (1.0 – 1.5)
• Поддерживается стабильность Rust – 96% пакетов, которые компилировались на 1.0, по прежнему компилируются с использованием версии 1.5

Поводом для написания статьи стала публикация исходного кода языка Swift — мне стало интересно поближе познакомиться с ним. В глаза сразу же бросилась схожесть синтаксиса с другим молодым языком программирования под названием Rust, к тому же за схожими синтаксическими конструкциями просматривалась и схожая область применения этих языков. Оба языка имеют сильную статическую типизацию с локальным выводом типов, оба компилируются напрямую в машинный код. И тот и другой языки впитали в себя многие приемы из мира функционального программирования. И Swift и Rust имеют средства для запуска кода, написанного на C, что позволяет без труда писать обертки над огромным количеством библиотек. Оба языка рассматриваются как замена существующим системным языкам типа C, C++, ObjectiveC. Так что же в них общего, а что различается?

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

Несказанно рад, что читателям понравилась предыдущая статья. Сразу сделаю оговорку — просто рассказать о таком ёмком понятии как тензор не получится — велик объем информации. Могу обещать, что к концу цикла мозаика сложится.

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

Тензор — математический объект, не изменяющийся при изменении системы координат, представленный набором >своих компонент и правилом преобразования компонент при смене базиса.

Скалярное произведение — это хорошо. Но как же быть с остальными операциями? Как они связываются с геометрией пространства и представимы ли в тензорном виде? Разумеется представимы, ведь векторы — это… тензоры! И скаляры — это тоже тензоры. Привычные нам математические объекты лишь частные примеры более общего понятия, коим является тензор.

Вот об этом мы и поговорим под катом.

Немного о мотивах

Доброго времени суток, уважаемые хабровчане. Некоторое время назад, я познакомился с библиотекой RivetsJS. Она мне пришлась по вкусу, хотя содержит в себе только инструменты для data-binding. Сразу хочу сказать, что даже не собираюсь спорить, для этих вещей есть замечательные AngularJS и др. фреймворки, но лично я не вижу смысла подключать такой мощный инструмент, как Angular, если мне требуется только малая толика его возможности. Поэтому, для этих целей, я выбрал именно RivetsJS. И вот, воодушевленный идеей перевести его документацию на русский, я пишу эту статью. Мотив простой — рассказать об этой библиотеке, и я не нашел ничего лучше, чем просто перевести её документацию, которая, возможно только на мой взгляд, написана на немного «ломаном» английском. Итак, поехали.

P.S. Сразу попрошу прощения, это мой первый перевод, возможно я не супер-пупер переводчик. Если вам что-то покажется нелепым или вы найдете ошибку — прошу сообщить об этом мне, я сразу же её исправлю. Заранее, спасибо.

Документация RivetsJS

Гайд

• Установка
• Использование
• Биндинг
• Форматеры
• Компоненты
• Адаптер
• Свойства
• Итерации биндинга

Справочник

• text
• html
• show
• hide
• enabled
• disabled
• if
• unless
• value
• checked
• unchecked
• on-[event]
• each-[item]