1 комментарий

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

Документация для разработчиков приложений: http://www.webasyst.com/ru/framework/docs/dev/cli/
Пример настройки Cron в cPanel: http://www.webasyst.com/ru/framework/docs/server/cron/

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

24 комментария

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

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

Без использования других приложений «Сайт» позволяет создавать относительно несложные сайты, состоящие только из статических информационных страниц. Вся гибкость и мощь «Сайта» раскроются, когда будут выпущены интегрированные с ним приложения: «Блог», «Фото», «Магазин» и прочие. Тогда на основе «Сайта» можно будет построить действительно многофункциональный сайт. Документация по интеграции своего приложения с «Сайтом» для разработчиков: http://www.webasyst.com/ru/framework/docs/dev/site-app-integration/

Вместе с этим обновлением в «Инсталлере» появилось два новых раздела: «Плагины» и «Темы». В данный момент эти разделы пустые, и мы будем развивать их в ближайших обновлениях.

16 комментариев

Ольга Митрофанова
Интернет-магазин «Мега Подарки»

В августе мы провели рекламную кампанию в купон-сервисе «КупиКупон»: на «КупиКупоне» можно было получить купон, который давал 50%-скидку на любой продукт в нашем интернет-магазине. Вкратце расскажу о результатах акции.

В отличие от стандартных акций, которые предлагают купон-сервисы — покупатель приобретает купон за реальные деньги, и купон дает ему право на скидку (например, покупаешь за 500 рублей купон, и можешь на него поесть на сумму 2000 рублей; другими словами, получаешь 75% скидку), — в нашем случае покупатель получал купон за внутренние бонусы сервиса «КупиКупон». Бонусы накапливаются при участии в других акциях, поэтому получается, что покупатель не платил реальные деньги за наши купоны.

Бонусные акции, в отличие от стандартных, не публикуются на главной странице купон-сервисов, и рассчитаны только на постоянных пользователей купон-сервиса. Интерес «КупиКупона» в бонусных акциях (ведь он за них не получает реальные деньги) — представить разнообразное, качественно отличное от «шиномонтажей» и «салонов красоты» предложение. Мы решили, что для пробы это будет самым подходящим вариантом акции. Плюс, в случае бонусной акции наши затраты были минимальными: мы не платим «КупиКупону» никакой комиссии и просто получаем новых посетителей, которым должны предоставить скидку. Скидка по купонам была установлена в размере 50% — меньшую скидку нельзя поставить по правилам «КупиКупона», а при большей скидке мы бы полностью работали в убыток. Со скидкой в 50% получалось, что в среднем мы продаем продукты по их себестоимости: некоторые продукты выходили «в минус», некоторые — «в плюс».

Итак, мы заключили договор с «КупиКупоном», и на их сайте появилась статья о нашей акции. Статья полностью написана сотрудниками «КупиКупона»: http://www.kupikupon.ru/deal/megapodarki_3872

Реализация на стороне магазина

Наш магазин работает на основе веб-сервиса Shop-Script, и для организации предоставления скидок по акции мы ничего не программировали — просто использовали стандартный механизм купонов на скидку, который предоставляет Shop-Script. «КупиКупон» предоставил нам приобретенные пользователями коды купонов в виде XLS-файла, и купоны из этого файла мы вручную создавали в магазине в режиме администрирования. Было, конечно, не очень удобно вручную добавить полторы тысячи купонов, зато все заказы уже автоматически рассчитывались со скидкой. Впрочем, на добавление купонов ушло всего около часа-полутора (в новой версии Shop-Script будет возможность импорта купонов из файлов — прим. ред.).

Результаты

О результатах акции лучше скажут цифры и графики.

Читать далее →

22 комментария

Работа над приложением «Сайт» близится к завершению.

Несмотря на то, что мы сами уже давно пользуемся этим приложением (например, сайт webasyst.com был открыт на основе «Сайта» еще в июне), для того, чтобы довести приложение до выпуска, потребовалось довольно много времени: было разработано несколько новых системных механизмов во фреймворке, которые будут использоваться другими приложениями для построения сайтов.

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

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

Например, «Блог» можно поселить по адресу /blog/*, а основной сайт — в корневой директории (/*). Все будущие приложения — Shop-Script, «Фото», «Форум» и прочие — будут легко добавляться в уже работающий сайт. Для этого нужно будет после установки приложения через «Инсталлер» поселить его: указать, по какому адресу оно должно открываться.

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

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

7 комментариев

Пока фреймворк находится в альфа-версии, и готовых полезных приложений всего одно-два, процесс разработки приложений для фреймворка имеет характер исследовательской дейтельности. Работа очень увлекательна, но в определенном смысле мучительна. Решение большинства текущих задач по фреймворку сводится к поиску паттернов, которые впоследствии будут применятся или рекомендоваться к применению в других приложениях. Например, приложение «Сайт» с дизайн-редактором, который должен подойти и для «Блога», и для шаблонов email-уведомлений, и для будущего Shop-Script; приложение «Блог» с плагин-структурой, архитектура которой должна подойти для многих других приложений; приложение «Поддержка», на котором отрабатывается системный механизм рабочих процессов (workflow); API, актуальный практически для любого приложения Вебасиста и т.п. Требуется много пробовать и принимать довольно ответственные решения, поэтому выпускать новые приложение не получается так быстро, как бы нам этого хотелось (например, как были сделаны «Списки дел»).

Расскажу немного о том, как мы разрабатываем приложения, из каких этапов состоит разработка. Опыт нашей команды в разработке веб-приложений насчитывает уже более десяти лет. В разное время мы пробовали всяческие подходы к веб-проектам: и писали с нуля, и на основе готовых решений, делали проекты для хостирования у себя, для хостирования где бы то ни было, и с подробными техзаданиями, и с зарисовками только на листочках. При разработке мы никогда жестко не придерживались каких-либо методологий разработки, таких как agile или waterfall, и не придерживаемся сейчас. Процесс у нас ближе, пожалуй, к agile, но не является таковым в чистом виде. Это отдельная тема, и о ней как-нибудь в другой раз — сейчас же расскажу о этапах, из которых состоит разработка каждого приложения на основе фреймворка Вебасист.

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


  1. Проектирование и дизайн.

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



    Мы не пишем никаких подробных техзаданий. Иногда делаем короткие PDF-файлы с описанием отдельных мыслей, но стараемся обходится и без этих файлов. Техзадание, фактически, готовится в виде макета интерфейса, по которому потом сразу ведется программирование. HTML-макет сделать быстрее, чем описывать то же самое словами. На макете сразу можно опробовать разные варианты оформления, затраты на корректировки минимальны. Также удобно коллективно обсудить, как будет выглядеть приложение.

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


  2. Программирование и тестирование.

    
Тут ничего нового: разработка структуры БД, программирование, трекер заданий, задачи, тестирование, задачи, тестирование.


  3. Внедрение.

    

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

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



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

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

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

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

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

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

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

4 комментария

«Онлайнер» — приложение для «Вконтакта», разработанное на основе фреймворка Вебасист.
Приложение позволяет следить за статистикой пребывания в соцсети друзей и самого себя. Для того, чтобы посмотреть приложение, необходимо быть зарегистрированным во «Вконтакте».

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

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

39 комментариев
Укажите в комментариях три самые самые желанные функции, которые вы ждете в новом Shop-Script. Можно высказывать любые предложения, комментировать предложения других, поддерживать, спорить, говорить спасибо и ругаться. Пост-флейм!

20 комментариев

В недавнем посте про историю Shop-Script я упомянул о том, что переход на новую версию Shop-Script будет платным. Это вызвало небольшую дискуссию в комментариях и, надо сказать, неприязнь. Вполне естественно, ведь раньше владельцы лицензий Shop-Script никогда не платили обновления. Последнее платное обновление было в 2005 году — переход с более младшей версии Shop-Script PRO на появившийся тогда Shop-Script PREMIUM. И то это неправильно называть обновлением — это был апгрейд с одной редакции продукта на другую. Далее все обновления были бесплатными, в том числе и переход с Shop-Script PREMIUM на WebAsyst Shop-Script. Естественно, информация о том, что обновление планируется платное, было встречено без особого удовольствия. Немного расскажу о том, почему мы так делаем.

Из применяемых моделей обновления программных продуктов наиболее распространены и применяемы две модели. Первая модель предполагает фиксированную цену за лицензию на программный продукт, и эта цена включает в себя определенный период доступа к обновлениям (как правило, один год). Далее можно продлевать доступ к обновлениям по некоторой цене, которая составляет, как правило, 20—30% от стоимости лицензии. Вторая модель предполагает фиксированную стоимость лицензии и бесплатные обновления в рамках текущего поколения продукта.

Среди большинства популярных веб-продуктов (особенно, CMS-систем) распространена первая модель — с платным доступом к обновлениям. Мы же будем развивать наши продукты по второй модели.

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

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

Жизнеспособность и действенность этой модели подтверждается богатым опытом «продуктов-монстров»: операционных систем Windows, Mac OS, графических редакторов Photoshop, офисных пакетов и т.д. Все эти продукты развиваются по второй модели. Если ты купил Windows XP, то получаешь все сервис-паки бесплатно, они делают твою систему стабильной, но в целом ты остаешься всегда с тем же продуктом. На новые поколения продукта (Vista, Windows 7) переходишь, только если они тебе нравятся.

Первая модель применима к сервисам аренды некоторого ресурса (например, для хостинга, веб-сервисов), но не к владению программными продуктами.

Мы тоже выбираем для Вебасиста вторую модель, и поэтому уже сейчас говорим о том, что переход на новый Shop-Script будет платным. В данный момент мы еще обсуждаем условия перехода и скидки, предусмотренные для владельцев лицензий на приложения WebAsyst текущего поколения. Безусловно, скидки будут. Только развитие по второй модели будет давать дополнительный стимул на создание качественно новых продуктов. Мы будем пытаться «прыгнуть через голову», сделать то, что опередит время.

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

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

Вот первое такое приложение — приложение «Списки дел»: http://www.webasyst.com/ru/apps/checklists/

Приложение «Списки дел» позволяет вести списки дел и отмечать, что сделано. Например, кому какие подарки купить, что не забыть сделать в офисе, что взять с собой в поездку, кого позвать на вечеринку, какие фильмы посмотреть и т.д. Списками можно пользоваться коллективно: доступ регулируется по спискам из приложения «Контакты» (скоро фреймворк позволит регулировать доступ напрямую из приложения). Посмотрите онлайн-демо нового приложения.

Приложение доступно для установки из «Инсталлера» внутри каждой установки Вебасиста, весит всего около 30 КБ и разработано действительно за два дня.

26 комментариев

Пока наша команда погружена в разработку фреймворка Вебасист, приложений «Сайт», «Блог» и «Поддержка», немного расскажу о том, как создавался проект Shop-Script.

shop.vofka.ru

Shop-Script я начал писать осенью 2001 года, то есть почти десять лет назад. Я тогда был студентом 2-го курса ВМиК МГУ и решил поизучать PHP. Писал код по вечерам в общаге ГЗ МГУ и написал первую версию скрипта примерно за месяц. Идея написать скрипт магазина появилась из желания сделать какое-нибудь полезное упражнение на PHP и заработать немного денег.

Упражнение переросло в профессию. Первая копия Shop-Script была продана 21 января 2002 года на дискетке за $70 ($50 — сам скрипт, $20 — установка на сервере заказчика). Встречался с заказчиком на станции метро «Кузнецкий мост» (даже помню его домен — starshop.ru — сейчас, правда, этот магазин уже не работает). Осталось отчетливое воспоминание: на деньги с первой продажи я купил шаурму.

Интересующимся я предлагаю скачать ту первую версию скрипта, которая продавалась за $49 аж до 2004 года: Shop-Script 1.0 (Zip-архив; 70 КБ). Скрипт был спроектирован неправильно априори, полностью построен на процедурном коде типа «лапша», однако, не требовал никакого вникания в архитектуру кода в принципе. Какой файл править — понятно из его названия. Я тогда не сильно беспокоился вопросами организации кода. Все проекты, которые делал до Shop-Script, были, в основном, академическими: интересные алгоритмические задачи, но не крупные проекты. Тем более, все былоне для веба. Впрочем, скрипт работал, стал приносить немного денег, а это позволило не искать постоянную работу и продолжать заниматься проектом.

Читать далее →