MikhailEdoshin

Perl плохо знаю, а вот Python и Ruby хорошо. Если вы планируете заниматься только web-разработкой, то я бы советовал все же Ruby. Как ни хорош Django, инфраструктура web-разработки на Ruby ушла гораздо дальше. Если планируются более разнообразные задачи, то лучшим выбором я бы назвал Python. Что же до себя, то я так и не смог выбрать, поэтому изучал и продолжаю изучать оба.

wire transfers в США осуществляются между банками, которые зарегистрированы и имеют представительсто в США.

В Вашем же случае Сбербанка не имеет представительства в США и соотвественно не может быть подключен к wire transfers Федеральной резервной системы напрямую.

Банк- корреспондент — это банк-резидент США в котором у Сбербанка есть счет. Банк корреспондент имея некую договоренность с Сбербанком переводит деньги в Сбербанк.

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

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

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

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

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

Да.

1) Для каждого сеанса обмена сообщениями генерируется случайный сеансовый ключ.
2) Сеансовый ключ передается в зашифрованном виде при помощи RSA 512/1024/2048
3) В дальнейшем сообщения шифруются симметричным алгоритмом (AES 128/256, Twofish, Serpent, IDEA) при помощи сеансового ключа.
Плюсы:
+ размер ключа для симетричных алгоритмов меньше при сравнимой криптостойкости
+ размер блока (а значит, минимальный размер сообщения) составляет 128-256 бит
+ симметричные алгоритмы работают гораздо быстрее
Минусы:
— нужно предварительно генерировать и передавать сеансовые ключи
— нужно следить за сроком действия и актуальностью сеансовых ключей

Из неперечисленных Беббидж и Дейкстра.

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

Теперь представьте себе пользователя. Он зашел в Qooqle, набрал «купить мопед москва» и видит: «Продам мопед, недорого, Москва», кликает по ссылке — а вы ему вместо мопеда показываете объявления из его города Замкадовска (где максимум можно купить подержанный велосипед). Это неправильно. Мы же делаем сайт для людей, а не для СЕО, верно?

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

Надо сделать отдельные папки или домены для разных городов: saint-peterburg.objava.ru/list например. Или objava.ru/saint-peterburg/list. Если юзер из одного города зашел на домен другого города — можно показать ему в шапке предложение перейти на домен его города, но не навязывать и не заставлять переходить. Может, я еду в какой-то город и хочу посмотреть объявления оттуда.

Что же касается главного домена — objava.ru — то можно показать на нем карту России или список городов (нормальными ссылками, без яваскрипта и прочей дряни), и например, ярко выделить в нем город пользователя и предложить перейти. Например, как это сделано на главной сайта avito.ru. Человек перейдет в свой город, а робот обойдет все.

А вот за показ разного контента для разных IP по одному УРЛ и за редирект, не спрашивая желания пользователя, я считаю, сайты надо банить (что иногда и происходит). Нам не нужен колхозный интернет. Давайте все делать в соответствии со стандартами, руководствами по юзабилити и лучшими практиками, а не пытаться обхитрить поисковые системы и пользователей.

Напишите на… WinAPI ;-)
Легче и прямее некуда просто…

В том же законе есть небезынтересная статья 8:

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

Там ещё есть проблема с оплатой. У меня мои немецкие кредитки и пейпал не пошли.

Вариантов в сети предостаточно:
proxy-list.org
www.proxybox.ru/proxy_private_usa.htm
www.proxy-base.org/

Второй вариант тока за $.
Первый реально может выдать американский прокси бесплатно.
Третий — ну в общем там в основном диапазоны выкладывают… но пошарившись по форуму тоже можно найти «за так».

ищите в google по словам VPN, USA и т.п.

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

Ч. Петцольд
Программирование для Windows 95. Том I
Программирование для Windows 95. Том II

Странные у вас теги

В Adobe Illustrator.

', '.join(map(str, a))