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

Обзор русскоязычной художественной литературы, за последние два года. В список попали самые лучшие работы по моему вкусу в 2017-2018 году.
Здесь предыдущая статья, за 2010-2016 года.

Короткий список

Финикийский торговец Принцип неопределенности
Авторская аннотация: Философско-приключенческий фанфик о попаданце во вселенную «Звёздных войн». История о поиске своего места в чужой и незнакомой вселенной. Учитывая дуализм этой вселенной, её мистицизм и глубокую символичность, как и извечный конфликт Орденов и сторон Силы – это наилучшие декорации для рассматриваемых вопросов. В таких случаях пишут — «осторожно философия». Также читателя ждут контрабанда, космос и всё, что с ними связанно.
Автору удалось описать огромный высокотехнологичный мир. Мир Звездных Войн, эта — галактика с многотысячелетней историей. Практически все произведения и авторы по SW не смогли передать ощущения действительно огромного мира, ведь это серьезнейшим образом влияет на экономику, торговлю, культуру и культурные различия.
Второй особенностью являются философия, и ее тут действительно много. Автор глубоко углубляется в темы мышления, цели и смысла жизни.
Минусом является объем, да и иначе быть не могло, огромный мир, глубокое пережевывание идей. Автор запрягает медленно, и уносит далеко далеко.

MaxKitsch Большой Дом
Ядреная смесь юмора и хоррора. Фанфик на Простоквашино, с использованием оккультизма. Оккультизм тут хорош, с десятками ссылок и хорошей жутью. И все это в исполнении персонажей из Простоквашино. Вышло шикарно.
Поначалу, это отличный юмор, ты сидишь и смеешься, смеешься и тут БАМ! вместо ожидаемой смехучки, качественный хоррор. Диссонанс рвет эмоции и дает интересные ощущения.

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

1. Тип уборки
2. Навигация
3. Производители
4. Управление со смартфона

Как только вы начали бояться своей технологии, вскоре появятся новые причины для страха.

Петля страха затягивается так:

1. Небольшие правки приводят к непредсказуемым, пугающим или дорогостоящим последствиям.
2. Мы начинаем бояться изменений.
3. Мы стараемся делать все правки как можно более мелкими и локальными.
4. Кодовая база наполняется заплатками, исключениями и особыми случаями.
5. Страх усиливается.

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



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

Николай Сивко (NikolaySivko) в своем докладе на RootConf 2018 рассказал о тонких и пока не очень популярных аспектах балансировки нагрузки:

• когда повторять запрос (retries);
• как выбрать значения для таймаутов;
• как не убить нижележащие серверы в момент аварии/перегрузки;
• нужны ли health checks;
• как обрабатывать «мерцающие» проблемы.

Под катом расшифровка этого доклада.

Недавно LINBIT выпустили свое новое решение для оркестрации и управления множеством DRBD-массивов.

К примеру у вас может быть несколько нод и у каждой будет собственный LVM или ZFS пул в котором LINSTOR будет автоматически создавать новые тома и реплицировать их между нодами используя DRBD-протокол.

LINSTOR поддерживает thin-provisioning, снапшоты и много других интересных штук.
Это решение хорошо подойдет для виртуальных машин и контейнеров.

Когда приложение было монолитным и вдруг, раз, стало распределённым, в формулу вычисления доступности добавляется ещё одна неизвестная — сетевая. Из-за проблем с вызовами между компонентами, приложения часто валятся и начинают дрыгать ножками. А выяснение причин нестабильной работы распределённого приложения — та ещё задачка. Дополнительную неразбериху в структуру приложения вносит условный kubernetes, который по своему внутреннему усмотрению может произвольно распределять условные поды по условным нодам. Пишу «условный», потому что на месте kubernetes может быть и Swarm и Openshift и прочие и прочие.

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

Разработка программного обеспечения и эксплуатация уже реализованного софта (например, приложения) находится в особом положении в контексте анализа расходов. Особенность в том, что типичный цикл производства товара и его продажи не существует в ИТ отрасли. Вместо этого мы имеем фактически бесплатно размножаемые копии продукта, но высокие издержки на само создание этого продукта и его поддержание. По этой причине экономика ИТ компании сильно отличается от экономики “свечного завода” или магазина.

Давайте детальнее рассмотрим ситуацию с издержками в ИТ компании. К сожалению не получится обобщить все ИТ компании в одну схему. Я попробую выделить несколько распространенных схем работы и рассмотреть их. Возможно кто-то из читателей добавит еще какие-то схемы, интересные для рассмотрения.

Я хочу выделить следующие типы ИТ компаний, хотя этот список, конечно, не полный:

1. Аутсорсинговая разработка — команда пишет софт под заказ и под требования заказчика. В дальнейшем софт чаще сопровождается самим заказчиком. Отношения фокусируются только на разработке и по сути продажи часов работников (как в форме прямой продажи часов, так и fix price, когда риски изменения сроков проекта ложатся на разработчика)
2. Вендор B2B софта — команда пишет софт для дистрибуции B2B, осуществляет внедрение, поддержку и разработку нового функционала.
3. B2C продукты — сюда я отнесу все компании, занимающиеся созданием B2C приложений и продуктов, работающих с массовым клиентом.
4. Провайдеры инфраструктуры — хостеры, дата центры, серверные мощности, сервисы обработки транзакций и т.п.

Какие расходы имеет первый тип компании? Давайте разделим на разные кучки расходы по основным типам, которые не зависят от предприятия:

Метод принципиальных переговоров был разработан Роджером Фишером, Биллом Юри и Брюсом Паттеном и опубликован в виде книги в 1981 г. Эта книга была переведена на 25 языков и стала бестселлером. Вниманию читателей предлагаю ее конспект, который может быть интересен не только различного рода менеджерам и людям, профессионально занимающимся ведением переговоров, но также ITшникам, домохозяйкам, бизнесменам, а также всем, кто хочет научиться побеждать в переговорах «по-гарвардски», но до прочтения всей книги пока не дошел.

Я хочу рассказать о такой штуке как DPDK — это фреймворк для работы с сетью в обход ядра. Т.е. можно прямо из userland писать\читать в очереди сетевой карты, без необходимости в каких либо системных вызовах. Это позволяет экономить много накладных расходов на копирования и прочее. В качестве примера я напишу приложение, отдающее по http тестовую страницу и сравню по скорости с nginx.

«Simplicity is prerequisite for reliability» by Edsger Dijkstra

Пролог

Графы — столь наглядная и проста для понимания структура данных, еще со времен Леонарда Эйлера заставляла ломать умы человечества над разнородными задачами, вроде того как можно пройти по всем семи мостам Кёнигсберга, не проходя ни по одному из них дважды или как разъездному посреднику, найти самый выгодный маршрут.

Компания Netflix одержима вопросом доступности сервисов. Мы уже не раз рассматривали его в нашем блоге и рассказывали, как нам удаётся достичь своих целей. Мы используем circuit breakers, лимиты параллельных подключений, тестирование с помощью намеренного внедрения ошибок (chaos testing) и многое другое. Сегодня мы представляем вам ещё один инновационный подход, который существенно повышает стабильность приложения при экстремальных нагрузках и позволяет избежать каскадных сбоев в работе сервисов — адаптивные лимиты параллельных подключений. Больше не нужно тратить силы, чтобы определить лимиты параллельных подключений, позволяющие системе поддерживать небольшое время отклика. В рамках этого анонса мы также выкладываем в открытый доступ простую Java-библиотеку с возможностями интеграции для сервлетов, управляющих программ и gRPC.

Пару месяцев назад я постила сводную таблицу-сравнение под названием «Лучшая страна для программиста». В ней было 9 стран. Статья была горячо воспринята и в силу некоторых ошибок в ней, и в силу желания читателей получить сходные данные по другим странам. Я обещала доделать таблицу. Сказано – сделано.

В этой статье 22 страны сравниваются по следующим параметрам:

1. Зарплаты программистов
2. Налоги
3. Стоимость жизни (аренда жилья, коммунальные услуги, продукты, транспортные расходы)
4. Развитость рынка IT
5. Социальное обеспечение

Привет Всем! Я недавно запустил на GitHub проект JavaScript Algorithms and Data Structures, который содержит примеры классических алгоритмов и структур данных написанных на JavaScript с объяснениями, примерами и ссылками для дальнейшего изучения (в частности на соответствующие YouTube видео).

Основная задача проекта — помочь программистам в изучении и применении алгоритмов и сделать это на JavaScript-е.

Материал основан на статье Simo Ahava «customTask — The Guide».

Примерно год назад (в 2017) произошло обновление JS библиотеки Universal Analytics. Обновление принесло с собой такую замечательную штуку как customTask. Данная фича, в рамках Google Tag Manager, позволяет выполнять любые «задания» до отправки хита в Google Analytics.

В оригинальной статье Simo Ahava подробно описывает механизм работы customTask и делится полезными примерами. Также можно ознакомиться с официальным мануалом по библиотеке Universal Analytics, где дано описание всех тасков с очередностью их выполнения.


Порядок выполнения заданий analytics.js

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

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



Зачем мы этим занялись?

Компания Альфа-Лизинг (дочка Альфа-Банка) за 2017 год сильно выросла: размер бизнеса увеличился в 5,5 раз, общее количество сотрудников более чем в 2 раза, а ИТ-департамент разросся с 10 до 50 человек. При этом мы понимали, что в большой компании каждому нужны прозрачные и понятные KPI, которые мы либо придумаем сами, либо их навяжут нам извне.

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

Главный вопрос этого поста: какие же изменения претерпевает agile коммуникация (и скрам, в частности), натягиваясь на распределенные команды?

Для этого, давайте сначала классифицируем коммуникацию:

1. стратегические митинги (планирование / ретроспектива)
2. ежедневную синхронизацию (в том числе daily standups)
3. прояснение рабочих вопросов

Давайте добавим еще одно измерение! Если попробуем наложить вышеприведенную классификацию на географию, то появляются дополнительные срезы для вышепреведенного:

«Принципу Анны Карениной» посвящено немало научных публикаций и даже отдельная статья в Википедии. Применим к ИТ и программированию? А может он уже работает против вашего проекта?

Мы в компании любим и уважаем Apache Kafka, и в ознаменование выхода ее недавнего обновления я решил подготовить статью про ее производительность. А еще рассказать немного про то, как выжать из нее максимум.

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

Предыстория

В двух словах — вступление о мониторинге и аппеляционности убеждений. Как многим известно, я сопровождаю Riemann — инструмент обработки потоков событий для мониторинга распределенных систем. В моей книге, посвященной мониторингу, я использовал Riemann, как основной инструмент для изучения новых подходов и паттернов мониторинга, и описал архитектуру whitebox-мониторинга (с выборочным blackbox-мониторингом), используя push модель.

Чтобы понять, о чем я вообще веду речь, объясним некоторые концепции. Blackbox-мониторинг отвечает за проверку внешних характеристик сервисов или приложений: возможно ли подключиться к открытому порту сервиса, возвращаются ли корректные данные или код ответа. Примером blackbox-мониторинга может служить ICMP-запрос и подтверждение получения ответа.

В свою очередь, whitebox-мониторинг сфокусирован на том, что происходит внутри сервиса или приложения. Приложение, обладающее соответствующим инструментарием, возвращает состояние самого себя или внутренних компонентов, результат выполнения транзакций или событий. Эти данные отвечают на вопрос “как работает приложение”, а не на вопрос “работает ли приложение”. Whitebox-мониторинг передает события, логи или метрики в специальный инструмент для мониторинга или предоставляет информацию наружу для последующего сбора инструментом мониторинга.