Программирование *

Часто так бывает, что есть хорошая библиотека, а чего-то в ней не хватает, каких-нибудь перламутровых пуговиц. Так и мне с Activiti, довольно популярным движком бизнес-процесcов с поддержкой BPMN 2.0, ценным своей Java-нативностью. Не вдаваясь в подробности внутреннего устройства этого продукта с открытым исходным кодом, достаточно очевидно, что в своей работе он использует разнообразные данные: метаданные определений бизнес-процессов, данные экземпляров и исторические данные. Для их хранения Activiti использует СУБД, позволяя выбрать из DB2, H2, Oracle, MySQL, MS SQL и PostgreSQL. Этот движок весьма неплох, и используется не только для маленьких поделок. Возможно, вопрос о поддержке кэширования обращений к БД в этом продукте возник не только у меня. Как минимум единожды он задавался разработчикам, которые на него ответили в том смысле, что метаданные кэшируются, а для остальных данных большого смысла в этом нет и это не просто. В принципе, про отсутствие большого смысла согласиться можно — данные конкретного экземпляра или его исторические данные с небольшой вероятностью могут повторно понадобиться. Но сценарий, когда такое всё-таки случится, тоже возможен. Например, если у нас кластер серверов Activiti с общей базой. В общем, человек с пытливым умом вполне может захотеть иметь приличный кэш в Activiti. Например, использовать в этом качестве Apache Ignite.

Под катом пример решения этой проблемы, код выложен на GitHub.

Если вы — программист, то вам приходится учиться очень много. Вспомните свой первый "Hello, World!". У меня это было в четвертом классе. Мы изучали С++, и наш учитель написал программу от руки на доске. Мы использовали Turbo C++, копировали ее на дискету, чтобы экспериментировать дома.

В том время я не думал, что Turbo C++ это редактор. Я не думал о нем как об IDE. Для меня Turbo C++ был языком C++. Это был единственный известный мне способ программировать. Я не знал, что значит "компиляция", не знал, зачем нужен #include  в начале файла. Я не понимал, что делает main и что printf может принимать любое количество аргументов. Я просто скопировал программу с доски, нажал Run и увидел вывод на экране.

Это круто. Так и нужно учить программированию. Нужно делать что-то до того когда еще не понимаешь, как это работает. Некоторое время нужно умышленно быть в неведении о деталях. Детали отвлекают.

Всем привет! До RailsClub 2016 осталось чуть больше месяца. Самое время регистрироваться!

Мы уже рассказали, что в этом году к нам приедут выступать Юкихиро Мацумото, Акира Мацуда, Шон Гриффин, Стив Клабник и Зак Бригс. А сегодня мы начинаем публиковать традиционные интервью с нашими докладчиками. В этом году сделать разговор со спикерами интересным нам помогает подкаст RubyNoName.

Ребята записали первый разговор, с Алексеем Тактаровым, фронтенд(!) разработчиком из These Guys. Алексей специализируется на разработке single-page приложений, пропагандирует чистоту и простоту дизайна и кода. Принимал участие в проектах Смартомато, ficus.io и resume.io, работал со Злыми марсианами; его основные инструменты — Ember.js, React и Ruby on Rails. В свободное время занимается южной около-фронтенд тусовкой Code Hipsters.

Мы впервые ставим в программу бэкенд конференции доклад про фронт. Никуда без него в 2016 году :). Лешин доклад называется "Дайте фронтенду в Rails второй шанс!".

Два года назад в OpenJDK был создан новый проект под кодовым названием «Panama». Основным направлением исследований анонсировалось создание нового интерфейса для работы с платформозависимыми библиотеками и данными вне Java heap’а (off-heap). Но цели проекта шире: исследование механизмов взаимодействия JVM и «внешнего» (не-Java) API.

Владимир Иванов iwanowww — ведущий инженер Oracle, работает в группе разработки виртуальной Java-машины HotSpot. Специализируется на JIT-компиляции и поддержке альтернативных языков на платформе Java. Владимир пришел в Sun Microsystems (приобретена Oracle в 2010) в 2005 году и с того момента поучаствовал в большом количестве проектов, связанных с Java (HotSpot JVM, RTSJ, JavaFX).

JNI 2.0?

— Большая часть проекта Panama — это работа с native библиотеками из Java кода. Как это можно делать сейчас?

— Работать с native кодом в Java можно было всегда. Native методы были еще в первой версии Java, а стандартный интерфейс JNI появился уже в версии 1.1. Но время идет, платформа развивается, требования меняются и, смотря на JNI сейчас, есть понимание, что можно организовать работу с native библиотеками удобнее и эффективнее.

На написание данного поста меня подвигла недавняя публикация этого и вот этого переводов, в которых авторы в интеллигентной форме выражают свое недовольство по поводу того, как O-оценки вычислительной сложности классических, казалось бы, алгоритмов вступили в диссонанс с их практическим опытом разработки. Основным предметом критики послужила модель памяти, в рамках которой эти оценки были получены — она, де, не учитывает особенности иерархической организации по принципу быстродействия, которая имеет место быть в современных вычислительных системах. От чего и произрастают все последующие неприятности. И судя по наблюдаемой реакции благодарных читателей, авторы далеко не одиноки в своем негодовании и желании «наехать» на классиков с их О-большими. Так возможно, действительно стоит отправить на свалку истории выкладки дядек в белых халатах, сделанные ими для ламповых тугодумающих и пышащих жаром машин, и дать дорогу молодым амбициозным моделям, более точно отражающим анатомию современного «железа»?


Давайте разбираться

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

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

1. История первая: воспоминание

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

А ведь самое логичное объяснение — он сам упал. Просто он рос, выбрасывал новые побеги, развивал и наращивал массу. Тянулся к солнцу. Однажды проекция центра тяжести цветка вышла за пределы опоры и он опрокинулся.

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

Вы когда нибудь задумывались, почему вы пишете код на Caché Object Script, а он экспортируется в XML файл?



Так вот, пора меняться. Начиная с выхода новой среды разработки Atelier и версии Caché 2016.2, у вас будет возможность экспортировать и импортировать файлы в формате, в котором вы пишете в студии, так называемый формат UDL (Universal Definition Language). Теперь вы сможете писать код, который не только быстро работает, но еще и приятен глазу в экспортированном виде. Но, возникает другая, не менее важная проблема: если все новые проекты будут находиться в UDL формате, то, кто позаботиться об обратной совместимости?

Когда я узнал, что появился новый язык программирования системного уровня, с производительностью как у С++ и без сборщика мусора, я сразу заинтересовался. Мне нравится решать задачи с помощью языков со сборщиками мусора, вроде C# или JavaScript, но меня постоянно терзала мысль о сырой и грубой мощи С++. Но в С++ так много способов выстрелить себе в ногу и других хорошо известных проблем, что я обычно не решался.

Так что я влез в Rust. И, блин, влез глубоко.

Язык Rust все еще довольно молод, поэтому его экосистема пока находится в стадии начального развития. В некоторых случаях, например, в случае с вебсокетами или сериализацией есть хорошие и популярных решения. В других областях у Rust не все так хорошо. Одна из таких областей это OpenGL GUI, вроде CEGUI или nanogui. Я хотел помочь сообществу и языку, поэтому взялся за портирования nanogui на Rust, с кодом на чистом Rust, без связок с С/C++. Проект можно найти тут.

Обычно, знакомство с Rust начинается с борьбы с идеей borrow-checker. Как и у других программистов, у меня тоже был период, когда я не мог понять, как решить ту или иную проблему. К счастью, есть классное сообщество в #rust-beginners. Его обитатели помогали мне и отвечали на мои дурацкие вопросы. Мне понадобилось несколько недель на то, чтобы почувствовать себя более-менее комфортно в Rust.

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

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



Так прошел PDUG Picnic 2016 — неформальная тусовка для разработчиков, которые на досуге всерьез задумываются о том, безопасен ли код, который они пишут.

Хочу поделиться с сообществом проектом, которым я потихоньку занимаюсь последние несколько месяцев.

Предисловие

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

На Хабре уже был перевод с обзором несколько месяцев назад, но недавно вышел первый релиз-кандидат PHP 7.1, а значит никаких существенных изменений больше не будет и можно сказать, какие точно изменения будут в релизе. Я решил немного оживить сухой “changelog” своим вольным переводом изменений, которые принесет нам новая минорная версия 7.х ветки.

Сервис для управления выездными сотрудниками (field management software) обычно состоит из веб-части, которой пользуются менеджеры в офисе, и мобильного приложения для работников, выезжающих на заказы к клиентам. Сегодня мы расскажем о разработке такого приложения.

Вот уже больше 16 лет JetBrains успешно занимается созданием профессиональных инструментов для программистов.

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

Сегодня мы хотим пригласить вас на мини-конференцию, JetBrains Night Moscow, которая состоится 29 сентября (четверг) в гостинице «Novotel Москва Сити». Цель данного мероприятия — пообщаться вживую. Мы расскажем о некоторых наших продуктах, о том что мы делаем, как и почему.

UPD: тут была ссылка на регистрацию, но теперь она недоступна, мероприятие уже прошло, скоро будет доступно видео, о чем мы отдельно напишем и тут тоже ссылку на него сделаем. Спасибо всем, кто пришел!

UPD 2: а вот и видео.

До встречи!
Команда JetBrains

Одним из широко освещаемых свойств фреймворка java.NIO является неблокируемость, что означает спо­соб­ность к параллельному выполнению операций ввода-вывода и вычислений. Если приложение, запросившее чтение файла, имеет вычислительную задачу, которую можно обработать до получения данных из файла, то становится возможным одновременное выполнение этих операций. В случае отложенной записи, возможностей для параллелизма еще больше, так как при записи, в отличие от чтения, приложение не ожидает поступления данных.

Среди всего разнообразия форматов представления действительных чисел в компьютерной технике особое место отведено формату чисел с плавающей точкой (ЧПТ), который запротоколирован в стандарте IEEE754. Главные достоинства чисел с плавающей точкой, как известно, заключаются в том, что они позволяют производить вычисления в большом диапазоне значений и при этом вычисления организуются инструментарием двоичной арифметики, легко реализуемой на вычислительном устройстве. Однако последнее обстоятельство таит в себе подводные камни, которые являются причиной того, что расчеты, сделанные с использованием этого формата, могут приводить к совершенно непредвиденным результатам.

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

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

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

Еще в 2011 году нас спрашивали, зачем вводить номер телефона для выставления счета на стороне партнера, подключенного к QIWI? Мы давно хотели облегчить интеграцию API, но раньше сделать это было достаточно сложно. Что же изменилось в 2016? Сейчас расскажем, а также поэкспериментируем с хабровским R&D голосованием.

Есть у Майкрософта такая не очень известная вещь, как Service Bus for Windows Server. И так случилось, что в нескольких проектах подряд довелось с ней поработать. В итоге получилось собрать небольшой набор подводных камней, встречавшихся в проектах чаще других. Чем и делюсь.

В первой и второй части была рассмотрен пример создания системы управления на основе логики «конечных автоматов» и создана модель регулятора нагревателя.

В этой части будет показано как из SimInTech сгенерировать код Си, реализующий программу управления на основе логики «конечных автоматов», а потом отдалить в MS Visual Studio 2015 совместно с моделью объекта в SimInTech.

Уважаемые пользователи Хабрасообщества, спешу вас поздравить с этим замечательным 256 днем года!

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