Примечание: Данный пост написан британским разработчиком и финансовым аналитиком Майклом Халлс-Муром, который является профессионалом в так называемом Quantitative trading. С нашей точки зрения информация, содержащаяся в этом топике, может быть интересна техническим специалистам и разработчикам, которые интересуются фондовым рынком и обладают навыками для создания, к примеру, успешных торговых роботов, но не знают с чего начать. Поэтому топик будет рассматриваться именно в таком контексте, кроме того, текст адаптирован к российским реалиям, соответственным образом переведены и некоторые термины. Будем рады вашим комментариям! (Поправки по переводу лучше отправлять в личных сообщениях).

Алгоритмическая торговля — является крайне сложной областью финансов, и чтобы освоить объем информации, который позволит создать свою собственную торговую систему или устроиться разработчиком в финансовую компанию или фонд, потребуется довольного много времени. Большой опыт в программировании просто необходим для успешной работы на этом рынке, как минимум алготорговец должен хорошо разбираться в таких языках, как C/C++ (в области финансов перспективен и язык Java) и Python, Matlab и R (на российском рынке набирает популярность разработанный в США TradeScript — прим. перев.).

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Протокол OData имеет множество скрытых достоинств (хотя и недостатков хватает). Начиная с этой статьи, мы хотели бы поделиться мелкими полезными хитростями использования протокола OData.

Признаться, я не был удивлен почти полному отсутствию статей по данной тематике. Так уж сложилось — людей, которые имели возможность поработать с HoloLens, едва ли наберется десяток на всю страну. Тем не менее, в рамках Imagine Cup в Редмонде, принять участие в котором мне довелось, был проведен один из первых тест-драйвов средств разработки данной платформы.

HoloLens overview

HoloLens – всерьез засекреченный проект Microsoft, который был начат аж в 2012 году. С тех пор компании удалось разработать прототип, который был представлен прессе в январе этого года. С достаточно сносным обзором можно ознакомиться, к примеру, здесь.

Введение

Коллеги, при разработке приложений, мы каждый день сталкиваемся с потребностью в гибком хранении информации (обновлении, поиске по ней, и т.д.). Класс продуктов, которые решают этот круг задач, как все мы знаем — Базы данных. Но что это такое в нашем понимании? У многих «база данных» твердо ассоциируется с MySQL, таблицами и SQL-запросами. И это устраивает до определенного момента. Действительно, реляционные базы данных дают массу преимуществ в работе: поскольку данные имеют сильную связанность, не нужно контролировать целостность базы данных. Используя простой под-запрос можно выбрать количество комментариев к каждому посту в блоге. Используя JOIN нетрудно делать сложные связанные выборки и получать данные сразу о нескольких сущностях.

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

Одним из самых больших нововведений в PHP 5.5 будет поддержка генераторов и корутин (сопрограмм). Генераторы уже достаточно были освещены в документации и в нескольких других постах (например в этом или в этом). Сопрограммы же получили очень мало внимания. Это гораздо более мощный, но и более сложный для понимания и объяснения, инструмент.

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

Генераторы

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

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

Продолжаем цикл статей о терминале/сниффере IO Ninja и переходим к рассмотрению одной из самых выигрышных сторон новой версии нашего продукта – программируемости. Она открывает новые применения такого, казалось бы, заурядного инструмента, как терминал или сниффер.

Обзор архитектуры плагинов

Как и в предыдущей, второй версии продукта, исполнимые файлы третьей версии IO Ninja содержат лишь фреймворк необходимых компонентов (включая UI виджеты, движок для логгирования и классы для работы с IO, такие как io.Socket, io.Serial, io.PCap и т.д.). Логика же работы с конкретными транспортами содержится в плагинах, написанных на языке Jancy. Эти плагины лежат в выделенной папке «scripts» в виде исходных кодов и доступны как для ознакомления, так и для редактирования пользователями.

Наверняка многие активные MODX-разработчики слышали про «Фабрику сайтов». Это такие ребята, которые сделали копию движка MODX Revolution, назвали ее Ф.CMS и клепают на ней сайты, выдавая за собственный движок. Но помимо того, что они взяли сторонний опенсурс-движок, они еще и «позаимствовали» различные модули сторонних разработчиков, так же переименовали их и продают как свои, не указывая никакого авторства. Среди пострадавших — andchir и bezumkin. Последний писал про эту ситуацию довольно давно и подробно.

В прошлом году мне пришлось столкнуться с парой клиентов, чьи сайты долго и безнадежно разрабатывались в Фабрике. Один из сайтов был мной переделан и по результатам был написан подробный топик, где я разбирал качество выполненной работы указанной компании. И да, переданный мне сайт был разработан на Ф.CMS, действительно очень сильно напоминающую MODX Revolution, и да, в качестве модуля интернет-магазина использовался ShopKeeper by Andchir.

На хабре уже присутствует некоторое количество статей, посвященных процессу прототипирования в разработке программного обеспечения. Есть достаточно фундаментальные статьи с обзорами стандартов и расчетами, есть статьи про прототипирование устройств, есть цикл из двух статей про процесс выбора инструмента для прототипирования. К сожалению, процесс создания прототипов мобильных приложений освещен очень скудно – в виде единственной статьи в 2010 году, и пара слов в статье Разработка мобильных приложений: с чего начать.

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

“Это унылое диалоговое окно действительно нужно?”

В этой статье я изложил главные принципы Material Design и дал советы по их воплощению. Текст написан по следам мастер-класса для разработчиков, который мы, Роботы, устраивали совместно с российским офисом Google (Think Mobile).


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

Все стало меняться в 2011 году, когда в Google начали усиленно работать над унификацией визуальной части экосистемы своих продуктов и назвали все это Project Kennedy.

28 января 1790 года представитель штата Джорджия Джеймс Джексон выступал в довольно молодой на тот момент Палате Представителей на заседании в Нью-Йорке. Его целью было разоблачение высокоскоростных трейдеров.

«Три судна, сэр», – прокричал конгрессмен Джексон, – «отплыли в течение двух недель из этого порта с намерением спекулировать; они собираются приобрести весь Штат и другие ценные бумаги несведущих…»

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

Какое же ужасное преступление совершили эти люди? Убийство? Измену?

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

Начнем с такого интересного типа, как ENUM.

mysql> CREATE TABLE enums(a ENUM('c', 'a', 'b'), b INT, KEY(a));
Query OK, 0 rows affected (0.36 sec)

mysql> INSERT INTO enums VALUES('a', 1), ('b', 1), ('c', 1);
Query OK, 3 rows affected (0.05 sec)
Records: 3  Duplicates: 0  Warnings: 0

Итак, у нас есть таблица, в ней есть два столбца. У первого, a, тип ENUM, у второго, b, INT. В таблице три строки, у всех трех значение b равно 1. Интересно, чему равны минимальный и максимальный элементы в столбце a?

mysql> SELECT MIN(a), MAX(a) FROM enums;
+--------+--------+
| MIN(a) | MAX(a) |
+--------+--------+
| c      | b      |
+--------+--------+
1 row in set (0.00 sec)

Кажется странным, было бы разумно, если бы самым маленьким был 'a', а самым большим — 'c'.
А что если выбрать минимум и максимум только среди тех строк, где b = 1? То есть, среди всех строк?

mysql> SELECT MIN(a), MAX(a) FROM enums WHERE b = 1;
+--------+--------+
| MIN(a) | MAX(a) |
+--------+--------+
| a      | c      |
+--------+--------+
1 row in set (0.00 sec)

Вот так мы заставили MySQL поменять свое мнение о том, как сравнивать поля в ENUM, просто добавив предикат.
Разгадка такого поведения заключается в том, что в первом случае MySQL использует индекс, а во втором нет. Это, конечно, не объясняет, почему MySQL сравнивает ENUMы по разному для сортировки в индексе, и при обычном сравнении.

Второй пример проще и лаконичнее:

mysql> (SELECT * FROM moo LIMIT 1) LIMIT 2;
+------+
| a    |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

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

Интересно, что далеко не любой SELECT в скобках сработает, в частности, UNION в скобках — это синтаксическая ошибка:

mysql> (SELECT * FROM moo UNION ALL SELECT * FROM hru) LIMIT 2;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UNION ALL SELECT * FROM hru) LIMIT 2' at line 1

Еще несколько интересных примеров под катом

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

Имя Синезис гордо красуется на фасаде. Помимо бальзамического эффекта для души и самолюбия, надпись работает прекрасным ориентиром: клиенты, партнеры и пицца легко нас находят среди нескольких офисных зданий.

Инженер во время штатной проверки

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

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

Бывают запросы на то, кто открывал стойку. В каком-нибудь ЦОДе может случиться так, что несут что-то по проходу и задевают кабель. Или вот ещё случай: инженер одной компании обслуживал верхний сервер в стойке, в процессе у него упала лестница и ударила прямо по другому серверу, в итоге — раскололся разъём.

Поэтому, конечно, видеонаблюдение в ЦОДах нужно. Расскажу, как мы это делаем для заказчиков, и как организовали в своих дата-центрах.

UPD: Статья обновлена и дополнена.

Я уже публиковал этот пост ранее на Хабре, но по некоторым причинам был вынужден вскоре снять его с публикации. Тем не менее, за короткий срок существования поста он вызвал определенный интерес со стороны Хабрасообщества, что побудило меня возродить его из пепла. Итак, встречайте — новая версия поста с блэкджеком и ...



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

Предисловие

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

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

Вы спросите: «Кто же в вашей команде главный?». Скажем так, мы оба прекрасно понимаем, кто главный. Но вслух это не обсуждаем, потому как один из нас может обидеться, а вторая слишком много о себе возомнит…

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

Другие публикации из этой серии

Часть 1. Unboxing VisuMax — фемто-лазера для коррекции зрения
Часть 3. Знакомьтесь — лазер по имени Amaris. Переезды и первое пробуждение VisuMax
Часть 4.1 Возвращаем зрение. От очков до эксимерного лазера
Часть 4.2 Возвращаем зрение. От очков до эксимерного лазера

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

Я постараюсь рассмотреть человеческое зрение через призму IT. Если кому-то не слишком интересно читать часть, посвященную биологическим аспектам зрения — ничего страшного. Просто пропустите разделы, начиная с оптической системы глаза, и сразу переходите к традиционному конкурсу от наших девушек. Однако, я все же рекомендовал бы ознакомиться с этим материалом, чтобы лучше понять следующую статью, в которой мы будем рассматривать LASIK, Femto-LASIK, ReLEx SMILE и другие методы лазерной офтальмохирургии.

Есть настроение разобраться, что именно говорят эти непонятные люди в белых халатах, задумчиво глядя на результаты вашего обследования? Вы хотите узнать немного нового об уникальном природном даре — зрении? Тогда добро пожаловать под habracut. Как обычно — много иллюстраций и трафика (≈5 MB).

На этой фотографии космоса (да, это не рисунок), сделанной в 1995, видны «Столпы творения» из туманности Орел. Их и сейчас можно увидеть, если у вас на чердаке завалялся Хаббл и парочка шаттлов.

Только вот беда — этих «Столпов» не существует. Точнее они перестали существовать 6 000 лет назад. Именно тогда их случайно смело взрывом сверхновой. Почему мы их видим и будем видеть еще 1 000 лет? Все просто — они находятся в 7 000 световых лет от нас. Их «текущее изображение» до нас еще не долетело. А прямо сейчас мы с вами видим прошлое. Хотите узнать подробный рецепт путешествий во времени?