Данный пост переродился из ответа на вопрос «Как искать работу за границей?», заданный на Тостере. Когда ответ, подогреваемый интересом читателей, достиг размеров полноценной публикации, я решил отредактировать формат ответа и перенести её сюда.

Дисклеймер

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

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

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

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

За последние сутки сотни новостных сайтов (клац и тыц) перепечатывают одну интересную новость, рассказывающую про обнаружение очередных зловредных приложений в Google Play. На этот раз adware показывало назойливую рекламу каждый раз при разблокировке устройства и было установлено на миллиарды миллионы телефонов и планшетов. К счастью, антивирусная компания Avast вовремя обнаружила угрозу и приложения были удалены.

Под катом я расскажу свою версию событий: как я вычислял и искал adware в Google Play, декомпилировал код adware sdk, можно ли дождаться ответа от поддержки Google, почему мобильные антивирусы бесполезны и как им удается на горячем инфоповоде сделать себе хорошую бесплатную рекламу.

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

Компьютер всегда прав

Самая раздражающая ситуация в программировании — когда код верный, но не работает. “Да тут три строчки, блин, просто негде ошибиться! Наверное баг! Пойду потрачу три дня на изучение баг-репортов компилятора/интерпретатора/фреймворка...”. Возникает чувство, будто компьютер над вами издевается!

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

За более чем десять лет моих активных поисков и применения GTD/PM-методик в своей, без малого, десятилетней практике фрилансера и предпринимателя, до меня наконец дошло — серебряной пули нет. Многие знали об этом всегда, мне же понадобились годы. Когда для тебя одновременное количество проектов измеряется не одним десятком. Когда ты прокрастинатор настолько, что даже прокрастинируя этой статьей от работы умудряешься прокрастинировать прокрастинацию чтением писем Лейбница и готов прокрастинировать рекурсивно. Когда ты перфекционист шестого разряда и программист-романтик, то до последнего надеешься, что есть универсальное лекарство. Но его нет…

Было бы счастье, да… многолетние поиски философского камня принесли и свои плоды. У меня накопился большой сундук различных подходов, которыми я хочу поделиться.

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

Статья будет полезна тем, кто хочет:

— в общих чертах понять, что такое авторское право (но лучше обратиться к юристу);
— подобрать свободную лицензию для своего проекта;
— разобраться, что нужно писать в шапке файла исходного кода.

Немного воды

Уже более полутора лет назад прошла новость о том, что «DARPA намерено совершить революцию в машинном обучении». Конечно, DARPA всего лишь выделила деньги на исследовательскую программу, связанную с вероятностным программированием. Само же вероятностное программирование существует и развивается без DARPA достаточно давно, причем исследования ведутся, как в ведущих университетах, таких как MIT, так и в крупных корпорациях, таких как Microsoft. И вовсе не зря DARPA, Microsoft, MIT и т.д. обращают пристальное внимание на эту область, ведь она по-настоящему перспективна для машинного обучения, а, может, и для искусственного интеллекта в целом. Говорят, что вероятностное программирование для машинного обучения будет играть ту же роль, что и высокоуровневые языки для обычного программирования. Мы бы привели другую параллель – с ролью Пролога, которую он сыграл для старого доброго ИИ. Вот только в Рунете по данной теме до сих пор можно найти лишь единичные ссылки, и то в основном содержащие лишь описания общих принципов. Возможно, это связано с тем, что потенциал вероятностного программирования еще только начал раскрываться и оно не стало основным трендом. Однако на что же способны или будут способны вероятностные языки?

Извиняюсь, если зря поместила пост в хаб космонавтики: к сожалению, хаба с названием «космос» или подобного не нашла. Так же извиняюсь за некоторое количество саморефлексии в трех следующих абзацах, но саморефлексия необходима, так как пост является критическим по отношению к нескольким ранее опубликованным, и за опечатки, которые наверняка присутствуют в моем посте (но будут исправляться по мере того, как я буду их замечать).

На написание своего поста меня сподвигла серия таких:

А Вы подключали телескоп к компьютеру?
Айтишник на отдыхе: а как насчет телескопа?
Айтишник на отдыхе: добавим немного астрономии?
Айтишник на отдыхе: прибамбасы к телескопу

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

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

Для затравки анекдот.
Приходит в магазин телескопов покупатель, и спрашивает:

— А можно у Вас купить телескоп за три тысячи рублей?
— Ну… можно, но линзы будут пластмассовыми, и лучше не стоит, возьмите вот лучше рефрактор за 6 тысяч. — Продавец показывает рукой на самый популярный среди школьников линзовый телескоп
— Хорошо, а можно купить телескоп за 25 тысяч? — Вопрошает покупатель
— Можно, — Отвечает продавец, показывая рукой на восьмидюймовый ньютон на EQ5 — это очень хороший телескоп для начинающих
— А в него можно увидеть плеяды сквозь облака? — спрашивает покупатель
— К сожалению, нельзя… — Качает головой продавец
— А есть телескоп за 100 тысяч? — Не унимается покупатель
— Да, вот — Продавец показывает на компьютеризированный и навороченный Nexstar 11SE
— А в него можно увидеть туманность Андромеды днём?
— К сожалению, нельзя, — качает головой продавец
— А зачем тогда он такой дорогой нужен?

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

«О каких граблях речь? Это же хобби! Им каждый занимается так, как ему нравится!» — Воскликнет скептик, и будет прав:
Например, ИТ-кам нравятся всякие высокотехнологичные жужжащие штуки, ну вот пускай и покупают мелкоскопчик с GoTo системой за ограниченный бюджет. Пусть мелкоскоп после наведения в точку на небе, где находится галактика «Игла» NGC 4565, такая красивая на фотографиях, со своими газопылевыми облаками не покажет ничего ни через окно кухни квартиры в центре Москвы, ни даже с застекленной и тёплой веранды дачи :) Главное, что мелкоскопчик жжужит, мигает красивыми красными огнями на пульте, и владелец оборудования доволен новым гаджетом и приощением к небу, сидя в тепле и комфорте, не так ли?

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

Когда-то я уже писала про то, как мне удалось постажироваться в Google в Швейцарии. Тогда же я обещала отчет о своей следующей стажировке — во второй раз в Googleplex в Калифорнии. И вот это время пришло — моя вторая стажировка подходит к концу, и мне есть что рассказать!: о)

Disclaimer: Мой личный опыт, как всегда, не претендует на универсальность.

Эта публикация рассказывает о том, как экономить время при разработке для Clojure и NodeJS, а также Bash скриптов, посылая текст из vim в REPL, c использованием tmux + vim + vim-slime. Также приводятся рецепты с nodemon.

Скорее всего, vim-slime сработает и для других интерпретируемых языков (Ruby / Python / PHP / Perl ...). vim-slime также работает со screen.
На хабре достаточно освещались и vim, и tmux. Я только хотел показать, что можно получить от их комбинации.
Добавление от Fikys: с Ruby работает.

Если вы знаете vim и tmux, и вам интересен только vim-slime — прыгайте сразу ко второй секции.

Вступление

Мы все стремимся быть производительными. После того, как код написан, мы хотим узнать, работает ли он и получить обратную связь. Мы придумали много способов ускорения обратной связи: статическое выведение типов при компиляции и в IDE, юнит-тесты, интеграционные тесты, REPL, LiveReload и т.д.

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

Я веб-разработчик. По работе и в своем проекте обычно я делаю фронтэнд и стыкующуюся с ним часть бэкэнда. В течении рабочей сессии я пишу PHP, phtml, Stylus, css, Coffeescript, Javascript, + sql запросики и пуши в гит; что обеспечивается связкой tmux и vim. Также есть пара маленьких проектов на CoffeeScript, для которых используется комбо tmux + vim + vim-slime + Coffeescript REPL. В проектной сессии увязываются Сlojure, CoffeeScript, Stylus; tmux + vim + vim-slime + Clojure REPL. Под катом я расскажу об трех сетапах для трех окружений.

Легендарный создатель цифровой криптовалюты Bitcoin общался с единомышленниками с адреса satoshin@gmx.com. К этому адресу были привязаны его аккаунты на нескольких форумах. К сожалению, последние события указывают на то, что контроль над этим адресом получил некто посторонний.

Администратор форума Bitcointalk.org вчера вечером получил странное письмо. Обратный адрес не подделан, письмо действительно отправлено c satoshin@gmx.com. В то же время текст ясно указывает, что его написал посторонний человек: «Майкл, пришли мне несколько монет, пока я не нанял снайпера». Такие шутки совершенно не в стиле Накамото.

Последнее время ни один пост от нашей компании не обходился без традиционного вопроса от читателей, «А когда же выйдет ваша кросс-платформенная C/C++ IDE?». И вот сегодня, наконец, мы готовы сказать: Public Early Access Program началась!



Если коротко: тут — скачать, здесь — почитать ознакомительную инструкцию, а под катом — подробности.

Мы не можем себе это позволить. Сколько раз за свою карьеру вы слышали такую фразу? Как правило, эти пять слов призваны напомнить собеседнику, что у компании просто не хватает на все денег. Хотя на самом деле в большинстве случаев деньги тут совершенно не при чем. Мы в этом убедились на собственном опыте, когда строили себе дом для Альфа-Лаборатории. Вот этот вот.





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

При этом практически все, разглядывая пуфики, супергероев на стенах и игровую, думают примерно одно и то же. Не исключено, что вы думаете так же, глядя на эти фотографии: «Ну, конечно, Альфа-Банк может себе такое позволить». Подразумевается, что в инновационную Альфа-Лабораторию вбуханы какие-то баснословные деньги.

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

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

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

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



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

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

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

Оглавление:

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

Эта заметка навеяна мелькавшими последнее время на хабре постами двух тематик — «интересные команды unix» и «как я подбирал программиста». И описываемые там команды, конечно, местами интересные, но редко практически полезные, а выясняется, что реально полезным инструментарием мы пользоваться и не умеем.
Небольшое лирическое отступление:
Года три назад меня попросили провести собеседование с претендентами на должность unix-сисадмина. На двух крупнейших на тот момент фриланс-биржах на вакансию откликнулись восемь претендентов, двое из которых входили в ТОП-5 рейтинга этих бирж. Я никогда не требую от админов знания наизусть конфигов и считаю, что нужный софт всегда освоится, если есть желание читать, логика в действиях и умение правильно пользоваться инструментарием системы. Посему для начала претендентам были даны две задачки, примерно такого плана:
— поместить задание в крон, которое будет выполняться в каждый чётный час и в 3 часа;
— распечатать из файла /var/run/dmesg.boot информацию о процессоре.

К моему удивлению никто из претендентов с обоими вопросами не справился. Двое, в принципе, не знали о существовании grep.



Поэтому… Лето… Пятница… Перед шашлыками немного поговорим о grep.

Многие уже слышали про колеса / wheels; рассказывать про них подробно не буду — на хабре были хорошие статьи. Опишу пошагово один (очевидный) способ использования колес на машине разработчика.

Все, кто устанавливал пакеты вроде numpy или scipy через pip знают, что это долго: компиляция может и десять минут занять, и двадцать, и тридцать. Среду для компиляции-то можно настроить (ну по крайней мере под mac и linux это не так сложно), но устанавливать такие зависимости в каждый virtualenv — то еще удовольствие. Можно, конечно, чай попить. Или виртуаленвы не использовать / использовать один общий.

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

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

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

Аннотация переводчика

Мой топик должен восполнить некий пробел в теме «Чем грозит Heartbleed простому пользователю», благодарю FFF за пост: habrahabr.ru/post/219151

Уязвимости клиентов никто не отменял. Но если топовые платёжные сервисы реагируют в течение суток, то как долго ждать обновлений от производителя смартфона или, скажем, «умного» ТВ? Нехороший сайт сможет запросто выпотрошить память клиента — недопатченного браузера, смартфона, планшета, слишком умного телевизора, видео- или игровой приставки, и т.д. Всякое устройство, способное загружать веб-страницы (включая ваш домашний Linux), и при этом обрабатывающее конфиденциальные данные — это цель, и порой на долгие годы.
Даю вам перевод статьи Роба Ванденбринка (Rob VandenBrink) целиком, это не заняло много времени.

Добрый день.

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

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

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

Почему? Maxifier представляет собой SaaS-продукт с клиентами в США, Бразилии, в нескольких странах Европы и в Японии, так что у нас около сотни серверов, раскиданных по всему миру. Для оперативной работы нам необходимо иметь удобный доступ к логам наших приложений и быстрый поиск ошибок в них в случае проблем на сторонних сервисах/api, появления некорректных данных т.д. Кстати, похожей системой сборки логов пользуются The Guardian (одни из наших клиентов).

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