На работе в новом проекте используется СУБД PostgreSQL. Так как до сих пор я работал с MySQL, сейчас приходится изучать и открывать для себя Постгри. Первая проблема, которая меня заинтересовала — замена мускулевского SQL_CALC_FOUND_ROWS. При использовании этой константы в MySQL можно получить количество всех найденных по запросу записей, даже если запрос с limit'ом — это незаменимо при постраничном выводе поисковых результатов, когда используются «тяжелые» запросы.
Сходу готового решения найти не удалось. На форумах просто констатировали, что SQL_CALC_FOUND_ROWS в Постгри нет. Некоторые писали, что надо юзать count(*). И больше никакой информации. Но еще из MySQL мне было известно, что поиск с count()-запросом работает почти в 2 раза медленнее, чем с SQL_CALC_FOUND_ROWS. Я консультировался у тех, кто пользуется PostgreSQL, день мучал google и в результате получил 4 варианта замены SQL_CALC_FOUND_ROWS в PostgreSQL, один из которых вполне приемлимый по скорости.

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

Это не первое место, которое надо оптимизировать, если запрос тормозит, скорее последнее. Изложенные ниже идеи осмысленно применять когда план выполнения (explain) уже с виду идеальный и комар в нём носа не подточит, но хочется «выжать» ещё немного.

PayPal обзванивает клиентов, информируя о нововведениях в конце августа — начале сентября.

Из хорошего:

• Резидентам Российской Федерации будут доступны операции с банками
• Станет возможно иметь рублевые счета

Привет, %USERNAME%! решил рассказать тебе, как, приложив минимальные усилия, начать разрабатывать на Haxe игры под iOS (на самом деле и не только, но я решил ограничить данную статью именно этой платформой).

Для этого нам понадобятся:

1. бабушка Руки. Желательно прямые. Ещё желательней из плеч;
2. Mac OS X;
3. XCode;
4. Идея для игры.

Приглашаю всех под кат, даже если чего-либо из списка у Вас нет в наличии.

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

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

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

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

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

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

Добрый день, уважаемые хабрапользователи.

С недавних пор я занимаюсь разработкой на Ext JS 4 и Zend framework 2.

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

Итак, Grid, часть 1.

Представляем проект indexisto.com — поиск для сайтов и мобильных приложений.
Проект в альфе, просьба отнестись с пониманием (нажимать аккуратно). Тестовая выдача сейчас по английскому контенту музыкальной тематики. Нам также очень нужны early adopter'ы, если поиск заинтересовал пишите ЛС.

Хроники

История началась пару лет назад, когда я переехал с Windows на Убунту, а потом продолжилась с переездом на Mac. Подобный переезд может дать начало десятку историй, однако у меня случилась одна — я вдруг стал пользоваться поиском по операционной системе как основным инструментом навигации.

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

Я так же стал замечать множество других сценариев, когда поиск здорово экономит время. Поиск по «настройкам» в Chrome, поиск по контактам в Skype, переход на человека через поиск в Facebook, подсказка URL в адресной строке Firefox с учетом частоты заходов на сайты…

В тоже время ситуация с поиском на сайтах в 99% случаев удручающая. Складывается ощущение что никто не воспринимает поисковую строку всерьез и не тратит времени на подумать. Да да, и на Хабре тоже.
С этого все началось )

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

Здравствуйте, уважаемые хабрапользователи!

Как вы уже поняли из заголовка, в данной статье пойдёт речь о новой версии Yii. Я попробую коротко, на живом примере, познакомить вас с замечательным Yii 2.

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

Для управления зависимостями в проекте, node.js, как и многие другие платформы, предоставляет собственный пакетный менеджер — npm. И несмотря на то, что он внешне похож, например, на Ruby Gems, и вроде бы выполняет те же самые функции, npm обладает некоторыми особенностями, которые стоит учитывать при разработке приложений на node.js. Одна из таких особенностей — это способ хранения директории node_modules в проекте. Многие, по аналогии с другими системами, оставляют в проекте только package.json с зафиксированными версиями модулей, а node_modules добавляют в .gitignore. Такая стратегия не всегда верна, если мы обратимся в FAQ на npmjs.org, то увидим там следующее:

Q: Стоит ли хранить node_modules в git?
A: Mikeal Rogers очень хорошо ответил на этот вопрос:
http://www.mikealrogers.com/posts/nodemodules-in-git.html
tl;dr

• Храните node_modules в git для проектов, которые требуется разворачивать, таких как вебсайты и приложения.
• Добавляйте node_modules в .gitignore для библиотек и повторно используемых модулей.
• Используйте npm для управления зависимостями в dev окружении, но не в скриптах используемых для деплоя.

Под катом перевод статьи Mikeal Rogers, в котором подробно описывается, с чем связан такой непривычный подход.

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

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

Генераторы

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

В PHPStorm есть встроенная возможность подключения автодополнения имен таблиц и полей в редакторе кода, однако не все об этом знают.



Если у вас код отображается примерно так, то прошу под кат.

Так уж повелось, что программисты закрепляют удачные решения в виде шаблонов проектирования. По шаблонам существует множество литературы. Классикой безусловно считается книга Банды четырех «Design Patterns» by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides" и еще, пожалуй, «Patterns of Enterprise Application Architecture» by Martin Fowler. Лучшее из того, что я читал с примерами на PHP – это «PHP Objects, Patterns and Practice» by Matt Zandstra. Так уж получилось, что вся эта литература достаточно сложна для людей, которые только начали осваивать ООП. Поэтому у меня появилась идея изложить некоторые паттерны, которые я считаю наиболее полезными, в сильно упрощенном виде. Другими словами, эта статья – моя первая попытка интерпретировать шаблоны проектирования в KISS стиле.
Сегодня речь пойдет о том, какие проблемы могут возникнуть с инициализацией объектов в ООП приложении и о том, как можно использовать некоторые популярные шаблоны проектирования для решения этих проблем.

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

Symfony 2.3.0

Мы все долго этого ждали, многие из нас работали последние 4 года что бы это произошло. Сегодня, Symfony 2.3.0 доступна и это первый релиз с долгосрочной поддержкой(LTS) для Symfony 2.

Я очень счастлив, что мы достигли этой точки в жизни Фреймворка. Спасибо вам, что сделали это возможным!

С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

Основная идея feature branch заключается в создании нового брэнча, когда вы начинаете работать над какой-то функциональностью. В DVCS вы делаете это в своем собственном репозитории, но те же принципы работают и в централизованных VCS.

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).

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

1. ресайз изображений под любые размеры (добавление новых размеров не должно вызывать головную боль)
2. модификация изображений: добавление водяного знака, применение эффектов оттенки серого, сепия и вообще добавление новых эффектов не должно быть трудной задачей
3. обработка изображения не должна влиять на основной поток (скорость загрузки страницы)
4. для ускорения загрузки изображений на странице решение должно позволять обойти лимит одновременных соединений в браузерах, детальнее о лимите (рус)
5. избежать возможность засорения сервера явной передачей параметров ресайза в url
6. кешировать результаты работы

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

tl;dr Eсть новое API для асинхронного try\catch. Из статьи можно скопипастить пример и поиграться.

Всем привет!

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

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

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