Александр Малинов

БЭМ - это такая методология вёрстки от Яндекса. Она подразумевает разбиение страниц на отдельные смысловые блоки (комментарий, пост, заголовок, футер, форма, инпут и т.п.). Каждый блок может состоять из других блоков. Основная идея - как можно больше повысить возможность повторного использования уже написанных блоков, для чего используются модификаторы. Плюс, БЭМ подразумевает отказ от каскадных стилей, потому что они препятствуют повторному использованию.
Например, на странице есть два разных заголовка (например, отдельно в статье, и отдельно во врезке). Как все привыкли делать это? есть код заголовка:
<h1 class="header">Заголовок</h1>
И мы ставим эти заголовки в текст статьи и во врезки:

<article class="article">
    <h1 class="header">Заголовок</h1>
    <p>Текст текст текст</p>
</article>
<aside class="incut">
    <h1 class="header">Заголовок</h1>
    <p>Текст текст текст</p>
</aside>

Тогда обычно мы используем каскад, чтобы стилизовать заголовок во врезке:

.header {font-size: 2em; padding-bottom: 1.5em;}
.incut .header {text-decoration: italic;}

Всё хорошо, но теперь мы не можем просто перенести эти стили заголовка во врезке в другое место, потому что эти стили привязаны именно ко врезке (классу incut). Плюс, что ещё хуже, если к элементу привязано несколько различных стилей, образующихся подобными каскадными правилами, то перенести такой внешний вид в другое место становится очень трудоёмко. А также, из-за большей специфичности каскадных стилей, их сложнее "перебить" новым стилем.
БЭМ предлагает отказаться от каскадных стилей и создавать отдельные стили-модификаторы:

<article class="b-article">
    <h1 class="b-article__header">Заголовок</h1>
    <p>Текст текст текст</p>
</article>
<aside class="b-article b-article__incut">
    <h1 class="b-article__header b-article__header_incut">Заголовок</h1>
    <p>Текст текст текст</p>
</aside>

.b-article__header {font-size: 2em; padding-bottom: 1.5em;}
.b-article__header_incut {text-decoration: italic;}

Чем больше проект, тем выгоднее использование подобной методологии. На маленьких и средних проектах БЭМ может быть избыточен. Хотя вот была статья habrahabr.ru/company/yandex/blog/234905 про использование в маленьких проектах.

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

Ну вот. Получилось не в двух словах, но менее подробно качественно описать БЭМ не получится, имхо.

Могу посоветовать www.axure.com/. Это не графический редактор, а программа для создания макета сайта (ну и дизайна даже)

preloader называется, их много разных, гугл в помощь

Ух, что ж вы так обстоятельно и с такой опаской к этому подошли-то? Это же всего лишь фриланс, здесь всё проще)

Расскажу свою маленькую историю. Работа у меня неплохая, в принципе устраивает, было интересено просто попробовать себя на одеске развлечения ради. Прочёл пару статей, зарегистрировался, прошёл тест на знание английского (натыкал только на below average :( ) и начал глядеть простенькие задачки «на вечер».
Никакую почасовую ставку даже не рассматривал, только fixed price. Зачем загонять себя, если опыта пока маловато?

Далее про выбор задачек. Смотрим цену, если она устраивает, ставим предложение процентов на 10 ниже, чтобы обратили внимание. И самый основной шаг — правильно составить cover letter. Минимум общих фраз о том, какой вы хороший (я вообще об этом писал одно предложение в начале), основное внимание уделяем задаче. Надо показать заказчику, что вы прочли задание и прониклись им. Задаём пару уточняющих вопросов или предложений по вариантам решения. Только не переборщите, письмо размером с этот ваш вопрос никто читать не будет. Помните, вводное письмо — это то, по чему оценит вас заказчик в первую очередь. Это то, что отличает нас от индусов, которые просто штампуют своё письмо, даже не читая текст задания. Наверняка замечали, что во многих вакансиях специально стоит такая «защита от дурака» :)

В конце, конечно же, следует указать примерные сроки выполнения. Я, как уже говорил, выбирал задачки на один-два вечера плотной работы с учётом моих скиллов. При этом писал заказчику, что, прямо сейчас я сильно загружен, но в уикенд у меня будет достаточно времени, чтобы завершить работу. Вам ведь никто не мешает предложить комфортный срок выполнения с учётом основной работы, шашлычков, семьи и проч.? Любые вакансии со словом urgent закрывал даже не дочитывая, нервотрёпка мне не нужна.

В таком режиме примерно 25-30% моих писем находили отклик. Дальше — предварительное согласование с заказчиком. Тут важно понять, какой он человек, дабы не напороться на неадеквата. Если общается в стандартном английском деловом стиле, отвечает на поставленные вопросы — всё скорее всего будет хорошо. Однажды мне попался человек, которые дважды не ответил на конкретный вопрос, продолжать общение с таким не было никакого смысла. Либо некомпетентен, либо невнимателен, а зачем нужен человек, из которого потом придётся тянуть клещами? И да, лучше конечно выбирать европейцев/американцев, общаться с малограмотными азиатами не слишком приятно.

На некоторые вакансии я отвечал только для тренировки — обмозговывал задачу и составлял письмо. Было интересно, ответят или нет. Потом просто отклонял предложение, ведь до заключения контракта вы никому ничего не обязаны. После одного из таких отклонений (с пометкой «слишком маленькая цена»), ко мне снова обратился заказчик с предложением заплатить больше. Пришлось всё таки взяться и сделать :)

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

P. S. Всё вышенаписанное воспринимать как поток сознания дилетанта с тремя выполненными задачками и парой сотен баксов на счету)

Начинал ~2 года назад (август/сентябрь) на oDesk (это была не первая моя попытка), выставил 14..15 баксов, без портфолио и истории. Первый заказ был получасовой, на 7 баксов, практически случайный (от новичка) — немного напортачил, но всё исправил, потратил времени в разы больше, но добился положительного отзыва.
Общение сразу пошло через Skype и электронную почту, оплата — через PayPal. Это против правил, но так предложил заказчик.

Затем оказалось, что работы у него непочатый край. До Нового Года переделывал маленькие сайтики (бизнес-проекты одного и того же человека). Взял меньшую плату, но повысил себе статистическую «среднюю ставку».

Самое сложное было в графике и работе из дома — жена (девушка) не подходила ко мне когда я говорил по Skype/SIP, но в остальные моменты очень мешала и сбивала с толку. Ещё обижалась, что я ничего не делаю по дому и ложусь спать/встаю с разницей 3..4 часа по отношению к ней — одна комната, горящий монитор, гудящий вентилятор и т.д. Очень сложно было когда мы оба заболели (простуда).

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

Шашлык и вино действительно хоть каждый день и стойкое желание переехать куда-нибудь в англоязычную Канаду (тем более, что часто звали). Ставка на почасовые заказы сейчас 20..35.
Иногда чувствую себя зомби (3 часа сна два дня подряд, потом 12 часов и всё равно не выспался, 6 часов, опять 2 дня по 3 часа, потом 14..15 на выходных).

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

Success story неполная — не даю ссылки на профиль (у меня их несколько, в т.ч. приходилось заказывать самому у себя, но это оказалось ненужной глупостью). Так что не просите — за треть проектов, особенно первых ужасно стыдно, при том, что посмотрев на некоторые из них клиенты просят «и мне так же сделай», причём никогда не угадаешь заранее что может понравиться.

Единственное, что радует — UK, CA, NZ, US AU — WeekEnd для них — это святое. На душе легко и спокойно с 3 утра субботы до 15:00 понедельника.
Но бывает, что заказчик шлёт мне в полседьмого утра письмо с вопросом «Как продвигается наш проект» в 6:30 утра по его часовому поясу.

С точки зрения разработки хорошо, что разделение testing/development/working environment очень чёткое и всегда есть время откатиться — начинаю обычно в час ночи и заканчиваю полпятого утра по их TimeZone, на живом, боевом сервере никогда не экспериментирую.

Ну и по поводу каналов в Интернет — у меня 2 FTTx и 3 «свистка» — иногда так медленно заливается на хостинг, что приходится вспоминать командную строку и перепробовать их все.

Зато индусы иногда вымораживают своим менталитетом, даже при хороших ставках.

Ну и естественно, я стал замечать за собой НЕНАВИСТЬ к нашим местным наебизнесменам-работадателям, которые предлагают оклады 15..22 тыс. руб./мес. работникам с образованием и опытом, особенно после того, как устроившись в одну из местных фирм-конкурентов «тайным покупателем», вернее разработчиком (чтобы посмотреть workflow, т.к. это довольно успешный бизнес-проект с большой клиентской базой) увидел тот же Job Offer с oDesk, но очень плохо, безграмотно переведённый топ-менеджером компании в редких перерывах между поездками на дайвинги.

В «малый бизнес» я тоже пытался уйти — очень сильная конкуренция, ценовая со школотой. Потом оказалось, что это ещё не главная проблема — рынок заказчиков всё равно растёт быстрее рынка исполнителей. Главная проблема — это чудовищная пропасть между опытом заказчика — НЕ ЗНАЮТ ЗАЧЕМ ИМ ИНТЕРНЕТ И НЕ ЗНАЮТ ЧЕГО ХОТЯТ и… ПОЛНЫМ ОТСУТСТВИЕМ ЖЕЛАНИЯ ПЛАТИТЬ профессионалам.

Ещё поразило соотношение между уровнем разработчиков и наглостью в сочетаниями с понтами у менеджеров компаний-конкурентов. Не знаю кого винить — Фурсенко, или сразу Вашингтонский кагал, но пока встречался с потенциальными заказчиками (сейчас только телефон, а лучше -электронная почта) по три раза на дню бывал в ситуации, когда выплеснув на меня ушат откровенной технической ахинеи дядя-Вася-на-джипе на вопрос «Где вы нашли эту чушь?» начинал быковать в духе «Это мне сказали девушки в конторе ИП XYZ, А У НИХ ВСЁ ЧЁТКО, ВЕДЬ У НИХ САМ ИВАН МОИСЕИЧ ЗАКАЗЫВАЕТ САЙТЫ!»

Короче oDesk — единственный шанс для заМКАДья, кроме восстания конечно.

ТЗ + Система управления проектами (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. Удачи!

Оперирую 4 сущностями:
1. Цели (когда-нибудь сделать)
2. Проекты (текущие дела)
3. Повторяемые дела (ежедневные\еженедельные и т.д.)
4. Календарь (дела которые нельзя переносить)

Для календаря — гугл-календарь, для остального майндмапы (mindmeister)