Web. Мы похоже, но все же мы разные.

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

Предположим такую ситуацию. Имеется возможность выбрать несколько значений, скажем, для фильтрации.
Пояснение:
Когда мы обращаемся к странице, мы не пишем параметры, т.е. никто сам не напишет: http://www.blogger.com/post?blogID=48276.

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

На этот случай в web-е есть прием которому лет 100. =)

Создаем скрытый элемент input: <INPUT TYPE=HIDDEN NAME=customerid VALUE="c2415-345-8563">

Пусть по умолчанию у него значение false: <input type=hidden name='deselect-all' value='false'>
Когда не один элемент фильтра не выбран при помощи javascript-a устанавливаем значение true. Включаем это поле в качестве параметра при отсылки запроса на сервер. Когда какой-то элементы фильтра выбран при помощи javascript-a устанавливаем значение false.
Вот и все решение. Если подумать головой, можно найти достойное применение этому методу.
Всего хорошего.

Делить так делить

О чем пойдет речь? Поговорим о дизайне. Я конечно не дизайнер, но для того, что бы дизайнер ставил всякие рюшечки и задал свою цветовую палитру, требуется что-то такое!
Здесь не будут рассказаны тайны мироздания, просто зарисовка из жизни.
В любом web-приложении есть:

• страничка с разметкой HTML;
• таблицы стилей CSS;
• javascript-ы;
• сервер.

Что требуется? Нужно сделать так, чтобы смена дизайна была легкой процедурой.
Опустим умные речи про то, как все работает в web и перейдем к делу.
Все оформление и дизайн в хорошем случае находится в css. Вот и все меняй не хочу. Но там много всего такого, что если неопытный человек начнет изменят, то будет "северный писец" =).
Выход до банальности прост.
Создаем новую иерархию каталогов со звучными названиями, например, цвета, рисунки, кнопки и т.д.
В этих каталогах размещаем новые css-файлы с говорящими названиями, основной фон, кнопки, текст и т.д.
В сss-файлах создаем css-классы с говорящими названиями (фон, кнопка увеличит и т.д). В эти классы переносим только 2 - 3 строчки отвечающие за дизайн (путь к картинке и смещение в ней, цвет фона и т.д), в основном классе их комментируем и пишем, что перенесены туда-то.
Новые css-классы дописываем к тем, где используются основные.
Для рисунков можно придерживаться принципа: cоглашение вместо конфигурации, это означает, что в вместо бесконечных настроек и кучи вариантов есть определенные соглашения о том, как надо делать. Это можно реализовать как, все иконки для кнопок размером 16*16, все иконки лежат в каталоге таком-то с таким-то именем и расположением картинок внутри.
Вот и все. Жизнь становиться прекрасной.
Нужно изменить иконки: рисуем новую картинку и сохраняем куда надо. Если изменяем одну картинку, а остальные не трогаем, то идем в css находим нужный класс меняем путь к картине, обнуляем смещение.
Основные проблемы:

• стало больше css-классов (много мест где менять);
• все, что раньше относилось к одному css-классу теперь размазано по нескольким (сложность);
• для картинок повторение атрибута пути к файлу (дублирование);
• и т.д. =)

Но теперь у вас главный плюс: удобство при изменении дизайна =)

Мелочь из JavaScript

Как корректно использовать точку с запятой в JavaScript-е?
Читаем Всё, что надо знать о точке с запятой

Рабочий момент: рефокторинг в виде отформатировать текст знаком всем =)
А что будет, если внешне изменение не значительное, а его суть коварна.
Будет два варианта: 1. вернуть назад и не трогать ничего (с газом, без газа - попил водички...) =)
2. узнать, обучить и стать специалистом =). В помощь спецификация
Второе круче.
Поэтому, запомним кое-что про ограниченные порождения:
Практический совет для программистов ECMAScript:

• постфиксные операторы "++" и "--" должны быть на одной строке со своим операндом;

• выражение в операторах return или throw должно начинаться на одной строке с токеном return или throw;
• идентификатор в операторе break или continue должен быть на одной строке с токеном break или continue.

Примеры:

i
++   это будет как  i; ++j
j

Так нельзя:

return
          {i:i, j:j}
Так можно:

       return {
           i:i, j:j}
    return (
           {i:i, j:j})
    return {i:i
           ,j:j}

На последок:

continue innerloop // верно
 
continue
    innerloop;     // неверно
// ThrowStatement : throw [no LineTerminator here] Expression ;
throw                                          // ошибка разбора
  new MyComplexError(a, b, c, more, args);
// В отличии от return, break, continue, 
// выражение после throw обязательно, 
// поэтому вышеприведённое неотпарсится вообще.
throw new MyComplexError(a, b, c, more, args); // верно
throw new MyComplexError(
    a, b, c, more, args);                      // тоже верно
// любой вариант с throw и new на одной строке верен.
 

Launchy

Что это за зверь: http://copiousfreetime.rubyforge.org/launchy/
Линка на код: https://github.com/copiousfreetime/launchy

Основная идея:
Иногда бывает так, что тест BDD валится, и еще в добавок сложно определить почему, точнее приложенные усилия не стоят потраченного времени. Другое дело, если взглянуть на страницу, на которой тест (например Cucumber) не нашел кнопку «Создать». Для этих целей можно использовать launchy.


Как использовать:
Для начала пишем определенный код.

Например для Cucumber

    Then 'WTF?' do
      save_and_open_page
    end

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


На основе статьи "Rails: Хватит отмазываться, начинаем BDD-ить!": http://habrahabr.ru/blogs/webdev/111480/