Давным-давно в 1637 году Пьер Ферма имел глупость написать на полях «Арифметики» Диофанта следующее: «… невозможно разложить куб на два куба, биквадрат на два биквадрата и вообще никакую степень, большую квадрата, на две степени с тем же показателем. Я нашел этому поистине чудесное доказательство, но поля книги слишком узки для него».

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

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

Недавно сразу несколько достаточно авторитетных по местным меркам новостных порталов взорвала новость: Узбекский математик разгадал теорему Ферма — Математик из Ташкента Борис Пономарев утверждает, что отыскал «простое оригинальное доказательство» Великой теоремы Ферма — загадки, над которой ученые всего мира бьются вот уже 350 лет (например, здесь, здесь и здесь). В одной из них даже было приведено доказательство.

     

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

Т.к. речь идет о HD-видео, то потребуется высокая производительность декодера. Например, если декодериуем на CPU, то на потоках 30-35 MBps на Intel Core2 Duo E8500 3.2 GHz уже начинают выпадать кадры. Процессор довольно быстрый, разница в производительности по сравнению с ядром Sandy Bridge на той-же частоте будет порядка 20%. Качественно пережатый full-HD фильм может создать проблемы, не говоря уж об оригинальных потоках с Blu-ray, там поток может достигать 45 MBps. Обладатели ноутбуков обычно имеют процессоры послабее, да и настольные системы не у всех с мощными CPU. Еще один случай, где CPU становится узким местом – это deinterlacing. Deintrlacing необходим при просмотре потоков спутниковых HD каналов, потоки там с разумным bitrate (обычно 10-15 MBps), но программный deintarlace съедает все остатки ресурсов. Причем качественный deinterlace, без замыливания и с сохранением fps, тяжелы для CPU. Единственный выход – использовать аппаратное декодирование, которое предлагают современные GPU. Про видео со спутниковых каналов следует отметить, что они бывают частично поврежденными, т.к. прием не всегда идеален, поэтому важно, чтобы плеер стабильно переваривал такие “срывы” потока.

В этой заметке я хочу показать вам процесс создания нового дизайна для скрипта интернет-магазина Simpla.

Низкий поклон Хабранароду!

Предисловие

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

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

Буду краток:



Подробности, что еще не работает, и как это установить — под катом.

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

В рамках чтения мной книги “MongoDB: The Definitive Guide” Kristina Chodorow and Michael Dirolf, решил выписывать основные моменты из глав, для лучшего освоения материала. Возможно, кому-то это тоже будет полезно.

Insert

Insert — базовый метод для добавление информации в MongoDB. Для того, чтоб добавить документ в коллекцию делаем вот так:

> db.foo.insert( { “bar” : “baz” } );

В таких ситуациях, когда нужно добавить несколько документов, для более быстрой вставки желательно использовать, так называемые, batch insert’ы (групповая вставка)

> db.foo.insert( { “arr” : [ { a : 1 , b : 1 } , { a : 2 , b : 2 } ] } );

Грубо говоря, просто вставляем массив.

Все началось в середине сентября. На тот момент, наш стартап работал уже пол-месяца и все, что мы собирались делать в публичном плане – это участвовать в предстоящем в Кишиневе Startup Weekend’e, который намечался на 11-13 ноября. Просматривая организаторов данного мероприятия, у меня в голове была только одна мысль – найти кого-нибудь, кто помог бы нам попасть в Кремниевую Долину. Тогда эта была всего лишь мысль и о том, каким образом и как скоро она реализуется я даже и представить не мог.

Около полугода назад я написал простой джейкверный плагин для галерей на сайтах. Назвал его Фоторамой и выложил в интернет. По клику кроссфейдом показывалась следующая фотография, клик с шифтом мотал назад — вот и всё.

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

В этом году в Google Analytics появился новый отчет Посетители > Соцфункции. Он, как можно догадаться, должен показывать взаимодействие с сайтом посредством социальных кнопок (like, share и т.п.)
Но для отслеживания каждой социальной кнопки необходимо было создавать функцию обратного вызова, которая бы посредством вызова метода _trackSocial и должна отслеживать нажатие на кнопку.
Об этом можно почитать в справке Google Analytics: http://code.google.com/intl/ru-RU/apis/analytics/docs/tracking/gaTrackingSocial.html
И это было не очень удобное решение, т.к. социальных кнопок на сайте может быть много и для каждой придется писать функцию.

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

Уже достаточно давно, когда я только в первый раз столкнулся с затеей интернет-радио, меня огорчило то скудное наличие средств создания потока, что имелось на рынке. Либо выбор сводился к комбайну SAM Broadcaster, либо к кучке утилит формата «собери конфиг сам». Мне же хотелось чего то более удобного, чем набор command-line утилит (т.е. с удобным графическим интерфейсом), но и более легкое, чем SAM. И вот, спустя годы, я начал писать свой велосипед…

Если вы запускаете новый сайт и заканчиваете его оформление, то есть смысл посмотреть коллекцию Subtle Patterns: отлично оформленную коллекцию фоновых текстур (паттернов) под лицензией Creative Commons Attribution 3.0 Unported. Их можно использовать без ограничений.

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

Все текстуры на сайте Subtle Patterns являются повторяющимися, то есть склеиваются в бесшовную заливку.

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

Известные

• Yet another Conference от Яндекс 2010 2011 — раз, два, три
• Application Developer Days
• DevPoint
• HighLoad++ Последние видео за 2009 год, но вроде как обещали выложить с недавно прошедшей
• РИТ
• JavaTechDays 2010, 2011
• DevСon'11
• Percona.TV Видео по MySQL
• PyCon — 2009-2011

Довольно давно на Хабре не было статей про такой удобный и эффективный инструмент для быстрого прототипирования как Axure RP.
Решил выложить свою подборку закладок по «Акшуре» в виде сводного списка ресурсов.

Как сделать свою радиостанцию в интернете?

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

Сегодня довольно мало информации о протоколе AMQP (Advanced Message Queueing Protocol) и его применении, особенно на русском языке. А вообще это — замечательный, уже достаточно широко поддерживаемый открытый протокол для передачи сообщений между компонентами системы с низкой задержкой и на высокой скорости. При этом семантика обмена сообщениями настраивается под нужды конкретного проекта. Такие решения существовали и ранее, но это первый стандарт, для которого существует большое количество свободных реализаций.

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

Сегодня тема доставки информации в реальном времени является крайне актуальной (достаточно вспомнить хотя бы Twitter, Google Wave). И здесь системы передачи сообщений могут служить внутренним механизмом обмена данными, который обеспечивает доставку данных (изменений данных) клиентам.

Я не ставлю своей целью сегодня рассказать о том, как писать приложения для AMQP. Хочу лишь немного рассказать о том, что это совсем не страшно, не очень сложно, и действительно работает, хотя стандарт находится еще в развитии, выходят новые версии протокола, брокеров и т.п. Но это уже вполне production-quality. Расскажу лишь базовые советы, чтобы помочь “въехать” в протокол.

Как сказано на официальном сайте —

Pinba is a realtime monitoring/statistics server for PHP using MySQL as a read-only interface.

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

Нам в Эльбе довольно часто задают вопросы по типу «Я „упрощёнщик“, у меня есть электронный кошелёк в Яндекс.Деньгах, как его в доходах-расходах учитывать и перед налоговой отчитаться?».

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

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

Вопрос: Почему поиск в python dict на больших объемах данных быстрее чем итерация по индексированному массиву?

Ответ: В dict хранятся хэши от ключей. Каждый раз, когда мы ищем в dict значение по ключу, мы сначала вычисляем его хэш, а потом (внезапно), выполняем бинарный поиск. Таким образом, сложность составляет O(lg(N))!

На самом деле никакого бинарного поиска тут нет. И сложность алгоритма не O(lg(N)), а Amort. O(1) — так как в основе dict питона лежит структура под названием Hash Table.

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

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

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