Red Rain

Для фриланса однозначно начни с PHP

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

Такие вопросы на хабре задавать бесполезно. =)

Большинство ответивших написали местами полную чушь. Основная масса веб-программистов дальше своих фреймворков не вылезают, и у них в итоге полная каша в голове. Например, кто-то путает интерфейс (WSGI, Pump, WEB3, PSGI, Rack, CGI и т.д.), сервер приложений (uWSGI, php-fpm, Rack, Gunicorn, unicorn, flup, Apache в данной роли, и ещё тысячи их) и протокол (HTTP, uwsgi, FastCGI, SCGI, CGI, AJP, WebSocket, да много их). Кто-то путает протокол, способ его реализации и способ запуска интерпретатора.

Основное, что вам нужно знать, содержится в документации Django:
docs.djangoproject.com/en/dev/howto/deployment/

Ответом на ваш вопрос будет: да существует множество и каждый HTTP-сервер поддерживает целый набор протоколов для общения с сервером приложений. И сервера приложений могут поддерживать один или несколько протоколов, один или несколько интерфейсов. Некоторые HTTP-сервера умеют выполнять двойную роль, выступая и в роли сервера-приложения, предоставляя определенный интерфейс. А некоторые приложения сами содержат встроенный HTTP-сервер. Термин же «веб-сервер» слишком общий, и трактоваться может разными способами.

У меня половина опыта работы — именно написание пауков и веб-парсеров.
Писал их и на PHP + CURL, потом на голом питоне + треды.
Потом узнал о Scrapy (асинхронный фреймворк для граббинга сайтов на Python) и на нём штук 5 независимых проектов реализовал, в том числе один, где нужно аггрегировать и периодически обновлять информацию с 20 различных форумов. Основная его проблема — он асинхронный, но однопоточный. Так что больше одного ядра им не нагрузить и долгий запрос к БД не сделать. А так очень хороший фреймворк.
Потом несколько пауков делал на Python с помощью Celery.
А совсем недавно переписал довольно сильно нагруженного паука (50-70Мбит/с через списки прокси) с Python + Celery на Erlang и понял, что это ОНО! Мало того, что стал работать в 2-3 раза быстрее, но понял, что для этой задачи что-то более подходящее сложно придумать.
Поясню — у паука на Erlang можно без остановки процесса, например, изменить число потоков, обновить код, перезагрузить конфиги. Можно на ходу отпрофилировать код чтобы узнать, почему скорость упала или что так нагружает CPU. Можно совмещать зеленые потоки, асинхронную работу с сетью и долгие запросы к БД. И всё это фактически из коробки. В конце концов, код получается более логичный.

Э… даже не знаю что тут ещё сказать можно, совершенно разные действия ведь. Грубо говоря, в первом случае ветка переставляется (со всеми коммитами), во втором отдельно взятый коммит (или несколько, схлопываются в один как вариант) патчится на другую ветку. Отсюда же и разное использование и разные ограничения. И механизм разный. Для понимания механизмов надо изучать всякие там progit и на дереве экспериментировать визуально. А если бы механизмы понимали, этого вопроса 100% не возникло бы :)

Вот именно по этому я использую Gimp — там это делается одной командой «Цвет в альфа-канал».

ayak.ru
мониторит 16 фриланс бирж

В общем случае, принципы построения индексов достаточно просты: индекс (кроме первичного) строится для ускорения запросов. Причем если есть WHERE по двум полям, то будет взят индекс, содержащий оба этих поля (если есть) и не важно сколько их там еще.

Другими словами, один индекс по полям «A, B, C» будет более «полезен» для запроса, содержащего некие условия по полям A и B, чем два отдельных индекса по полям «A» и «B».

Фактически, индексы A,B,C и A,C,D будут одинаковы в части поиска по полю «А». При поиске по полям А,B будет взят первый индекс. При поиске по полям A, C — второй.

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

Не бойтесь добавлять слово EXPLAN в тело запроса и смотрите какие индексы он использует. Порой оптимизатор использует fullscan даже при наличии индексов.

Как вариант, можно воспользоваться агрегатором RSS.

alllance.com/ — довольно удобен.
Бесплатно — задержка в 20 минут, 1$ — получаете все без замедления.
Есть приложение-клиент: висит в трее, по мере поступления заказов всплывают сообщения.

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

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

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

Интерфейс не представляет из себя некую самостоятельную сущность. Как пульт от телевизора, например.

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

Как пишут умные люди (Шилдт, Троелсен) в своих умных книжках, интерфейс определяет функциональные возможности, поведение — «что именно следует делать, но не как это делать» (Г.Шилдт, Полное руководство C#). В абстрактном классе «определяется лишь самая общая форма для всех его производных классов, а наполнение ее деталями предоставляется каждому из этих классов» (там же).

Простой пример, в контексте графического редактора можно определить:
Абстрактный класс — Figure (геометрическая фигура), от него могут быть образованы классы конкретных фигур — например, Rectangle, Circle и т.д.
Интерфейс — Drawable (то, что можно нарисовать). Он может быть реализован как во всех классах конкретных фигур (Circle, Rectangle), так и в других классах, не образованных от абстрактного Figure.

Интерфейсы надо использовать, когда классы, которые должны предоставлять один и тот же интерфейс, не должны быть (или не могут быть) связаны иерархически.
Кроме того, если нужно предоставить несколько интерфейсов, а множественного наследования нет (как в PHP), то интерфейсы — единственный выход.