Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



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

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

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

Часто, при разработке сервисов, нужно понимать какие данные отправляются в другой сервис, а возможность перехватить траффик есть не всегда. И как раз для того, чтобы отлавливать подобные запросы, существует проект requestb.in, позволяющий собирать запросы по определённому урлу и отображать их в веб-интерфейсе. Написанием подобного же приложения мы и займёмся. Чтобы немного упростить себе задачу, возьмём за основу какой-нибудь фреймворк, например Martini.

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

Предлагаю читателям «Хабрахабра» перевод публикации «ExecutorService — 10 tips and tricks».



Абстракция ExecutorService была представлена еще в Java 5. На дворе шел 2004 год… На секунду – сейчас Java 5 и 6 больше не поддерживаются и Java 7 готовится пополнить список. А многие Java-программисты по-прежнему не в полной мере понимают как работает ExecutorService. В вашем распоряжении множество источников, но сейчас я хотел бы рассказать о малоизвестных тонкостях и практиках по работе с ней.

Когда я начинал писать на node.js, я ненавидел две вещи: все популярные шаблонизаторы и огромное количество callbacks. Я добровольно использовал callbacks, потому что понимал всю силу событийно-ориентированных серверов, но с тех пор в JavaScript появились генераторы, и я с нетерпением жду день, когда они будут имплементированы.

И вот этот день наступает. На сегодня генераторы доступны в V8 и SpiderMonkey, имплементация следует за обновлениями спецификации — это заря новой эры!

Уважаемые читатели! Представляю вашему вниманию перевод методологии создания веб-приложений The Twelve-Factor App от разработчиков платформы Heroku. Мои комментарии скрыты спойлерами по ходу статьи.

Введение

В наши дни программное обеспечение обычно распространяется в виде сервисов, называемых веб-приложения (web apps) или software-as-a-service (SaaS). Приложение двенадцати факторов — это методология для создания SaaS-приложений, которые:

• Используют декларативный формат для описания процесса установки и настройки, что сводит к минимуму затраты времени и ресурсов для новых разработчиков, подключенных к проекту;
• Имеют соглашение с операционной системой, предполагающее максимальную переносимость между средами выполнения;
• Подходят для развертывания на современных облачных платформах, устраняя необходимость в серверах и системном администрировании;
• Сводят к минимуму расхождения между средой разработки и средой выполнения, что позволяет использовать непрерывное развертывание (continuous deployment) для максимальной гибкости;
• И могут масштабироваться без существенных изменений в инструментах, архитектуре и практике разработки.

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

Благодаря популярности CSS фреймворка Bootstrap, для него разработали массу различных дополнений. Даже сейчас вы можете использовать Bootstrap практически для любой задачи при разработке и оформлении вебсайта.

Для статьи я подобрал наиболее полезные дополнения «на все случаи жизни».

Memcached — система для кэширования объектов в памяти, которая работает очень быстро. Использование Memcached может значительно увеличить скорость работы Rails-приложения с минимальными затратами.

Предварительные условия

Предполагается, что в вашей системе уже установлены Ruby on Rails и Memcached. Если это не так, то вам помогут ссылки, приведенные ниже:

• Как установить Ruby on Rails в Ubuntu 12.04 LTS (Precise Pangolin) с RVM (прим. переводчика: на русском можно почитать здесь)
• Как установить и использовать Memcache в Ubuntu 12.04 (прим. переводчика: на русском можно почитать здесь)

Также предполагается, что у вас есть запущенное Rails-приложение, которое вы планируете оптимизировать с помощью Memcached.

Набор библиотек для разработки CMS медиа издания практически ничем не отличается от любого другого приложения. На примере приложения для Ленты и Ведомостей мы решили прокомментировать выбор каждой библиотеки. Описание составлено в формате обсуждения каждого гема.

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

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

Предпосылки

Информацию об авторизованном пользователе я решил хранить в sessionStorage, копируя её при запуске приложения в $rootScope. Также по рекомендации авторов UI Router я храню в $rootScope значения объекты $state и $stateParam, для удобного доступа. Информацию же о доступе к тому или иному состоянию можно передавать через блок data при описании самого состояния. Поскольку в моем приложении везде закрыт доступ, я решил идти от обратного и добавлять значение noLogin = true для состояний, которые не требуют авторизации, например страницы ввода логина, восстановления пароля или регистрации.

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

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

UPD (13 марта 2015): Заменил несколько плагинов на более актуальные + решил проблему с импортом CSS файлов внутрь SCSS

Я занимаюсь в Яндексе продуктовой безопасностью и, кажется, сейчас самое время подробнее, чем уже было на YaC, рассказать на Хабре о том, как мы внедряем TLS.

Использование HTTPS-соединений является важной частью безопасного веб-сервиса, так как именно HTTPS обеспечивает конфиденциальность и целостность данных на этапе передачи их между клиентом и сервисом. Мы постепенно переводим все наши сервисы только на HTTPS-соединение. Многие из них уже работают исключительно по нему: Паспорт, Почта, Директ, Метрика, Такси, Яндекс.Деньги, а также все формы обратной связи, имеющие дело с персональными данными пользователей. Яндекс.Почта уже больше года даже обменивается данными с другими почтовыми сервисами по SSL/TLS, поддерживающими это.



Все мы знаем, что HTTPS — это HTTP, завернутый в TLS. Почему TLS, а не SSL? Потому что принципиально TLS — это более новый SSL, при этом название нового протокола наиболее точно характеризует его назначение. А в свете уязвимости POODLE можно официально считать, что SSL больше использовать нельзя.

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.

Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

JavaScript бесспорно стал незаменимым инструментом для разработчиков фронтенда. Сейчас сфера его применения расширяется на другие области, такие как серверы и микроконтроллеры. Этот язык программирования выбрали престижные университеты, чтобы обучать студентов основам информатики.

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

• Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
• Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
• Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
• Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
• Нужно ли использовать техники вроде PJAX или TurboLinks?
• Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?

Двадцать пять лет назад IBM представила генеральный план восстановления контроля над рынком PC. В ноябре 1987 года в магазины отправились первые дискеты с OS/2 версии 1.0. Microsoft разрабатывала ее вместе с IBM и в случае успешной реализации этих планов мир был бы совсем иным. И мир уже начал меняться.

Сейчас о OS/2 обычно вспоминают только в связи с той ролью, которую она сыграла в промышленной войне, окончившейся триумфальной победой Microsoft. На момент выпуска OS/2 в Microsoft работало 1800 человек, меньше, чем сейчас работает в ливерпульском телемагазине QVC. Microsoft даже не была крупнейшим производителем программ для PC. Но всего через несколько лет компания стала не только крупнейшим игроком отрасли, но и одной самых дорогих компаний в мире; один лишь слух о выходе Microsoft в новую нишу вызывал панику у существующих игроков.

Согласно традициям нашего издания я вернул старые программы к жизни и оценил OS/2 с современной точки зрения. Но гораздо интереснее вновь задать иной вопрос: могла ли IBM победить? Если именно OS/2 стала причиной поражения Синего Гиганта, то смогли бы они остановить Microsoft с помощью более хитрых планов? Давайте вернемся в те времена, когда мир еще не знал слов «платформа» и «экосистема» и вспомним, как выглядела отрасль информационных технологий в середине 1980-х.

Вот уже полтора года я зарабатываю фрилансом на бирже oDesk. За это время у меня накопилось много материалов по данной теме. В данном топике я собрал все в одну статью и адаптировал для аудитории хабра.

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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

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

Представьте: Вы — веб-разработчик, который только недавно освоил Ruby on Rails. И тут Ваш первый проект подходит к стадии, когда его нужно выложить в интернет.
Вы, конечно, можете залить его на Heroku, но тамошние цены немного кусаются. Остается только купить VPS, настроить его и выложить проект туда.
«Что может быть проще? Найду какой-нибудь гайд, да следаю всё по нему» — подумаете Вы. Вот только гайдов, которые не просто выкладывают команды, но и объясняющие, что эти команды делают, — единицы, да и те используют уже устаревшую вторую версию Capistrano.

Поэтому я решил написать свой гайд, в котором постараюсь подробно рассмотреть:

• Первичную настройку сервера
• Установку и настройку nginx (с модулем PageSpeed), postgresql, redis
• Установку rvm, rails
• Настройку гема foreman для управления процессами Вашего приложения
• Настройку сервера Unicorn
• Настройку гема Capistrano (v3.1) для автоматизации деплоя

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

Если у вас или у ваших клиентов почтовый ящик на mail.ru, будьте готовы к неприятностям.

Немного истории

Исторически сложилось так что почта mail.ru особо не пользовалась популярностью среди ИТ-шников и технарей, как и сама компания в целом. Но в последнее время компания изменилась в лучшую сторону, ребята собрались и сделали отличный почтовый сервис, перешли на HTTPS, даже успешно перевели почту на UTF-8. Недавно вот еще «Облако» сделали бесплатное на 1ТБ, и даже изменили к нему лицензионное соглашение. Ну и много всего у них происходит хорошего. Но

«не будем говорить о плохом, а лучше сделаем»

 цитаты великих людей :)

Вернемся в настоящее

Все администраторы у кого есть «сайт / блог / форум» наслышаны о проблемах с доставками писем в ящики для пользователей mail.ru, я их не оправдываю, ведь в большинстве случаев у них плохо настроен MTA, нет DKIM подписей, нет правильной PTR-записи, и все их письма «успешно» валятся в спам. («успешно» без сарказма). Но команда антиспама решила не останавливаться на таких примитивных проверках как валидные цифровые подписи DKIM, обратные записи PTR, «трастовость» домена и исходящего сервера и многое другое что используют бесплатные сервисы с устаревшей антиспам системой (eg. Yandex, Google, Yahoo), команда антиспама отказалась от этих проверок, и начала использовать настоящую магию!

Если вы являетесь rails-разработчиком, то вы наверняка слышали про Unicorn, http-сервер, способный одновременно обрабатывать множество запросов.

Для обеспечения параллельности Unicorn использует создание множества процессов. Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.

Это здорово, т.к. нам тяжело быть уверенными, что наш код является потокобезопасным. Если мы не можем быть уверены в этом, то ни о параллельных веб-серверах, таких как Puma, ни даже об альтернативных реализациях Ruby, реализующих параллелизм, таких как JRuby и Rubinius, не может быть и речи.

Поэтому Unicorn предоставляет нашим rails-приложениям параллельность даже если они не потокобезопасны. Однако, это требует определенной платы. Rails-приложения, запускаемые на Unicorn’е требуют гораздо больше памяти. Не обращая никакого внимания на потребление памяти вашим приложением, вы можете в итоге обнаружить, что ваш облачный сервер перегружен.

В этой статье мы рассмотрим несколько способов использования параллельности Unicorn'а, при этом контролируя количество потребляемой памяти.