Пару дней назад на первой (!) странице NY Times была опубликована вроде как сугубо техническая статья о том, что некоторые «привилегированные» компании имеют возможность осуществлять трейдинг уже через 30 миллисекунд после поступления заявок (квот), гораздо быстрее, чем все остальные. Якобы их сервера установлены прямо на бирже рядом с теми серверами, где осуществляются транзакции. На примерах показывалось, как именно можно зарабатывать прибыль аж до одного цента на акцию. При миллиардах транзакций в день один цент на акцию — это огромные деньги. Несложная схема получения сверхприбылей изображена на диаграмме. Надеюсь, все понимают английский язык.



Интересно, что недавний скандал с русским программистом Goldman Sachs — из той же оперы. Именно эту компанию считают главный «махинатором» сверхскоростного трейдинга. Поэтому кража программных кодов из компании является вопросом национальной безопасности США, ведь программное обеспечение Goldman Sachs де-факто применяется для манипуляций на бирже.

Эффект разгромной статьи в NY Times не заставил себя долго ждать. Буквально через несколько дней сенатор от партии демократов Чарльз Шумер обратился с просьбой к SEC, официально запретить практику сверхскоростного трейдинга, ибо она противоречит принципам свободного рынка.

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

В последнее время модно стало использовать гуглякарту.
Гугля карту суда, гугля карту туда.
И главное не забыть отобразить свои объектики на карте.
Но, почему-то, подавлявшее число сервисов используют неправильную реализацию процесса передачи маркеров с сервера на клиент.
Точнее они не правильно формируют запросы.
А если выразиться еще более точнее — они это делают

«Лучше день потерять, потом за час долететь» © Крылья, ноги, хвост

Не так давно мне «посчастливилось» перевести веб сайт средних размеров из одной кодировки в другую. Если быть точнее из windows-1251 на UTF-8. Потом еще один — побольше, на третьем я сломался, и следуя верному принципу вышесказанного мне пришлось потерять кучку времени на написание скрипта по автоматизации этого процесса, но зато потом, за час я все-таки долетел.

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

Наверняка вы слышали о сервисах Amazon EC2, Rackspace и им подобным. Может быть даже пользовались. Лично мне бывает нужен иногда личный VPN-сервер. Для этих целей я уже давно держал микро-инстанс на Амазоне, предоставляемый им в течении первого года бесплатно. Плюс использовал для архивов Amazon Glacier, который с его ценой «1 цент за гигабайт в месяц» можно считать тоже почти бесплатным. Но вот год закончился и за EC2 стало нужно платить. Архивы мои тоже разрослись прилично и затраты на Glacier аналогично перестали радовать.

Случайно пробежавший мимо обзор сервиса DigitalOcean по-началу оставил меня равнодушным. Ну, облачный сервис, ну виртуалки. Ну да, чуть-чуть дешевле (но не так чтобы уж очень), чего-то аналогичного Glacier вроде бы нет да и вообще оно того не стоит.

Я сильно ошибался. Ниже будет рассказано как на базе DigitalOcean сделать себе VPN-сервер в пару десятков раз дешевле такого же на Амазоне и сервис хранения архивов, в бесконечность раз дешевле Glacier.

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

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

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

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

Также отмечу что весь свободный софт, и перл не исключение, делается для Unix-подобных ОС, на винде всё это можно делать, но не нужно, рекомендую сразу осваивать нормальную для девелопера ОС (GNU/Linux, FreeBSD).

Как обычно всё будет в шпаргалочном стиле, ссылки будут в основном на официальные доки, всяких док для быстрого старта полно в сети:

Здравствуй, Хабр.

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

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

Изначальная идея проекта принадлежит моему другу (он не с Хабра). Первый раз она прозвучала примерно так:

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

Не помню, что я ответил. Мне интереснее было именно сделать такой сервис. Challenge accepted ;)

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

Триггер — это хранимая процедура, которая не вызывается непосредственно, а исполняется при наступлении определенного события ( вставка, удаление, обновление строки ).
Поддержка триггеров в MySQL началась с версии 5.0.2

Однажды понадобилось мне переопределить на работающей программе поле, помеченное как private final. Причем останавливать программу было нельзя, ибо сервер. Ну и как маленькое дополнение тип переменной был определен как inner класс. Разумеется тоже private.

К счастью, программа позволяет на ходу подключать модули, содержащие произвольный код. А значит — в нашем распоряжении вся мощь reflection!

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

Всего парой запросов можно узнать, какими запросами формируется страница (для веб-девелоперов)
и почему она тормозит.

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

Итак, как пользоваться:

Не будем тянуть кота за хвост. Сразу к делу

curl -u username:password --silent "https://mail.google.com/mail/feed/atom" | tr -d '\n' | awk -F '<entry>' '{for (i=2; i<=NF; i++) {print $i}}' | wc -l

Результатом будет количество новых писем у вас в ящике.

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

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

По данным летнего опроса на habrahabr, на mootools програмируют около 8% разработчиков. Понятно, что чем популярнее фреймворк, тем быстрее и качественнее он развивается, тем больше плагинов под него появляется в сети. Можем ли мы как либо влиять на эту цифру? Я думаю, можем!

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

Разработчики MooTools неплохо поработали над документацией, но в сети она доступна только на английском. Ну вот я и решил исправить ситуацию. Сейчас полностью переведена только секция Core, остальные секции пока что находятся в процессе перевода. Вот я и решил обратиться к Вам, уважаемые разработчики, принять участие в переводе (кого заинтересовало мое предложение пишите мне на oleg точка cherniy at Гмейл.ком).

Полезные ссылки:

• Текущий вариант перевода документации по MooTools
• Обсуждение перевода на тематической google-группе
• Исходный код, а также инстукция по установке доки на свой компьютер

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

Также, после опубликования первых двух статей я получил пару отзывов и вопросов, связанных с проектированием БД / расстановкой индексов / составлением запросов. На многие вопросы старался отвечать. С некоторыми из них поделюсь и в этой статье.

Осталось совсем немного времени до выхода MySQL 5.1. В статье будут рассмотрены изменения и новые возможности этой версии.

По заявкам трудящихся решил написать еще одну статью, посвященную оптимизации запросов в MySQL.

В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.

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

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

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

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

Этот пост меня сподвигли написать две вещи. Автокадабра и некто под ником napisal, кто активно не соглашался с моим постом…

Дело было так: я зашёл в карту клубов Автокадабры и понял что она мне ни о чём не говорит. Создавалось впечатление, что пишут всего в трёх клубах. После изучения облака я пришёл к выводу что линейная зависимость размера тега (в данном случае блога) от количества публикаций совершенно не информативна. Клубы с одной публикацией выглядят так же как и с 15-ю.