The Whiz

Использовал для одного проекта — ivanribas.com/evento/
Продукт не бесплатен, но очень хорошо написан, красив и удобен в использовании и модификации. Сэкономил мне кучу времени.
На мой взгляд значительно лучше приведённого вами примера.
П.С Если будет интересно, через личку могу дать вам примеры сайтов основанные на этом продукте.

Я пробовал и так, и сяк. С nginx + uswgi вещи получаются проще и как-то прямолинейнее.

Даже любимый апачерами массвиртуалхостинг оказывается проще и универсальнее — так я легко могу каждому хосту выдать отдельню конфигурацию и даже отдельную версию php, а также python (2.7/3.2), ruby и что там ещё uwsgi поддерживает.

Стоит конечно, рельсы рекомендуют версию 1.9.3

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

Что бы останавливать меню в конце, то надо делать так:
alexeyshishkin.net/test/fiddle.htm

Если просто скрывать, то просто добавьте в section overflow: hidden

Тз идеальное если исполнители поняли, что вы хотите получить на выходе.

ТЗ + Система управления проектами (PM, мы используем feng office) + система контроля версий (SVN).
На первом этапе составляется ТЗ с планом работ и детализацией.

ПП: разработка модуля обработки испытания:
1. Адаптация модели данных: 4 часа,
2. Выборка из протокола данных: 2 типа протоколов по 2 часа на каждый + 1 час на отладку = 5 часов,
3. Разработка GUI: 3 контрола с графической обработкой * 4 часа на каждый + 2 контрола для таблиц * 1 час на контрол + 1 контрол общей информации * 0.5 часа = 14.5 часов
4. Тестирование GUI: 3 графической обработки * 0.5 часа = 1.5 часа
5. Разработка отчета: дизайн 16 часов + верстка 8 часов + отладка 16 часов = 40 часов
Итого: 60 часов

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

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

При разработке вдвоем показала себя хорошей практика 1-го коммита в 1-4 часа в ветку и каждые 4-7 часов слияние веток. Большие изменения не накапливаются и оба работаем над актуальной версией. Для своих личных проектов стараюсь придерживаться такого же ритма. Главным преимуществом при разработке в одиночку является возможность быстрого отката последних изменений, да и затраты времени считать удобно.

Максимально допустимым сроком комита является 8 часов (1 рабочий день). Если интервал коммитов превышает этот срок, то возможны только 3 варианта: 1. Работа стоит, 2. Возникла серьезная проблема, 3. Задача слишком большая и нужно было ее более подробно детализировать. Если возникает именно 3-й случай, то нужно проверить ТЗ на похожие задачи и детализировать их. Так же коммит должен идти на каждое исправление бага, с обязательным оповещением остальных о необходимости срочно получить свежую версию.

Минимум 1 раз в неделю детальное обсуждение состояния проекта всем отделом(компанией, группой, нужное подчеркнуть), желательно с чек-листами проверки работы программы. Так же 1 раз в месяц можно требовать отчет о проделанной работе в письменном виде, возможно с пакетом документации на программу. Главное не забудьте внести в ТЗ минимум 4 часа в месяц на него (если с документацией, то минимум 8-16).

PS. Что касается выбора разработчика, то лучше всего попросите помочь в выборе знакомого программиста. Если его нет, то попросите кандидата прислать пример кода и оцените его на качество форматирования. Правила форматирования найти очень легко. Или попросите оценить код любого программиста, например с хабра, какого нибудь форума или еще откуда нибудь.

PSS. Удачи!

1)Самый важный параметр выбора на данный момент это опыт, смотрите портфолио и собственно все биржи позволяют смотреть предыдущие контракты и оценки за них.
2)В любом случае баг трекер или таск менеджер, для кода гитхаб или битбакет, всегда видно когда и сколько закоммитил программист, и нет отмазки я долго пишу такой то код, если нет коммитов то ничего не пишет.
3)Для программиста я выставляю деадлайн, после оценки задачи, если задача на восемь часов и программиста я беру на фуллтайм, я ставлю деадлайн завтра, на мой взгляд наиболее оптимальная и всем понятная система, в жизни конечно все сложнее, так как есть внешний взаимодействия, но основной принцип остается прежним.

Система управления нужна, даже если сам и менеджер и программист в одном лице.
Но хватит простейшей. Успешно использовали Trac (http://trac.edgewall.org/) в команде в 5 человек.
Можно заняться самостоятельной установкой и обслуживанием (не сложнее апача настроить), а можно использовать готовые Trac-хостинги.
Удобство — интеграция системы управления с системой контроля версий.

В последнее время используем bitbucket.org — вполне достаточно для нужд небольшой команды.
Приятная мелочь — возможность хостинга приватных проектов с командой до 5 человек.

Но все это — лишь инструменты, чтобы ими пользоваться надо наладить процесс управления. Определенно нужны правила, хотя бы на листке А4, как сказано выше ежедневный коммит — хороший кандидат для этих правил.

В своих удаленных проектах я использовал элементы скрама — планирование, митинги, демонстрации. Полнота реализации зависит от ваших возможностей и потребностей.
Например:
1. Собираемся в 20 февраля на планирование, я определяю дату сдачи спринта, давайте возьмем неделю в качестве тренировки, потом сможете увеличить продолжительность, по мере роста доверия к оценкам. Определяем количество сторипоинтов в спринте исходя из ваших договоренностей с исполнителем о том, какое время он будет уделять работе. Возьмите поправку для себя, аналог фокус-фактора (мое личное предпочтение — не обсуждать фф с удаленными исполнителями, потому и аналог), поправка для профессионала в слаженной команде — 0,7 — 0,8, для профи в новой предметной области — около 0,5. В процессе работы уточните. К примеру насчитываем 20 часов, с учетом фф 0.5 = 10 ч/ч. Устанавливаем дату сдачи спринта 27 февраля (заметьте, еще до того как определили, что именно делать).
2. Исполнитель оценивает задачи в часах, в реальных в отличие от скрам. Исходя из приоритетов и учитывая целостность результата по окончании вы набираете задачи на спринт, можете зафиксировать их в версии или milestone в trac.
3. Ежедневно (или с другой периодичностью, но лучше ежедневно) в установленное время собираетесь на митинг 5-15 минут, исполнитель проговариает три вещи: что сделал вчера, что делает сегодня, с какими затруднениями столкнулся. Это самое важное мероприятие из всех, стимулирует к работе, позволяет заранее вскрыть проблемы. На этом мероприятии обычно задачи передаются в тестирование, но если тестировщика нет, вероятно замените его вы, в таком случае вы принимаете выполненные задачи и на следующий день на митинге отчитываетесь об успешной их проверке или возвращаете их исполнителю.
4. 27 февраля собираемся на демонстрацию, позвольте самому исполнителю отчитаться о проделанной работе (показать реализованный функционал по пунктам), вероятно он расскажет о недоработках, идеях, проблемах, где-то вскроется неправильно реализованная логика. (В случае, когда вы сам тестировщик — пункт спорный, но некоторое мероприятие на сдаче, хоть и короткое я рекомендовал бы проводить).

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

Самая последняя, 6.0.2.

Несколько примеров навскидку:







И такие артефакты повсюду. Даже в айтюнс сторе иногда похожее бывает. А в хроме такого нет, видимо, он не системный, свой собственный webkit юзает.