Про ценообразование при разработке сайтов.

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

Каждый раз, когда я начинал трогать мышку менее чем за 1000$ я потом сильно жалел, не бывает "простеньких сайтов", аппетит приходит во время еды, требования плывут, и все в рот имели итеративный подход, если итерации сопровождаются соответствующими выплатами и этапами по договору. Это даже с точки зрения бухгактерии не выгодно. Это нижний порог. У хороших студий эта планка в 10 раз выше. На мой взгляд это правильная политика. При скудном бюджете есть миллион разных способов продвижения в интернете своих услух, не требующих сайта, работающего на имидж или выполняющего роль инструмента продаж. Если обсуждается сумма ниже 1000$ — мы друг–друга просто не поймем, может быть кто–то другой поймет. От заказов нужно уметь оказываться.

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

Средний ценник среднего проекта под ключ у меня получается в районе $5000. Всякая верстка — это 1–15% от объема работ работы. Основной объем падает на тестирование и удовлетворение меняющихся требований. Пусть дизайн будет 1000$, программирование — 1000$ верстка и изготовление графического контента — еще $1000. На пальцах — это расклад при котором все участники процесса довольны.

С огромной вероятностью стоимость проекта относительно объема работ в итоге составит 5000–10000$ — косвенные расходы, непредвиденные работы, тестирование, изменений, детализация требований, дополнительные встречи с заказчиком, переговоры и т.д. Вот и получилось x2.

Если натягивается готовый шаблон на готовый движок, то все равно внезапно окажется что у нас не два уровня иерархии разделов, а все–таки 3, секретарша не справляется с wysywig редактором, гамма должна быть несколько светлее, внезапно образуется еще 200 единиц графического контента, шаблон выглядит как полное говно в IE6, которым пользуется заказчик из–за своей внутрикорпоративной политики и т.д.

Если вы не поняли — именно на это говно уйдет половина вашей работы. Если вам заказывают сайт по вашей оценке на 10k$, но бюджет заказчика позволяет всего лишь 7,5k$ а сам он видел что "что–то такое же" вообще делали за штуку и считает что за такие бабки получит священный грааль с элексиром вечной молодости, то это не клевый крупный заказ. Это плохая мерзкая жопа в которую вы гарантированно влезете. К тому же, с большой вероятностью, вы и объем работ оценили неправильно и он не на 10k$, а на 15k$ или больше.

Другой взгляд: если заказчик хочет хоть как–то заниматься продвижением, то либо сам сайт или его услуги должны быть просто замечательными, а это либо дорого либо сложно, соответственно, либо, если, это хоть сколько ни будь конкурентный рынок и область продвижения, стоимость продвижения будет составлять большое количество штук баксов. Очень странно, если конечная точка, куда приходит посетитель, будет стоит 100$

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


  Нет комментариев   23 января 2012   Статьи  

Самое простое ускорение сайта

В итернете есть куча более правильных статей на тему организации дружбы между nginx и memcache. Я же, покажу самый простой пример, который можно сделать за пять - десять минут и который поможет разгрузить основные страницы вашего сайта.

Что я предлагаю ?

Давайте засунем главную страницу сайта, в memcache, и настроим nginx что бы он отдавал ее прямо из memcache не обращаясь к интерпретаторам. Будем класть раз в минуту сроком жизни на 60 секунд. Стоит понимать, что данный способ нужно дорабатывать, если у вас на страницах используется динамичные данные, то есть данный способ актуален только для "гостей" сайта, благо nginx умеет работать и cookie.

Пример настройки nginx'a
location / {
 
    default_type    text/html;
 
    if ( $request_uri = '/')
    {
        set $memcached_key "index_page";
        memcached_pass 127.0.0.1:11211;
 
        error_page 404 503 = @fallback;
    }
 
    error_page 404 = @fallback;
}
Пример cron скрипта, который можно повесить на выполнение.
<?
 
    error_reporting(E_ALL);
    ini_set('display_errors', 1);
 
    if( class_exists('Memcache', FALSE))
    {
        $mem = new Memcache;
 
        $mem->connect('localhost', 11211);
 
        $html = file_get_contents('http://blog.rpsl.info/?asd');
 
        if(!empty( $html ) )
        {
            //$mem->delete('index_page', 0);
            $mem->set('index_page', $html, 0, 60 );
 
            //echo $html;
        }
    }
    else
    {
        echo 'no memcache';
    }

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

Идею я донес, дальше сами справитесь.

Dive into Python :)

Шесть месяцев назад я нашёл в Интернете книжку "Dive into Python". Странная книжка, толстая, да ещё на не русском языке. Усердно прочитал её, методично и вдумываясь, но таки ничего и не понял. Но что–то не отпускало меня — я пошёл на python.org и стал изучать стандартную библиотеку, старательно, скрупулезно, от корки до корки. Гугля примеры кода, я наткнулся на пост в блоге одного гуру, где было написано про PEP8. То, что рассказывал этот умудрённый опытом кодер, настолько впечатлило меня, что я словно в припадке безумия бросился зубрить эту конвенцию по написанию питоньего кода. У меня тряслись руки, по телу прокатывали волны возбуждения, я, можно сказать, бился в экстазе всё это время — и теперь могу процитировать наизусть любой пункт, даже если меня разбудить посреди глубокой ночи.

Новые знания окрыляли меня, я бросился писать (что бы вы подумали?) очередную имиджборду. Я не писал раньше имиджборд, эта была моей первой. По пути пришлось освоить азы вёрстки на html и css, но там всё оказалось совсем не сложно.

Я плавно двигался вперёд, наращивая функционал. И знаете что? Я упёрся в недостаток производительности. Ну, так мне показалось. Я делал замеры, устранял места с тяжёлым кодом. Тысячи раз запускал ab, но так и не сумел перейти порог в 300 запросов в секунду. Я как–то ожидал большего и был немного разочарован.

Гугл, снова гугл. Десятки статей и тем на форуме… Довольно быстро я заметил, что люди часто пишут про какие–то "асинхронные веб–сервера". Часто встречались названия Tornado и Gevent. Я прочитал про них подробнее — и был просто ошеломлён. Как мне это раньше не приходило в голову?! Это же, это просто гениально, чёрт меня побери!

Исходники в ведро, всё переписать! Меня переполняло новое знание, поток мыслей ровно ложился в строчки кода. Я просто не мог остановиться. Чашка кофе… Ещё чашка… Мой небольшой кусочек софта приобретал кристальную чистоту, я смертельно устал, но продолжал в умилении полировать его зудящими руками, нанося последние штрихи.

Пять тысяч. Я получил производительность в пять тысяч запросов в секунду. В ту ночь я так и не смог заснуть.

Увлекательнейший мир хай–лоада открылся передо мной. Позже я изучил ещё много классных вещей типа сверх-быстрых асинхронных key–value–хранилищ, или, например, такого необычного подхода к обработке данных, как map–reduce.

Это уже был другой я, новый, обновлённый. С незашоренным взглядом, с жаждой новых знаний и незнакомых концепций. Я летел вперёд, оставляя за спиной ступень за ступенью.

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

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


Как разрабатывают ПО для шатлов

Утром кто-то в твиттере скинул ссылку на статью, рассказ о том, как разрабатывают ПО для шатлов. Для расширения кругозора полезно почитать.
В то время, когда 120-ти тонный шаттл стоит, окруженный почти 4-мя миллионами фунтов ракетного топлива, источая ядовитые пары, с явным желанием бросить вызов земной гравитации; его бортовые компьютеры получают команду. Четыре идентичных компьютера, работающие под управлением идентичного ПО, собирают информацию из тысяч датчиков, принимая сотни миллисекундных решений, утверждая каждое решение, сверяясь друг с другом 250 раз в секунду. Пятый компьютер, с другим ПО, готов взять управление на себя в случае сбоя остальных четырех.
В момент времени -6.6 секунды, если давления, насосы и температуры в норме, компьютеры дают приказ зажечь главные двигатели шаттла – каждый из трех двигателей вспыхивает ровно через 160 миллисекунд, тонны сверхохлажденного жидкого топлива попадают в камеры сгорания, корабль дрожит на своей пусковой площадке, удерживаемый на земле только креплениями. Когда главные двигатели достигают силы тяги в миллион фунтов, их выхлопы превращаются в голубые бриллианты пламени.
Тогда и только тогда, в момент времени -0 секунд, если компьютеры убедились, что двигатели работают правильно, они дают приказ поджечь массивные ракетные ускорители. Менее чем за секунду, они развивают силу тяги в 6.6 миллионов фунтов. И именно в этот момент, компьютер отдает приказ взрывчатым креплениям взорваться, и корабль весом 4.5 миллионов фунтов величественно поднимается над стартовой площадкой.
Это удивительное проявление доблести оборудования. Но ни один человек не нажимает на кнопки, чтобы это произошло, ни один астронавт не манипулирует джойстиком, чтобы вывести шаттл на орбиту.
Читать полностью

Еще немного про собеседования

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

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

Первое на что хочу обратить ваше внимание, это то, что вопросы которые задают php(?) программистам, в основной своей сути имеют довольно академический характер и в жизненных циклах проектов встречаются не часто, но тем не менее, нужно уметь решать эти задачи. Это обусловленно тем, что у работодателей нету времени и желания давать вам типичные задачи, в стиле - "Напиши класс, который будет отвечать за работу с пользователями". 99 процентов всех вопросов задаются по заготовленному листку и должны быть решены на листке бумаги. Никаких IDE, никаких гуглов, никаких ответов типа "я не помню синтаксис". Если вы настроены решительно и хотите произвести хорошее впечатление, то уделите время, что бы потренироваться и чувствовать себя уверенно.

Все вопросы можно разделить на три категории: PHP, MySQL(?), все остальное.

Любой из этих пунктов, так же делится на две части: теория и практика. Начну пожалуй с PHP. С теоретическими вопросами, в целом, не сложно. Они почти везде одинаковые: Отличия между PHP 5.2 и 5.3, основные приципы ООП. Не частый, но вопрос с подвохом - "В каких случаях использование ООП, является убыточным?". Дальнейшие вопросы на теорию, в основном, зависят от ваших ответов, и несут цель узнать на сколько хорошо вы разбираетесь в материале о котором говорили выше.

Практические вопросы, это чаще всего просьба написать некую ф-цию, которая делает какую либо хрень. Почти на каждом собеседование меня просили написать функцию которая переворачивает строку, без использования дополнительных буферов, можно попробовать схитрить и ответить что-то в стиле
 <? function revert( $string ){ return strrev( $string ); } ?>

Но это не cамый лучший вариант ответа. Выучите алгоритм с обращением к символом строки как к объекту массива.
Очень частые задачи, на написание рекурсивных функций или на понимание работы операторов кода.
<? $a = 10;
echo ++$a + $a++ - ++$a + $a ;
?>
На днях пока решал задачи, попалось интересное задание, у меня такое ни разу не спрашивали, но думаю что к такому надо быть готовым:
<? var_dump( 0123 == 123 ); ?>

Думаю, что на счет PHP я достаточно ясно изложил типовые вопросы, если что-то осталось не понятно, то спрашивайте в комментариях.
Теоретические вопросы про MySQL или любую другую СУБД почти всегда касаются индексов и насколько вы понимаете как их использовать, в каких случаях и на что их ставить и в каких случаях индексы могут быть вредны. Обязательно спросят про различия между версиями. Поинтересуются насколько глубоко вы знаете тонкости работы СУБД и вкурсе ли вы про то, что такое тригеры, хранимые процердуры, представления.

Практические задачи - это просьба нарисовать две таблицы с различными данными и просьба написать запрос, который покажет умеете ли вы использовать операторы HAVING, GROUP BY, ... etc. Обязательно знать разницу между JOIN запросами.

Еще часто спрашивают про верстку, про css, про javascript. Но расписывать это все не вижу смысла.