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

Что мы будем рассматривать в данной статье?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие

Первый прототип (например, игры в новой для вас нише) часто делается «на коленке» из палок и самизнаетечего. Причем палки, как правило, тоже из этого самизнаетечего. И на то есть несколько причин.

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

Забегу вперед и расскажу, что сейчас DAU в наших проектах около 1,5 млн. Но так было не всегда.

Arrays, Collections: Алгоритмический минимум

Массивы и списки

Недавно на собеседовании в крупную компанию на должность Java разработчика меня попросили реализовать стандартный алгоритм сортировки. Поскольку я никогда не реализовывал самописные алгоритмы сортировки, а пользовался всегда готовыми решениями, у меня возникли затруднения с реализацией. После собеседования я решил разобраться в вопросе и подготовить список основных алгоритмов сортировки и поиска, которые используются в стандартном пакете java — Java Collections Framework (JCF). Для этого я изучил исходники Oracle JDK 7.80 (UPD: добавлена ссылка).

В самом обобщенном виде результат изучения представлен на рисунке. Подробности — в основном тексте.



Рисунок 1. Методы Arrays, Collections и реализуемые ими алгоритмы

Аникин Денис (danikin, Mail.Ru)

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

Базы данных – это хранилище, более структурированное, чем файл, и обладающее рядом некоторых фич, которых у файла нет.



Там можно делать запросы, там есть транзакции, индексирование, таблицы, устойчивые, более-менее надежные хранилища. На самом деле, базы данных – это более удобно, чем файлы.

Игра на bash'е с поддержкой мультиплеера, миф или реальность?



Истина где-то тут. Разоблачительный текст далее.

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

В нашем проекте PT Application Inspector реализовано несколько подходов к анализу исходного кода на различных языках программирования:

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

Наш цикл статей посвящен структуре и принципам работы модуля сигнатурного поиска (PM, pattern matching). Преимущества такого анализатора — скорость работы, простота описания шаблонов и масштабируемость на другие языки. Среди недостатков можно выделить то, что модуль не в состоянии анализировать сложные уязвимости, требующие построения высокоуровневых моделей выполнения кода.

К разрабатываемому модулю были, в числе прочих, сформулированы следующие требования:

• поддержка нескольких языков программирования и простое добавление новых;
• поддержка анализа кода, содержащего синтаксические и семантические ошибки;
• возможность описания шаблонов на универсальном языке (DSL, domain specific language).

В нашем случае все шаблоны описывают какие-либо уязвимости или недостатки в исходном коде.

Весь процесс анализа кода может быть разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат;
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена первому этапу, а именно: парсингу, сравнению функциональных возможностей и особенностей различных парсеров, применению теории на практике на примере грамматик Java, PHP, PLSQL, TSQL и даже C#. Остальные этапы будут рассмотрены в следующих публикациях.

Продолжаем серию материалов «Как сделать веб-студию эффективной и начать зарабатывать?» В предыдущем материале мы разобрали, как оптимизировать бизнес-процессы студии, связанные с документооборотом, который необходим для обеспечения контракта.

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

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



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

Вступление

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

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

Введение

Динамические веб приложения (SPA, Single Page Applications) становятся все более популярными. Их использование позволяет упростить и ускорить разработку и поддержку за счет следующий преимуществ:

• не требуется server-side рендеринг;
• сайт — это набор статических файлов (html, js, css, images, fonts), которые лежат на CDN;
• нет затрат на масштабирование frontend;
• код frontend локализован в одном проекте. (Раньше часть кода была на server-side, часть в frontend.);
• уменьшение затрат на разработку backend (только API);
• уменьшение нагрузки на backend (только API запросы);
• возможность вместо собственного backend использовать сервисы типа (https://scaphold.io), микросервисы, lambda.

Из популярных библиотек для SPA хочется отдельно выделить ReactJS. Его использование позволяет создавать сложные веб приложения быстро и просто, сохранить скорость разработки на большой базе кода, избежать регрессионных ошибок при добавлении новых функций.

Большой нерешенной проблемой SPA является их полная несовместимость с веб краулерами поисковых систем (индексация сайтов) и социальных сетей (sharing в соц. сетях). На текущий момент краулеры не выполняют на своей стороне javascript и поэтому не могут получить содержимое SPA в виде html кода. В 2015 году Google официально отказался от поддержки выполнения javascript кода на своей стороне.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

Оглавление

0. Подготовка к работе
1. Введение
2. Загрузка ресурсов [Вы тут]
3. Создание игрового мира
4. (wip) Группы
5. (wip) Мир физики
6. (wip) Управление
7. (wip) Добавление целей
8. (wip) Последние штрихи

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

Как и в прошлых статьях, не пропускайте комментарии в коде.

Полный код, написанный в этой статье, вы найдете в Github репозитории с тегом part-2.

Приступим!

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

Нам, например, круглосуточно требуется мониторить более 46 000 метрик на более чем 500 серверах в 6 дата-центрах и 4 странах, а DAU игры War Robots стабильно переваливает за 1 500 000 человек.

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

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

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

Тема моего доклада — то, как мы запускали в продакшн микросервисы на достаточно нагруженном проекте. Это некий агрегированный опыт, но поскольку я работаю в компании «M-Tех», то давайте я пару слов расскажу о том, кто мы.

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

В 2014 мы с друзьями решили создать настолько крутые инструменты веб-дизайна, насколько это вообще возможно. Мы создали UI kits, Admin Dashboards, Templates и Plugins.

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



С точки зрения доходов, если не брать во внимание Черную пятницу с ее распродажами (которая помогла нам удвоить прибыль ноября 2016 года), мы выросли примерно до $ 22 000 выручки в месяц. Часть ее уходит на оплату комиссии по партнерской программе, НДС, налога поставщиков и другие траты. В результате на данный момент мы имеем около $17,000 ежемесячной чистой прибыли.
Сегодня я хочу поделиться с вами, как мы создавали свои продукты и как немного раскрутили этот побочный бизнес.

Мы рады объявить результаты соревнования «Акселератор Медиа». В его рамках авторы и редакторы представляли на конкурс статьи по теме «Бизнес в эпоху новых медиа».

В этой статье я хотел бы поделиться своим опытом создания SaaS-сервиса на базе LAMP стека, Postio и доведения сервиса до состояния, когда он стал приносить 3 700 долларов ежемесячно (до обрушения рубля было почти 7 000). Сразу надо сказать, что эта история не имеет ничего общего с инвесторами, с золотой лихорадкой Кремниевой долины и с какой-то сверхсовременной технологией. Просто незамысловатая история от независимого разработчика о создании прибыльного SaaS-сервиса, который может сделать любой. Этот веб-сервис был сделан для внутреннего рынка России, поэтому я перевёл всё на английский и в доллары для удобства (пожалуйста, обратите внимание, что это перевод моей статьи, которая изначально была написана для англоязычной аудитории). Но, с другой стороны, этот опыт является довольно универсальным и может быть применён везде. По сути, это инструкция по созданию проектов такого рода.

Три года назад я решил заняться SMM, и самым простым способом сделать это показалось запустить свою собственную группу в какой-нибудь нише и попытаться развить её. Facebook был уже, мягко говоря, довольно конкурентным на тот момент, поэтому я запустил свою тестовую группу на базе «ВКонтакте». Я выбрал очень популярную нишу, потому что всё, что я хотел, — это научиться, а не доминировать на рынке.

Наверное, я должен немного отвлечься и сказать, что VK.com имел и до сих пор имеет процветающую «экосистему» таких групп, которая приносит прибыль их владельцам. Это — своеобразный рынок, который Facebook прикрыл уже давно. И этот базар является прекрасной средой для обучения и экспериментов.

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

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

Однако микросервисы являются не таким уж простым и универсальным решением. В частности, модели предметной области, транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. В результате разработка транзакционных бизнес-приложений с использованием микросервисной архитектуры является довольно сложной задачей. В этой статье мы рассмотрим способ разработки микросервисов, при котором эти проблемы решаются с помощью паттерна проектирования на основе предметной области (Domain Driven Design), Event Sourcing и CQRS.