На прошлой неделе я случайно увидел в Твиттере сообщение о VII бесплатном семинаре по Интернет-маркетингу. Бесплатное участие и докладчик из Гугл-Россия соблазнили мгновенно. Зарегистрировался и стал с небольшим волнением ждать заветной пятницы 20-го: в вебинарах до этого не участвовал, с гуглоидами не общался, поневоле ждал чего-то любопытненького, какой-то «клубнички». В хорошем смысле – по-нынешнему то бишь эксклюзива и инсайта. Хотя рассудок, пессимистятина такая, туманно кивал на «халяву», намекая на тщетность этих ожиданий. И оказался таки прав.

Пришла пятница. Подошло время. Пришёл я к начальнику IT-отдела и сказал: пора, дружок, тестировать канал и микрофон.

Самая мощная команда в MySQL – это EXPLAIN. EXPLAIN может в точности рассказать вам, что происходит, когда вы выполняете запрос. Эта информация позволит вам обнаружить медленные запросы и сократить время, затрачиваемое на обработку запроса, что впоследствии может значительно ускорить работу вашего приложения.

Введение

Любой прогресс и оптимизация приветствуется кем угодно. Сегодня хотелось бы поговорить про прекрасную вещь, значительно облегчающую жизнь – очереди. Внедрение best practices в этом вопросе не только улучшают производительность приложения, но и успешно готовят ваше приложение к архитектуре «в стиле» Cloud Computing. Тем более, что не использовать уже готовые решения от провайдеров облачных технологий просто глупо.

В этой статье мы рассмотрим Amazon Web Services с точки зрения проектирования архитектуры средних и больших веб приложений.

Рассмотрим схему такого приложения:

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

Варианты построения высокодоступных систем в AWS. Преодоление перебоев в работе

Отказоустойчивость является одной из основных характеристик для всех облачных систем. Каждый день множество приложений проектируются и разворачиваются на AWS без учета этой характеристики. Причины данного поведения могут варьироваться от технической неосведомленности в том, как правильно спроектировать отказоустойчивую систему до высокой стоимости создания полноценной высокодоступной системы в рамках сервисов AWS. В данной статье освещается несколько решений, которые помогут преодолеть перебои в работе оборудования провайдеров и создать более подходящее решение в рамках AWS инфраструктуры.
Структура типичного Интернет приложения состоит из следующих уровней: DNS, Load Balancer, веб сервер, сервер приложения, база данных, кэш. Давайте возьмем этот стек и подробно рассмотрим основные моменты, которые необходимо учитывать при построении высокодоступной системы:

• Построение высокодоступной системы в AWS
• Высокая доступность на уровне веб сервера / сервера приложения
• Высокая доступность на уровне балансировки нагрузки / DNS
• Высокая доступность на уровне базы данных
• Построение высокодоступной системы между зонами доступности AWS
• Построение высокодоступной системы между регионами AWS
• Построение высокодоступной системы между различными облачными и хостинг провайдерами

Часть 2

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Вступление

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

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

Скажу сразу — «Америку не открываю», так же как не «изобретаю велосипед». Статья базируется на модели ситуационного лидерства Херси-Бланчарда. Сама модель в значительной степени изменена в применении к управлению именно ИТ-командами в нашей стране и подкреплена практическим опытом управления командами в Майкрософт Рус и в собственном бизнесе.

Выбирая между «академическим» и «популярным» стилями изложения выбрал «академический». Все таки разговор о серьезных вещах. Так что если эта тема Вам прямо сейчас не супер-актуальна — смотрите диаграммы, их достаточно для понимания идеи. Остальное — для достаточно узкой аудитории.

На сегодняшний день диапазон цен на рынке веб-сайтов колеблется от 500 рублей до 50 000 евро и выше. Давайте разберемся, сколько стоит сайт и почему. Простой расчет поможет убедиться в справедливой стоимости профессионально выполненного сайта и наведет заказчиков на несколько полезных жизненных выводов. Выводы навеяны опытом работы и отзывами наших клиентов. Интервалы цен приведены, по большей части, для региона «Центр».

Для начала, пара слов в защиту описания fail'ов

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

Наблюдал у многих, с кем я работаю, этот синдром. Даже у себя наблюдал [из-за чего с предыдущей работы ушёл]

Синдром, если в кратце, звучит так: «Меня не ценят».
Человек работает, работает, и постепенно понимает, что деньги, которые ему тут платят, не соответствуют его навыкам.

Как это выглядит? Я попробовал нарисовать схему и пояснить её:

Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

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

Все, все будут писать тесты

Уже 3 года прошло, с тех пор как я увидел свою первую красную полоску. Что меня дернуло начать писать тесты, уже не важно. Я начал собирать информацию, перечитал весь wiki.agiledev.ru и торжественно запустил свой первый тест на SimpleTest. Конечно, эти тесты были ужасны, да и архитектура тоже (в моем сегодняшнем понимании). Тогда я, наверное, словил большинство ошибок, но зато замечательно провел время :)

Потом перешел на PHPUnit — просто было интересно, чем он отличается от SimpleTest и что в нем такого «навороченного».

А lime — гадость. Чего ребята из Symfony в него так вцепились? Понимаю ветка 1.*, наследие и все такое. Но 2.0 можно было бы и на PHPUnit начинать.

Да, мне это было интересно. Я активно писал тесты, даже честно пытался делать это перед тем, как писать код. Что-то не получалось, читал разные статьи на тему, как надо и не надо писать тесты, перечитывал wiki.agiledev.ru. Но внутри явно чего-то не хватало.

Меня часто спрашивают, какой мой любимый компонент в Zend Framework, и я всегда отвечаю: «Forms» (формы).
В парадигме модель-представление-контроллер формы всегда играют непростую роль. Конечно, форма — это всего лишь HTML,
но для меня это нечто более абстрактное.
По сути, форма — это HTML, средствами которого пользователь вводит и получает данные, но кроме этого форма еще выполняет
нормализацию, проверку, фильтрацию данных и вывод сообщений об ошибках, если они есть.
Это может потребовать довольно-таки значительного объема кода.

Привет, Хабр!

Нашими силами подготовлен аналитический материал, посвященный итогам 2009 года на рынке разработки интернет-проектов. Материал получился довольно большой, поэтому приведу некоторые выдержки (а именно, разделы «ситуация на рынке» и «тренды развития»), представляющие наибольший интерес:

Ситуация на рынке:

Объем рынка в 2009, по нашим оценкам, вырос по отношению к 2008 году (напомним, объем рынка в 2008 был оценен на уровне 6,8 млрд. руб.). На рынке действует порядка 4 000 игроков (в подавляющем большинстве — небольших компаний), что делает его по-прежнему весьма непрозрачным. Финансовый кризис сыграл определяющую роль в развитии отрасли в 2009, в положительном смысле повлияв на скорость взросления рынка и среднее качество оказываемых услуг, а также на эффективность взаимодействия с клиентом.

Консолидация

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

Работая долгое время области банковского ПО, а в частности по всяким электронным платежам, вместе с коллегами я составил мини-ЧАВО на тему банковских пластиковых карт. Многие вопросы очевидны, а некоторые могут быть весьма туманными. В России бизнес пластиковых карт набирает обороты, что приятно, и лучше быть подкованным по «матчасти».

Итак, 10 распространенных заблуждений.

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

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

Коллаборативная фильтрация (англ. collaborative filtering) — это метод, который даёт автоматические прогнозы исходя из наколенной информации о интересах и вкусах пользователей.

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

Успех состоит из пути от одной ошибки к другой без потери энтузиазма.
Уинстон Черчиль

Каждый знает, что такое стартап. Разве нет?
Я бы предложим новое объяснение тому, почему появляются стартапы: стартап – это организация, созданная для поиска повторяемой (в англ.оригинале «repeatable» – в значении «не одноразовая модель», а НЕ «бизнес-модель, которую можно повторить») и масштабируемой бизнес-модели.

Бизнес-модель

Хорошо, а что такое бизнес-модель?
Бизнес-модель описывает, каким образом ваша компания создает, достигает и завоевывает ресурсы.
Простым языком, бизнес-модель описывает, как ваша компания зарабатывает деньги (в вашей системе координат это могут быть успех, новые пользователи, прирост трафика и т.п.)
Представьте, что бизнес-модель – это диаграмма, на которой показаны все связи между различными частями вашей организации. Эта диаграмма показывает и то, как ваша продукция попадает к покупателям и как оплата за эти продукты попадает к вам. Также она демонстрирует структуру затрат, как каждый отдел компании взаимодействует с другими, как ваша компания интегрирована в рынок и взаимодействует с партнерами. Слова словами – проще отобразить на схеме.

Схема бизнес-модели

Много людей пытались понять, как лучше отобразить диаграмму или схему бизнес-модели. Мои студенты занимались этим годами, но работа Александра Остерволдера (Alexander Osterwalder) это лучшее, что я увидел за последние десять лет. Его диаграмма – это универсальный образец бизнес-модели. Ваша собственная бизнес-модель будет иметь свойственные только ей нюансы.

Студентов MBA на западе учат древней индейской мудрости — если Вы замечаете что лошадь, на которой Вы скачете сидите, мертва, то лучше всего с неё слезть. Применимо к бизнесу и стартапам это означает, что если продукт помер, его часто лучше списать в утиль и идти дальше, чем вкладывать деньги в реанимацию или особенно бездействие. Замечу, что даже сидя на мёртвой лошади менеджмент может быть уверен, что скачет галопом в светлое будущее. Многие будущие CEO эту мудрость на вооружение берут более дословно — мол не зазорно уйти с тонущего корабля одним из первых, существуют и другие выводы, результирующие из недо-, пере- и иначе-понимания этой мудрости.

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

Что мы делаем когда закрадывается смутное предположение, что компания скачет на мёртвой лошади:

[ Индикаторы класса «Возможны ложные срабатывания» ]
— Мы достаём более хлёсткий и мощный кнут для мёртвой лошади (а нередко и на конюхов розг хватает)
— Ждём, ничего не делаем, ведь мы всегда точно так ездили на мёртвых лошадях и раньше проблем не было
— Меняем наездника. Когда мёртвая лошадь не скачет виноват обычно он
— Облагораживаем стойло, достаём конюхам пряников
— Едем за бугор, там с незапамятных времён водились наездники на мёртвых лошадях, перенимаем их опыт
— В добровольно-принудительном порядке предлагаем курсы верховой езды сотрудникам отдела
— Создаём группу и анализируем мёртвую лошадь, время смерти и меру окоченения
— Признаём мёртвую лошадь неверно аттестованной, она живее всех живых

Более веские приметы под катом