Друзья, я хочу вам рассказать историю развития проекта president2012.ru. Сайт является лидером по тематике выборов президента России, за 3 месяца его посетило около 2 млн. человек, в пике имел до 20 тыс. посетителей онлайн и более 1 млн. хитов в сутки, задействовано было 3 сервера облака.

Интересных моментов в процессе работы над проектом набралось столько, что держать в себе эти знания я не могу, и хочу поделится с вами. Я понимаю, что многое, о чем я сейчас собираюсь рассказать, уже описано качественнее в специализированных разделах, и ничего нового я не открою. Моя задача скорее в том, чтобы через отдельные нюансы передать ту атмосферу, в которой проходила работа над проектом. А так же в миллионный раз с помощью success story показать таким же как я людям, что всё возможно и всё в их руках.

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

Каждый из нас, хоть раз при разработке мобильных версий сайта, задумывался о том, как можно ускорить процесс разработки, дебаггинга и быстрого просмотра изменений. Кто-то поднимал для этого локальный сервер, кто-то ставил эмуляторы, чтобы лишний раз не тянуться к телефону для просмотра, кто-то делал и более костыльные решения. Ребята из Adobe Lab позаботились о нас и выпустили сегодня прекрасное приложения для этих нужд. Барабанная дробь, встречайте — Adobe Shadow!

Adobe Shadow — это совершенно новый инструмент помогающий front-end разработчикам и дизайнерам максимально увеличить эффективность и скорость разработки мобильных версий сайтов за счет оптимизации процесса просмотра изменений и дебаггинга на мобильных устройствах. Shadow работает независимо от других продуктов от Adobe и пока совершенно бесплатен!

Сначала «скелет», а потом «мясо».
Сначала процесс, а потом инструмент под процесс.
Автоматизация хаоса дает хаос.

Это все — разные формулировки одной простой идеи. Идея, которая часто не учитывается во множестве вещей.

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

Не учитываются следующие моменты
1. Сам процесс может существовать только в воображении создателя стартапа. К примеру, процесс аггрегации результатов матчей ЦСКА вовсе может быть не нужен фанатам этого футбольного клуба, как бы себе это не представлял стартапер. Поэтому важно быть в самом процессе, понимать, какой процесс — реален, а какой нет.

Всем доброго времени суток!

Введение

На написание этого поста меня сподвигло слишком малое количество материала о sinatra, и тем более о данной связке. Надеюсь для кого то этот пост будет полезен. Ниже я опишу как можно совместно использовать sinatra, mongodb и carrierwave, на примере создания простой фотогалереи. Для общения между sinatra и mongodb мы будем использовать отличный gem — mongoid. По умолчанию предполагается что у вас уже установлен ruby и mongodb. Приступим.

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



Путь займёт около 400 миль, в день мы можем пройти 4 мили в час по десять часов, так что придём мы туда примерно через 10 дней. Мы звоним друзьям и бронируем столик на 6 вечера в воскресенье.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Большинство разумных веб-разработчиков уже давно знают, что принудительная регистрация — зло. Но некоторые до сих пор без лишней необходимости закрывают контент от пользователей или не дают им купить товар до тех пор, пока они не зарегистрируются. Такой подход оправдан в случае платных услуг или сервисов вроде РуТрекера. Но в большинстве своём является для ресурса крайне вредным или даже губительным.

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

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

У многих людей, как-либо связанных с безопасностью, периодически возникает желание заняться pentest'ом, то есть тестом на проникновение. И чаще всего начинают все с pentest'а веб-приложений. Порог вхождения довольно мал (простейшая sqli определяется добавлением кавычки в параметр и эксплуатируется не особо сложнее), но при этом встречаются и довольно сложные задания, которые заставляют потратить пару-тройку дней на ковыряние.
Но возникает вопрос — где применять теоретические знания, без страха внезапного появления маски-шоу? Под катом проведу небольшой обзор полигонов для экспериментов по pentest'у.

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

Представляю вашему вниманию третью и, на сегодняшний день, последнюю из цикла статей с описаниями техник анализа проблем и принятия решений (первые две статьи: «Дерево существующей реальности» и «Вопросы Леонардо да Винчи»).

Сегодня я расскажу вам о технике под названием «3D-анализ».
Она ориентирована скорее на поиск конкретных действий, направленных на решение конкретных небольших проблем.
Думаю, что каждый сможет самостоятельно определить для себя масштаб проблем, которые подходят для анализа по этой технике.
Также необходимо сразу оговориться, что описываемый метод является достаточно спорным, однако себе я доказал его эффективность неоднократным использованием и при решении личных проблем, и для достижения профессиональных целей.

Все еще интересно? Тогда приглашаю под кат.

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

Лента фриланса сейчас напоминает золотые прииски Колорадо. Людей тьма, а золота нифига. О последних нововведениях вообще говорить не хочется.

Вот я и подумал: зачем чахнуть в ожидании, чтобы получить хоть, сколько интересный проект. Лучше сделать что-то по фану.

Иногда мне кажется, что в экосистеме Ruby on Rails есть проклятое место: встраиваемые движки для ведения блогов. Это особенно мило наблюдать в свете существования бесконечного количества скринкастов «блог на Rails за 10 минут».

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

Некоторое время назад, когда я работал в «АБАК-ПРЕСС», руководство повелело внести в милый сайтик LookMart.ru весьма модную нынче «фишечку» — пользовательские блоги (на данный момент эта функциональность находится в активной разработке). Меньше всего нам хотелось изобретать велосипед и городить очевидные вагоны из контроллеров с моделями, но после небольшой разведки пришлось смириться и сделать всё самостоятельно. Почему?

Привет, сообщество!

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

В общем, действительно не для слабонервных.

Брэм Коэн анонсировал новую версию протокола BitTorrent. Она получила название BitTorrent Live и предназначена для организации видеотрансляций через пиринговые сети. На разработку нового протокола у программиста ушло три года, зато теперь даже при многомиллионной аудитории задержка передачи видео не превышает пяти секунд.

BitTorrent Live позволит снизить нагрузку на распространителя файла до 99%. Таким образом, передача видео будет стоить дешевле, чем по спутнику или с помощью CDN, и для него не потребуется дорогостоящая инфраструктура.

Создатель протокола заявил, что хочет уничтожить телевидение в его нынешнем виде: «Физическая инфраструктура телевидения неизбежно отомрет, но телевидение как модель потребления контента останется».

Сейчас Коэн ищет партнеров, которые дадут согласие на распространение своего контента по предложенной им модели. Netflix и Hulu, которые планируют сократить затраты на инфраструктуру, уже заинтересовались изобретением. Кстати, BitTorrent Live смогут использовать и некоммерческие вещатели — новый протокол является открытым и свободным.

BitTorrent Live уже функционирует в тестовом режиме. Посмотреть видео по новому протоколу можно через сайт live.bittorrent.com, предварительно скачав специальный клиент.

Расскажу о личном опыте выпуска iPhone-приложения Pocket Lists, продажи которого за первые два с половиной месяца составили $12500 долларов США. Категория приложения: Productivity.



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

Первый месяц после выпуска

На тему оптимизации MySQL запросов написано очень много, все знают как оптимизировать SELECT, INSERT, что нужно джоинить по ключу и т.д. и т.п.

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

Доброго времени суток!

Предисловие

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

Введение

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

Однако, изучение Ruby on Rails является достаточно простым занятием. Это невероятно мощный фреймворк, который имеет огромное сообщество, продвигающее его вперёд. Итак, у нас возникает вопрос: какой способ изучить Rails является лучшим? Вот он — план занятий.

Здравствуйте!

Это вторая из трех статей о техниках анализа проблем и принятия решений (первая здесь).

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

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

Примеров в этой статье не будет по двум причинам.
1. Пример в первой статье оказался крайне неудачным
2. Текст получился бы слишком громоздким, если бы я использовал хотя бы один пример (сейчас поймете почему)

Всех заинтересовавшихся прошу под кат.

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

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

Прошу под кат!

NB: Это первая статья из серии «Техники анализа проблем и принятия решения».

NB2: Рассмотренные в примере выводы являются приблизительными и основаны на полностью выдуманной ситуации.

От переводчика. Данный текст является вступительным текстом к минисерии из 4 публикаций, посвященных социальным сетям и сообществам, их сходствам и различиям, а также их взаимосвязи друг с другом.

1. Сообщество или социальная сеть?
2. Как люди образуют связи
3. От слабых связей к сильным
4. Поддержание сильных связей

Автор этой серии публикаций — Майкл Ву (Michael Wu), ведущий аналитик компании Lithium, специализирующийся в изучении социальных взаимодействий и онлайн-сообществ.

---

Я хочу поделиться с вами своим недавними исследованиями, посвященными взаимосвязи между социальными сетями и сообществами.

С 2008 года социальные медиа становятся широко используемым и модным понятием в корпоративном мире. Вопрос в том, что такое социальные медиа? Одни, похоже, отождествляют это понятие с сайтами, называющимися социальными сетями, вроде Facebook. Другие думают, что социальные медиа — это блоги, микроблоги (вроде Twitter), Flickr, Youtube или любые другие аналогичные вебдванольные сервисы, основанные на коллективном обмене информацией между пользователями. Указывают на разные типы социальных медиа, начиная с сервисов социального взаимодействия (вроде Wikipedia, Delicious или Digg), и заканчивая онлайн-сообществами (вроде тех сообществ, которые мы создаем вокруг брендов или же таких как Yahoo! Answer).

Все эти определения в некоторой степени верны, если мы классифицируем социальные медиа по их функциональным признакам. С другой стороны, писатель и блоггер Брайан Солис (Brian Solis) предложил иную классификацию социальных медиа, основанную на способах общения между людьми. Он назвал свою классифиацию «Призмой общения» (conversation prism). Однако, если мы хотим понимать социальные медиа с точки зрения выстраивания связей между людьми в рамках социальной антропологии, мы обнаружим, что существует всего два основных типа социальных медиа:

1. Социальные сети
2. Онлайн сообщества