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

Однако допустим, что вы располагаете привлекательным бизнес-планом, вы ожидаете самоокупаемость проекта уже через 2 года от момента его старта, и предвкушаете ежегодный 50% рост его рекламного потенциала. В MS-Visio подготовлены многообещающие схемы пользовательского интерфейса проекта. И даже более того, ваш дизайнер, вооружившись модным руководством, в рекордные сроки обозначил графический вид проекта. Так, что сверстанные в лучших традициях безтабличной верстки типовые страницы пользовательского интерфейса дожидаются своего звездного часа в вашей локальной папке проекта.

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

Когда пришлось реализовывать дерево комментариев, столкнулся с необходимостью рекурсивного вызова представления (view в MVC). Так как представления у меня, да и практически везде, — это обычные файлы с кусками HTML-кода и возможностью вставки PHP, то подключаются они с помощью include. Мне стало не по себе, когда представил как этот include вызывается рекурсивно сотни раз. Первая мысль — засунуть файл представления при первом запросе в память и потом выполнять его через eval. Такой подход позволит кешировать код представлений, и даже хранить его в БД. Так как eval кушает только PHP, а представления у нас чистым PHP-кодом не являются, то обрамляем содержимое в '?>' и '<?php'.

Как-то я пообещал сравнить Yii с CodeIgniter.

Думаю, на данный момент я достаточно распробовал Yii, чтобы адекватно сравнить
два замечательных фреймворка.

Grid 960 — это CSS Фреймворк, который позволяет разработчикам быстро конструировать прототипы дизайна. Они являются замечательным инструментом для создания макетов. Почему? Потому что они делают за вас всю тяжелую работу, позволяя получить быстрые результаты.

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

Вчера вышла очередная версия Yii — 1.0.10. Заявлено, что релиз включает в себя около тридцати багфиксов и небольших улучшений.

Давайте вкратце посмотрим чем же мы теперь сможем воспользоваться в своих проектах.

• Добавлена директива max_file_uploads которая управляет максимальным количеством загружаемых файлов для избежания DDos (атака отказ от обслуживания) через переполнение каталога для временных файлом TMP.
• Добавлены отсутствующие проверки для exif;
• Исправлен режим Safe-mode в обход функции tempnam();
• Исправлен параметр open_basedir в обход функции posix_mkfifo();

Список изменений в PHP 5.3.1

Скачать PHP 5.3.1

Это пока вся информация доступна на php.net этот топик(пост) будет обновлен, как только появится более полная информация

Наша команда разработчиков уже скачала эту версию и установила на внутриофисный сервер для тестирования.

К сожалению на этой версии PHP не работает наш регулярно используемый в разработках фреймворк CodeIgniter, так как была исключена функция для работы с регулярными выражениями (убрали ereg, оставили preg_match).

UPD: Проблема с CodeIgniter снята в CodeIgniter 1.7.2 разработчики фреймворка решили эту проблему и все теперь работает как часы.

Скачать CodeIgniter 1.7.2

Благодарность за информацию хабраюзерам: DenisO и @zzkey

В php5.3.1 проблемы с gettext под Windows (http://bugs.php.net/bug.php?id=49349) Благодарность хабраюзеру: grolse

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

INTRO

В интервью японца Tokuhiro Matsuno прозвучала следующая фраза:

«Некоторыми приложениями нашей компании пользуются более миллиона человек. Все это работает на Amon2.»

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

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

Множество удобных инструментов, найденных командой популярного онлайн журнала SmashingMagazine, приводится под катом

Главное новшество этого года — место проведения. В этом году конференция пройдет в Москве, а не в Санкт-Петербурге, как это было ранее.

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

Свое участие в качестве спикеров уже подтвердили ряд специалистов. Также ведутся переговоры с иностранными докладчиками, в том числе с Zend Framework Core Team.

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

На сайте опубликован полный список докладов конференции и открыта финальная регистрация.

В этом году с докладом выступит гость из Италии — Enrico Zimuel из Zend Framework Core Team. А также Виктор Фараздаги, Александр Веремьев, Алексей Качаев и многие другие специалисты.

Meteor представляет собой набор новых технологий для быстрого создания высококачественных веб-приложений, с которым справятся не только опытные разработчики но даже и новички.

Чистый JavaScript.

Пишите всё приложение полностью на чистом JavaScript. Все API, доступны на клиенте и на сервере — в том числе API базы данных! — Так что один код может легко работать на клиенте и на сервере.

Живые обновления страниц.

Просто напишите ваши шаблоны. Они автоматически обновляются при изменении данных. Meteor поддерживает любой язык шаблонов.

Чистая, мощная синхронизация данных.

Пишите ваш код клиентской части, как если бы она была запущена на сервере, и имела прямой доступ к базе данных. Больше не придется получать данные через REST.

По иронии судьбы, видео с самой первой — первопроходческой конференции 2010 года до сих пор пылилось в архиве (даже в неоцифрованном виде).

В предверии очередной конференции (ZFConf 2012, которая пройдет 21 апреля в Москве) мы решили заполнить этот пробел. Надо заметить, что большинство из докладов даже не потеряло своей актуальности.

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

В этой статье хочу поделиться своим опытом использования данного инструмента в реальном проекте. Нужно было сделать удаленную админ панель и через api реализовать управление сайтами-клиентами. Требования: модульность, оптимизация под нагрузки, использование API Youtube, ЧПУ.

Далее я буду указывать конкретную задачу, а напротив опишу какие инструменты использовались и насколько эффективно:

Я обожаю twitter bootstrap. Прост, местами логичен, достаточно красив, подходит для быстрого прототипирования веб-интерфейсов. Но этого оказалось недостаточно. Взяв twitter bootstrap в большой проект, мне пришлось целиком его разобрать и переосмыслить css-фреймворки как боевые единицы в веб-проектах. В результате переосмысления родились требования к любому css-фреймворку, удобному как верстальщику, так и frontent-разработчику.

Введение

На хабре уже несколько раз упоминали о проекте Meteor, основанном в 2011 году семерыми энтузиастами web-технологий из Сан-Франциско. По сути Meteor является просто надстройкой над node.js, который сам ещё даже не дошёл до релизной версии. Тем не менее проект собрал более семи тысяч подписчиков на github и получил 11 миллионов долларов инвестиций.
С чего такая популярность? Дело в заявлении авторов о том, что они хотят кардинально переосмыслить способ написания современных web-приложений в сторону его упрощения. Не секрет, что написание кода на чистом node.js довольно сильно выворачивает мозг и вынуждает использовать различные костыли в виде control flow средств. На Meteor, говорят авторы, писать крутые приложения сможет даже гуманитарий.
Ну что же, проверим. Имеется: 1 гуманитарий-социолог, закрывший сессию и желающий после Парсонса и Зиммеля перейти на что-нибудь полегче, компьютер с Ubuntu 12.10 и установленный node.js (не спрашивайте, как он оказался у социолога).

Вдохновимся обещаниями разработчиков, прекрасной девушкой-членом команды и начнём.

Введение

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

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

Интерес к Javascript MV* фреймворкам вызвал их подъем. Meteor, Ember, Angular, and Backbone, все они действительно популярны на Github. Измерить популярность довольно сложно, но хорошим показателем может быть количество Github-фоловеров. Используя данные из Github-архива, можно продемострировать это визуально (с помощью запроса на BigQuery и некоторых других скриптов).