Пусть p — нечётное простое число. Довольно широко известно, что p представимо в виде суммы двух квадратов целых чисел p=a²+b² тогда и только тогда, когда p при делении на 4 даёт остаток 1: 5=1²+2², 13=3²+2², 17=1²+4², ...; 3, 7, 11,… непредставимы. Куда менее известно, что a и b можно записать красивой формулой, имеющей непосредственное отношение к одной эллиптической кривой. Об этом результате 1907 года за авторством немца по фамилии Jacobsthal и о связанных вещах мы сегодня и поговорим.

Совсем легко понять, почему 3, 7, 11 и прочие числа, дающие при делении на 4 остаток 3, непредставимы в виде a²+b²: квадрат чётного числа всегда делится на 4, квадрат нечётного числа всегда даёт остаток 1 при делении на 4, сумма двух квадратов при делении на 4 может давать остатки 0, 1 или 2, но никак не 3. Представимость простых чисел вида 4k+1 неочевидна (особенно если заметить, что простота существенна: число 21 хотя и имеет нужный остаток, но суммой двух квадратов не представляется).

Расскажу немного об упражнении для развития концентрации и кратковременной памяти.

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

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

Эта статья о том, как можно избавиться от дублирования сквозного кода, и как сделать его чуточку лучше с помощью АОП.

Добрый день, хабровчане!

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

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

Немного вскружилла голову статья Использование MySQL как NoSQL — История о том, как достичь 750,000 запросов в секунду (Перевод моего друга Вадима). Есть и другие материалы по этой теме. И вот дошли руки до экспериментов.

Под PHP разработано три разных клиента:
extension code.google.com/p/php-handlersocket
PEAR openpear.org/package/Net_HandlerSocket
PHP native github.com/tz-lom/HSPHP

Ниже приведены мои впечатления о первых экспериментах.

Позвольте предоставить субботние диванные рассуждения на тему «Как нам обустроить...» именно в виде статьи, а не вопроса, потому что статью прочтут в 10 раз больше читателей, а ориентирована она на всех читателей Хабра, а не только на читателей его вопросов.

В статье есть также одно простое предложение о том, как поправить дела с QA. Оно звучит так: давайте откроем доступ в QA всем, включая ReadOnly. Плюс парочка мелких замечаний к нему. Думаю, что после этого там пойдут дела на поправку. А ниже — подробности о том, что там происходило с момента рождения раздела, что происходит, и почему я считаю, что там дела идут плохо (не так, как на StackOverflow).

Обычно мы пишем про хостинги, в частности про зарубежный shared хостинг в США. Но чтобы писать, нужно иметь аналитические данные под рукой. Вот как раз тут требуется помощь Google Docs, если файл получится предположительно меньше 400 000 строк.

За несколько месяцев работы с таблицами Google пришлось много раз анализировать посредством формул разного рода данные. Как и ожидалось — то, что можно было решить в MS Excel, можно реализовать и в Google таблицах. Но многочисленные попытки решить проблемы с помощью любимого поисковика приводили только к новым вопросам и почти к нулевым ответам.
Посему, было решено облегчить жизни другим и прославить себя.

Кратко о главном

Для того чтоб Excel, либо spreadsheet (таблица Google) поняли что написанное — это формула, необходимо поставить знак "=" в строку формул (Рисунок 1).


Рисунок 1
Далее, начинаем писать формулу с клавиатуры либо выделяем мышкой те ячейки, с которыми мы собираемся работать.

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

PHP очень гибок и расширяем, с его помощью можно создавать скрипты, которыми можно заменить аналогичные на других языках (Perl/bash-скрипты и прочее). Функциональность ncurses поразительна и действительно выводит возможности работы с терминальным php-приложением на новый уровень.

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

Для кого предназначена статья

Материал предназначен для опытных php-программистов, заинтересованных в создании консольных php-приложений с пользовательским интерфейсом. (прим. переводчика: материал пригодится разработчику любого уровня, здесь нет ничего сложного).

Буквально за несколько недель, с момента показа новой iOS 7, произошел легкий сдвиг в сознании не только у дизайнеров, но и у пользователей, имя ему — плоский дизайн. Этот прием, да, назовем его так, получил шквал критики и восхищения, у него появились сторонники и лютые ненавистники, но сегодня, я постараюсь рассмотреть новый, современный, набирающий огромную популярность подход при проектировании — long shadows (длинные тени).

(P.S. — Все картинки кликабельны).

Что такое длинные тени в дизайне, и как это понимать?

Примечание переводчика: оригинальная статья была написана в 2007-м году, однако, на мой взгляд, полностью сохраняет актуальность и сегодня.

Разработчики программного обеспечения не любят составлять план работ. Обычно пытаются вовсе от него отказаться. «Закончу, когда закончу!», — говорят они, ожидая, что этот смелый и веселый поступок вызовет одобрение у босса, а о планировании будет успешно забыто.

Большая часть расписаний, с которыми вы встретитесь, будет представлять из себя бездушные отписки. Совершенно забытые, они хранятся в каком-нибудь общем каталоге. После выпуска продукта с опозданием на пару лет странный парень, в чьем офисе, говорят, видели картотеку, принесет на обсуждение причин провала старую распечатку, которую все засмеют. «Только гляньте! Мы запланировали две недели, на переписывание системы с нуля на Ruby!»

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

Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно. После чтения различных холиваров на тему правильных подходов к написанию кода мне в глаза бросилась одна тенденция: каждый пытается применить означенные подходы не в целом к программированию, а только к своему опыту разработки, к своим проектам. Многие не осознают, что хорошие практики — это не абсолютные правила, которые должны строго соблюдаться в 100% сценариев, это лишь советы о том, как следовало бы поступать в большинстве ситуаций. На каждую хорошую практику всегда можно придумать несколько дюжин примеров, в которых она работать не будет. Но это вовсе не означает, что хорошая практика не такая уж и хорошая, просто её применили не к месту.

Несколько недель назад, я работал над проблемой клиента, который столкнулся с падением производительности БД и даже ее отказами, которые происходили приблизительно каждые 4 недели. Ничего особенного в окружении, в железе или запросах. В сущности, большей частью базы данных была одна таблица, в которой присутствовали, кроме прочего, INT AUTO_INCREMENT PRIMARY KEY и UNIQUE KEY.

Запросы, работающие с этой таблицей, почти все были типа INSERT ... ON DUPLICATE KEY UPDATE (далее — INSERT ODKU), где столбцы, перечисленные в INSERT, соответствовали столбцам с UNIQUE KEY. И выполнялись они с частотой, приблизительно 1500-2000 запросов в секунду, непрерывно 24 часа в сутки. Если вы хороши в математике, то наверное, уже догадались в чем дело.

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

В последнее время в сети часто пишут про clustered index в InnoDB и таблицах MySQL, но, несмотря на это, на практике используют довольно редко.
В данной статье мы покажем на двух реальных примерах, как мы оптимизировали достаточно сложные системы Badoo, основываясь на понимании принципов работы clustered index.

Clustered index – форма организации таблицы в файле. В InnoDB данные хранятся в дереве, в таком же, в котором лежат обычные B-TREE ключи. Таблица InnoDB сама по себе уже является большим B-TREE. В качестве значений ключа используется clustered index. Согласно документации, в качестве clustered index выбирается PRIMARY KEY. Если PRIMARY KEY отсутствует – выбирается первый UNIQUE KEY. Если и такого нет, то используется внутренний 6-тибайтный код.

Что же вытекает из такой организации данных на диске?

Как реализовать long polling с помощью Nginx и Javascript в сети достаточно много материала. Но полного руководства я ещё не встречал. То возникают проблемы с компиляцией модуля под Nginx, то в браузере вертится иконка загрузки при long poll запросах. Под катом, полный материал как же все таки это сделать правильно.

На хабре уже было несколько статей о работе с вконтактом (раз, два, три), однако оно производилось через простые запросы на страницы с последующим ее парсингом. Это ужасно неправильно, так как если верстка страницы либо порядок запросов поменяется — скрипт перестанет работать. Кроме того, если не ошибаюсь, это запрещено правилами сайта.
Для этого есть официальный API от вконтакте.

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

Дело в том, что не так давно Facebook внедрил новую практику Breaking Change Policy (если по-русски, то что-то вроде «Политика критических изменений»). Социальная сеть уведомляет разработчиков о грядущих «перестройках» в API, что, соответственно, требует изменений в коде уже существующих приложений. И которые надо будет учесть при разработке новых, естественно. Facebook призывает разработчиков подписаться на блог, дабы не пропустить ничего важного.

А пока о самых актуальных изменениях, которые уже начали внедряться или будут внедрены в совсем скоро (завтра, 6-го февраля — начало первого этапа изменений).

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Вкратце: статья будет полезна тем программистам, кто уже заинтересовался релевантным поиском и прочитал статьи по стартовой установке сфинкс поиска, погонял на тестовых примерах и таких же синтетических задачах. Часто эти примеры не дают ответа на вопрос, а как же ощутить реальную пользу от поискового модуля Sphinx в сравнении с другими более простыми вариантами поиска. Примеры кода в статье — на php+smarty, Sphinx 2.0.1-beta, база данных — mysql, исходники и дамп структуры базы выложены отдельным архивом в подвале. В статье описан пример использования таких особенностей сфинкса, как:

• Создание единого конфиг файла для windows development и linux production
• SetMatchMode(SPH_MATCH_EXTENDED2) и почему SPH_MATCH_ANY и другие не подходят для реального поиска
• SetSortMode(SPH_SORT_RELEVANCE), SetFieldWeights — сортировка по релевантности и установка весов для полей индекса
• SetLimits(0,20) — ограничение вывода результатов
• AddQuery, RunQueries — построение мультизапросов
• SetFilter, ResetFilters — добавление фильтрации в мулльтизапросе для ограничения получаемых данных
• Wordforms — использование синонимов и преодоление ограничений для нестандартных словоформ, как «C#»

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