Будучи программистом 1С, мне часто приходится использовать классы .Net через различные прослойки.

Использование сборок .Net через обертку реализующую IReflect
Для подключения .NET сборок используется «CLR Hosting API»
1C.Net: Предприятие – пример коммерческого успеха .Net-решений в России
Как вызвать метод из C# в 1С?

Но все они используют в той или иной степени COM. С появлением .Net Core стало возможным использование сборок .Net и на любой оси отличной от Windows.

На просторах интернета было найдено решение: Hosting .NET Core Clr in your own process и simpleCoreCLRHost и
initializeCoreCLR createDelegate и
unixinterface

Суть подключения заключается в загрузке библиотеки coreclr.dll, получения нужных интерфейсов и запуск CLR Runtime Host.

Привет, Хабр! В этом цикле статей я планирую рассказать о том, как можно организовать сбор и передачу данных с помощью одного из инструментов Hadoop — Apache Flume.

Язык программирования Nim (ранее именовался Nimrod) — захватывающий! В то время как официальная документация с примерами плавно знакомит с языком, я хочу быстро показать вам что можно сделать с Nim, что было бы труднее или невозможно сделать на других языках.

Я открыл для себя Nim, когда искал правильный инструмент для написания игры, HoorRace, преемник моей текущей DDNet игры/мода Teeworlds.

(прим. пер. На синтаксис Nim имели влияние Modula 3, Delphi, Ada, C++, Python, Lisp, Oberon.)

Запускаем!

Да, эта часть всё ещё не захватывает, но просто следите за продолжением поста:

for i in 0..10:
  echo "Hello World"[0..i]

На волне популярности Docker на Хабре, после участия в некоторых дискуссиях в комментариях относительно Docker, и в связи с недавней необходимостью настроить централизованную авторизацию для кластера Linux машин, я решил написать небольшую заметку. Здесь будет показан яркий, на мой взгляд, пример применения Docker'a для небольшой частной задачи.

Вот так, кстати, выглядит FreeIPA WebUI (официальное демо) (кликабельно):



Какие задачи я хотел решить при помощи FreeIPA:

1. Иметь возможность создавать/изменять/удалять акаунты пользователей централизовано, а не на каждом отдельном сервере
2. Централизованные плавила для sudo
3. В последствии мы подключим к этой системе ещё и VPN авторизацию, а потом может и другие внутриофисные сервисы

Да, скорее всего FreeIPA в нашем случае это выстрел пушкой по воробьям, но с другой стороны — альтернатив что-то не видно. Я рассматривал такие варианты: NIS (по-моему он уже давно должен отправиться на отдых), OpenLDAP +… +… (не очень дружелюбно, да и FreeIPA в итоге под собой имеет LDAP, только нам не приходится с ним иметь дело напрямую), тут перечень заканчивается, я не нашёл ничего больше.

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

Предисловие.

А его и не будет, что бы не спамить, всё описано в «послесловии». Обязательно его прочтите, что бы не было диссонанса с более ранними комментариями.
Статью пришлось переделать 01.03.2017 и она отличается от первоначальной.

Achtung! Не стоит рассматривать эту статью, как некий научный труд или претензия на нобелевку.
Тем более:

«… И нет ничего нового под солнцем»

(Экклизиаст 1:9).
О топливах, ракетах ракетных двигателях писалось, пишут и будут писать.

Одной из первых работ по топливам ЖРД можно считать книгу В.П.Глушко «Жидкое топливо для реактивных двигателей», изданную в 1936 г.


Для меня тема показалась интересной, связанной с моей бывшей специальностью и учёбой в ВУЗе, тем паче «приволок» её мой младший отпрыск «шеф давай замесим, что нить такое и запустим, а если лень, то мы сами сообразим». Видимо лавры Лин Индастриал» не дают покоя.

Так хочется правильно взорвать свой ракетный двигатель.

«Соображать» будем вместе, под строгим родительским контролем.

«Ключ на старт»… «Поехали»! (Ю.А. Гагарин& С.П. Королёв)


Какой бы тип РД (схема, характер процесса) не применялся в ракетной технике его целевое предназначение: создание тяги (силы), путём преобразования исходной энергии, запасённой в РТ в кинетическую энергию (Ек) реактивной струи рабочего тела.
Ек реактивной струи в РД преобразуются разные виды энергии (химическая, ядерная, электрическая).
Для химических двигателей топливо можно разделить по фазовому состоянию: газообразное, жидкое, твёрдое, смешанное.

Часть №1-топлива для ЖРД или жидкие ракетные топлива.

Все плюсы docker для приложения, уже много раз описывали на Хабре, как и его архитектуру.

Мы же решим практическую задачу по упаковке jvm приложения и получим контейнер с миниатюрным Linux, JDK и нашим приложением, который опубликуем на hub.docker.com и сможем запускать где угодно.

Прочитав статью об упаковке JVM приложения в Docker, я остался в смятении. Я, как и любой разработчик, хочу чтоб мои волосы развевались на ветру контейнер собирался за одну команду, сразу, без лишних телодвижений. Чтобы конфигурация проекта и сборки была собрана в одном файле, и чтобы не было зависимостей от внешних систем.



Далее последует альтернативный способ сборки Java-приложений в Docker контейнер используя Maven.

В 2012 году пользователь с ником rovo89 на комьюнити XDA опубликовал исходные коды и готовый к использованию фреймворк, упрощающий кастомизацию прошивок, с подробной инструкцией и примерами, предложив альтернативу традицоинному, на тот момент, способу (деодексирование→ дизассемблирование → декомпиляция → рекомпиляция → тестирование → загрузка патчей в телефон): Часть 1, Часть 2, Часть 3, Часть 4

Он предложил использовать отдельные модули, которые можно изменять фактически налету, не вмешиваясь в исходный код прошивки или отдельных ее компонентов. Но авторитетные разработчики хором ответили: "Неа… никому это не нужно"

Rovo не забросил свое детище, а продолжил развитие. Когда в 2013-ом году вышла версия KitKat, все то же сообщество именитых девелоперов ответило: "Неа, это слишком опасно… хотя..."

Тем временем Google принял решение выпускать новую версию операционной системы ежегодно. Разумеется, стало накладно кастомизировать прошивки: не успеваешь сделать одну, как появляется новая версия ОС. Так в 2014-ом выходит версия Lollipop и разработчики наконец обращают внимание на фреймфорк с мыслями: "Может все же стоит посмотреть что это такое? Выглядит многообещающим".

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

Сейчас конец февраля 2017-го. Xposed под Nougat все еще не доступен, а толпы страждущих разработчиков и пользователей то и дело открывают темы под тип "Xposed не работает! Он мне нужен! Rovo, пожалуйста!"

Сегодня я расскажу об Xposed Framework.

В прошлой статье мы познакомились с одной из самых интересных возможностей языка Rust — процедурными макросами.

Как и обещал, сегодня я расскажу о том, как писать такие макросы самостоятельно и в чем их принципиальное отличие от печально известных макросов препроцессора в C/C++.

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

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

Наверно, в мире данных нет подобного феномена настолько неоднозначного понимания того, что же такое Hadoop. Ни один подобный продукт не окутан таким большим количеством мифов, легенд, а главное непонимания со стороны пользователей. Не менее загадочным и противоречивым является термин "Big Data", который иногда хочется писать желтым шрифтом(спасибо маркетологам), а произносить с особым пафосом. Об этих двух понятиях — Hadoop и Big Data я бы хотел поделиться с сообществом, а возможно и развести небольшой холивар.
Возможно статья кого-то обидит, кого-то улыбнет, но я надеюсь, что не оставит никого равнодушным.

Демонстрация Hadoop пользователям

Что такое CoreOS?

CoreOS — это операционная система на базе Linux для построения легко и гибко масштабируемых кластеров. CoreOS — минималистичный дистрибутив. Установочный ISO образ объемом всего в 136Мб, а в памяти на конечной машине после установки и запуска она займет всего 114Мб. CoreOS основан на ChromeOS, который в свою очередь базируется на Gentoo.

Фактически, CoreOS можно условно можно разделить на следующие части:

• Systemd — управляет локальными службами на машинах кластера
• Docker — обеспечивает изоляцию служб, но его использование, в принципе, не обязательно
• Etcd — распределенно хранит конфигурацию кластера
• Fleet — обеспечивает распределенное управление службами («надстройка» над systemd)

CoreOS умеет запускать службы systemd на нужных машинах кластера, следить за их состоянием, хранить их конфигурацию.

Что здесь интересного:

Обзорная статья о Consul (http://consul.io) — системе для поддержания обнаружения сервисов и распределенного хранилища ключ-значение. Кроме самого Consul, рассмотрим Consul-Template — средство для управления конфигурациями сервисов автоматически отражающее изменения в топологии. Статья будет интересна DevOps инженерам, системным архитекторам, тим-лидам проектов и прочим интересующимся микросервисными архитектурами.

disclaimer Так получилось, что последний месяц я разбираюсь с ZooKeeper, и у меня возникло желание систематизировать то, что я узнал, собственно пост об этом, а не о сервисе блокировок, как можно было подумать исходя из названия. Поехали!

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

От распределенного сервиса блокировок разумно требовать:

1. работоспособность в условиях моргания сети (первое правило распределенных систем — никому не говорить о распределенных системах сеть ненадежна)
2. отсутствие единой точки отказа

Создать подобный сервис нам поможет ZooKeeper

В википедии написано, что ZooKeeper — распределенный сервис конфигурирования и синхронизации, не знаю как вам, но мне данное определение мало что раскрывает. Оглядываясь на свой опыт, могу дать альтернативное определение ZooKeeper, это распределенное key/value хранилище со следующими свойствами:

• пространство ключей образует дерево (иерархию подобную файловой системе)
• значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode
• между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии
• возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру
• все данные должны помещаться в память
• устойчивость к смерти некритического кол-ва узлов кластера

Привет! Меня зовут Андрей Степачев. В конце прошлого года я выступил перед коллегами с небольшим рассказом о том, что такое ZooKeeper, и как его можно использовать. Доклад изначально был рассчитан на широкий круг аудитории и может быть полезен и разработчикам, и админам, желающим разобраться, как все это примерно работает.

Начнем, пожалуй, с истории появления ZooKeeper. Сначала, как известно, в Google написали сервис Chubby для управления своими серверами и их конфигурацией. Заодно решили задачу с распределенными блокировками. Но у Chubby была одна особенность: для захвата локов необходимо открывать объект, потом закрывать. От этого страдала производительность. В Yahoo посчитали, что им нужен инструмент, при помощи которого они могли бы строить различные системы для конфигураций своих кластеров. Именно в этом основная цель ZooKeeper — хранение и управление конфигурациями определенных систем, а локи получились как побочный продукт. В итоге вся эта система была создана для построения различных примитивных синхронизаций клиентским кодом. В самом ZooKeeper явных понятий подобных очередям нет, все это реализуется на стороне клиентских библиотек.

Стоит отметить, что протокол, используемый Zookeeper называется ZAB, ссылки на описания протокола приведены в конце статьи.

Ежедневно Яндекс обрабатывает входящий поток из миллионов писем и файлов. Их количество постоянно и непрерывно увеличивается. При этом уровень входящей нагрузки неравномерный, он сильно зависит от времени суток и дня недели. Кроме того, периодически случаются ботнет-атаки.

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



Обработка может занимать разное время: от миллисекунд, требуемых для сохранения письма, до нескольких десятков секунд, затрачиваемых, например, на извлечение текста из фотографий.

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

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

Периодически у меня появляются задачи обработать большое количество файлов. Обычно это конвертирование из одного формата в другой: XSLT-трансформация, парсинг, конвертация картинок или видео. Для решения этих проблем я приспособил фреймворк GridGain In-Memory Data Fabric. Он дает возможность делать distributed computing, MapReduce, распределенные кэши и очереди, распределенную файловую систему в памяти, перемещение кода к данным, job stealing, ускорители для Hadoop и многие другие модные ныне вещи. И все это легко и под разные операционки. Вы легко можете все это пощупать под виндовс.

Попробую рассказать о своем опыте использования на примере простенькой задачи.

Предыстория

Уже довольно давно я работаю в проекте, в котором используется система сборки Maven. По началу, когда проект был ещё не таких размеров как сейчас, время его полной компиляции было относительно разумным и не вызывало нареканий. Но со временем код разросся, количество подпроектов резко увеличилось и среднее время полной компиляции выросло до 6 — 10 минут. Что служило постоянным источником упрёков со стороны разработчиков.

Следует так же отметить. что мы не использовали параллельную сборку, т.к. это регулярно вызывало различные проблемы. То артефакты в локальном хранилище побьются, то просто соберёт не в том порядке и в финальный WAR артефакт попадёт старый, неперекомпилированный код. Конечно некоторые разработчики использовали параллельную сборку на свой страх и риск. Но рано или поздно попадали в ситуацию, когда не могли разобраться что происходит. И простая перекомпиляция в один поток сразу помогала.

Так продолжалось довольно долго, пока я не наткнулся на довольно любопытный сайт компании Takari, на котором предлагаются способы по усовершенствованию методов работы с Maven.

Самыми интересными там являются три вещи:

• Concurrent Safe Local Repository
• Takari Smart Builder
• The Takari Lifecycle

Так же на GitHub у них выложен Maven Wrapper (аналог враппера из Gradle).

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

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

Вот первичный анонс о внедрении нового сборщика, датированный августом 2015-го:

В Go создаётся сборщик мусора (GC) не только для 2015 года, но и для 2025-го, и ещё дальше… Сборщик в Go 1.5 возвещает о наступлении будущего, в котором паузы на сборку больше не являются барьером для перехода на безопасный язык. Это будущее, в котором приложения без труда масштабируются вместе с оборудованием, и по мере роста мощности оборудования сборщик мусора больше не является сдерживающим фактором при создании более качественного, масштабируемого ПО. Go — хороший язык для использования как минимум в ближайший десяток лет.

Создатели утверждают, что они не просто решили проблему пауз на сборку мусора, а пошли куда дальше:

Одним из высокоуровневых способов решения проблем с производительностью является добавление GC-настроек (knobs), по одной на каждую проблему. Программист может менять их, подбирая наилучшую комбинацию для своего приложения. Недостатком этого подхода является то, что при внедрении каждый год одной-двух новых настроек через десять лет придётся законодательно регулировать труд людей, которые будут менять эти настройки. Go не пошёл по этому пути. Вместо кучи настроек мы оставили одну и назвали её GOGC.

Более того, освободившись от бремени поддержки десятков настроек, разработчики могут сосредоточиться на улучшении runtime’а приложения.

Не сомневаюсь, что многие пользователи Go были просто счастливы получить новый подход к runtime’у в Go. Но у меня есть претензии к этим заявлениям: они выглядят как недостоверный маркетинговый булшит. А поскольку они раз за разом воспроизводятся в Сети, пришло время подробно с ними разобраться.