Wott

Собственно, интересует как вы (в качестве исполнителей) боретесь с этой проблемой и получаете проекты?

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

Но в принципе такая проблема есть. Даже не в том что оценки бывают большие, а в том что у людей есть бюджет, за пределы которого они могут выйти, но не просто так, а обоснованно. Поэтому я в первую очередь, еще до любых цифр стараюсь навести диалог, что бы начать говорить на одинаковом языке. И когда дело доходит до цифр я уже на понятном заказчику языке описываю что я оцениваю. Бывает достаточно первого уровня WBS.

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

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

Как проводить оценку сроков? Например я заказчик, я не владею матчастью сколько та или иная функциональность может разрабатываться, можно ли доверять исполнителю назначать сроки?

Сложно вам придется. Как правило люди слишком оптимистичны и сроки названные кем угодно постоянно срываются.
Нужно самому оценивать реалистичность и накидывать сверху на риски

Вопрос фрилансерам — часто ли заказчик соглашается на Ваши сроки?

Соглашение — суть взаимный компромисс. Если заказчик необоснованно настивает на своих условиях, то соглашения не будет

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

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

От фрилансеров хотелось бы узнать наиболее распространенные причины почему так произошло.

Стандартно — недооценка обьема работ.
Потом банальная прокрастинация.
Потом всякие форс-мажеры и другие более важные для исполнителя работы, занятия

По нескольким положительным опытам, HR должен принимать человека, а собеседовать специалист.

Вообще-то все же тут профессионалы, не так ли? :) Так и надо каждому действовать в рамках своей компетенции — специалист ( который начальник, но вообще-то не всегда начальник достаточно компетентен в технологиях для нанимаемой позиции ) оценивает технический уровень, а hr оценивает личностные качества, тестирует на скрытые пороки, отсеивая алкоголиков и прокрастинаторов. Если же начальник не специалист, то отдельно и с ним собеседуется, хотя бывает так что нет.

если работать как в офисе то так и получается — 4, в лучшем случае 6 часов продуктивной работы.

Если говорить про почасовой фриланс то так и надо считать что 4-6 часов это нормальный рабочий день и считать свой комфортный рейт ( 22 дня в месяц, 6 часов в день ). Если же проблема в том что надо увеличить количество реальных продуктивных часов, то надо менять свой график жизни и работать несколько раз в день по 2-3 часа, с перерывами. Можно добивать до 10 часов в день, но через 2-3 недели будет падать работоспособность и через месяц-полтора наступит полная апатия и нежелание видеть эту работу.

стандартное решение — dhcp ( получение IP и ссылка на загрузку pxe ) — pxe ( конфигурация на загрузку ) — tftp ( получаем ядро и initrd) — nfs ( монтируем root fs )

для убунты гуглить по diskless

Можно обойти любую фильтрацию, но есть некоторые признаки, которые могут отсеять явных ботов
1. переменные окружения — почему-то ленятся скопировать результат запроса типичного браузера
2. скорость клика — боты либо быстрые, либо регулярные. Делаете порог для html запросов в минуту или считаете вариативность задержек между запросами.
3. скачивание/нескачивание контента — обычный браузер качает картинки, css и прочее, но тут есть тонкости — например некоторые браузеры стали оптимизировать и не запрашивают невидимый контент. Но явно нужный css например хороший триггер для человека
4. Прокликивание ссылок — делаете ссылку со страницы, которую пользователь не может нажать и готовый триггер для бота. Для надежности делаете рандомные место, класс и параметры ссылки
5. Javascript — большинство ботов его не выполняет, но есть и пользователи без него. Делаете по загрузке страницы запрос на css, например, что будет условным триггером для человека.

В общем делаете фильтр, который проверяет кучу признаков и по сумме решает что это бот — дальше либо в сессии, если есть такие, выдаете ему всякую фигнгю, либо рубите. Если нет сессий, то создавайте правило в iptables/pf/ipfw что у вас там для данного ip на час-два-сутки.

Надо сказать пару слов о нужных ботах — спайдеров поисковых машин, можно предварительно отфильтровать ip адреса по user-agent, но есть вероятность что под них маскируются ненужные боты. Так что их надо модерировать, прежде чем заносить в белый список.

Любая сборка. если оптимизируется, то под конфигурацию, которую имел в виду ее автор. Наверняка она отличается от вашей машины.
На серверах хостингов, как правило. настройка более адекватна.

Если нужна скорость, то разберитесь в настройках — это не сложно.

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

Не знаю, поможет ли, но я начинал не с odesk, так что мне было проще
1. надо сделать все что можно до первого задания что бы профайл был хорошим — заполнить все, сделать профильные тесты 3-4 для начала нормально, лучше 1-2 или все профильные быть в 10%, приложить примеры работ или сайты, но только хорошие. Поддерживайте профиль впоследствии — делайте и улучшайте тесты, добавляйте хорошие сделанные работы.
Я лично сделал несколько фильтров для выборки работ и закинул их rss в reader и спокойно перебирал предложения 2-3 раза в день. Ждать предложений даже с хорошим профайлом, рейтингом и большим количеством часов практически бесполезно — очень много спамят и мало действительно хороших предложений падает просто так — надо их искать.
2. брать небольшие фикс работы. возможно 3-4 может 10 первых работ будут только фикс прайс. Брать надо то что вы знаете на 80% минимум, то что делали или имеете полное представление о работе, учиться надо самостоятельно на своих проектах, потом со временем можете учиться и в процессе, но по чуть-чуть. Брать незнакомое — это мало того что риски не сделать это еще и риски ошибиться с обьемом, временем и так далее.
Первые работы — только на отзыв, так что выкладывайтесь — делайте быстро и хорошо, облизывайте клиента, делайте его хотелки. Небольшой обьем позволит не тратить на сверхоговоренные работы много времени (=денег)
3. Когда будет хорошие отзывы 4,5 лучше 5, можно смотреть повременные работы. Если опыт первых работ показал что идет, то можно сразу прыгнуть на 15-20$, если не очень — то попробуйте пониже. Когда пойдет — то медленно поднимать планку. Как правило если вы делаете хорошо и превышаете ожидания заказчика — они легко идут на 2-5$ в плюс. Когда вы поймете что ваше время не резиновое, то можно поднимать дефолтную планку. Держаться хороших заказчиков и расставаться с плохими. Хорошие заказчики вам скорее предложат уйти с odesk в прямой paypal, но можно продолжать пользоваться таймингом odesk, создавая небольшую фиксированную работу и не закрывать ее.

Фриланс — это все должности сразу, надо быть и менеджером и говорить с заказчиком на его языке, его терминами, уметь определять его адекватность и платежеспособность, надо уметь оценивать обьемы, ТЗ, время, приоритеты, надо уметь управлять своим временем и уметь учиться и планировать и улучшать все вышесказанное. И конечно хороший специалист, плохому во фрилансе ловить имхо нечего — конкурировать с индусами и китайцами, работающие за еду просто глупо.

Поднять до 30$, а в отдельных специализациях до 40-50$ без проблем, если вы и вправду хороший фрилансер. Да и стать таковым можно за год-два. Правда лет за пять может и надоесть до чертиков. Но начинать надо, может быть с 5$ за работу, но работать — фрилансер прежде всего это самоорганизованый трудоголик, иначе идите в офис и просиживайте штаны там.

Всем кто считает часы. Попробуйте изо дня в день работать указанные 8 часов непрерывно, именно работать — писать код, общаться по существу — то что оплачивается без вопросов. Даже если и получиться то недели через две сдуетесь. Можно конечно и по 10-12 часов работать, но не долго — сгорите за месяц-два. Реально держать 6 часов в день, с выходными. Да и то комфортнее, да еще и на скучных заданиях 4 часа или меньше.

у вас просто масштабы мелкие
есть куча навороченных тем, которые бывает надо чуток промодифицировать

попробуйте позитивный просмотр вперед сразу после первой цифры

мало-мальски мастерская

имхо подразумевает всякие системы хранения — инструменты, материалы.
например у жены как раз много всякого похожего — проволока в мотках, например — на стене сетка металлическая ( торговое оборудование, решетка, толстые прутья около 3мм ) и консоли разные — мотки висят на таких штырях с загнутыми концами что бы не падало.

У меня кабели либо с электрооборудованием и для них сделаны ( стырены у оптиков :) и допилены ) самозаматывающиеся бобины. А отдельные шнуры хранятся смотанными в полке стола

Я бы поискал моделистов — им приходиться резать из пенопласта разные фигуры, кто-то даже станки 3Д для этого сооружает.
Сделать чертеж, купить пенопластовые блоки и за вознаграждение вырежут.

Но, если честно — пенопласт хорош для транспортировки, разовой причем. При вынимании он крошиться и вообще.
Я бы попробовал посмотреть в сторону полок для видеокассет, если они еще бывают, хотя если где и видел — диски хранят на простых полках, вертикально на длинной стороне вполне безопасно имхо.

1. цензура это плохо по-любому
2. надо оценивать аудиторию для игры. Если это детская игра, то детей надо воспитывать с одной стороны и контролировать агрессию с другой стороны. Тогда жесткий антиматовый и не только фильтр нужен, но вкупе с мотивацией вести себя культурно. Если же это адреналиновый хардкор, то без матов нельзя, но при этом детям и кисейным барышням там не место.
3. надо давать возможность общаться в своем круге. Общий чат это поток спама и скама, а вот уже внутриклановый это «свои», в том числе и культура своя — кому-то надо и можно матюгнутся что бы высказаться точнее, а для кого-то это некомильфо. Понятно что общие каналы нуждаются в фильтрах, хотя скорее всего антиспамовых, и какие-то общие свободные сообщества тоже, но частные каналы должны быть свободны хотя бы опционально.

Искусственный Интеллект

Теория игр конечно относиться к разделу математики, который претенциозно называют «Исскуственным интеллектом», но называть интеллектом пусть даже самообучающийся алгоритм наверно некорректно. Хотя все вопросы к Тьюрингу, как всегда.

Очевидно, что победа человека в интеллектуальных / математических играх — это дело времени.

Практика показало что наоборот — как только мощности позволяют то алгоритм оказывается «сильнее», что в общем-то логично. А интеллектуальными называют игры в которые выигрышная стратегия слишком сложная, что бы ее мог обсчитать обычный человек.

Вот на такой общий вопрос сразу ответил — нет.
но потом вспомнил что я дофига что делал бесплатно и open source и не очень ровно по той же причине — было время и было интересно, а деньги меня либо не интересовали в таком обьеме либо я видел что у людей проблемы с ними, а все равно интересно :)

WP очень любит обращаться в базу по любому пустяку, так что вынесение ее в далекие дали черевато.
Правильнее было бы сделать репликацию базы, но если у вас там какие-то изменения типа комментариев, то надо делать master-master репликацию, которая для 2 серверов имеет проблемы, лучше поставить 3й.
Если же изменения централизованы ( админ или api ) то можно сделать master-slave реплику.

Но проблема мне видится в другом — наплывы посетителей решаются через кеширование. Если у вас там нет юзерозависимых блоков, то достаточно поставить nginx с 1 минутным кэшем перед wp и нагрузка стабилизируется

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

v2 устарел давно, посему Гугл всячески стимулирует переходить на v3, который к тому же привязку к домену не имеет, только лимиты.

HL это на самом деле задача по оптимизации. В первую очередь надо уменьшить времена формирования ответа, времена загрузки на клиенте, что достигается оптимизацией самого приложения (профилирование, склеивания запросов и разнесения контента) и и потом уже кеширования, которое бывает разное — тупое (ставим nginx ) или структурное ( разбиваем на блоки, которые формируем и кладем например в memcached ), управляемое ( содержимое меняется при необходимости ) и нет ( по таймауту ). Для кеширования может понадобиться изменять приложение ( обновления в данных ) или адаптировать кеширование ( сброс кеша или его игнорирование по кукам например )
Дальше, если сервер уже не справляется в одиночку или надо HA, переходим к горизонтальному масштабированию. И начинать надо с того что запросы должны быть атомарными — любые состояния, типа сессий, усложнят масштабирование ( придется расшаривать сессии на кластер или привязывать пользователя к серверу по ip например, что легко если шардинг, но HA страдает ). Какая база ( SQL или NoSQL. не говоря уже об названии ) или кластер — зависит в первую очередь от приложения, а не от моды или комментов на хабре. Лучше жить на MySQL, тем более что Percona+Galera очень даже неплохи, если вы его хорошо знаете, чем окунаться в проблемы незнакомого сервера на production. Опять же конкретная технология должна решать конкретные проблемы, которые определяются, исходя из архитектуры приложения в первую очередь. Ну и пробовать, экспериментировать.