С начала 2014 года российский фондовый индекс РТС снизился на 14% до 1120,2 пункта. При этом акции российских технологических гигантов «Яндекс» и Mail.Ru Group упали в цене гораздо сильнее — ценные бумаги этих эмитентов подешевели на 35% и 37% соответственно. Аналитики, опрошенные журналистами РБК заявили о том, что подобное снижение может быть обусловлено внешними факторами.

Есть ли в текущих условиях целесообразность в покупке акций этих компаний, и если да, то как это сделать?

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

В данной публикации я расскажу о том, как подружить Linux (ubuntu server 14.04) с Selenium Server v.2.43.1, о подводных камнях и зачем мне в облаке понадобился сервер для автоматических тестов.



Не так давно на Хабре была опубликована статья «Автотесты – барское дело». Я считаю, что в команде, где более 2-х разработчиков работают над одним проектом — это просто необоходимая вещь. Когда я работал один, обходился без тестов. Проект писался с нуля, код я знал как свои 5 пальцев. Компания росла очень быстро — в месте с ней и количество задач. Появились новые разработчики, тут то и начались проблемы. Пишем один функционал — отваливается другой. Не подумайте, такое случалось редко, но такие ошибки стоили дорого и нужно было с этим бороться. В это время я принял решение ввести автотесты в процесс разработки, о чем ни капли не жалею.

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

Для чего выдумывать все эти паттерны проектирования, принципы и методики? Разве не было бы проще обойтись без всего этого, а просто научить разработчиков хорошему дизайну? Или почему бы не формализовать этот процесс и ввести четкие количественные метрики, которые бы говорили, что одно решение однозначно лучше другого?

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

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

В свете последних событий, связанных со Skype (блокировка «старых» версий клиента, насильное обновление клиентов на всех платформах, откровенно сырая новая версия клиента для Linux), решил поделиться с сообществом успешным опытом использования Google Hangouts для коллаборации (командной разработки ПО, парного программирования) и написать универсальное руководство (tutorial, how-to) для Debian/Ubuntu Linux, а также Mac OS X и Windows, собрав всю необходимую и полезную информацию воедино.

Эта статья для тех, кто в поиске полноценной альтернативы Skype для большинства современных платформ и в первую очередь для Linux.

Предлагаю вашему вниманию первую часть перевода книги «Mature optimization» Карлоса Буэно о принципах оптимизации высоконагруженных проектов.

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

Книгу стоит прочесть, если вы:

1. Хотите повысить производительность своего проекта, но не знаете с чего начать.
2. Хотите повысить производительность своего проекта, но боитесь все сломать.
3. Не знаете о подводных камнях оптимизации производительности.
4. Давно хотели настроить мониторинг проекта, но не уверены что именно стоит мониторить.
5. У вас есть система мониторинга, но она не сообщает о проблемах заранее.

Что было до этого?

В статье нет прямых ссылок на наш продукт и даже его скриншотов. Да, я все еще боюсь НЛО.



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

С тех пор, как в институте появился предмет маркетинг, я прочёл несколько десятков книг, полезных для проект-менеджеров, стартаперов и руководителей компаний. Лучшие я собрал в небольшую библиотеку и хочу рассказать о них вам. Все эти книги заслуживают внимания и будут вам полезны. О многих вы уже слышали, часть упоминалась на Хабре, но, надеюсь, вы откроете для себя нечто новое из тех 22-х книг, о которых хочу рассказать.

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

Хотите узнать, как на просторах интернета убеждать людей и получать от них желаемое?

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

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

Вы доверяете своей команде?
Я доверяю. Но проверяю.
В этой статье я расскажу о том, как меня кинул один из участников нашей команды, попытавшись увести людей и заказчиков. И как мы оставшейся частью команды выправили ситуацию.

Про fail2ban написано уже много, в том числе и на хабре. Эта статья немного о другом — как сделать защиту им еще надежнее и о еще пока неизвестных в широких кругах новых функциях fail2ban. Добавлю сразу — речь пойдет пока про development branch, хотя уже долго проверенный в бою.

Краткое вступление

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

Уязвимость Shellshock (CVE-2014-6271) по масштабности и последствиям для всемирной сети и подключенных к ней устройств можно сравнить только с печально известной Heartbleed, которая была обнаружена весной этого года. Такое название получила уязвимость в командном интерпретаторе Bash, который используется во всевозможных модификациях и дистрибутивах Linux, Unix, Apple OS X (включая новейшую версию OS X Mavericks), а также Android. Уязвимости присвоен наивысший — 10-й уровень опасности, при этом уязвимыми являются все версии интерпретатора, включая новейшую 4.3.



Основную опасность Shellshock представляет по той причине, что он позволяет удаленно выполнить код на уязвимой ОС (исполнять необходимые атакующим команды интерпретатором). При этом с точки зрения эксплуатации уязвимости, это сделать довольно просто. Сам Bash привлекается к использованию в CGI-скриптах (что и позволяет осуществлять удаленную эксплуатацию), которые работают на веб-серверах и не только, например, с использованием компонента cgi_module. Одна из вредоносных программ, которая доставляется атакующими на скомпрометированный сервер обнаруживается AV-продуктами ESET как Linux/DDoS.M.

Вдруг, кто-то не знает. Предлагаю попробовать совместить контекстное меню в браузерах FF/Chrome:

и

С их списками поисковых машин и расширить эти списки:



В результате должен получиться «кроссайтовый» поиск без copy-paste самым коротким способом. Это не реклама плагина контекстного поиска _{(я не автор плагинов, упомянутых далее)}, а скорее реклама новой привычки.

17 сентября 2014 года состоялся выпуск Popcorn Time версии 0.3.3 — программного обеспечения с открытым исходным кодом предоставляющего пользователю простой и понятный интерфейс для потокового просмотра фильмов и сериалов по протоколу BitTorrent.
На Хабре уже не раз упоминали Popcorn Time и попытки закрытия проекта (Popcorn Time: самая удобная программа для просмотра торрентов, Разработчики Popcorn Time исчезают один за другим, Popcorn Time закрылся из-за «угрозы юридических преследований и закулисных махинаций», MPAA добилась удаления форков Popcorn Time с GitHub), но Popcorn Time по прежнему жив и активно разрабатывается. Кому интересно что нового привнесла версия 0.3.3 — добро пожаловать под кат.

Многие используют фильмы с субтитрами, чтобы слушать речь и одновременно читать. Хочу предложить альтернативу — слушать аудио книги и читать их текст с подстрочным переводом и доступом к каждой отдельной фразе. Они доступны онлайн на сайте BookTitres.com .

Самое интересное

Уже доступные для чтения книги вы можете найти в разделе "Слушайте и читайте" на сайте. Книга "Хоббит" закончена — это 11 часов аудио и 13800 фраз. Пройдя её полностью, вы ощутите заметное улучшение своего английского. Особенно, если будете повторять за чтецом каждую фразу. От других книг в основном сделаны несколько первых глав. Если хотите продолжения — ответьте на опрос и укажите желаемую книгу.

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

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

Первая часть перевода тут.

После прочтения Google's AngularJS Guidelines, у меня создалось впечатление о его незавершённости, а ещё в нём часто намекали на профит от использования библиотеки Closure. Ещё они заявили, «Мы не думаем, что эти рекомендации одинаково хорошо применимы для всех проектов, использующих AngularJS. Мы будем рады видеть инициативу от сообщества за более общий стайлгайд, применимый как для небольших так и крупных проектов».

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

В 2008 мы с партнёром закончили обучение по специальности «компьютерная инженерия» в университете в Аргентине.

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

Поэтому, когда мы делали Project eMT, сравнительный поисковик для Латинской Америки, мы решили работать по-другому: без менеджеров проектов. Через шесть лет у нас в команде было 34 инженера из Чили, Бразилии, Мексики и Колумбии, и мы всё ещё работаем без использования традиционных структур и рабочего графика, а наш ежегодный рост составляет 204%.

Перед тестированием всегда стояли и стоят две задачи – помочь команде поддерживать высокий уровень качества разработки и делать это, не задерживая весь процесс. И это справедливо не только для наших проектов в Яндексе, где мы работаем над очень большим количеством сервисов. Часто основная задача и вовсе формулируется как увеличение скорости тестирования при сохранении должного уровня качества. Скорость процесса разработки, приверженность ценностям частых и быстрых релизов – это основополагающие факторы для успеха любого продукта. У команды больше возможностей маневра, команда быстрее находит и исправляет ошибки, быстрее получает фидбек. Как же ускоряться, не теряя качества, как достичь дзена непрерывной доставки изменений?



Сегодня мы покажем, что Continuous Delivery — это просто и весело! А пользу от него можно получить, встроив его даже частично. Мы в тестировании Яндекса уже несколько лет используем подобный подход для наших библиотек с открытым исходным кодом — Allure Framework или Yandex QATools. Процесс прост, значительно масштабируем и может применяться как для огромных команд из одного человека, так и для маленьких командочек из десятков человек. А самое главное — весь инструментарий доступен в Open Source!

Кстати, до 30 сентября можно подать заявку и поступить в нашу Школу автоматизации процессов разработки в Питере. Обучение в ней бесплатное и будет состоять не только из курса лекций — обязательным этапом станет командная работа над учебным проектом.

А теперь вернёмся к теме. Представьте картину: уютное рабочее место, вы пишете код, добавляете юнит-тесты и отправляете изменения в систему контроля версий, а через пару часов они «выезжают» на боевые сервера. И все при этом работает.

Пролог

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

В моем случае, в качестве frontend сервера, стоит nginx и формат access-лога имеет вид:

log_format main '$remote_addr — $remote_user [$time_local] "$host" "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" -> $upstream_response_time';

Что на выходе дает что-то вроде такой строки:

188.142.8.61 — - [14/Sep/2014:22:51:03 +0400] «www.mysite.ru» «GET / HTTP/1.1» 200 519 «6wwro6rq35muk.ru» «Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.191602; .NET CLR 3.5.191602; .NET CLR 3.0.191602» "-" -> 0.003

1. tail -f /var/log/nginx/nginx.access.log | cut -d ' ' -f 1 | logtop

Позволяет получить общую картину: распределение уникальных IP, с которых идут запросы, кол-во запросов с одного IP и т.д.
Самое ценное — что все это работает в режиме реального времени и можно мониторить ситуацию, внося какие-либо изменения в конфигурацию (например просто забанить ТОП 20 самых активных IP через iptables или временно ограничить географию запросов в nginx через GeoIP http://nginx.org/ru/docs/http/ngx_http_geoip_module.html).