Дмитрий Евграфович

Да всем плевать.
Разработчикам ваша мега-идея покажется дурью в 99% случаев.

Видимо трогали, или вы или хостер.

А вообще вам на Фрилансим
Или в Гугл.

Я пользуюсь Photoshop CC, там есть автоматическая генерация ассетов. Переименовываю нужные мне слои/шейпы/папки в виде "imagename.png", а затем генерирую библиотеку изображений средствами самого фотошопа. Если нужно разделить конкретное изображение на две (или больше) части, пользуюсь layer via cut и так же переименовываю получившиеся фрагменты.

Фрилансеры ничем не отличаются от любого другого наёмного труда на раз.
Вот допустим копаю я например яму 2 на 3 глубиной 1 метр, беру за это 1000р. и укладываюсь в 3 часа.
Получаю заказ на яму, и как обычно 3 часа и 1000р. обговариваем и начинаем. А в том месте бац и 2 булыжника больших, кто про них знал, да никто. В 3 часа уже не укладываемся, их же надо откопать, достать и переместить куда-то. Никто не доплатит за это.
Ещё в один раз бац и кабель какой-нибудь на месте копания ямы, забыли предупредить. С кабелем тоже надо что-то делать. Если отказаться от этой ямы, денег никто не даст, а ты уже половину то перекопал, а заказчику всё-равно, у него триггер(сделано/не сделано).
Ещё одна яма, а там бац труба какая-нибудь. Тебе говорят копай тогда в другом месте сначала. А то что и эта часть копания должна быть оплачена никому нет дела.
Таких вариантов бесконечное множество, здесь можно добавить «А почему яма прямоугольная, а давай её звездочкой сделаем» или «А почему ты так лопату держишь, я хочу чтобы мою яму ты копал держа вот так лопату» и т.д.
Набив кучу таких шишек ты начинаешь ставить срок 6 часов и 5000р., по твоим расчётам в это время решаются большинство таких сюрпризов. Только кто к тебе обращаются ноют «А вот у друга знакомого сын копает за 800р.».
Со временем ты плюёшь на всё это, открываешь например кладбище и копаешь в своё удовольствие без всяких сюрпризов и собираешь сильно больше денег. =)

можно ли доверять исполнителю назначать сроки?

Офигенный вопрос.
А кому ещё можно «доверить» это? Заказчику чтоли? Забавную картину представляю я себе: заказчик полулёжа на кресле, с сигарой, говорит «да что тут делать — полчаса, ну максимум час, это ж элементарно — поле ввода текста и кнопка, вот тебе и твиттер».
Заказчика могут либо устраивать сроки, либо нет — на этот случай у него есть рынок с набором исполнителей. А называть сроки может только исполнитель.

...«тут нельзя оставлять пробел» и подобное.

Ну если ваша верстка от пробела разваливается, то проблемы скорее у вас, а не у программистов :)

Вот и обращайся после этого в студию за сайтом: движок- паблик… шаблон-паблик… а денег дерут — по самое «не балуй»…

Можете выбирать из готовых библиотек, вот список
У каждой из них есть дока и примеры, ну и минимум по одной статейке (англ.) с примером применения (гугол найдеть)
Плюсы и минусы в избытке.

Первым из появившихся, а как следствие самым «прокачаным» и стабильным является модуль WebRTC.io,
большая часть остальных — его форки.
WebRTC.io (WebRTC-клиент для ноды )

PS: Тем не менее со стороны сервера WebRTC не представляет ничего особенного, с ним можно управляться при помощи всем известного socket.io (например вот так).
Что в общем-то и советуют делать некоторые умные люди, так как задача весьма специфична для решения через дополнительный уровень абстракции.

PPS: собственно сабж IRL (с исходниками)

До того как вы пойдете на Кикстартер я бы рекомендовал собрать демо и заручиться поддержкой игроков. Уже на этапе демо. Условно говоря есть Project Zomboid, он и так неплохо существует. Отмечен рядом видных цифровых информационных ресурсов, в том числе и RPS, попасть в ленты которого — большой успех, т.к. после этого новости разносятся как огонь по саванне.

Project Zomboid распространяется через Desura и дает возможность сразу попробовать игру на этапе ранних альф. Есть как минусы так и плюсы. Но один из неоспоримых плюсов — формировка комьюнити. Только при информационной поддержке и при поддержке комьюнити проект может собрать необходимые средства.

Вспомните Тома Холла. В принципе известная фигура в игровой индустрии, но не смотря даже на ролик, в котором мелькнули другие известные люди (в том числе Маркус Персон и еще один скандальный персонаж Джон Ромеро) игра не набрала необходимую сумму. Почему? Потому что помимо их чудесных лиц у них были только — слова.

За вычетом этого у них была поддержка комьюнити и прессы. Первые им не поверили, а вторые засомневались. И правильно сделали потому, что давать нужно денег только тем в ком ты уверен. Подавляющее большинство разработчиков собирающих средства на К. имеют что показать. Если у вас это тоже есть — шансы есть. Осталось дело за малым. Вы должны быть известны и людям, и прессе.

Модальные окна имеют свои плюсы:
— акцентируют внимание на важной информации;
— позволяют вынести информацию, которую сложно встроить на страницу, в отдельное окно, тем самым не портить текущий дизайн.

На экране мобильного или вертикального планшета места еще меньше, и встраивание доп.инфы еще сложнее. Проблема перекрытия данных клавиатурой ввода все равно останется.

Предлагаю просто адаптировать модальные окна:

@media (max-width: 768px) {
    .modal {
        border: 0;
        border-radius: 0; // избавляемся от границ и скруглений
        margin: 0; // отменяем сдвиг направо (margin-left: -280px;) для больших экранов
        position: absolute;
        top: 0; // размещаем сверху
        left: 0; // отменяем центрирование для больших экранов
        width: 100%; // растягиваем на всю ширину экрана
    }
    .modal.fade.in { top: 0; } // фиксим бутстраповский хардкод
}

PS. Системными алертами можно заменить только информационные окна (с текстом и кнопками «Ок», «Отмена»). Но это лишь частный случай.
Пример адаптивной верстки выше я использовал, к примеру, на сайте дата-центра «Технодом» на странице пополнения баланса, где в модальном окне отображается не только дополнительная информация о размере комиссии, но и поле ввода суммы пополнения.

Используйте $(…).prop("checked", true) — и тем невозбранно достигнете желаемого.

К Yii выше, я бы еще добавил Laravel очень доходчивый, хорошо документированный и понятный фрэймворк — laravel.com/docs

Попробуйте Kohana,
Я его везде юзаю, хоть сообщество уже почти загнулось, да и 3.3 никак не зарелизится:(
А так неплох Yii.

Вы можете привести аргументы, ссылки и т.д. администраторам сайта, а далее решение о блокировке (а может и нет) аккаунта пускай принимают они в соответствии с правилами сайта и личным отношением к данной ситуации. Я на Вашей стороне.

Мне думается, архитектурный паттерн это рекомендация по построению программы в целом, в то время как паттерн проектирования показывает, как решать конкретную специализированную задачу уже в пределах выбранной архитектуры. Архитектурный паттерн это более абстрактная вещь. Хотя по смыслу слов оба термина очень близки.

Я бы сказал так:
Интерфейс — это возможность задать жёсткую семантику.
Абстрактный класс — это возможность вынести дублирующийся код и явно это отметить в иерархии.

К примеру, нужно написать класс для работы с кэшем.

У нас есть класс Cache, который будет делать всю грязную работу. Он в свою очередь будет использовать библиотеку под определенный тип кэша (memcached, eaccelerator, ...). Для согласованности, библиотека должна реализовать интерфейс cacheInterface, чтобы класс Cache мог нормально работать. Вот небольшой пример.

Интерфейс для библиотеки: