Для розминки я намутив собі консюмера, який буде хавати тоукени з вконтактє. Знайшов свого давно-закинутого аккаунта, намутив APP і почав тестувати. Так шоб ви собі орієнтувались на скільки це просто: 20 хв роботи і я вже всьо заработало. Дуже поміг модуль oauth2 (блог автора Івана Броткіна), там є всьо шо вам може бути потрібно.

Давайте буду попорядку всьо розказувати і код показувати. До вашої уваги контроллер, який буде приймати authorization_code від Вконтакте, і ходитиме з цим authorization_code по самий справжнісінький access_token.

Модельку вже самі собі можете написати, в мене модельки дуже екзотичні, так шо приводити їх тут нема сенсу. Собі якось збережете, якщо захочете.

А отак ми можемо взяти любу інформацію, на яку був виписаний тоукен з вконтактє чи нагадити на стіну. Access_token бібліотека сама підставить, в метод передаєте масив параметрів, які одразу ж будуть передані на АПІ Вконтакті. Як ви побачите по ссилці, то вконтактє трошки негарно розділяють методи АПІ, а саме через «.» (точку). В випадку сабжової ліби треба замість точки ставити _, він потім сам намутиться в точку.

Бібліотека власне хоститься тут. Нехай щастить при використанні.

На ліноді в мене тут нема місця жручим пам’ять тоннами апачам, гарненький собі стоїть nginx і всьо хвацько роздає. Так шо нармалди, будемо надіятись шо це все запрацує трошки швидше. Такий позитивний пост хочеться розбативи кусочком музики, яка вот буквально шойно підвернулась в інтернетах. Встрічайте, Ляпіс Трубєцкой з пісньою про добро і всяке всьо:

Click here to view the embedded video.

db.regions.find().sort({'name': 1});

де name — відповідно ім’я області. По крайній мірі так пише офіційна дока MongoDB на тему сортування. І тут відбуваються чудеса. Виглядає так, шо кириличні символи сказились і я отримую список областей в наступній послідовності:

1. Івано-Франківська область
2. Автономна Республіка Крим
3. Волинська область
4. …. тут все як положено…
5. Чернігівська область
6. м. Київ, міськрада
7. м. Севастополь, міськрада

Ну тобто всьо вроді правильно, спочатку великі літери, потім маленькі. Але шо Івано-Франківська область робить з самого початку. Ця штука мене харить дуже сильно, ще на телефонах Нокія (по крайній мірі в мене тільки Нокії були, то і про них говорю) теж буква «І» попереду букви «А».

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

А я поки рішатиму задачу наступним чином: зроблю додаткове поле sort_order (це не просто два слова, які стосуються до сортування, а переклад на англійську словосполучення «порядок сортування»), в якому цілими числами розставлю собі порядок, в якому я хочу сортувати сутності. Це буде безмежно круто, бо в майбутньому я зможу собі їх змінювати як захочу.

Такі діла. А взагальному я дуже приємно здивований з MongoDB.

P.S.: не я один такий недовольний. Бага в джирі монго.

git svn fetch

Дістане з svn репозиторію нові бранчі.

Також, якщо ще колись інтегруватимеш фейсбук на чиїсть блядські сайти — читай це.

Шо би такого розказати вам за мадженто? А, вот. API в них є. Soap або XML-RPC. Звісно не кошерно, був би REST всьо би було па другому, але тут і це канає. Так ось, є кастомні модулі і їм теж потрібно дати API. Реалізується це напрочуд легко. Добавляєте свою api.xml в etc каталог модуля, переопреділяєте назви методів і вуалля. Мадженто дає вам можливість мапити API calls одразу на методи моделі. Звісно для цього потрібно створити окрему модель, бо якщо ви хочете мапити на реальні моделі, то це буде накладно. Детальніше нема сил розказувати. Хіба якось потім.

Також хочу зауважити, шо працюю з Enterprise версією мадженто (да-да, баблисто і жирно, доступ до самого коду коштує 10кілодоларів в рік). Enterprise фічі не дуже здивували і порадували, при достатній підготовці їх неважко накатати на звичайне Community edition. Потішило сильно тільки ахтоматична генерація CrossSells і подібних продуктів. Ну це таке.

Вобщєм, дякуємо українським розробникам (і мабуть не тільки українським) за хороший продукт.

Недавно мав нагоду апдейтити вордпресс. Цей апдейт трішки відрізнявся від звичного для апдейта для користувача вордпрессу. По-перше, мені прийшлось апдейтити декілька інстансів одразу. По-друге, версія вордпресу, яка потребувала оновлення трошки не сходиться з офіційною. Так-так, ми на роботі такі погані хлопці, патчимо своїми злими патчами вордпресс, а шо робити. Але ж обновлятись то хочеться, нє? Добре, що патчів небагато. Кому цікаво програмістські будні, то читаєм дальше.

Перш за все, потрібно відмітити, що якщо ви використовуєте Subversion для контролю версій то ви в сраці, такий фокус провернути буде дуже неможливо, так дуже неможливо, що я навіть не знаю як це зробити. Але так як ми круті пацани і використовуємо давно git, то біди в нас зовсім немає. Вордпресс, як і багато інших популярних продуктів, мають свої git дзеркала svn репозиторіїв, де видно комміти, бранчі і взагалі все-все-все, тільки з зручним для користувача git інтерфейсом доступу. Один з таких знаходиться на GitHub (чуваче, ти спаситель і сохранитель, дякую тобі безмежно). Отож допустим, що в нас є свій репозиторій з Вордпрессом. Більше того, він взятий розумно з гіт дзеркала наведеного вище. Наш master звісно не збігається з master дзеркала, там куча своїх комітів і взагалі свій зовсім мастер. Робимо наступне, а потім вам поясню:

Спочатку ми добавили дзеркало до своїх ремоутів, а потім створили гілочку integration, туда змерджили апдейтнутий ВордПресс з дзеркала, розрезолвили всі конфлікти, які появились (мабуть у вас вони теж появились, проте цей крок пропущено, мерджити конфлікти вміють навіть самі затянуті svnщики, більше того, вони це добре вміють, бо за тиждень до мерджа серйозної гілки моляться і роблять жертвоприношення). Коли все змерджили звісно потрібно потестувати. Потестували? Нє, я останній раз питаю, точно потестували? Тоді далі все просто:

Це прокатає всі комміти, з гілки integration в master. На цьому наш маленький урок закінчився. Такі діла, гарного вечора.

sudo apt-get install php5-pear libcurl3-ssl-dev php5-dev mongodb

Тепер треба поставити pecl extension для підключення mongodb адаптора до php:

sudo pecl install -Z mongo

Параметр -Z приходиться добавляти з Убунти 10.04 здається. Гіркий досвід роботи з Magento і його розширеннями. Власне раді цього вся стаття. Ну а тепер стрічку

extension=mongo.so

Потрібно додати в php.ini. Готовченко.

Останню декаду ми були свідками другої ітерації веб розробки і дизайну. Веб сайти перетворились у веб додатки і рідко тепер зустрінеш новий веб проект, який би не включав в себе деякий елемент інтерактивності. Зростаюча складність програмного забезпечення для веб змушує розробників більше часу приділяти структуризації і проектуванню продуктів.

Та ж зростаюча складність стимулює сучасні програмні розробки опиратись на виділені сервіси для виконання завдань, які потребують багато процесорного часу. Більше того, запровадження хмаркових сервісів від Amazon, Google та інших дозволяє розробникам порівнянно зменшити навантаження процесорів на власних серверах. Кожен сервіс зазвичай проектується як окрема частина програмного рішення, що виконується на власному домені з власними ресурсами.

Набагато важче переконати замовника використовувати більше ніж одну частину програмного рішення, особливо коли працюєш з малими бюджетами. В цих ситуаціях я з’ясував, що багато клієнтів не вважають масштабування проблемою. Вони “очікують” дня, коли масштабування стане проблемою.

Щоб зменшити початкові інвестиції, зазвичай вирішується розробляти сайт як єдиний програмний продукт, який включає в себе всю необхідну функціональність. Таке рішення призводить до проблем, якщо продукт стає популярним за короткий проміжок часу (в мене особисто є неприємний досвід рефакторингу існуючого коду, який не масштабувався). Також подібний підхід може погано відбитися в грошовому і часовому еквіваленті, коли доведеться змінювати архітектуру програми, яка не масштабувалась. В ідеальному світі програмні продукти повинні розвиватись органічно і без одноразових вливань великих сум в цьому процесі.

Найпопулярнішим паттерном на даний момент, мабуть, є паттерн MVC , який асоцієються з розробкою веб додатків на усіх платформах.

Паттерн HMVC

MVC та HMVC

Паттерн HMVC являється прямим розширенням MVC, який вирішує багато проблем з масштабуванням, зазначених вище. Вперше згадка про HMVC паттерн датується липнем 2000 року на сайті JavaWorld в статті HMVC: The layered pattern for developing strong client tiers. Велика частина статті зконцентрована на перевагах використання HMVC для графічного інтерфейсу користувача. Також зустрічаються натяки, що автори власне заново інтепретували паттерн Presentaion-Abstraction-Control (PAC), описаний в 1987 році. Стаття на JavaWorld наводить детальні пояснення того, як HMVC може допомогти при проектуванні десктопних програм з графічним користувацьким інтерфейсом. В цій статті ми зосередимось на тому, як HMVC може використовуватись для створення веб додатків, що легко масштабуються.

HMVC складається з колекції традиційних MVC тріад, які оперують як один додаток. Кожна тріада повністю незалежна і може виконуватись без наявності будь-якої іншої тріади. Всі запити до тріад повинні виконуватись через інтерфейс контроллера, ніколи не завантажуючи моделі чи бібліотеки поза власним доменом. Фізичне розташування тріад в хостинговому середовищі не важливе, поки тріада доступна з усіх інших частин системи. Відмінності HMVC заохочують до перевикористання існуючого коду, спрощення тестування відмінних частин системи, а також забезпечують легке вдосконалення і розширення системи.

Для успішного проектування додаку, що реалізовує HMVC паттерн, критичним є поділ функцій на системи. Кожна з систем буде однією MVC тріадою всередині більшої HMVC програми, незалежно управляючи методами презентації і збереження інформації. На данний час небагато фреймворків мають підтримку HMVC без додаткових розширень або використовують для цього непридатний Фронт Контроллер. Kohana PHP версії 3 — фреймворк, що спроектований одразу з підтримкою HMVC в ядрі. Я буду використовувати Kohana 3 для усіх прикладів коду в даній статті.

Kohana 3 використовує об’єкт Request для виклику контроллерів. Запити можуть бути як внутрішніми (до контроллерів додаку), так і зовнішніми (до веб сервісів з прозорим використанням одного і того ж класу Request^[1]). При масштабуванні MVC тріади потрібно змінити тільки один параметр запиту.

Внутрішній запит потребує правильного маршруту, що вказує на контролер і дію. Створення запиту до зовнішнього ресурсу відрізняється тільки наданням повного URL до нього. Ця функціональність дозволяє швидко змінювати внутрішні на зовнішні запити і навпаки, забезпечуючи легке масштабування. Використання класу Request в Kohana для отримання інформації з внутрішніх контроллерів може здатись подібним до форвардингу дій в інших фреймворках, таких як Zend. В дійсності ці два методи доволі різні. Request в Kohana має здатність оперувати особливі запити в ізоляції. Форвардинг дій функціонує іншим чином: кожна дія контроллера існує в рамках основного запиту. Наступний приклад демонструє це:
Наведений приклад демонструє незалежність, що надає об’єкт Request. Початковий HTTP GET запит викликає контроллер Default дію index, який в свою чергу викликає POST запит до контроллера Log дії access. Дія index встановлює три POST змінні, які не доступні в глобальній змінній $_POST першого контроллера. Коли виконується другий запит, $_POST містить в собі змінні, надані попереднім кроком. Зверніть увагу, як після виконання $log->execute(); зникають $_POST змінні в основному контроллері. Для таких динамічних інтеракцій в інших фреймворках потрібно використовувати новий інструмент для запитів, як наприклад cUrl.

Gazouillement, сервіс статусів

Для демонстрації потужностей Ієрархічного MVC давайте подивимось на приклад гіпотетичного сервісу оновлення статусів, який працює подібно до Twitter. Gazouillement спроектовано навколо сервісно орієнтованої архітектури (SOA) для забезпечення відокремленості двигунів повідомлень і відношень від веб інтерфейсу.

Схема роботи сервісу

Трафік до сервера буде відносно малим спочатку. Сервіс новий і публіка не здогадується про його інсування. Тому зараз безпечно виконувати всю логіку додатку на одному сервері. Давайте реалізуємо контроллер для відображення домашньої сторінки користувача. На цій сторінці будуть видно останні статусні повідомлення користувача і людей, за якими слідкує користувач.

Тепер розглянемо що ж робить Controller_Index::action_index(). Спочатку дія пробує завантажити користувача посилаючись на параметр user, що наданий в URL. Якщо користувача не існує, то відображається 404 сторінка. Новий запит за повідомленнями створюється з використанням імені користувача як значення параметру в URI запиту і просячи про відповідь у xhtml форматі. Інший запит виконується подібним чином, знову ж в xhtml форматі. По закінченню цих запитів об’єкт View створюється з значеннями користувача, повідомлень і зв’язків.

Так як існуючі повідомлення і зв’язки завантажуються через новий запит, цілісна логіка додатку залишається абстрактною не прив’язуючись до веб сайту. Ця архітектура надає дві значних переваги над традиційним виконанням контроллера:

1. Жодна частина логіки сервісу повідомлень не стосується контроллера. Контроллер тільки просить повернути результат виконання в xhtml форматі. Ніяких додаткових бібліотек або розширень не було завантажено під час виконання контроллера.
2. Кожен контроллер відповідальний за одну конкретну задачу, забезпечуючи значно легше написання unit тестів для контроллера.

Через абстракцію прикладу, який ми щойно продемонстрували, неможливо побачити що ж ці сервіси насправді роблять. Тому давайте розглянемо контроллер сервісу повідомлен, починаючи з маршрута, що зазначений в bootstrap.php для внутрішньої обробки запитів до повідомлень. Клас Маршрута в Kohana займається обробкою внутрішніх URI, визначаючи елементи URI згідно з параметрами контролера і дії.

Так встановлюється маршрут до сервісу повідомлень, що в даний час знаходиться в домені головного додатку. URI запиту до messages/find/samsoir.xhtml буде направлене на контроллер Messages, дію Find з параметрами ‘user’ => ‘samsoir’, format => ‘.xhtml’.

Детальний процес отримання повідомлень користувача показано в контроллері Controller_Messages. Всі методи і властивості стосуються виключно контексту повідомлень, включаючи зв’язок з користувачем. Давайте покроково проаналізуємо код контроллера повідомлень для розуміння що ж відбувається.

Об’єкт Request викликає метод before() перед зазначеною дією. Це дозволяє вставити код, який буде виконано перед будь-якою дією, нормалізуючи загальні задачі контроллера. Метод before() спочатку перевіряє, чи підтримується наведений формат, після чого валідує дані користувача. Припустимо, що before() виконався без Exceptions, тоді об’єкт Request викликає дію find(). find() завантажує повідомлення користувача з бази даних перетворюючи їх в об’єкт Model_Iterator. Важливо зазначити, що об’єкт ітератора буде порожнім, якщо в користувача не знайшлось жодного повідомлення. Нарешті ітератор повідомлень передано до метода парсингу prepare_response(), що форматує інформацію на вивід і встановлює заголовки згідно до зазначеного формату.

Обидва контроллери Controller_Index і Controller_Messages виконались під час одного запиту до додатку, хоча кожен з контролерів не знав про існування інших. Будь-який розробник міг би прочитати цей код і зрозуміти, що і де виконується. Тут необхідно підкреслити ще одну з якісних відмінностей HMVC — мейнтейнебіліті.

Після завершення написання коду інших сервісів, директори компанії задоволені першою ітерацією розробки і дають зелене світло для розгортання сервісу для обмеженої бети. Через декілька тижнів програма повністю готова до використання. Наступні місяці відбуваються подальші покращення і оптимізації по усій архітектурі, так як клієнтська база неухильно зростає.

Ефект Стівена Фрая

Стівен Фрай (@stephenfry) зараз один з найвідоміших користувачів Twitter, за яким слідкують понад 1.3 мілліона людей. В минулому, Стівен міг зносити веб сайти просто відправляючи посилання в повідомленні, що спричиняло DDoS атаку на сервер.

Gazouillement ріс останні декілька місяців. Хоча час відклику більшості запитів виріс, він все ще вміщається в прийнятні норми. Потім користувач Twitter з кількістю фолловерів близькою до Стівена Фрая відправляє повідомлення, що містить в собі URL нашого Gazouillement. Наша система потрапляє в серйозні неприємності.

Першою проблемою буде обвал трафіку на сервер. Якщо раніше наша програма обробляла декілька сотень запитів за секунду, то тепер їй доведеться обробляти багато тисяч. Скоріш за все наш Gazouillement перевантажиться, впаде і потягне за собою увесь сервер. Очевидно додаток потребує оптимізації і вдосконалення для обробки такої кількості трафіку.

Аналіз коду для покращення швидкодії – далеко не просте завдання. Починати його потрібно з замірів і профайлингу. Щоб включити рідний профайлинг Kohana достатньо встановити в bootstrap.php наступну змінну:

Також до виводу варто зачепити результати роботи профайлера. Це легко зробити в методі after() контроллера, забезпечуючи вивід профайлера на всі дії.

Коли профайлинг включено, наступне буде додано до виводу усіх дій контроллера.

Нажміть для деталей

Профайлера показує результати тестування по виконанню запиту, групуючи контексти фреймворку разом, включаючи інітіалізацію, запити, запити до бази даних та інші операції співставлені з виділенною пам’яттю і процесорним часом. Так як показується створення кожного запиту, знайти той запит, який більше всього забирає часу на виконання.

Масштабування Gazouillement

Аналіз швидкодії всього додатку Gazouillement показує, що отримання повідомлень — вузьке місце. Команда розробки рефакторить і оптимізує код тріади MVC, яка відповідає за повідомлення настільки, наскільки це можливо, але необхідні прибавки в швидкодії так і не досягаються. Після вичерпання опцій вертикального масштабування по збільшенню пам’яті та процесорів на сервері, директори компанії погоджуються масштабувати додаток починаючи з системи повідомлень.

В традиційному MVC додатку новий сервіс проектується, розробляється, проходить тестування і тільки потім розгортаться. Цей процес може зайняти тижні, а то й місяці, що потребує великих інвестицій. Власне це нова частина програмного продукту, яка буде інтегрована в Gazouillement.

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

Код вище показує невелику зміну, що була потрібна Controller_Index::action_index(), що обслуговує публічний веб сайт. Замість відправки запиту на внутрішні контроллер і дію, запит відправляється на інший сервер, який працює на сабдомені http://messages.gazouillement.com/. Те, що б зазвичай виглядало як велика архітектурна перешкода, зараз стає маленькою зміною. Тестування, зв’язане з цією зміною порівняно менше, так як змінилось не багато коду.

Це тільки один з прикладів, як паттерн Ієрархічний MVC дозволяє розробникам проектувати веб рішення, що можуть масштабуватись як вертикально так і горизонтально з самого початку. Ми побачили, як працювати з об’єктом Request для отриманя правильної інформації через простий інтерфейс. Нарешті ми побачили, як традиційні MVC тріади можуть розширюватись і можемо з впевненістю сказати, що об’єкт Request в Kohana робить це масштабування доволі простим завданням. Ціна, закладена в масштабування програмного забезпечення, може бути порівняно малою через мінімальні зміни, що ощасливить директорів вашої компанії.

Для більшої інформації про Kohana PHP відвідайте офіційний сайт. Документація по Kohana. Скачати Kohana.

Зноски

1. Згаданий клас Request, що використовується в прикладах, є частиною гілки ядра Kohana, що на даний момент знаходиться на стадії розробки. Ви можете знайти його у форці.