Привет, хабр! 18-20 мая 2016 года в Маунтин Вью, Калифорния, пройдет юбилейная, десятая по счету конференция Google I/O, посвященная самым актуальным передовым трендам в технологиях и программном обеспечении от Google.



Лететь через пол мира на одну конференцию — удовольствие то ещё, да и если всех желающих собрать — никаких конференц-холлов не хватит. Поэтому мы рады вам сообщить, что Google I/O будет проходить и в самых крупных городах России.

Google I/O Extended — уникальная возможность стать участником одного из самых крупных слётов любителей Google-технологий. Всё будет происходить в онлайн-режиме, так что вы сможете вместе с представителями GDG в Маунтин Вью наблюдать за ежегодной презентацией самых крутых новинок в IT мире! Сейчас I/O Extended включает более 550 ивентов в 94 странах на 6 континентах и охватывает всю планету.

В этой серии из двух статей о производительности и памяти описываются базовые принципы и приводятся советы для разработчиков по повышению производительности программного обеспечения. Эти статьи затрагивают, в частности, работу памяти и компоновку. В первой части было рассказано об использовании регистров и о применении алгоритмов блокирования для повышения многократного использования данных. В этой части статьи сначала описывается компоновка данных для обычного распараллеливания — программирования для общей памяти с потоками, а затем распределенные вычисления по сетям MPI. В статье описываются понятия, связанные с распараллеливанием: векторизация (инструкции SIMD) и работа с общей памятью (многопоточная архитектура), а также вычисления с распределенной памятью. И наконец, в этой статье сравниваются компоновки данных «массив структур» (AOS) и «структура массивов» (SOA).

Вы знаете, что «нобелевку» по научной фантастике получил китайский автор Лю Цысинь (Liu Cixin, 劉慈欣) с произведением The Three-Body Problem ( 三體). На эту книгу обратили внимание Барак Обама (пруф) и Марк Цукерберг (пруф).


Ольга Браатхен по своей инициативе перевела книгу на русский (вот тут можно качнуть fb2), за что ей большое спасибо.

Еще один кандидат на «нобелевку» в 2016 — это Нил Стивенсон (написавший «Лавину» и «Криптономикон») с произведением Seveneves (качнуть на английском можно тут, жаль, что на русский никто не взялся переводить).

Разработчики компании EDISON создали программу Управления доступом к электронным документам, о чем я писал пару лет назад, а сегодня речь пойдет об SDK для внедрения поддержки электронных книг в формате FB2.

В нашей системе мирно сосуществуют 2 сервера. Основной сервер(ядро), написанный на JAVA и сервер приложений — NodeJS, именно ему и посвящена данная статья.
Изначально у сервера приложений существовало 2 фундаментальные задачи:

1) проксирование запросов к основному серверу для того, чтобы уменьшить неспецифичную нагрузку и сэкономить ресурсы для решения более важных задач;
2) реализация client-specific функционала для того, чтобы не пришлось вносить изменения в код ядра при появлении клиентских “хотелок”.

Строго говоря, наличие сервера приложений вовсе не обязательно для функционирования системы, т.к. ядро имеет полноценное REST API, реализующее весь основной функционал системы. Несколько слов о протоколе. RTLSCP (real track location system communication protocol) – протокол, работающий поверх HTTP и позволяющий получать данные и выполнять базовые операции с системой RealTrac с использованием запросов и ответов в формате JSON/KML/PNG.

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

Наверное, каждый веб разработчик сталкивался с необходимостью в реализации поиска на сайте. Довольно распространенное решение — Apache Solr. В мире Drupal разработки это не исключение. Для интеграции Solr с Drupal и реализации фасетного поиска существуют модули search_api, search_api_solr и facetapi. Но в большинстве случаев нам бы хотелось, чтобы результаты поиска и фасетные фильтры обновлялись без перезагрузки страницы, то есть ajax'ом. И, как обычно в мире Drupal, на d.org найдется какой-нибудь проверенный временем и пользователями модуль (а может и не проверенный, как повезет), который делает то, что нам нужно. В данном случае это ajax_facets.

«Пусть тахорги в страхе воют,
Издавая визг и писк!
Ведь на них идет войною
Структуральнейший лингвист!»

• Очень жесткий правдоруб.
• Мог бы стать физиком-теоретиком (как Ричард Фейнман, который тоже родился 11 мая), но выбрал несуществующую на тот момент профессию — программист.
• Носит имя алгоритма поиска кратчайшего пути. Алгоритм был создан при решении железячной задачи «О нахождении оптимального пути передачи электрического тока всем существенным элементам цепи, минимизируя при этом расход меди».
• Непримиримый враг goto.
• Инициатор мема Considered harmful. «GOTO Statement Considered Harmful», "„GOTO Considered Harmful“ Considered Harmful", «„«GOTO Considered Harmful» Considered Harmful“ Considered Harmful?»
• Автор концепции семафора.
• Разработчик операционной системы THE (Technische Hogeschool Eindhoven).
• Стоял у истоков структурного программирования и распределенных вычислений.
• Не написал ни одной статьи на компьютере.

В обычной жизни Э.В.Дейкстра был чудаком: предпочитал простую ручку компьютеру, в его доме не было телевизора, он не пользовался мобильным телефоном, не смотрел кино. Когда его коллеги подготовили и издали к 60-летнему юбилею специальный сборник, Дейкстра ответил каждому из них личным благодарственным письмом, написанным от руки (61 адресат). Ученому его уровня и положения полагался секретарь, но Дейкстра отказался от этой привилегии и все предпочитал делать сам. Любил музыку и был хорошим пианистом.

Под катом несколько цитат Дейкстры, пара сокращенных эссе и список статей на русском языке.

Немного истории

В самом начале 2010 года Vincent Driessen пишет отличную статью A successful Git branching model. Для понимания того, о чем пойдет речь дальше, со статьей нужно, конечно же, познакомиться. А для тех, кому сложен язык оригинальной статьи, на хабре есть её отличный перевод.

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

• Плагин к самому Git'у
• Плагины к различным IDE: IDEA, Eclipse
• Встроенная поддержка в GUI клиентах: SourceTree и Git Extensions
• Плагины для систем сборки: Maven, Gradle, и т.д.
• Встроенная поддержка в менеджерах репозиториев: GitHub, BitBucket, GitLab и т.д.

Кажется, что модель идеальна. Быть может так оно и есть, если у вас небольшая команда, неизменяемый скоуп релизов, высокая культура работы с VCS. Тогда, действительно, GitFlow может и удовлетворит все ваши потребности. Но, к сожалению, описанные условия подходят не всем командам и не всем проектам. К слову, найти статьи, в которых бы авторы описывали проблемы этой модели не так уж и просто даже в 2016 году. Но как мы все знаем, серебряной пули нет, а, значит, и в этой модели всё хорошо далеко не для всех.

Мы создадим простой, но реалистичный модуль комментариев для блога, упрощенный аналог модуля комментариев реального времени, предлагаемый такими ресурсами как Disqus, LiveFyre и Facebook.

Мы обеспечим:

• Представление для отображения всех комментариев
• Форму для ввода и отправки комментариев
• Задел на будущее, для подключения настоящего бэк-енда

Также будут реализованы:

• Optimistic commenting: комментарии появляются на странице раньше чем они сохраняются на сервере, что визуально ускорит наш модуль
• Live updates: комментарии других пользователей появляются на странице в реальном времени
• Markdown formatting: пользователи могут использовать Markdown-разметку для форматирования текста

Финальная версия

Ссылка на GitHub

Merthyr Tunnel by Pictonart

8 мая состоялся первый квалификационный раунд чемпионата Russian Code Cup 2016. Напоминаем, что в этом году состязание программистов впервые проводится и на английском языке, так что языковой барьер теперь не является препятствием для наших зарубежных участников. Для прохождения первого квалификационного раунда было необходимо решить пять задач. На решение отводилось не более двух часов. Учитывалась не только правильность, но и скорость решения. Всего в раунде приняли участие 3559 человек, из которых занявшие первые 200 мест переходят на следующий этап соревнований. А пока давайте рассмотрим решения предложенных задач:

1. Двоичная строка
2. Поезд и туннель
3. Красивое разбиение
4. Подготовка задач
5. Похожее метро

Использование точек с запятой в JavaScript – один из самых горячо обсуждаемых топиков (сразу после пробелов и табов… два пробела, пожалуйста). Вот с ходу три ссылки, почему точки с запятой не нужны. Но так ли это на самом деле?

Какие инструменты облачного тестинга используют в Яндексе? Как устроено Selenium-тестирование в Badoo? Что представляет собой система автоматизированного frontend-тестирования в Wrike?

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

«Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов».»
— Пол Грэм, разработчик, инвестор, эссеист.



Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод спасибо Щекотовой Яне)

Читать первую часть главы.

Подход к делу

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

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

В нашем блоге на Хабре мы не только рассматриваем различные технологии финансового рынка, но и описываем различные инструменты, использующиеся аналитиками в ходе его анализа. В частности, не так давно мы писали о том, как гипотезу случайного блуждания можно использовать для прогнозирования состояния финансового рынка. Количественный аналитик хедж-фонда NMRQL Стюарт Рид опубликовал на сайте Turing Finance результаты своего исследования, где применил эту гипотезу для тестирования случайности поведения рынков.

Идея заключалась в следующем: генераторы случайных чисел «прогоняются» через группу тестов NIST, чтобы понять, где возникает уязвимость, позволяющая использовать неэффективность рынка для извлечения прибыли. В ходе эксперимента автор пришел к выводу, что поведение рынка нельзя описать в терминах простого подбрасывания монетки, как считают отдельные авторитетные ученые. Некоторым тестам удалось зафиксировать определенный уровень «шума» в поведении рынка. Один из них – тест на линейную сложность – привлек внимание автора, поскольку напоминает об идее отношения случайности и степени сжатия.

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

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

Под катом описание и реальный пример того, как работает runtime программирование.

Привет, Хабр!

Недавно мы выпустили вторую версию серверного продукта Hub. Hub — это система управления пользовательскими аккаунтами, группами и правами доступа, а также лицензиями для командных инструментов JetBrains: YouTrack, Upsource и TeamCity. Hub также является единой точкой входа (single sign-on) во все наши командные инструменты. Hub абсолютно бесплатен для неограниченного количества пользователей.



Если вы уже используете YouTrack 6.0+ или Upsource, вы заочно знакомы с Hub, так как он встроен в оба этих продукта. Для TeamCity мы недавно выпустили Hub-плагин, позволяющий авторизовывать и синхронизировать пользователей в Hub и TeamCity, а также добавлять виджеты из TeamCity на единую панель управления (Dashboard) в Hub. Управление правами доступа и лицензиями пока остается на стороне TeamCity.

Подробнее о Hub можно почитать здесь.

Кому пригодится Hub 2.0?

1. Всем, кто использует несколько командных продуктов JetBrains. Например, YouTrack и Upsource, YouTrack и TeamCity, или все три инструмента одновременно.
2. Всем, кто использует хотя бы один из командных продуктов и хочет использовать Hub для аутентификации во все приложения, которые поддерживают SAML 2.0.

В чем преимущества Hub?

1. Технология единого входа в YouTrack, TeamCity и Upsource.
2. Поддержка SAML, что позволяет использовать Hub для входа во внешние сервисы, например Zendesk, Google Apps for Work или Artifactory.
3. Общее управление пользователями во всех командных продуктах.
4. Единое администрирование прав доступа в YouTrack и Upsource, а также управление лицензиями для этих продуктов на уровне отдельных пользователей.
5. Общая панель управления с виджетами из YouTrack (отчеты, списки задач), Upsource (коммиты, код ревью) и TeamCity (статус проекта, билд артефакты, исследования (investigations)).
6. Возможность подключить несколько серверов YouTrack и Upsource к одному Hub.

А теперь расскажем подробнее о том, что добавлено в новой версии Hub 2.0.

Давайте на время отвлечемся от очередного "языка-убийцы C++", ошеломляющих синтетических тестов производительности какой-нибудь NoSQL-ой СУБД, хайпа вокруг нового JS-фреймворка, и окунемся в мир "программирования ради программирования".

Ключевые слова: DPS (DamagePerSecond); Wolfram Mathematica; дискретность и непрерывность; матанализ; заработок игровой валюты в компьютерных играх; паки ArcheAge.

Введение

Всем знакомы однотипные вопросы в школьных задачах по математике про мотоциклиста выехавшего из пункта А в пункт Б, которые вызывают скуку, отвращение, или просто безразличие. Вопросы, которые вызывают, все что угодно кроме интереса к изучению математики. Очевидно что, гораздо больший интерес и больше эмоций вызывают вопросы типа:
1) «как он смог меня одолеть в игре, если у моего персонажа и здоровья больше и DPS (Damage Per Second) выше?!»
2) «как быстрее всего заработать голду (игровую валюту), чтобы сделать своего персонажа сильнее?!»
На самом деле эти игровые вопросы очень похожи на классические школьные задачи. Разница лишь в том, что есть заинтересованность в получении ответа на игровые вопросы, есть цель, ради которой хочется решить эти задачи. К сожалению, очень многие преподаватели в школах и вузах совершенно не умеют заинтересовать обучаемых в получении конкретной информации, новом методе решений математических задач, доведении их до ответа. Но раз уж игры вызывают этот самый интерес, то грех не воспользоваться заинтересованностью в игре, для пробуждения интереса к математическому анализу.
Вот две задачи, которые являются лишь переформулированными вышеупомянутыми вопросами.
1) Петя и Коля решили помочь дедушке наполнить две одинаковые пустые бочки водой из колодца. Петя таскал воду в 5-и литровом ведре и на один заход к колодцу и обратно к бочке тратил 3 минуты, а Коля в 8-и литровом и на один заход тратил 5 минут. Каждый заполнял свою бочку. Кто из мальчиков быстрее заполнит свою бочку, если а) объём бочки 60 литров? б) если объем бочки 56 литров? (начали мальчики одновременно)
2) Два купца Семён и Добрыня покупают у крестьян по 10 пудов мёда за 5 золотых и везут его на продажу в соседние города. Добрыня везёт в ближайший город и продаёт там за 8 золотых, весь путь до города и обратно у него занимает 2 дня. Семён же, желающий продавать своё мёд как можно дороже, не ленится и везёт его ещё дальше, тратя на весь путь 3 дня, и продавая мёд в другом городе за 10 золотых. Кто же из купцов заработает больше за 360 дней непрерывной работы? Как изменится ситуация, если оба купца вынудят крестьян снизить цену на мёд до 3 золотых?
Разбор этих задач, описанный ниже, поможет ответить на животрепещущие вопросы игры ArcheAge (и других) про «паки» и DPS. А также позволит задуматься над такими понятиями как «дискретность» и «непрерывность», а так же над таким, казалось бы, очевидным вопросом как «прибыль».

Регистрация.

Rust — современный системный язык программирования с мощной системой типов. Он защищает от многих типичных ошибок программирования, таких как использование освобождённой памяти и гонки данных. Эти проблемы в Rust обнаруживаются сразу во время компиляции! При этом язык не использует сборку мусора — а значит, обладает предсказуемой производительностью, легко встраивается в другие языки и отлично подходит для встраиваемого программирования. На Rust можно писать надёжные, высокопроизводительные многопоточные программы.

Год назад произошёл выпуск первой стабильной версии языка — Rust 1.0. С тех пор язык активно развивался. Ещё вчера про Rust никто не знал, а сегодня Dropbox переписал на нём ядро своей дисковой инфраструктуры.

Вечером 17 мая мы соберёмся в московском офисе "Лаборатории Касперского", чтобы поговорить о теоретических и практических моментах использования Rust, его экосистеме и инструментах, поделиться опытом написания программ на нём, а также рассмотреть частые проблемы и способы их решения.

Не пропустите! CoLaboratory: Rust — это шанс узнать о многообещающем языке программирования, который может вскоре заменить привычные инструменты, чьи позиции сейчас кажутся незыблемыми.

Введение

Прежде всего, хочу сразу отметить, что я не являюсь профессиональным разработчиком. В этой статье я постараюсь изложить свой опыт создания игры «Feel Speed Racing». Данный материал, скорее всего не будет интересен тем, кто уже имеет большой опыт в разработке игр, но начинающим разработчикам, которые хоть немного работали с Unity думаю, будет интересно.