rzhannoy

я бы выбрал python + qt.

qt сейчас один из самых кроссплатформенных тулкитов.

Попробуйте библиотеку grab туториал - http://habrahabr.ru/post/139435/ . Там есть работа со списком прокси.

На самом деле, сам язык не так важен. Важно насколько вы хорошо понимаете, что происходит за кадром и что может происходить в разных ситуациях. Конечно же есть языки которые лучше подходят для решения определенных задач. Но практически все задачи решаются на любом языке. Поэтому понимание процессов важнее знания языков. Грубо говоря, если вас спросили как кудато пройти и вы не знаете, то и на родном русском объяснить не сможете. А если знаете, то со словариком или без, на любом языке объясните.

Раз уж вы знакомы в WordPress, изучите PHP. В качестве фреймворка я бы посоветовал СodeIgniter как самый простой.

Я не советую вам сейчас лезть в Python и другие языки. PHP, даже без фреймворков, заточен под веб и во много облегчает работу. С ним достаточно легко научиться понимать и делать базовые вещи (связь с БД, обработка запросов, понятие ООП, MVC, Design Patterns). Когда почувствуете что бы достаточно хороши в PHP и в понимании основ программирование, беритесь за Python / Ruby / Java / и так далее.

Кроме того, на PHP на самом деле больше работы.

Удачи

эйфория от новых возможностей прошла и вскрылись недостатки, на мой взгляд основные их них:
— Слабая производительность на 1-серверной БД. Особенно заметно на map-reduce по данным, которые полностью влезли в память.
— Особенности документо-ориентированной структуры. Многие переходили с табличных БД и тут понеслась: сначала радость, что не надо возиться со структурой, а потом расплата — в одной коллекции куча разных объектов и приложение регулярно читает из вроде бы известной коллекции что-то для себя неожиданное (очень старые объекты, некорректно измененные и т.п.).
— Целостность данных. Кто-то привык, что БД контролирует этот вопрос, вешают констрейнты и ловят ошибки в логе в случае какой промашки по части бизнес-логики. Монга же ничего такого сама не контролирует, ну и получаются внутри БД ссылки на объекты, которых нет.
— Отсутствие полноценных транзакций. Те, кто бросились все хранить в монге с ужасом поняли, что для биллинга нужно что-то другое. (должен оговориться, что не все пока поняли)

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

PS Мое мнение основано на годичном опыте неплотной работы с монгой, опыт работы с реляционными БД — примерно 10 лет.

Найдите причину, почему прижата к правому краю (должно по умолчанию к левому прилипать), устаните её и добавьте к блоку классы col-xs-offset-3 col-sm-offset-3 col-md-offset-3
Ручной margin тут не оправданно использовать.

$('.element_3, .element_4').wrapAll('<div class="new">');

hasOwnProperty?