Алексей Сундуков

ZendFramework тяжелая куча абстракции. Может быть килограммы кода под него генерить и не нужно, но на старте времени потребует явно много. taliban прав, выбирать нужно под конкретную задачу в текущем контексте.

Лежит. Но не весь. Выхожу с дом.ру (Самара), GMail еще как то работает, а вот документы не пашут. Отваливается по таймауту.

По сабжу. Видимо на текущий момент об облегчении интеграции бизнеса и банка в России мечтать не приходиться. Из того, что удалось накопать, это СБ банк. Руками сам еще не щупал, их нет в моем регионе, но обязательно планирую. Потому как уже их сайт и размещенная на нем документация производят очень положительное впечатление.

Линки:
Банки, предоставляющие програмные API
Ищу банк с уведомлениями на e-mail

Jabber на базе GTalk. В том числе со вкусом своего домена.

На скидку стоило бы копать в сторону настроек ядра, в частности сетевой подсистемы. Банально netstat-ом посмотреть, сколько соединений висит и в каких состояниях.

>умножать начальный эстимейт на 2-2.5
Рекомендую «правило пи». Умножать на 3.14

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

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

Браузер сам их загрузит. Работать будет во всех современных.

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

1) Потому что в 99% случаев разработчики даже не думаю применить шифрование. "SSL? Чоэт? Аааа… ну не, пусть этим админы занимаются, это их работа".
2) Варианты на вскидку: а) более защищенный вариант чем сертификаты для других поддоменов; б) в случаем компрометирования wildcard-сертификата под удар попадают все поддомены кроме этого.

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

Рекомендую работать через gettext.

В салоне себестоимость всегда будет ниже чем дома по той же причине, почему массовое производство дешевле кустарного. Даже если ставить СНПЧ, даже если использовать не оригинальные краски и печатать только на ламонде. Зато удобно и всегда под рукой. Аналогии примерно как личное авто и общественные транспорт. Второе по цене всегда выигрывает.

Имхо, потому что воркеры-процессы более просты в реализации и более обкатаны по времени. Но логичнее было бы спросить самого Игоря.

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

Смотреть нужно в сторону разного анализирующего ПО (антиспамы/антивирусы).

Если цель — защита от перехвата, то самое разумное — HTTPS.