Здравствуйте. Несколько недель назад я начинал серию переводов статей по изучению OpenGL. Но на 4 статье один хабровчанин заметил, что мои переводы могут нарушать лицензию, по которой распространяются учебные материалы, предоставленные в исходной статье. И действительно, мои переводы нарушали лицензию. Для разрешения этой проблемы я обратился к авторам того набора уроков, но так и не смог добиться нормального ответа. По этой причине я связался с автором другого, не менее (а возможно даже и более) крутого, набора уроков по OpenGL: Joey de Vries. И он дал полное разрешение на перевод его набора уроков. Его уроки гораздо более обширные, чем прошлый набор, поэтому эти переводы растянутся на долго. И я обещаю, будет интересно. Заинтересовавшихся прошу под кат.

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

На счет уроков по Vulkan: к сожалению мне тяжело сейчас написать уроки по данному API по причине скудной видеокарты на данный момент, которая просто не поддерживает Vulkan API, поэтому уроки по данному API будут только после обновления видеокарты.

Вот уже вышло две статьи в потенциально очень длинной серии обзоров распределённой платформы Apache Ignite (первая про настройку и запуск, вторая про построение топологии). Данная статья посвящена попытке подружить Apache Ignite и Spring Boot. Стандартным способом подключения некой библиотеки к Spring Boot является создание для этой технологии «стартера». Несмотря на то, что Spring Boot весьма популярен и на Хабре описывался не единожды, про то, как делать стартеры, вроде бы ещё не писали. Этот досадный пробел я постараюсь закрыть.

Статья посвящена преимущественно Spring Boot'у и Spring Core, так что те, кого тема Apache Ignite не интересует, всё равно могут узнать что-то новое. Код выложен на GitHub, стартера и демо-приложения.

В предыдущих статьях мы несколько раз упоминали о такой проблеме, как перегрузка агентов. Что это такое? Чем это грозит? Как с этим бороться? Обо всем этом мы и поговорим сегодня.

Проблема перегрузки агентов возникает, когда какому-то агенту отсылается больше сообщений, чем он успевает обрабатывать. В результате очереди сообщений постоянно увеличиваются в размерах. Растущие очереди расходуют память. Расход памяти ведет к замедлению работы приложения. Из-за замедления проблемный агент начинает обрабатывать сообщения дольше, что увеличивает скорость роста очередей сообщений. Что способствует более быстрому расходу памяти. Что ведет к еще большему замедлению приложения. Что ведет к еще более медленной работе проблемного агента… Как итог, приложение медленно и печально деградирует до полной неработоспособности.

Проблема усугубляется еще и тем, что взаимодействие посредством асинхронных сообщений и использование подхода fire-and-forget прямо таки провоцирует возникновение перегрузок (fire-and-forget – это когда агент A получает входящее сообщение M1, выполняет его обработку и отсылает исходящее сообщение M2 агенту B не заботясь о последствиях).

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

В форумах я часто вижу вопросы от начинающий программистов на С++: «какую посоветуете литературу?». Обычно я отвечаю набором надежных книг с дополнением: никакое количество прочитанных книг не заменит практику. Нужно на самом деле делать что-то. Но что? Что может быть хорошим проектом? Нужно что-то, что научит многому, но при этом достаточно простое и интересное, чтобы не заскучать. Я недавно задумался над этим вопросом, и, кажется, нашел ответ. Вам несомненно стоит написать интерпретатор байт-кода. Для меня такой проект оказал решающее значение в становлении всей последующей карьеры.

Как все началось

В 200Х году я учился на втором курсе в университете. У меня уже был небольшой опыт в программировании. Я умел использовать абстракции, доступные в С++, я не понимал на самом деле как все работает. Для меня компилятор и операционная система были просто черными коробками, работающими благодаря магическим заклинаниям, и я в целом считал это приемлемым.

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

И в отличии от классических SQL баз данных или noSQL типа MongoDB здесь очень удобно делать неточный поиск по всему документу. Для этого используется синтаксис Query DSL. Для полнотекстового поиска по всему документу есть несколько поисковых запросов. У себя на сайте мы используем тип query_string. Этот запрос поддерживает Lucene синтаксис, который позволяет и нам и пользователю создавать сложные запросы в google-style. Вот примеры таких запросов:

title:apache AND title:vulnerability
type:centos cvss.score:[8 TO 10]

Можно сделать вот такой простой запрос и все:

{
  "query": {
    "query_string": {
      "query": "exploit wordpress"
    }
  }
}

Но начав впервые использовать query_string, вы столкнетесь с тем, что поиск выдает не то, что вы хотите видеть. Как же добиться от elasticsearch внятного результата поиска?

Привет, Хаброжители! Ранее мы Вас спрашивали переводить ли книгу «Multiplayer Game Programming: Architecting Networked Games (Game Design)». Недавно новинка пришла из типографии.

В этой книге подробно рассматриваются все основные понятия, необходимые для создания сетевых многопользовательских игр. Вначале мы познакомимся с основами сетевых взаимодействий: как работает Интернет и как выполняется пересылка данных на другие компьютеры. Далее, после закладки фундамента, будут рассмотрены основы передачи данных в играх, как подготавливать игровые данные к передаче по сети, как изменять содержимое игровых объектов по сети и как организовать взаимодействие компьютеров, вовлеченных в игру. Затем мы поговорим о том, как компенсировать ненадежность соединения и задержки при передаче данных по сети и как обеспечить масштабируемость и безопасность игрового кода. В главах 12 и 13 рассматриваются службы объединения игроков для выделенных серверов и использование облачного хостинга — две темы, чрезвычайно важные для современных сетевых игр.

Это четвертая статья из серии по IL2CPP. В ней мы поговорим о том, как il2cpp.exe генерирует код C++ для вызовов методов в управляемом коде.

Добрый день, дорогие Хабравчане! Сегодня решил рассказать вам о нашем опыте создания бота для Telegram на Node.js практически без опыта серверной разработки и на добровольных началах. Сразу оговорюсь: у меня за спиной чуть больше четырех лет разработки под iOS, у остальных членов команды тоже был опыт разработки от одного до шести лет в смежных областях. Для большинства из нас это был первый случай использования Node.js в сравнительно большом проекте. Как мы это сделали, зачем мы это сделали, почему фриланс-биржа и как она отличается от классических моделей, какие у нас были проблемы и как мы с ними боролись – под катом!

I. Предыстория

Я много лет использую UltraEdit как редактор на самые разные случаи жизни. Одна из основных причин — быстрая работа с гигабайтными файлами без загрузки их в память. Для программирования на JavaScript он тоже достаточно удобен, вот только с одним существенным недостатком: автодополнение в нём основывается на достаточно бедном, жёстко заданном списке ключевых слов и глобальных переменных, вдобавок отстающем от развития языка. Как-то я задался вопросом, можно ли пополнить этот список полным перечнем всех готовых свойств и методов, какие только можно ввести в контексте Node.js и Web API (браузера). Где бы такой список можно раздобыть? Мне приходили в голову такие варианты:

1. Готовый перечень, кем-то составляемый и обновляемый для всеобщего пользования, вроде библиотеки globals, но полнее.

   
   

2. Парсинг документации (спецификация ECMAScript, сайты MDN и Node.js и т.п.), вручную или программно.

   
   
3. Получение списка метапрограммированием.

Введение

При разработке под Android довольно часто возникает задача наложить маску на изображение. Чаще всего требуется закруглить углы у фотографий или сделать изображение полностью круглым. Но иногда применяются маски и более сложной формы.

В этой статье я хочу проанализировать имеющиеся в арсенале Android-разработчика средства для решения таких задач и выбрать наиболее удачное из них. Статья будет полезна в первую очередь тем, кто столкнулся с необходимостью реализовать наложение маски вручную, не пользуясь сторонними библиотеками.

Я предполагаю, что читатель имеет опыт в разработке под Android и знаком с классами Canvas, Drawable и Bitmap.

Код, используемый в статье, можно найти на GitHub.

О проекте модуляризации Java мы слышим из года в год. Каждый раз ждём, следим за анонсами. Нам говорят, что Jigsaw практически готов, но каждый раз переносят срок выхода. Может быть, это не такой простой проект, как видится многим? Возможно, что изменения в нем повлияют на разработку в корне? Может быть, модулярная система — это только верхушка айсберга? Ответить на вопросы, связанные с проектом Jigsaw, мы попросили Ивана Крылова.

Иван занимается разработкой виртуальных машин Java и компиляторов более 10 лет, в настоящее время развивает компиляторную инфраструктуру в виртуальной машине Zing в Azul Systems. Регулярный докладчик на конференциях JUG.ru и других европейских Java-конференциях.

Что такое Jigsaw, и как он повлияет на мир Java?

— Иван, добрый день. Расскажите, пожалуйста, какое влияние проект Jigsaw окажет на экосистему Java?

— Добрый. Для объяснения моего взгляда на Java и модулярность стоит немного рассказать о моей деятельности. Коммерческим программированием я занимаюсь примерно двадцать лет. Последние одиннадцать из них — разработкой виртуальных машин. Работал в команде HotSpot Runtime в Sun. Потом компания была куплена Oracle. Далее было несколько изменений деятельности, и последние три с половиной года работаю в компании Azul Systems, где занимаюсь разработкой виртуальных машин.

В предыдущей статье я рассказал о том, как построить простейшую топологию для Apache Ignite. Она состояла из одного клиента и одного сервера, клиент слал на сервер сообщение и сервер его отображал. Было рассказано о том, как настроить продукт и проконтролировать его жизнедеятельность. Теперь пришло время для более сложного примера. Будет продемонстрировано построение сложной топологии и более интересные сценарии взаимодействия. Предполагается, что читатель ознакомился с базовыми операциями с Apache Ignite, изложенными в первой статье. В результате прочтения этих двух статей у читателя могут возникнуть какие-то предположения о том, как ему применить этот, без преувеличения, мощный продукт в своих проектах. Также статья будет полезна тем, кто интересуется построением высокопроизводительных систем, и хочет подсмотреть готовое решение для своего велосипеда.

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

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

• Функции слишком длинные, и на них слишком много задач
• Часто у функций есть побочные эффекты, которые сложно определить, а иногда даже сложно отлаживать
• Непонятные имена у функций и переменных
• Хрупкий код: небольшая модификация неожиданно ломает другие компоненты приложения
• Плохое покрытие кода тестами или вообще его отсутствие

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

Однажды мой коллега уволился, потому что пытался справиться с REST API на Ruby, который было трудно поддерживать. Он получил этот проект от предыдущей команды разработчиков.

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

Такие ситуации случаются часто, и это печально. Но что делать?

В начале этого года мы в HeadHunter начали проект, нацеленный на автоматизацию различных HR-процессов у компаний-клиентов. Архитектурой этого проекта на фронте выбрали React-Redux стек.

За 9 месяцев он вырос из небольшого приложения для тестирования сотрудников в многомодульный проект, который сегодня называется “Оценка талантов”. По мере его роста мы сталкивались с вопросами:

• хранения стейта, его нормализации;
• построения масштабируемой архитектуры проекта, удобной иерархии — как в структуре, так и в бизнес-логике.

Это проявлялось в изменении подхода к построению компонентов, архитектуры редьюсеров.

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

Эпопея с добровольно-принудительным «подталкиванием» пользователей прошлых версий Windows к обновлению до десятой версии, наверное, войдет в учебники по рекламе. В качестве примера или антипримера — это кто как воспринимает, но крови (во всем мире) идея «не мытьем, так катанием» получить от пользователя согласие на установку «десятки» попортила немало, а число комментариев по этому поводу побило, вероятно, самые смелые ожидания маркетологов компании.

Что же, ничто не вечно под луной, и обещанный срок бесплатного обновления минул больше месяца как. Срок минул, а напоминалки в иных системах как были, так и остались (возможно, неактивными). И вот (кто бы мог подумать?) в списке обновлений для Windows появилось оно — обновление KB3184143.

Константин Осипов (kostja )

Как родилась идея доклада? Я не очень люблю выступать и рассказывать про фичи, особенно про будущие фичи. Выясняется, что и люди не особо любят это слушать. Они любят слушать про то, как все устроено. Это доклад о том, как все устроено или должно быть, с моей точки зрения, устроено в современной СУБД.

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



На макроуровне – это то, как должна быть устроена современная СУБД. Почему у нас сегодня есть возможность создавать новые базы данных, почему нельзя взять текущую и удовлетвориться ее производительностью, подтюнить или написать для нее патч? Просто взять и написать патч, который бы ее ускорил, если она медленная? Из какого пространства решений мы выбираем?

18-го сентября был проведен последний, финальный этап чемпионата по спортивному программированию Russian Code Cup 2016 года. Первое место в упорной борьбе занял Геннадий Короткевич, второе и третье места — Владислав Епифанов и Николай Калинин соответственно.

Турнирную таблицу финала можно найти здесь, призовой фонд в этом году впервые распределен на первые 25 мест рейтинга. Это не единственное нововведение — впервые в RCC имели возможность поучаствовать англоговорящие программисты, коих набралось более тысячи из 4.5 тысяч участников. Помимо традиционных для соревнования стран СНГ, в финальном раунде боролись представители Германии, Финляндии, Японии, Швейцарии, Китая и Южной Кореи. Кроме того, в этот раз был проведен зеркальный раунд на Codeforces — сразу после финала основного состязания, у всех желающих была возможность решить задачи финала в специально организованном соревновании для первого дивизиона, поучаствовало чуть больше 200 программистов.

Традиционно предлагаем вам разбор задач финала (тесты можно скачать здесь):

A. Церемония закрытия
B. Кактусофобия
C. Домашнее задание
D. Слалом
E. Шифр
F. Покрытие массива

Незаметно пролетели почти три года с момента публикации первой статьи о платформе на Хабре. За это время многое изменилось: мы вышли на международный рынок, перешли к open source лицензии, обновили стек технологий и внесли множество улучшений во фреймворк и средства разработки. Поэтому вместо длинного списка изменений мы решили опубликовать ещё одну обзорную статью о платформе CUBA, которая, я надеюсь, будет интересна разработчикам кровавого энтерпрайза корпоративных информационных систем — как ещё не знакомым с платформой, так и тем, кто уже что-то слышал о ней.

Итак, под катом вы узнаете:

• Что представляет из себя платформа CUBA и какова её архитектура
• Какие решения эффективнее всего разрабатывать на CUBA
• Как платформа помогает сэкономить время разработки корпоративных систем
• Какое окружение необходимо для развертывания CUBA-приложений
• Как мигрировать устаревшую систему на CUBA
• Под какой лицензией распространяется платформа
• Как организована поддержка разработчиков

Я фронтенд-разработчик в компании Wrike, пишу на JavaScript и на Dart, который компилируется в JavaScript. Сегодня я хочу рассказать о библиотеке Zone.js, лежащей в основе Angular 2.

Изначально Zone.js была придумана разработчиками Google для языка программирования Dart и утилиты Dart2JS. С помощью этой библиотеки «гугловцы» решили проблему с дайджест-циклом, которая была характерна для первого Angular’а.
Чтобы понять, где эта библиотека используется и для чего нужна, прошу под кат.