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

Все началось с того, что мой контракт подошел к концу (в течение года я участвовал в работе над почтой Mail.ru). «Снова меня ждут приключения», — пронеслось в мыслях, — «новая страна, новая работа». Я пошел к своему начальству и в ходе обсуждений все-таки получил порцию приключений в виде интересной задачки — заняться проектом Ответы.

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

Как показывает практика, большинство людей (увы!) бросают свои диссертации, не дойдя до защиты. Почему так происходит?

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

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

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

Коллеги расскажите, пожалуйста. как вы делаете деплой на production сервер(сервера) веб-проектов.
Если у вас используется 3 или 4 вариант, то как вы переключаете document_root — создаете симлинк на новый релиз или переписываете (скриптом) конфиг nginx?
Если переключать симлинк не бывает проблем с APC или XCache?
Если не хватает какого то варианта пишите в комментарии.

UPD: Спасибо всем за комментарии, пятничный пост получился очень продуктивным и полезным думаю для многих.
UPD2: Небольшой обзор комментариев:
подробные разборы деплоя habrahabr.ru/post/211733/#comment_7286111 habrahabr.ru/post/211733/#comment_7287769
утилиты для создания deb пакетов habrahabr.ru/post/211733/#comment_7286187
наиболее популярное готовое ПО capistrano, fabric, teamcity

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

В прошлом году на конференции Whalerider Алексей fisher Рыбак рассказывал о том:

• как у нас Badoo сейчас устроена разработка;
• как в процессе развития проекта её перестраивали;
• какие проблемы решали;
• как преодолевали кризисы роста;
• на какие грабли наступали.

В секции вопросов есть интересная информация о том, как в Badoo устроена система мотивации и бонусов.
Сейчас у нас появилось видео и мы хотим поделиться им с вами.

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

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Давным давно в одной из компаний, лидере мирового производства микропроцессоров, меня однажды поразила менеджерская напасть. Решил, знаете ли, заняться развитием сотрудников. (Периодически, такое с менеджерами случается, да.)

Подхожу к своему сотруднику — назовем его Серега:

— Серега, — говорю, — ты в какую сторону вообще хочешь развиваться: в техническую или в менеджерскую?

— Сань, ну голова варит уже не очень, возраст… (Серега старше меня на 3 года) Поэтому, наверное, в менеджерскую.

Ну, в менеджерскую — так в менеджерскую. Я ж на тот момент был менеджер опытный, уже 4 года опыта! Энергии много, желания помочь людям — через край!

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

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

Заодно поговорим, что делать, если вы обнаружили себя и/или своих сотрудников в квадрате C в статье:

• Управленческие инструменты: Как играть в нелинейные шахматы

Yac 2013 посетил Jason Rudolph из GitHub. Я считаю его доклад про API был одним из самых интересных на конференции. Яндекс обещал выложить в сеть записи, так что советую на досуге посмотреть его всем, кто не видел.

Но речь пойдет не о докладе. На картинке график релизов GitHub на продакшн.



Когда я услышал цифру, я не поверил своим ушам. У GitHub'а сотни обновлений в неделю. В команде около сорока разработчиков и ни одного QA.

К счастью Джейсон после доклада еще какое-то время находился рядом со сценой и я смог расспросить его с пристрастием о том как они это делают.

Когда проект маленький, особых проблем с ним не возникает. Список задач можно вести в текстовом файле (TODO), систему контроля версий, по большому счёту, можно и не использовать, для раскладки файлов на живой сервер их можно просто скопировать (cp/scp/rsync) в нужную директорию, а ошибки всегда можно посмотреть в лог-файле. Глупо было бы, например, для простенького сервиса с двумя скриптами и тремя посетителями в день поднимать полноценную систему управления конфигурациями серверов.

С ростом проекта требования растут. Становится неудобно держать в TODO-файле несколько десятков задач и багов: хочется приоритетов, комментариев, ссылок. Появляется необходимость в системе контроля версий, специальных скриптах/систем для раскладки кода на сервер, системе мониторинга. Ситуация усугубляется, когда над проектом работает несколько человек, а уж когда проект разрастается до нескольких серверов, появляется полноценная инфраструктура («комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы», Wikipedia).

На примере нашего сервиса "Календарь Mail.ru" я хочу рассказать о типичной инфраструктуре и жизненном цикле разработки среднего по размерам веб-проекта в крупной интернет-компании.

Когда мы говорим об автоматизации процесса разработки и тестирования, мы подразумеваем, что это очень масштабное действие, и это действительно так. А если разложить его по частям, то станут видны отдельные фрагменты всей картины ― такая фрагментация процесса очень важна в двух случаях:

• действия выполняются вручную, что требует сосредоточенности и аккуратности;
• жёсткие временные рамки.

В нашем случае налицо лимит по времени: релизы формируются, тестируются и выкатываются на продакшн-сервер два раза в день. При ограниченных сроках в жизненном цикле релиза процесс удаления (отката) из релизной ветки задачи, содержащей ошибку, имеет важное значение. Для её выполнения мы используем git rebase. Так как git rebase ― это полностью ручная операция, которая требует внимательности и скрупулезности и занимает продолжительное время, мы автоматизировали процесс удаления задачи из релизной ветки.

Несколько месяцев назад мы ускорили генерацию code coverage с 70 до 2,5 часов. Реализовано это было как дополнительный формат в экспорте/импорте coverage. А недавно наши pull requests попали в официальные репозитории phpunit, phpcov и php-code-coverage.

Мы не раз рассказывали на конференциях и в статьях о том, что мы «гоняем» десятки тысяч юнит-тестов за короткое время. Основной эффект достигается, как несложно догадаться, за счёт многопоточности. И всё бы хорошо, но одна из важных метрик тестирования ― это покрытие кода тестами.
Сегодня мы расскажем, как его считать в условиях многопоточности, агрегировать и делать это очень быстро. Без наших оптимизаций подсчёт покрытия занимал более 70 часов только для юнит-тестов. После оптимизации мы тратим всего 2,5 часа на то, чтобы посчитать покрытие по всем юнит-тестам и двум наборам интеграционных тестов общим числом более 30 тысяч.

Хочу поделиться опытом изучения Tarantool. Про все преимущества и особенности самого Тарантула я писать не буду, на эту тему было много статей (например, эта, эта и эта). Этот пост рассказывает о том, как начать работать с тарантулом и про некоторые особенности и вкусности которые можно получить из коробки.

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

Ускорение набора текста с помощью добавления спецсимволов

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

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

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

Мой выбор пал на несколько отечественных вузов с вечерними программами, и я уже было выбрал МГТУ имени Баумана своей второй альма-матер, как я наткнулся на сайт Harvard Extension School .

У нас неплохо получается хранить фотографии, поэтому мы решили упростить жизнь и вам, если вы хотите соорудить свой tumblr, facebook или imgur. Дело на самом деле нехитрое, но есть тонкости, о которых лучше знать заранее. К тому же мы сделали всё на node.js, что не слишком характерно для хранилища с более чем 100 000 000 фотографий.

Сегодня мы поговорим про разработанную нами утилиту, которая оптимизирует тестирование PHP-кода с помощью PHPUnit и TeamCity. При этом нужно понимать, что наш проект — это не только веб-сайт, но и мобильные приложения, wap-сайт, Facebook-приложение и много чего ещё, а разработка ведется не только на PHP, но и на C, C++, HTML5 и т.д.

Методы, которые мы описываем, прекрасно адаптируются под любой язык, любую систему тестирования и любое окружение. Поэтому наш опыт может оказаться полезным не только разработчикам веб-сайтов на PHP, но и представителям других областей разработки. Кроме того, в ближайшем будущем мы планируем перевести нашу систему в Open Source ― без обязательной привязки к TeamCity и PHPUnit ― наверняка она кому-нибудь пригодится.

Без качественного тестирования невозможно разрабатывать и поддерживать крупный веб-сервис. На ранних этапах его развития часто можно обходиться только ручным тестированием по заданному тест-плану, но с появлением новых фич и увеличением количества тест-кейсов довольствоваться только им становится все сложнее и сложнее. В этой статье мы расскажем о том, как автоматизируем функциональное тестирование веб-интерфейса Яндекс.Почты с помощью Selenium WebDriver и Node.js.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.