Так, нфпример, в последней работе очень бросающийся в глаза косяк с отражением:

Случайно ни у кого из вас нет xbox или sp2 дать в аренду на пару деньков? :)

Заранее благодарен

Практически сразу бросилась в глаза двойственность языка. С одной стороны разработчики старались упростить языковые конструкции, с другой – добавили странные для меня типы данных. Так, например, в питоне не оказалось привычного всем цикла for – его заменили конструкцией for X in Y (эквивалент foreach) + снабдили функцией range() для кол-венной итерации. Разработчики не ввели такой привычный оператор switch, а вместо этого сократили if/elseif/else до if/elif/else, что позволило структурировать условия в удобный столбик. Авторы добавили удобные операции с массивами и строками (получение и замещение срезов) и ввели оператор «*» для повторения символов. Но при всем этом, зачем-то были введены словари, таплы, списки, последовательности и наборы, что могло слихвой быть заменено словарями (хотя может я еще чего-то не понимаю).

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

Таких мы беспощадно увольняем.

есть пути:
/users/$username
и
/users/$some_action

Как правильно организовать роуты в системе ZF?

Мое решение на данный момент:

UsersController::view
UsersController::someAction

routes.php

->addRoute("user-view", new Zend_Controller_Router_Route(
    "users/:username/*",
    array(
        "controller" => "users",
        "action" => "view"
    )
) )

UsersController::view

try {
    $user = $this->getUserFromRequest();
 
} catch ( PageException_NotFound $e ) {
    $action = $this->getRequest()->getParam( 'username' );
    $this->_forward( $action );
    return;
}

внешний вид результата работы плагина

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

Изменения в отличае от оригинала:

• теги могут быть многословными
• тег создается при нажатии на enter или запятую
• улучшено поведение интерфейса

Скачать и поиграться

Работа в офисе в 5 минутах от метро «Левобережная». Удобное кресло, большой монитор, чай, кофе, книги.

Требования

• Самостоятельность и ответственность. Нужно уметь делать свою задачу хорошо, до конца и вовремя. Не искать причины, почему не получается, а делать так, чтобы получалось.
• Умение писать чистый и качественный код. Так, чтобы его было легко понимать остальным участникам проекта, поддерживать и использовать повторно.
• Понимание ООП (зачем оно нужно, как и когда пользоваться).
• Умение и желание быстро разбираться в новом (чужой код, технологии, API, …)
• Желательно знать xhtml, css. Верстать не придётся, но понимать что и почему – нужно.

Технологии

Проекты пишутся на PHP с использованием Zend Framework, Doctrine, PHPUnit. Знать это всё не обязательно, но тогда нужно будет разобраться.

З/п от 1500 до 2000$, в зависимости от.

связаться можно по почте: job@strangecompany.ru

Сторона клиента

Больше всего кода прийдется написать именно тут. Хотя все зависит от сложности выборки на стороне сервера. Если воспользоваться готовым поисковым механизмом типа Sphinx, то писать прийдется крайне мало, а вот на клиенте, как я говорил, прийдется попотеть.
Итак, представим что у нас вполне конкретная задача: фильтровать фильмы по неким параметрам. Для нашего примера ограничимся жанром и полем сортировки записей (по году выпуска или по рейтингу).

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

Графический интерфейс тоже усложнять не станем. В столбик сделаем группу чекбоксов и селект для выбора сортировки, под ними список отфильтрованых результатов.
Теперь можно нахардкодить много кода, который проверяет каждый элемент, читает какие-то его атрибуты, создает строку запроса на сервер и отправляет все для получения данных, но мы поступим иначе: сначала мы создадим два класса, которые будут представлять сущность каждого типа выбора. Чекбоксами мы можем выбрать несколько значений для отображения, а селектом только одно. Таким образом нам нужны классы MultipleSelect и SingleSelect. Их интерфейс на диаграмме.

Модели еденичного и множественного выборов

Как видно из диаграммы, интерфейсы классов идентичные. Они оба обладают методами select(), getSelected() и reset(). Отличия, как принято в ООП, наблюдаются только в реализации. Класс SingleSelect в методе select() заполняет указанным значением приватную переменную selected, и таким образом у него выбран всегда только один конкретный вариант, который возвращается методом getSelected().
MultipleSelect же в свою очередь при каждом вызове select() добавляет переданный идентификатор во внутренний массив selected, и метод getSelected() возвращает этот массив. Дополнительный метод unselect(), как можно догадаться, удаляет из массива выбранных значений указанное.
Методы reset() в обоих случаях ведут себя одинаково – они очищают приватную переменную от установленных значений.

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

// создаем объект выбора для жанров
var genres_selector = new MultipleSelect();
 
/** 
 * для каждого чекбокса в списке жанров добавляем событие на нажатие, 
 * которое отмечает выбранный жанр в объекте выбранных, либо удаляет его от туда
 */
$$( 'ul.genres input[type=checkbox]' ).each( function ( cb_element ) {
    cb_element.addEvent( 'click', function () {
        if ( this.checked ) {
            genres_selector.select( this.get( 'value' ) );
        } else {
            genres_selector.unselect( this.get( 'value' ) );
        }
    } );
} );
 
 
// создаем объект выбора для сортировки
var sort_selector = new SingleSelect();
 
// отмечаем выбор, при изменении значения в селекте
$( 'sort-selector-el' ).addEvent( 'change', function () {
    sort_selector.select( this.get( 'value' ) );
} );

Теперь при взаимодействии с пользовательским интерфейсом наша модель заполняется данными.

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

Класс для получения с сервера отфильтрованных данных

Какой принцип действия у этого класса?
После инстанциирования он заполняется объектами фильтра, каждому из которых присваивается название атрибута (второй параметр в методе addSelector() ). При добавлении нового селектора, ему при помощи шаблона «Наблюдатель«, добавляем слушателя на события onSelect, onUnselect и onReset, которые бросаются при каждом вызове методов select(), unselect() и reset() соответственно.
При каждом из этих действий FilterRequestor должен запросить данные с сервера. Для этого он использует метод doRequest(), по окончании работы который бросает событие onSuccess, передав данные как аргумент функции-слушателю.

Все. Осталось получить массив отфильтрованых данных (либо готовый HTML) и вставить на место старого.

О серверной части говорить пока не стану – там все должно быть понятно. Ну а если нет – пишите и эту тему раскрою более детально.