Уверен, вам не раз подалась на глаза аббревиатура OpenID. Вполне возможно у вас сложилось мнение, что это эдакая модная штуковина, о поддержке которой все чаще заявляют различные популярные проекты. По большому счету так и есть, но зачем эта технология на самом деле нужна? Предположим, вы заядлый блоггер, у вас имеется учетная запись на wordpress.com, но случилось вам прочесть сообщение в чужом дневнике и возникло непреодолимое желание оставить автору комментарий. Но вот незадача – чужой дневник оказался на livejournal.com. Неужели только для того, чтобы оставить комментарий вам придется регистрироваться на «вражеском» блог-хостинге?!

Таких историй на Хабре уже не мало, но, как мне кажется, каждая из них имеет свои нюансы, поэтому все они полезны.
Занимаясь каким-то своим делом, наверное каждый когда-то подходит к черте «отбеливания» своего бизнеса. Что так же в большинстве случаев позволяет подняться на новую ступень. Я говорю о регистрации юридического лица.
Круг клиентов наработан, партнерские отношения налажены, получено достаточно опыта и я решился зарегистрироваться. Кто-то говорил что это очень сложно, кто-то — очень просто. Никто не оказался правым. Сложность — вообще можно оценить только в сравнении.

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

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

США является одной из самых сильных мировых экономик. Но не многие знают, что половину ВВП в США даёт малый бизнес. Более того малым бизнесом создаётся около 70% рабочих мест.
Дмитрий Медведев не относится к числу тех, для кого данные факты являются новостью. Во многих его обращениях и действиях явно прослеживается желание поднять отечественную экономику на новый уровень как раз с помощью развития малого бизнеса. Но не смотря на появление различных законодательных актов, призванных облегчить ведение малого бизнеса обстановка в этой области не становится сильно лучше. Можно много говорить о причинах такой ситуации. Я бы хотел рассказать об одной, с которой столкнулся сам, а точнее мой друг.

Зачем писать приложения для Facebook

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

Заметка посвящена не столько возможным методам защиты (о них уже было много написано), сколько обзору небольшого списка для быстрой проверки при подготовке к возможных скачкам посещаемости. Судя по статистике нагрузки на электронные магазины на прошлой неделе (когда начался рождественский сезон продаж на Западе), даже для крупных магазинов время ответа может колебаться на 20%, что же говорить о менее крупных веб-сайтах?

Такую проверку обязательно нужно проводить перед выпусками новых продуктов, а также перед сезоном массовых покупок (для России это время в канун Нового Года и Рождества). Итак, с чего начать?

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

Я вряд ли ошибусь, если предположу, что язык РНР достаточно популярен, если не самый популярный в веб-разработке. Мы не будем анализировать причины этого (а тем более, следствия), а сконцентрируемся на одном небольшом аспекте, а именно — как на РНР разрабатывать сложные AJAX веб-приложения. И не просто так разрабатывать, а использовать в своей работе библиотеку ExtJS, которая позволяет создавать интерфейсы для этих веб-приложений. Конечно, все это можно разнести и серверная сторона, на РНР или на любом другом языке, совершенно ничего не будет знать о клиентской части и AJAX-библиотеке, просто оперируя JSON данными и обычным HTML. Но можно сделать и по-другому — этот подход, аналогичен популярной сегодня технологии Google Web Toolkit. Мы ничего не разделяем, а просто пишем приложение, используя одну среду, один язык и все возможности (и языка и среды), а уже сервер самостоятельно генерирует код для клиента, полностью автоматически. Таким образом можно совсем (ну или почти) не знать и не разбираться в верстке, JavaScript и ExtJS, но писать приложения, которые будут использовать этот фреймворк.

Для языка Java подобные решения существуют, а недавно такой проект, EXT GWT, даже перешел под крыло самой компании-разработчика ExtJS, превратившись в вполне серьезное профессиональное решение. Ну а как в других языках? Java, конечно, хорошо и даже отлично, но душа и тело хотят разнообразия, или просто не хотят переучиваться. Для таких случаев есть свои решения. И одно из них, для РНР, так и называется — PHP-Ext.

Уважаемые коллеги, представляю на ваш суд стартап MindApps: http://mindapps.ru.

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

Основной идеей, заложенной в платформу, является простота создания и скорость изменения приложений. Для того, чтобы компания могла создавать себе нужные информационные инструменты по потребности — и, желательно, без программистов. Возникла потребность –> принято решение –> создано/изменено приложение –> введено в использование. Скажем, в течении дня на весь цикл.

Последнее время в инете стало появляться все больше публикаций про использование data:uri css sprites. Приведу две ссылки из блога Steve Souders, известный всему миру «оптимизатор» работающий в Google.

CSSEmbed — automatically data: URI-ize
Aptimize: realtime spriting and more

Наш отечественный герой «веб-оптимайзер» sunnybear намного раньше поднимал вопрос про использование data:uri в css и нами совместно был проведен ряд исследований. В то время вылезло много интересных моментов и особенностей о которых мы писали в предыдущих статьях. Последние эксперименты вскрыли ряд ранее неизвестных моментов по работе браузеров с data uri css спрайтами.

Вчера увидел в фиде Компьютерры новость о том, что некий Waze приходит в Россию. Решил посмотреть — что за зверь такой.

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

Сразу предупреждаю не знал куда публиковать. Сильно сомневаюсь в правильности выбора :-)

Есть набор документов c датой создания.
Отсортируем их по дате создания.
Документы могут а) добавлятся, причем только в начало (то есть самые новые), б) удалятся.
Как сделать, к примеру в Apache CouchDB, постраничный вывод?
Ваши предложения?

Что такое Apache CouchDB читаем на официальной страничке и на хабре. Про map reduce читаем в вики и в оригинальной статье гугла.

Эта «небольшая» статейка является развитием темы затронутой в этой статье.
Как известно, PHP зародился довольно давно и уже тогда возник вопрос, что делать с возникающими ошибками. Perl, который является несомненным прародителем PHP по умолчанию не имел какой-либо системы обработки ошибок. При возникновении любой ошибки сервер выбрасывал 500-ю ошибку и на этом все заканчивалось. Поэтому Warnings, Fatal Errors и Notices были настоящим прорывом в облегчении и без того нелегкого труда программиста. Однако время шло, механизмы PHP не менялись, а технологии, как известно, на месте стоять не любят.

Введение

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

• элементов
• декораторов
• фильтров
• валидаторов

Элементы — это, собственно, то, что мы понимаем под элементами формы: поля ввода, выпадающие списки и пр.
Декоратор — это вся верстка, которая логически связана с элементом формы (окружает его), но не является его частью. Проще говоря, декоратор — оформление элемента формы.

    Действительно, в интернете сейчас можно найти достаточно много информации о настройке GIT и работе с ним, но недостаточно освещен вопрос коллективной разработки и «рабочего процесса» отдельно взятого проекта от начала и до конца.

    Попробую восполнить этот пробел на примере открытого проекта Midnight Commander, не останавливаясь на вопросах установки необходимого ПО, так как этот момент неплохо описан в интернете, и вы сможете легко найти интересующую вас дополнительную информацию самостоятельно.

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

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

Чаще всего прибегают к готовому решению от Google, с помощью которого можно еще и подзаработать на контекстной рекламе. Но для рунета я бы посоветовал сделать поиск при помощи сервиса Yandex.XML, потому что такой поиск больше адаптирован под морфологию русского языка. К тому же вы можете получить шанс получить самые жирные биды для контекста, если будете использовать поисковый директ.

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

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

Наиболее простая схема «распараллеливания» нагрузки — вынос основной нагрузки на несколько frontend. Раньше приходилось мучиться (или наслаждаться, кому как) с webdav'ами, кластерными ФС и прочими хитростями чтобы обеспечить актуальную информацию, так было до тех пор, пока не появился nginx, а точнее proxy_store и proxy_cache в нём.

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.