В нашем блоге на Хабре мы не только рассматриваем различные технологии финансового рынка, но и описываем различные инструменты, использующиеся аналитиками в ходе его анализа. В частности, не так давно мы писали о том, как гипотезу случайного блуждания можно использовать для прогнозирования состояния финансового рынка. Количественный аналитик хедж-фонда 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 думаю, будет интересно.

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

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

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

Я видел много технических стартапов, которые теряли из виду, что, как и зачем они делают, и скатывались к 100-процентному фокусированию на добыче денег, необходимых исключительно на поддержание текущего состояния дел. Такое встречается очень часто. Подумайте о всех этих благотворительных фондах, которые начинали с чёткой цели (условно говоря, "спасти кота"), но спустя несколько лет вперёд оказывается, что большинство их усилий — если не все — направлены лишь на то, чтобы найти денег на то, чтобы выплатить всем зарплату и продолжать "благотворительность".

Не помню что и почему я искал в интернете несколько дней назад, но я наткнулся на интересную статью с необычными фотографиями. А позже на еще одну статью, где описывалась реализация алгоритма создания таких фотографий на python. После прочтения меня заинтересовала эта тема и я решил провести вечера майских праздников с пользой для себя, а именно реализовать алгоритм «конвертирования» видео в щелевое фото. Правда, не на питоне, но подручными средствами на bash'е. Но обо всем по порядку.

Блогер Скотт Хелм (Scott Helm) поделился с читателями своего твиттера любопытным скриншотом, содержащим экран настроек геолокации мобильного приложения NissanConnect (ссылка на оригинальный твит, который в ленте Geektimes занимает слишком много места). На первый взгляд приложение выглядит вполне обыденно, если бы не любопытная строка «The spirit of stack overflow is coders helping coders» в самом низу.

В статье рассказывается про модуль, позволяющий создавать подмножество javascript с любыми ключевыми словами. Строго для безудержного веселья.
На волне статьи про rucckuu.js я обзавидовался и решил обнародовать своё творение: небольшую экосистему для создания произвольных подмножеств javascript. Если к вам давно закрадывалась мысль о том, что некоторые ключевые слова плохо подходят к контексту их применения или мысль о том, что javascript слишком многословен (всякое бывает). Если вы хотите добродушно подшутить над коллегами или просто объяснить вашей маме, чем вы всё-таки занимаетесь на работе, добро пожаловать под кат.

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

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

Основная цель — это выполнить проект в сроки и в дальнейшем развивать его вкладываясь в запланированный бюджет.

Один из важных критериев качества кода — это его простота. Но как измерять простоту? Один из вариантов — это рассчитать кол-во элементов системы. Чем меньше элементов тем система проще.

Допустим бизнес логику меньше сделать нельзя, так как она зависит от бизнеса, а не программиста, разве что можно ее оптимизировать. Тогда критерий будет — кол-во кода НЕ бизнес-логики. С опытом разработки мы увидели, что очень удобно разделить MVC таким образом:

Core Components
Server Environment needs
Routing
Common Libraries
M (Controller can connect with different objects):
2nd layer of business-logic
Get, Set, Data processing
HMVC Contollers
Adapters (for easy work with other services)
V = templating, head, footer-scripts, parts
C = easy code and first layer of business logic
+L = Libraries (for advanced and third-party components)

Модель многие понимают как работу с данными и это может быть как получение данных из базы так и целый внутренний сервис или сборка MVC компонента для вставки во view. Желательно, что бы они были НЕ сильно связаны и код можно было легко расширять.

View в веб-разработке часто несёт в себе заголовки head и скрипты, которые не являются уже внешним видом, а несут отдельный смысл. Лучше их переносить в отдельные файлы. Также View-ки должны легко делится на части для простоты масштабирования проекта

Controller — это основной элемент всей связки. В нем происходит распределение реакций на запросы клиента. И часто на первом этапе это распределение выполняет Rotuting, а уже потом в методе контроллера собираются все нужные данные и помещаются во View.

Вольный перевод статьи «Should we use a coding standard?» из блога «Virtuous Code» Avdi Grimm. Мнение автора оригинальной статьи может не совпадать с мнением редакции.
Примечание переводчика: лично я согласен с автором.

Эта статья основана на материалах презентации, которую я представил в этом году на конференции OSCON. Я отредактировал текст, чтобы он был более лаконичным, а заодно учёл ту обратную связь, что я получил после своего выступления.

Про Go часто говорят, что он хорош для серверов: здесь есть статические бинарники (static binaries), развитый concurrency, высокая производительность. В этой статье мы поговорим о двух последних пунктах: о том, как язык и среда выполнения (runtime) ненавязчиво позволяют Go-программистам создавать легко масштабируемые серверы и не беспокоиться из-за управления потоками (thread) или блокирующих операций ввода/вывода.

В то время, как ребята из команд, работающих над Angular, React, мягко, но уверенно пересаживают разработчиков на ES2015, я хотел бы немного рассказать о возможностях использования нового стандарта спецификации с библиотекой Backbone.js. На сегодня основной подход к использованию ES2016 в браузерах один и не зависит от используемого фреймворка/библиотеки. И заключается он в следующем: пишем код на ES2015 и с помощью транспайлера (напр., Babel) получаем код (который и выполняется в браузере) на предыдущем стандарте ES5.

Но как модули, классы и прочие "фишки" из ES2015 использовать в рамках сущностей библиотеки Backbone.js? Об этом речь пойдет под катом.

Введение: Зачем нужен RESTful сервис на Meteor

Meteor привлекает простотой использования и возможностью очень быстро создать работающее приложение с минимальным набором функций. У Meteor — хорошо развитое сообщество. Есть множество полезных дополнительных модулей, которые не требуют сложной настройки, и могут быть использованы сразу после установки. Есть хорошая документация, примеры и большое количество постов на форумах, вроде StackOverflow. Meteor — это full-stack фреймворк, который предлагает удобную и многофункциональную интеграцию сервера с клиентом. Так зачем же выходить за рамки этого взаимодействия, и создавать RESTful сервис?

Клиент-серверное приложение, по-сути, состоит из 2 независимых частей, которые взаимодействуют посредством определенного интерфейса. При этом каждая из частей клиент-серверного приложения может создаваться разными людьми или командами. Разработчики клиенсткой части вовсе не ограничены использованием Meteor, они могут использовать любой другой JS фреймворк, клиент даже не обязательно должен быть написан на JS, это может быть к примеру приложение Android, написанное на Java, или iOS, написанное на Objective C.

Именно эти причины заставили меня выбрать Meteor для построения back end в моем проекте, и искать пути для создания RESTful сервиса на Meteor.

Эффективные Рельсы — более точного названия для книги придумать было бы сложно. Всё содержание описывается этими двумя словами и раскрывается для нас в сотне рецептов на 380+ страницах. В ожидании выхода финальной версии Rails 5, данное чтиво — то, на что стоит потратить время, благо потребуется его не так много. Но данное вложение вернётся колоссальной прибылью знаний и позволит, как говорится на обложке, «создавать Rails-приложения с нечеловеческой скоростью». Да и не только Rails, да и не только Ruby. Первые две главы включают в себя обилие информации по работе с терминалом и СКВ. Подробности под катом.

Примечание от переводчика:

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

---

Я разработчик программного обеспечения и я создаю баги и ошибки. Однажды я сбросил продакшн-базу SQL на дефолт, что угробило важную информацию и похоронило огромный кусок работы моих коллег. Содержание данного поста абсолютно субъективно и не направлено против какой-либо компании. Я считаю, что у нашей сферы есть серьезные проблемы с качеством выполняемых работ и я не вижу этому конца.

За последние несколько лет стало ощущаться, как качество программного обеспечения и услуг по всей отрасли стало падать, а не расти. Все и всегда находится в стадии Беты (как исходя из названия, так и из качества). Товары отправляются потребителям тогда, когда этого хотят маркетологи, а не когда они реально готовы к продаже, а все потому, что «мы всегда сможем легко все пофиксить». Конечный потребитель превратился из покупателя в бета-тестера, но это уже норма, потому что в разработке используется Agile. В программировании мы стали считать, что ошибки и неудачи — это нормально, поэтому нам теперь не нужно прикладывать так много усилий для их избежания. Поддержка миллионов клиентов — вещь сложная, поэтому волноваться не стоит. Зачем вообще тратить время на ознакомление с фидбеком и репортами от пользователей, если их просто можно отправить в бесконечный лабиринт под названием «саппорт» и «обратная связь»?

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

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

(Приглашение к совместному проекту с открытым исходным кодом)

Зачем люди пишут игровых ботов? – Можно назвать много возможных причин, одной из них, безусловно, является чисто академический интерес решения сложной задачи AI. В литературе по философии CS и по философии математики программирование неоднократно сравнивалось с альпинизмом. Трудно сказать, кто первый сделал такое сравнение. На наш взгляд, оно очень подходит и к нашему случаю, поэтому, рискуя показаться не оригинальными, все же сделаем утверждение: написание нетривиального бота для программиста – такой же вызов, как покорение вершины для альпиниста. Чем недоступнее вершина – тем сильнее желание ее покорить. Поэтому, прежде всего, нужно выбрать действительно достойную вершину в интересном горном массиве. Одним из таких массивов со множеством сложных, никем пока не покоренных вершин, является игра "Космические Рейнджеры 2 HD: Революция" (КР2) — продолжение серии игр "Космические Рейнджеры" (КР).

На днях широкое внимание привлекло состоявшееся в начале года на митапе NYC Lisp выступление Джеральда Джей Сассмана, — одного из авторов великого и могучего SICP, а также крестного отца Scheme. Всему виной — ответ на вопрос, почему в MIT прекратили преподавать ставший легендарным курс 6.001, построенный на основе книги Сассмана и Абельсона «Структура и интерпретация компьютерных программ» (вопрос задан на 59 минуте).



Сассман назвал две причины; впрочем, сразу замечу, что в первой из них нет ничего особенного. К 1997 году Абельсон и Сассман уже устали рассказывать практически одно и то же с 80-ых, поэтому решили оставить преподавание и предложили главе кафедры самостоятельно решить, как поступить с самим курсом. Здесь удивляться действительно нечему — что угодно может осточертерть, если заниматься им достаточно долго.

Впрочем, вторая причина гораздо серьезнее. По мнению Сассмана, они с Абельсоном осознали, что учебный план SICP больше не в силах подготовить инженеров к тому, что представляет собой «инжиниринг» сегодня. В 80-ых и 90-ых инженеры строили сложные системы, комбинируя простые и хорошо изученные «части». Целью SICP было предоставить язык абстракций для рассуждений о таких системах.