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

Важнейшим стопором развития этого рынка является вопрос обеспечения информационной безопасности данных пользователя. На бытовом языке вопросы формулируются примерно так: «Как же я размещу ключевые для моего бизнеса данные где-то у провайдера?», «Что будет, если провайдер прекратит оказывать эти услуги?», «Какие гарантии, что данные не будут утрачены, переданы конкуренту?» и.т.п.

Я хочу на доступном языке дать ответы на эти вопросы, разложить по полочкам вопросы безопасности, описать «изнанку» работы SaaS провайдера.

Многие из читателей этой статьи брали кредиты. Как правило, мало кто изучает в деталях все условия кредитного договора, чем весьма охотно пользуются банки. Тем не менее, читать весь договор, включая написанное мелким шрифтом – весьма полезно. Например, можно посчитать, сколько вы переплатите за пользование кредитом (имеется в виду – на самом деле), и за что. Или узнать, какие санкции будут к вам применены, если вдруг что-то пойдет не так. А в некоторых договорах среди прочих услуг можно заметить некую «комиссию за ведение ссудного счета». Вот о том, что это такое, мы сейчас и поговорим.

Приход-расход

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

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.

Представляю вашему вниманию перевод статьи под названием "Fundamental Guidelines Of E-Commerce Checkout Design" от Christian Holst. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением издания Smashing Magazine.

Грустная статистика систем электронной коммерции — согласно последним исследованиям, по крайней мере 59,8% потенциальных покупателей покидают сайт на этапе оформления заказа и его оплаты (у разных исследований разные показатели — от 59,8% у MarketingSherpa до 83% у SeeWhy).

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

Disclaimer
Этот пост появился здесь по нескольким причинам:
1) Меня попросил сам Boomburum
2) Есть предположение, что на хабре всё-таки есть люди, имеющие прямое отношение к IT, но при этом имеющие весьма отдалённое представление о пользе SSH и её извлечении из обычного домашнего роутера, и которым, надеюсь, будет весьма интересно и полезно об этом узнать.

Хабралюдям, познавшим Дао IOS, tun, VPN, *wrt, WOL… etc, предлагается на выбор:
А) Закрыть топик, заняться делом и не выводить себя из нирваны чтением этой любительской фигни.
Б) Потратить время на конструктивную критику и полезные дополнения в комментариях.
Специально для GrammarNazi:
Пишите пожалуйста об ошибках в личку — обещаю исправиться.

Бла-бла-бла, а топик-то о чём?
Итак, я обещал рассказать «как поднять ssh-туннель домой без необходимости оставлять включённым домашний ПК» и, как правильно догадался peter23 речь пойдёт про ssh-сервер на роутере.

Настольная версия браузера Opera, начиная с версии 11.10, позволяет владельцам сайтов определять, как их сайт будет отображаться в миниатюрах Экспресс-панели. По-умолчанию, для отображения используется скриншот целой веб-страницы. Теперь появилась возможность указывать значок через CSS или в теле веб-страницы.

Приветствую, уважаемые сообщники!

Эта статья — о том, как мы реализовали веб-кластер для новостного портала (с пиком посещений в 130 тысяч уникальных посетителей в день — это 7Тб траффика за 3 дня — выборы и 2 последующих. Сейчас в среднем кластер раздаёт 35-40 Тб траффика в месяц), о том, как по-разному понимают одинаковые задачи программисты и журналисты, о том, как можно достичь одной и той же цели, идя разными путями.

Она будет интересна тем, кто хочет построить легко масштабируемый географически распределённый веб-кластер, не вкладывая астрономических сумм в оборудование (а по меркам телевидения — будут вообще смешные суммы).

Я больше чем уверен, что маркетологи, толкающие убер-решения свежевыпущенных продуктов, имеющих в своём названии слова «масштабируемый веб-кластер» или «horizontal infinite scalable web cluster», меня возненавидят.

Я больше чем уверен, что конкуренты наших клиентов будут удивлены простотой решения, которое мы использовали.

Жизнь была прекрасна и все было в этом мире хорошо, пока почта с моего сайта не стала активно посылаться в спам практически всеми крупными почтовыми серверами. Особенно усердствовал в этом Gmail. Частенько меня принимали за спамера в Yandex, реже в mail.ru и rambler.

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

В моем первом посте я описал применение Apache Traffic Server в качестве кеширующего reverse-proxy. В отзывах меня спрашивали почему не nginx? Поскольку в ATS все равно не нашлось удобного способа трансформировать контент сайта, то я решил изучить возможности Nginx. Для решения задачи пришлось углубится в дебри документации, и вот что получилось…

Как известно, все люди делятся на два вида: те, кто ещё не делает бэкапы, и те, кто их уже делает. У тех, кто только начинает делать бэкапы, первым обычно встаёт вопрос о том, каким способом архивировать данные. Простые варианты (вручную нарезать болванки, целиком архивировать каталоги на другие серверы) рассматривать не будем — у них весьма скромные возможности по индексированию и поиску архивных файлов. Вместо этого обратимся к автоматическим системам бэкапов, в частности bacula. Данная статья не рассматривает вопрос, почему bacula. Главные причины — она распространяется под свободной лицензией, доступна для кучи платформ и обладает огромной гибкостью.

Второй вопрос после выбора системы архивации — выбор места, где хранить бэкапы. Bacula позволяет использовать стриммеры, компакт-диски, писать архивы в FIFO-устройства и в обычные файлы. Стриммер удобен на корпоративных серверах, где есть постоянный физический к железу. Хранение архивов в файлах подойдёт, когда объём архивов не превышает объёма жёстких дисков, плюс для надёжности хранения желательно делать RAID-массив с избыточностью, а то и несколько физических серверов для бэкапов, желательно в разных помещениях. Иначе всё это до первого пожара. Нарезать на болванки — это домашний вариант, главный недостаток которого — необходимость регулярного втыкания свежих дисков. Мы же настроили bacula для архивации данных на Amazon S3.

На хабре уже проскакивали периодически заметки посвященные AWS (Amazon Web-Services) — так что тема не новая. Однако, если для меня лично (да и для многих моих знакомых как выяснилось) — этот термин был знаком — однако каких-либо деталей я не знал. Попробую на основании только-что полученного опыта рассказать немного подробней, а так же изложить основные шаги по организации хостинга сервера на AWS и его преимущества. Как и несколько ссылок, которые могут оказаться полезными.

Танцуют все!

Итак, только что завершили формирование образов и окончательно вышел Debian GNU 6.0 «Squeeze», как обычно доступно множество архитектур, среди которых:

• amd64
• armel
• kfreebsd-i386
• kfreebsd-amd64
• i386
• ia64
• mips
• mipsel
• powerpc
• sparc
• s390

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

Вчера, прочитав пост "Сборник советов и фактов по оптимизации PHP-скриптов", побывал в недоумении от некоторых пунктов статьи. Очень часто по работе приходится сталкиваться с крупными проектами. Последние 5 лет я работал с высокими нагрузками и получил, как мне кажется, хороший опыт их разработки и поддержки. Не хочу начинать холивары и в деталях расписывать все тонкости оптимизации проектов. Я лишь хочу высказать свою точку зрения на некоторые озвученные в статье пункты и, если Хабрапользователь меня поддержит, с огромным удовольствием эта статья будет началом цикла статей по оптимизации.

Самое главное правило, которое надо помнить при оптимизации: преждевременная оптимизация — это корень всех бед.

Эту статью давно стоило переписать (слишком много «экономии на спичках»), но руки не доходят. Пускай весит и напоминает о том, как мы глупы в молодости.
Одним из основных критериев успешности любого интернет-ресурса является скорость его работы и с каждым годом пользователи становятся всё более и более требовательными по этому критерию. Оптимизация работы php-скиптов — это один из методов обеспечения скорости работы системы.
В этой статье я бы хотел представить на суд общественности свой сборник советов и фактов по оптимизации скриптов. Сборник собирался мною достаточно долго, основан на нескольких источниках и личных экспериментах.

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

Здесь я попытаюсь ответить на эти вопросы, рассмотрев:

• Причемущества от наличия SSL вообще, и подписанного сертификата в частности.
• Типы SSL-сертификатов.
• Пути их получения.

Я не претендую за 100% верность данной статьи, она основана только на моем мнении и личном опыте :)

В далеком 2008 году уже была написана подобная статья и я попытался применить знания, но, к сожалению, не справился с русским языком (на denwer-е работал, на хостинге нет). Возможно сказалось отсутствие опыта. А недавно нашел хорошую библиотеку и решил поделиться. Топик, скорее всего, адресован начинающим программистом и ни на, что не претендует.

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

Задача и выбор площадки

Задача: выбрать виртуальный сервер на стабильной немецкой площадке, с недорогим трафиком и ценой до 20 евро в месяц и установить archlinux.



Поиск по хабру дал несколько полезных статей и еще один ресурс от которых можно оттолкнуться.
В итоге выбор пал на трех претендентов: server4you.net, hetzner.de, hosteurope.de.

Данная статья давно назревала в моей голове, но совсем в ином формате.
Прочитав последние несколько неуклюжих статей на тему WEB-сервисов (например: http://habrahabr.ru/blogs/development/108973/) и применения в них REST технологии, решил что настало время все-таки откинуть лень, выделить время и написать «переформатированную» в своей голове статью.
Итак, кратко, что Вы найдете в статье и кому она будет полезна:

— новичкам, которые интересуются или планируют написать WEB-сервис для проекта
— профи вряд ли найдут что-то новое для себя
— общая идеология REST
— применение CRUD в WEB-сервисах
— принципы KISS при построении раутеров
— лучшие практики
— немного пиара ;)
— ссылки, литература