Коллеги! Началось традиционное голосование за доклады DEVCONF 2012!
Всего была подана 61 заявка.

• Общая секция — 18
• php — 16
• js — 8
• ruby — 6
• python — 4
• perl — 1
• Мастер-классы — 7

Скажи ДА! Интересным и полезным докладам на DevConf 2012.

Хабы: Тестирование, Веб-разработка, Ruby

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

Почему Spine?
Потому что «Specs Inline» и потому что(imho) для рационального ПО, тесты играют роль позвоночника.

Многим это статья может показаться повтором и они будут отчасти правы,
так как данная статья основана на пятой части знакомства с Presto.
А сам Spine вырос из и стал на замену PrestoTest фреймворка.

И зачем повторять то что уже написано?
Просто Spine существенно отличается от PrestoTest и соответственно данная статья тоже отличается от предыдущей, процентов на 80.
Да и представлять новый гем в пятой части знакомства с Presto как-то не корректно.

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

Мотивация:

1. Визуальный контакт. Я хочу писать спецификации одновременно с кодом
   и чтобы они физически находились рядом, в том же файле или папке, но никак не в амбаре.
   
2. Простые вещи должны остаться простыми.
   foo.should == bar никак не заменит foo == bar
3. Я не хочу ни запоминать список синтетических заменителей простых вещей
   ни работать с документацией под рукой.
   
4. Никаких хаков. Тестируемые объекты и базовые классы Ruby должны остаться в
   первоначальном состоянии.
   

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

Хабы: Веб-разработка, Ruby, Google Chrome

Взаимодействие с браузерами никогда не было работой для слабонервных: около полудюжины различных API, различные механизмы IPC, и разные возможности у разных поставщиков. Такие проекты, как WebDriver, пытаются абстрагироваться от этой сложности, к тому же в Сети можно найти десятки других «безголовых» драйверов, использующих WebKit или иные движки. В настоящее время в работе даже находится спецификация W3C на WebDriver.

Инструментирование Google Chrome

Тем не менее, в то время, как создание общего решения является сложной задачей, оказалось, что инструментирование Chrome очень просто, — как я недавно обнаружил при исследовании некоторых вопросов, связанных с сетевыми задержками. Начиная с 18 версии, Chrome теперь поддерживает протокол удалённой отладки v1.0, который предоставляет все возможности браузера с помощью обычного WebSocket!

/Applications/Path To/Google Chrome --remote-debugging-port=9222 # OSX
$> curl localhost:9222/json

[ {
   "devtoolsFrontendUrl": "/devtools/devtools.html?host=localhost:9222&page=1",
   "faviconUrl": "",
   "thumbnailUrl": "/thumb/chrome://newtab/",
   "title": "New Tab",
   "url": "chrome://newtab/",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1"
} ]

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

Хабы: Тестирование, Веб-разработка, Ruby

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

Мотивация:

1. Визуальный контакт. Я хочу чтобы спецификации физически находились рядом, в том же файле или папке, но никак не в амбаре.
2. Умные браузеры. Когда я пишу спецификацию для определённого action-а, браузер должен определять адрес автоматически.
3. Никаких хаков. Тестируемые объекты и базовые классы Ruby должны остаться в нетронутом состоянии.

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

Хабы: Хостинг, Веб-разработка, Ruby on Rails

Доброго времени суток, хабровчане!

Как переехать на VDS за 15 минут и не углубляться в изучение nginx, unicorn и capistrano. Пошаговая инструкция под катом. Читать дальше →